Mr. Darkmatter,

See some of the reasons for why this distro mechanism is the *least bad one* in the post above
https://bt.irlbtc.com/view/563972.msg7676923#msg7676923

Can you elaborate on this?

Yes, this is of course THE QUESTION.

If spin-offs can be successful then there cannot possibly be a better target for a spinoff tracking clone than Ethereum.

I guess the answer to this is only known to DeathAndTaxes ... i.e. how alive is the code base behind the spinoff idea ?

Will there actually be an Aethereum at all ?

I am joining this bounty with 1 BTC

Smooth had an interesting idea that he posted to the aethereum thread. I'm cross-posting it here as it is relevant to the format for snapshot.bin.
 

A disadvantage of this approach is that, as you say, inner hashes are repeated.

Perhaps the two approaches can be combined.

A small snapshot.bin can be distributed, containing the outputs with the highest value or perhaps those somehow deemed "most likely" to be claimed (which might in part be a function of value, perhaps age, etc.). Those can be claimed by direct reference without a proof. For holders of the rest, a claim would need to be made using the (less space efficient) proof.

The blockchain-size implications on Smooth's proposal to hash the claim entries into a Merkle tree.  

D&T's work suggests that the UTXO set can be expressed as approximately 3 million unique claims.  To build the first row of the corresponding Merkle tree, each transaction would be hashed (e.g., by SHA256) into (e.g.) a 32-byte digest:  

Length of first row = 32 bytes  x  3x10^6 = 96 MB

The row above this one consists of half that number of hashes. Each entry is the hash of the 64-byte concatenation of the corresponding two hashes below it in the tree.  This process is continued until we arrive at the root hash:


The number of rows in the Merkle tree is given by:

    1 + ceiling (log₂ 3x10^6) = 23

A claim transaction that provided the complete Merkle-branch proof would be be ~23 rows long where each row (except the root) would contain 2 x 32-byte hashes.  So the additional overhead to provide the Merkle-branch claim proof would be approximately:

    Size of Merkle-branch claim proof ~= 23 x 2 x 32 bytes = 1.5 kbytes

If we imagine that 1% of the potential claimants make a claim, the blockchain would grow (due to storing the Merkle-branch claim proofs) by:

   0.01  x  3x10^6  x  1.5 kbytes = 45 MB

Similarly, if 10% or 100% of stakes were claimed, the blockchain would grow by 450 MB and 4.5 GB, respectively.  This means that if over a few percent of claims were made, the blockchain would be bigger than it would be if the flat snapshot.bin files was stored as the genesis block.  


Additional thoughts

Hashing the claim entries into a Merkle tree and requiring the claimant to provide the Merkle-branch proof increases the size of the blockchain should a large number of claims be made; however, the big benefit is that this seems to simplify the cloning process.  It means that the clones don't need to be aware of or manage snapshot.bin.  They just need to define a new type of claim TX that verifies the signature (either using FCV or SCV) and then follows the Merkle branch down to its root and compare that to the hard-coded Merkle root.  If the signature verifies and the Merkle branch leads to the hard-coded root hash, and if the claim has not already been made, then the claim TX is valid.  But will it be more difficult for the clones to verify that a particular claim hasn't already been made using this method?

Sorry that I haven't been active in the development.  This is more for "fun" and the development which pays the bills has been taking up most of my time.  

To expand on Peter's "to merkle or not to merkle" discussion
1) Peter, a merkle branch only need one hash per level not two (the other side is computed each level from the claim txn) and a single bit to indicate if the additional hash is on the left or right).  You also don't need to include the root hash for the same reason.  If that doesn't make sense I can go into detail but I will wait to avoid a long explanation on what might just be a simple oversight.  The size of a merkle branch (in bytes) for up to 32 levels would be: branch_size = (merkle_levels * digest_size)+4.

2) The larger claimset the more the overhead.   However this is not likely to have much of an impact due to the logarithm relationship between set size and number of branches.  Until we reach more than 4.19 million valid claims the merkle branch would only need 22 segments and using 160 bit hashes that would be 444 bytes.  If more than 32 levels are needed then the size of the branch increases another 4 bytes but the number of unique "claimants" in the UTXO would need to be more than 10x the current size before that happens.


3) Using a 160 bit hash would make the merkle branch smaller by a third.  Even smaller hash digest (100 to 128 bit) could be used but that only provides a minimal reduction in size.  The set is fixed so it can be guaranteed to be collision free.  A preimage attack against even a 100 bit reduced length hash is infeasible at the current time.  It may however make sense to benchmark the speed of various hash functions as there will be a large number of branch validation in bootstrapping nodes.   I know off the top of my head SHA-512 has much higher throughput than SHA-256 on most systems this is due to SHA-512 using 64 bit words.  NIST does rate SHA-2 to be used in "cutdown" digests (i.e. take left 128 bits) and there are no known security implications in doing so.

Thanks for the proposal and clarification Peter.  I prefer a multisig means of pledging with a time limit and am happy to go with that.  I did understand and to confirm, yes I am happy with the 'any spin-off' criterion, in that it may well be something other than Aetherium.

This is a "fun" project for me too.  I do think we are making good progress, however.


Yes, of course.  I've never coded a Merkle tree or used a Merkle branch so I missed the obvious fact that the other side follows from the claim TX.  What you just said makes perfect sense.  


Good point.  There's no need to use 256-bit hashes, so we can save space this way like you said.  



I am leaning towards the Merkle tree approach.  Let's see if anyone has any valid objections.  


Yes, that's what I was thinking too.  It does mean that the spin-off developer needs to include code to manage the ordered list of claimed claims (an additional requirement) but I think this is still easier than managing the full snapshot.bin file.