[bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Rusty Russell rusty at rustcorp.com.au
Thu Sep 17 21:57:51 UTC 2015


Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> The advantage of enforcing the rule when 75% is reached (but only for
> blocks with the bit set) is that miners get early notification that they
> have implemented the rule incorrectly.    They might produce blocks that
> they think are fine, but which aren't.

Indeed.  There are three believable failure possibilties:

1) You don't implement the rule at all, and don't set the bit.
2) You implement it and set bit, but think some valid block is invalid.
3) You implement it and set bit, but think some invalid block is valid.

#1 is by far the most common, and the proposal is designed so they
*always* get ~2 weeks warning before those drop to SPV security.

Assuming the mining majority isn't buggy (otherwise, it's arguably not a
bug but a feature!) #2 is the worst case: some miners fork off and don't
rejoin.

So there is a slight advantage in doing this early: those buggy miners
no longer contribute to the 95% threshold.  But that's outweighed IMHO
by:

1) We would need another delay at 75% so #1 nodes can upgrade.

2) The new feature won't be exercised much before impliciation, since
   it's useless before then, so it might not find bugs anyway.

In conclusion, I'm not convinced by the extra complexity.

Cheers,
Rusty.


More information about the bitcoin-dev mailing list