From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XYQoH-0001pR-5a for bitcoin-development@lists.sourceforge.net; Mon, 29 Sep 2014 02:35:33 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.93 as permitted sender) client-ip=62.13.148.93; envelope-from=pete@petertodd.org; helo=outmail148093.authsmtp.net; Received: from outmail148093.authsmtp.net ([62.13.148.93]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XYQoF-00073K-Dr for bitcoin-development@lists.sourceforge.net; Mon, 29 Sep 2014 02:35:33 +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 s8T2ZODA098716; Mon, 29 Sep 2014 03:35:24 +0100 (BST) 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 s8T2ZKEH044730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Sep 2014 03:35:23 +0100 (BST) Date: Sun, 28 Sep 2014 22:35:53 -0400 From: Peter Todd To: Gavin Andresen Message-ID: <20140929023553.GA11877@savin.petertodd.org> References: <20140618001503.GA8360@savin> <20140619100909.GA3544@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 4370c86c-4781-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAsUC1AEAgsB AmIbW1deU1h7W2A7 bA9PbARUfEhLXhtr VklWR1pVCwQmQhRl BHRlJ2FycwFBe34+ ZEBnWnUVWEd9dRV1 RB1JEWoOZHphaTUb TRJbfgVJcANIexZF O1F6ACIKLw51Pz4z GA41ejw8IzhbLzxQ TwcRGBo0TFlDGSY3 QBwPBn0mG0FNWz86 KQcvIUIdG0BZLEgo KlomXxoeLhoYBxdF fQkNHyZCbxYbSi4i HUtGXUNWMSZmXS5a DhQyLldSHzhfQWJW A1ENc0s0K2tZSiBO Uz9WTiwqCkNmZioA 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: 1XYQoF-00073K-Dr Cc: Bitcoin Dev Subject: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions') 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: Mon, 29 Sep 2014 02:35:33 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote: > RE: soft-forks bumping version numbers: >=20 > Yes, we have consensus that is the way we will do it. I should probably > turn https://gist.github.com/gavinandresen/2355445 into an informational > BIP. That gist is mistaken. To see the problem consider the "re-define OP_NOP1 to be OP_Q_CHECKSIGVERIFY" example. It says "Transactions that use the new opcode are given a new version number." The problem is in the definition of "use" Lets first suppose that the evaluation of a scriptPubKey was done according to the transaction version # of the transaction creating the scriptPubKey. This is technically feasible as the UTXO set records the version of the transaction creating the txout. However if I create a P2SH address whose redeemScript makes use of a new opcode - say the new OP_Q_CHECKSIGVERIFY - non-upgraded clients sending funds to that address will be creating scriptPubKeys whose contents can be spent by anyone. Not exactly ideal! This can be solved by upgrading the address format at the same time to let senders know they must send the funds in a transaction with an increased version number, but obviously needing new addresses for every new opcode defeats the purpose of P2SH. On the other hand suppose scriptPubKey evaluation is done according to the version of the transaction spending the scriptPubKey. This is insecure as now transaction outputs using the new opcode can be trivially spent by just spending them in a transaction with the previous version number; the OP_Q_CHECKSIGVERIFY is evaluated as OP_NOP and checks nothing. If txouts be spent only by transactions with nVersion >=3D the nVersion of the transaction spending them, but again you're forced to upgrade the address format for every new opcode. Interestingly this shows that the common assertion that "P2SH should have been done by upgrading the tx version #" is in fact wrong except for the fact that P2SH required an address format upgrade anyway; doing that for future opcode upgrades would be a mistake. With the above in mind the "Relax IsStandard rules for P2SH transactions" pull-req(1) is incomplete as it doesn't blacklist usage of the upgradable NOPx opcodes. After a future soft-fork redefining a NOPx opcodes' behavior non-upgraded nodes will accept and mine transactions that may now be invalid, the latter creating invalid blocks and thus false confirmations. I've created a pull-req to fix this issue by specifically blacklisting the NOPx opcodes if they are executed: https://github.com/bitcoin/bitcoin/pull/5000 Secondly the "Blockchain Rule Update Process" gist above should be rewritten to say that new opcodes will be enabled for all scripts by the block nVersion upgrade mechanism; scripts must never depend on a NOPx opcode being executed least they be rendered unspendable by a future upgrade. By comparison BIP62 proposes that the transaction version # be increased to indicate that the sender wants anti-malleability rules to be applied. This is an appropriate usage of tx version numbers as in this case the person creating the transaction wants the anti-malleability rules applied; the creator of the scriptPubKey's being spent does not care whether or not they are spent in a transaction that is or is not malleable. Equally the new owners of the txouts being created don't in general care how they were created. (modulo certain special-purpose protocols where they would have the transaction anyway) 1) https://github.com/bitcoin/bitcoin/pull/4365 --=20 'peter'[:-1]@petertodd.org 000000000000000005ec432fd4c506119a0123a028911fa3981bcde0568b66ab --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUKMWFXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNDdkYTlkODNhNjBjZDA4OWM4ODJhMWE0OTZlMzc1OGY0 ZGI5NTJjN2ZmYWRmNDEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu6YAf+JPnlOV74k+yd895nwsplYEiM H/2YXqWHkOn2h5yNNlUNggFEzGgWWt8KmkhLuVkQ5U83V+i1cHmoODyC7JUgMPNh gjRhdfM/iSISEy1nVwOtiqKYmb+Ts/oyTJqGScsoSSPd9emUvGu7IKd7ECPai3IA 8ifPVWyoGeiWpL648mpZdLBRh73SxqjChEPUtEFdCnXTz6Y+1eqqZC4uLydX4hfA Bl+TCp/tDz2aQnQQ/W9ibsPvh+AJ4RYwY/sm0BNMm8JsjmCZ2iNfp4rZZ+jn4q2g u8NakwjB18B1msAStHEU+oKTwOIYVqR0HJaDGiRe08gOrF/6fEEpqu1S5nYwBg== =9qqP -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--