Quote from: emski on January 05, 2015, 09:27:22 pm

Does the following make sense:

Select first N blocks.
Create a snapshot of all unspent balances at N-th block.
Hardcode that snapshot in some future release that should fork the network at N+K-th block.
After the N+K-th block use the snapshot as input for any transaction (older clients will not work, but this happens with most of the updates anyway).

This should manually dust off the blockchain with a single update.

The bolded part is the hard part. You need to represent the entire state of the database snapshot using a single root hash. And every client, regardless of the platform they run on and the particular implementation of the client (what if they don't want to use LevelDB?), needs to be able to deterministically derive the same root hash given a particular snapshot consensus state of the database. This is why I linked to the Ethereum wiki page on Merkle Patricia trees.

Besides allowing the blockchain to be pruned and allowing a client to bootstrap to the present state more quickly by using a recent snapshot instead of the genesis, it also has the benefit of providing better lightweight client security.

C'mon, let's do this. Let's not let Ethereum have the superior technology in this case.

So you cant hardcode few hundred megabytes of snapshot data in any format and read it on any platform?
Is it that hard ?

Setting default delegate approval is pretty high centralisation. This is something everyone is trying to avoid... I hope...

On the other hand there is indeed a voter apathy and this makes the "income" of some of the core devs uncertain. The solution to this serious problem shouldn't degrade the qualities of the system. 

A possible (but still controversial) approach to solving this might be:
On the client first startup bring up a list of ALL slates and/or voting window. The user should be able to choose zero, one or more slates/delegates before continuing work. Of course there could be debates about slate/delegate ordering but this should push more people to vote. There could even be an explanation text why voting for core developer's slates is beneficial.

In any case I do NOT think there should be any default selected slates/delegates.

http://www.tomshardware.com/news/german-minister-fingerprint-cloned-photos,28268.html

I am aware of the issues.  It is frustrating me as well.

@bytemaster What happened to the PR that was going to review all your non-technical forum posts ?

As a delegate should have a backup machine IMHO that should not be necessary as you can simply switch over to the backup machine by enabling/disabling block production.

@xeroc Have you changed your mind given the recent events ?

@everyone Is the proposal in OP useful ?

1. (priority 1) Core functionality -> resolve all forking issues.
2. (priority 1) User protection and information -> Implement safety features in the clients that prevent the user from transacting if that user is on a fork. (Apart from delegate participation there could be queries to some seed nodes in order to see if the client is on the same fork). The users must be clearly informed about the state of the network.
3. (priority 1) Polish all the clients!
4. (priority 3) Lightweight client. Mobile application.
5. (priority 3) Spread the word about Bitshares.

EDIT1:Added 3. (polishing of clients)

Quote from: bytemaster on December 17, 2014, 09:52:51 pm

Quote from: emski on December 17, 2014, 08:16:33 pm

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain.

Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.

Why don't you just try to theoretically explain the delegate backup system first?