Quote from: DeathAndTaxes on July 26, 2014, 09:11:32 PM

One recommendation would be to remove the section_ids (as the records are self describing) and instead add a value (in bytes) to the header with the offset to the first record of each type.

For example in your sample the offsets would be
0x01 = 4800000000
0x02 = 9F00000000
0x03 = BC00000000
0x04 = 2A01000000

Agreed. This makes the body of the file a contiguous list of claims but still allows for fast searching.

Quote from: DeathAndTaxes on July 26, 2014, 11:38:12 PM

Here is a good native multisig (vout:2) to use in your example instead of a fake one 14015bd586c0c7a28979ca294b114441f23bfc97be17cd6077b9e12e2709fec3:2.

Thanks. I'll update the example files when I make the other updates and after people have had a chance to comment.

By the way, do you think my requirement that the claims in snapshot.bin are sorted is overkill? I did it for two reasons: (1) to permit efficient searching, and (2) as part of making the snapshot file a deterministic output of the block number.

Also, the more I think about Smooth's suggestion to provide a Merkle-branch as part of the claim TX, the more I like it. It means that as long as one trusts that the Merkle root in the genesis block corresponds to that from a legitimate snapshot, he can verify any particular claim TX with just the TX itself (without looking anything up in snapshot.bin). The method seems more transparent, as it puts the onus on the claimant to provide proof (which gets mined when he is awarded his spinoff). It also simplies the genesis block requirement for spin-offs: only the MerkleRoot is needed (along with the bitcoin blockhash for SCV). I think this should be the recommended manner in which a spin-off verifies a claim, even though it increases the blockchain size if a large number of claims are eventually made.