The LIFO priority ensures that an attacker working on a secret fork cannot change the coins he holds by shuffling change between accounts. A slight drawback of this approach is that stake is rounded down to the nearest integer number of rolls. However, this provides a massive improvement in efficiency over the follow-the-satoshi approach. While the rolls are numbered, this approach does not preclude the use of fungibility preserving protocols like Zerocash. Such protocols can use the same “limbo” queue technique. Motivation This procedure is functionally different from merely drawing a random address weighted by balance. Indeed, in a secretive fork, a miner could attempt to control the generation of the random seed and to assign itself signing and minting rights by creating the appropriate addresses ahead of time. This is much harder to achieve if rolls are randomly selected, as the secretive fork cannot fake ownership of certain rolls and must thus try to preimage the hash function applied to the seed to assign itself signing and minting rights. Indeed, in a cycle of length N = 2048, someone holding a fraction f of the rolls will receive on average fN mining rights, and the effective fraction received, f0 will have a standard deviation of √1√1−f. N f If an attacker can perform a brute-force search through W different seeds, 3 then his expected advantage is at most (√2log(W)√1−f)fN N f blocks. For instance, an attacker controlling f = 10% of the rolls should expect to mine about 205 blocks per cycle. In a secret fork where he attempts to control the seed, assuming he computed over a trillion hashes, he could assign itself about 302 blocks, or about 14.7% of the blocks. Note that: - The hash from which the seed is derived is an expensive key derivation function, rendering brute-force search impractical. - To make linear gains in blocks mined, the attacked needs to expend a quadratically exponential effort. 3 this is a standard bound on the expectation of the maximum of W normally distributed variable 12

A Self-Amending Crypto-Ledger White Paper - Page 14 A Self-Amending Crypto-Ledger White Paper Page 13 Page 15