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 andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
