From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RsHlg-00058z-Hl for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 17:45:20 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=gmaxwell@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RsHlf-0003dy-Ka for bitcoin-development@lists.sourceforge.net; Tue, 31 Jan 2012 17:45:20 +0000 Received: by vbbff1 with SMTP id ff1so335701vbb.34 for ; Tue, 31 Jan 2012 09:45:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.67.229 with SMTP id q5mr11196070vdt.14.1328031914231; Tue, 31 Jan 2012 09:45:14 -0800 (PST) Received: by 10.220.151.200 with HTTP; Tue, 31 Jan 2012 09:45:14 -0800 (PST) In-Reply-To: <201201311651.02726.andyparkins@gmail.com> References: <201201311651.02726.andyparkins@gmail.com> Date: Tue, 31 Jan 2012 12:45:14 -0500 Message-ID: From: Gregory Maxwell To: Andy Parkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RsHlf-0003dy-Ka Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP16/17 replacement X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:45:20 -0000 On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins wrot= e: > Hello, > > Gulp. =C2=A0Am a little nervous about wading into this swamp. =C2=A0Howev= er, 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. >=C2=A0Surely 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=E2=80=94 Starting with the OP_CAT key combinations many mont= hs 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=E2=80=94 I don't think I can identify any particul= ar 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 t= hat 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=E2=80=94 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. > =C2=A0- Increase the version number in transactions to make a new transac= tion > =C2=A0 structure > =C2=A0- Dump the "scriptPubKey" field completely. =C2=A0Everything will b= e pay-to- > =C2=A0 script-hash in version2 transactions > =C2=A0- Replace it with "hashOfClaimingScript" > =C2=A0- 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=E2=80=94 at least not before a tim= e that the system is simply too big to make that kind of change.