On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins <andypark...@gmail.com> wrote: > Hello, > > Gulp. Am a little nervous about wading into this swamp. However, it seems > to me that the debate has veered into the personal and away from the
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. The differences between BIP16/BIP17 are technically obscure, everyone who is well versed in the issue (with the potential exception of Luke). There is broad consensus among the involved technically minded parties over just about all of it. Luke has been maintaining an opinion tracker page: https://en.bitcoin.it/wiki/P2SH_Votes reflecting the views of core developers and people who've been technically involved enough to have an informed opinion. > Surely if there are objections to both suggestions, that another > solution might be better? There is always a different color that the shed could be painted. Expecting absolute consensus on the _best_ way forward is an unreasonable standard, especially if you're going to invite the opinions of many people. Depending on how you count we have considered a good two dozen options in this space— Starting with the OP_CAT key combinations many months back, and including many variants of the current ideas. The BIPs only represent the "final" surviving ideas. In particular, BIP16 was the isolated consensus path forward that came out of the discussions about the concerns that BIP12 was too computationally powerful— I don't think I can identify any particular person as the author of the BIP16 idea. At the the time BIP16 became a BIP only Luke was actively objecting to it. Though his hard work and tireless (...unstoppable dogmatic) promotion he's managed to build a workable alternative, and it now has some support other than himself. This, however, doesn't constitute a material schism. > this idea up for my traditional mailing-list roasting but with the hope that As always, asbestos underwear is required. > If the change is going to be a big one anyway and will require a client > upgrade why not... 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. > - Increase the version number in transactions to make a new transaction > structure > - Dump the "scriptPubKey" field completely. Everything will be pay-to- > script-hash in version2 transactions > - Replace it with "hashOfClaimingScript" > - Add an "unsignedParameters" array. 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") 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 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. ------------------------------------------------------------------------------ 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
