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