[bitcoin-dev] An implementation of BIP102 as a softfork.

Peter Todd pete at petertodd.org
Wed Dec 30 14:19:55 UTC 2015

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.


> 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

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

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/38a95928/attachment.sig>

More information about the bitcoin-dev mailing list