Re: [Bitcoin-development] BIP16/17 replacement

[Andy Parkins <andyparkins@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2743 bytes --]

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.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]