snapshot.bin file sizeThe initial distribution of wealth in a spin-off is based on a snapshot of the unspent outputs of the bitcoin blockchain at a particular block height. Bitcoin holders can claim their wealth by producing the appropriate bitcoin-signed message and broadcasting it to the spin-off network. The Snapshot for a spin-off is similar to the Genesis Block for Bitcoin. It becomes part of the definition of the coin, is downloaded with the binaries, and has its file hash hardcoded in software. The purpose of this post is to estimate the minimum size of this file, and to open a discussion regarding the appropriate file format.
John Ratcliff has done a nice job preparing blockchain statistics
here. In late December 2013, he reported that:
- 2.4 million addresses contained a non-zero balance,
- 1.15 million of those addresses contained less than 1000 bits.
The file snapshot.bin must contain an entry for each of the
N addresses that hold a claimable balance. The "balance record" for address
n must contain the following 28 bytes:
pubkeyhash_n (20 bytes) balance_n (8 bytes)
Depending on whether the unspent dust outputs are included, the size of snapshot.bin can be no less than
filesize of snapshot.bin >= 28 x 2,400,000 = 67 MBytes (including unspent dust)
filesize of snapshot.bin >= 28 x 1,250,000 =
35 MBytes (dust removed)
My inclination (although I am flexible here) is to remove dust less than 1000 bits (100,000 satoshis) by calculating the balance of the
nth address as follows
balance_n = 100000 * floor(sum_of_unspent_outputs_assigned_to_address_n / 100000);
The file format for snapshot.bin can be very simple. I propose a small header that specifies the blockheight when the snapshot was taken, and miscellaneous other header data, followed by a contiguous list of balance records, expressed in binary, and sorted canonically so that a particular balance can be found in O(log
2N) time. I haven't decided how to deal with balances claimable with more complex redemption scripts such as multisig, and I am looking for advice here. In any case, the more complex cases can be appended to the end of the snapshot file as shown.
// File header:
version (1 byte) blockheight_of_snapshot (4 bytes) num_bytes (4 bytes) header data // total of num_bytes of header data
// Wealth data for regular addresses:
tag1=0x4E (1 byte) num_bytes (4 bytes) pubkeyhash_1 (20 bytes) balance_1 (8 bytes) … pubkeyhash_N (20 bytes) balance_N (8 bytes) // total of num_bytes of records here
// Wealth data for multisig addresses:
tag2=0xA7 (1 byte) num_bytes (4 bytes) data format to be determined
// Wealth data for other types of outputs with unusual redemption scripts:
tag3=0xB4 (1 byte) num_bytes (4 bytes) data format to be determined
Is there anyone interested in volunteering to write a simple program to parse the blockchain and construct the file snapshot.bin (for an arbitrary blockheight)? I think for the time being and to get started quickly, you can leave out the multisig balances for now.
