From: Rusty Russell <rusty@rustcorp.com.au>
To: Tier Nolan <tier.nolan@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
	<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
	<87r3lyjewl.fsf@rustcorp.com.au>
	<CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
	<CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
	<CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
	<CAE-z3OXbUhsyzd=8hxzFAST9rEQyTg9whn+CMh92S0FMdLH4ug@mail.gmail.com>
	<CABm2gDo4f6bpJeobwRyoukKw9t=ApuRtHMYWpWFXjv9=K7aFyA@mail.gmail.com>
	<CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
	<CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com>
	<CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>
	<CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Fri, 18 Sep 2015 07:27:51 +0930
Message-ID: <87h9msiu8w.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and
	delay.
Precedence: list

Tier Nolan via bitcoin-dev <bitcoin-dev@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.