Subject: Re: [bitcoin-dev] Bitcoin XT Fork

From: Peter Todd <[email-masked]>
Date: Thu, 20 Aug 2015 02:13:34 -0700

On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote:
> >
> > It is just that no one else is reckless enough to bypass the review process
> 
> 
> I keep seeing this notion crop up.
> 
> I want to kill this idea right now:
> 
>    - There were months of public discussion leading to up the authoring of
>    BIP 101, both on this mailing list and elsewhere.
> 
>    - BIP 101 was submitted for review via the normal process. Jeff Garzik
>    specifically called Gavin out on Twitter and thanked him for following the
>    process:
> 
>    https://twitter.com/jgarzik/status/614412097359708160
> 
>    https://github.com/bitcoin/bips/pull/163
> 
>    As you can see, other than a few minor typo fixes and a comment by sipa,
>    there was no other review offered.
> 
>    - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
>    request, to invoke the code review process:
> 
>    https://github.com/bitcoin/bitcoin/pull/6341
> 
>    Some minor code layout suggestions were made by Cory and incorporated.
>    Peter popped up to say there was no chance it'd ever be accepted ..... and
>    no further review was done.

No, I said there was no chance it'd be accepted "due to a number of
BIP-level issues in addition to debate about the patch itself. For
instance, Gavin has never given any details about testing; at minimum
we'd need a BIP16 style quality assurance document. We also frown on
writing software with building expiration dates, let alone expiration
dates that trigger non-deterministically. (Note how my recently merged
CLTV considered the year 2038 problem to avoid needing a hard fork at
that date)"

Of course no further review was done - issues were identified and they
didn't get fixed. Why would we do further review on something that was
broken whose author wasn't interested in fixing even non-controversial
and obvious problems?

The process is to do review, fix issues identified, and repeat until all
issues are fixed.

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d