[Bitcoin-development] BIP16/17 replacement

Andy Parkins andyparkins at gmail.com
Wed Feb 1 09:46:31 UTC 2012

On 2012 January 31 Tuesday, Gregory Maxwell wrote:

> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.

Well that's good that there is no real problem.

> It does not, in fact— Yes, it requires a client update to make use of
> the new functionality, but old nodes will happily continue to validate
> things.  It's hard to express how critical this is distinctly.
> Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that
> things were done right, the validate them for themselves.
> A breaking change of the kind you suggest is not something that would
> be considered lightly, and this is certainly not justified for this.

To be brutally honest; I don't see how the BIP16/17 changes are any less 
"breaking" than what I proposed (I'm not trying to push mine; forget it, the 
last thing bitcoin needs is another proposal if there is no real argument).  
I will agree the changes are smaller for BIP16, since the transactions are 
left as they are.

If BIP16/BIP17 were being honest they would too increase the version number 
of the transaction structure.  The new transaction type is not supported by 
the old client... that's a break.  My argument would be that once you're 
going to break the old clients anyway, go the whole hog and fix some other 
stuff as well.

> If we ever were to scrap the system, I think we very much would do
> something like what you describe here... and as much has been
> documented:
> https://en.bitcoin.it/wiki/Hardfork_Wishlist
> (see "Elimination of output scripts")

I'm glad I wasn't talking rubbish then.
> But, to be clear, this stuff is pretty much fantasy. I'm doubtful that
> it will ever happen, doubtful that we can get the kind of development

Me too.  Which is a shame; as it means we're locked into quite a fair number 
of earlier decisions that will now never be changed.

> resources required to pull off a true breaking change in a way that
> people would actually trust upgrading to— at least not before a time
> that the system is simply too big to make that kind of change.

Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm 
just not familiar enough with the conventions.  As far as I understand; no 
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not 
going to pass the IsStandard() test.

I'd repeat: the reasonable thing to do is to increase the version number of 
the transaction structure to indicate that they are being processed 
differently from old transactions.

Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/1fd55c20/attachment.sig>

More information about the bitcoin-dev mailing list