On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev wrote: > As a first impression, I think this proposal is intellectually interesting, > but crufty and hackish and should never actually be deployed. Writing code > for Bitcoin in a future in which we have deployed a few generalized softforks > this way sounds terrifying.
<snip> > It might be possible to make that a bit simpler with recursion, or by doing > subsequent generalized softforks in a way that doesn't have multi-levels-deep > block-within-a-block-within-a-block stuff. Still: ugh. Your fear is misplaced: it's trivial to avoid recursion with a bit of planning. For instance, if Bitcoin was redesigned to incorporate the forced fork concept, instead of block headers committing to just a merkle root, they could instead commit to H(version + digest) For version == 0, digest would be a merkle root of all transactions. If the version was > 0, any digest would be allowed and the block would be interpreted as a NOP with no effect on the UTXO set. In the event of a major change - e.g. what would otherwise be a hard-forking change to the way the merkle root was calculated - a soft-fork would change the block validity rules to make version == 0 invalid, and verison == 1 blocks would interpret the digest according to the new merkle root rules. Again, version > 1 blocks would be treated as NOPs. A good exercise is to apply the above to the existing Bitcoin ecosystem as a soft-fork - it certainely can be done, and done right is technically very simple. Regardless of how it's done - existing Bitcoin compatible or clean sheet redesign - you get the significant safety advantages soft-forks have over hard-forks in nearly all situations where you'd have to do a hard-fork. OTOH, it's kinda scary how this institutionalizes what could be seen as 51% attacks, possibly giving miners significantly more control over the system politically. I'm not sure I agree with that viewpoint - miners can do this anyway - but that has made people shy away from promoting this idea in the past. (previously it's been often referred to as an "evil" soft-fork) -- 'peter'[:-1]@petertodd.org 00000000000000000831fc2554d9370aeba2701fff09980123d24a615eee7416
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
