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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XljXO-0001QX-Q3 for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 19:13:06 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.102 as permitted sender) client-ip=62.13.148.102; envelope-from=pete@petertodd.org; helo=outmail148102.authsmtp.net; Received: from outmail148102.authsmtp.net ([62.13.148.102]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XljXN-0005Nm-CA for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 19:13:06 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sA4JCwbT016762; Tue, 4 Nov 2014 19:12:58 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA4JCrXe069313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Nov 2014 19:12:56 GMT Date: Tue, 4 Nov 2014 14:13:13 -0500 From: Peter Todd To: Pieter Wuille Message-ID: <20141104191313.GA5493@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 957dcbc0-6456-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgYUFloCAgsB AmIbWl1eUV97XGU7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm0F fG1cOkxycQxFeX0+ ZEZlVngVVUF9IRUv EU5JE2kDY3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E GUpKFDMjVUMYWzgp IlQ9IUQdBFpZL109 K1ItVElw X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XljXN-0005Nm-CA Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP62 and future script upgrades 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, 04 Nov 2014 19:13:07 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 04, 2014 at 05:29:46AM -0800, Pieter Wuille wrote: > one of the rules in BIP62 is the "clean stack" requirement, which > makes passing more inputs to a script than necessary illegal. >=20 > Unfortunately, this rule needs an exception for P2SH scripts: the test > can only be done after (and not before) the second stage evaluation. > Otherwise it would reject all spends from P2SH (which rely on > "superfluous" inputs to pass data to the second stage). >=20 > I submitted a Pull Request to clarify this in BIP62: > https://github.com/bitcoin/bips/pull/115 >=20 > However, this also leads to the interesting observation that the > clean-stack rule is incompatible with future P2SH-like constructs - > which would be very useful if we'd ever want to deploy a "Script 2.0". > Any such upgrade would suffer from the same problem as P2SH, and > require an exception in the clean-stack rule, which - once deployed - > is no longer a softfork. >=20 > Luke suggested on the pull request to not apply this rule on every > transaction with nVersion >=3D 3, which indeed solves the problem. I > believe this can easily be generalized: make the (non mandatory) BIP62 > rules only apply to transaction with strict nVersion=3D=3D3, and not to > higher ones. The higher ones are non-standard anyway, and shouldn't be > used before there is a rule that applies to them anyway - which could > include some or all of BIP62 if wanted at that point still. >=20 > Opinions? I agree with Luke: make the rules only apply to transactions with a strict nVersion=3D=3D3. If we want to extend that later we can do so in another soft-fork. On another topic, I'm skeptical of the choice of nVersion=3D=3D3 - we'll likely end up doing more block.nVersion increases in the future, and there's no reason to think they'll have anything to do with transactions. No sense creating a rule that'll be so quickly broken. --=20 'peter'[:-1]@petertodd.org 000000000000000002986604739bc94cc42d5c6adf75186e80ba3dbb501a076d --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUWSVEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZTVhMjcwMTMyOTRhNDg4ZGRiNTQyNmE1YzYzZDZmN2E4 ZmVlMDg1YTQxZWZlM2QvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfthWgf+J9UtIQkRs+kxo3z92oubS33j RT2AFDvhgNSdMtoF3uu3b3bg86rptRQgz1hnZLFn99yOAcnh7jiO9hptT5nC5RTx 4LO8C5ZvXnrDs92grVqJB/9KGjZbDX5EZuKS1Bh9Pejy7dhinoBazuvFojDYjSLc g4oef04RIaVox+QOQ7mjWOsg6TFfc0nH4aK/8pz6gL9nItqAElEENrbpGfWimz9O Ez9XeYaTjrFaioC6Un6BJmsvSe/tHPBqZMjU7rz7TnAH0qcRMMXT8WauEEkH+n1g kO6fJwv3R4GuKS4aamu/QnI3Apcau++s4WdmdJ8CnhK1bPXbcXgC1qO+pPGadQ== =eR2j -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--