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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XYTc0-0004e8-N1 for bitcoin-development@lists.sourceforge.net; Mon, 29 Sep 2014 05:35:04 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.106 as permitted sender) client-ip=62.13.148.106; envelope-from=pete@petertodd.org; helo=outmail148106.authsmtp.co.uk; Received: from outmail148106.authsmtp.co.uk ([62.13.148.106]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XYTby-0007kf-UD for bitcoin-development@lists.sourceforge.net; Mon, 29 Sep 2014 05:35:04 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s8T5YtbO052478; Mon, 29 Sep 2014 06:34:55 +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 s8T5YqNl010220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Sep 2014 06:34:54 +0100 (BST) Date: Mon, 29 Sep 2014 01:35:26 -0400 From: Peter Todd To: Alan Reiner Message-ID: <20140929053526.GA21446@savin.petertodd.org> References: <20140618001503.GA8360@savin> <20140619100909.GA3544@savin> <20140929023553.GA11877@savin.petertodd.org> <5428E053.7070601@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <5428E053.7070601@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 57c24b54-479a-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAsUC1AEAgsB AmIbW1JeU1l7XGY7 bA9PbARUfEhLXhtr VklWR1pVCwQmQhRl A3dfLEVydgVEen4+ ZEJrWnYVWUMpd0Iv R0pJEWoPNHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDODMj DxcaFjIjEFZNTiM/ ZwA8I1gHFU0NM0I0 eUUsQ0kZNBlwQgtD GktAGjQRZ0YIXGJk Fw5eVF5WDD1QCQZH OQEhJBNBGDAaQDdc CVANRRYVQxsfawkA VCxUVDYkB0QoIEQx fWV3 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [62.13.148.106 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XYTby-0007kf-UD Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [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 05:35:04 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 12:30:11AM -0400, Alan Reiner wrote: > On 09/28/2014 10:35 PM, Peter Todd wrote: > > 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. >=20 > Can't this be solved with a single update to the address format, > allowing a tx version number to be part of the address serialization?=20 > Then the sending software will apply that version to the payment tx. =20 > Of course, I'm not sure if allowing nodes to create transactions with > version numbers outside of their programming is safe. It seems like it > should be since we're talking about soft forks anyway, but there's > probably some subtleties I'm overlooking. Keep in mind that when a *wallet* - not a node - creates a transaction the scriptPubKeys in the transaction outputs have been specified by the receiver(s) and aren't executed until they are spent. Modulo sigops(1) there is absolutely no reason why the wallet should care what the contents of those scriptPubKeys are at all. This is particularly apparent when you remember that there may be multiple recipients of a transaction. If I'm paying Alice and Bob, who have specified that they want the transaction to have version number 2 and 3 respectively, now what? Do we take the highest of the two and constrain ourselves for how scripts are interpreted for all eternity? It just doesn't make very much sense. Meanwhile the man-hours of effort that would be required to implement that "one-time" address format change is huge - it took literally years for everyone to update their software to just support P2SH addresses. I'm working on a CHECKLOCKTIMEVERIFY implementation right now, and know of exchanges who would like to use it ASAP. Why make them wait years for everyone to upgrade? On that basis alone I think the question ought to be why should we use transaction version numbers to enable new opcodes rather than just enabling them globally based on block version numbers. 1) Satoshi implemented a per-block sigop limit to prevent blocks from causing an unreasonable number of signature checking operations, but rather than computing that limit based on the scripts actually executed, the limit is computed based on the contents of all scriptSigs and scriptPubKeys in the block. This is bizzare given that the contents of the latter are *not* executed, and the former misses the prevout scriptPubKeys that *are* executed. In short this means you can create a block that passes the sigop limit, yet executes millions of expensive signature operations by being filled with scriptSigs spending txouts with large numbers of sigops in their scriptPubKeys. P2SH improves on this situation somewhat by counting the sigops in redeemScripts towards the limit, but missed the opportunity to just count all sigops in all scriptSigs directly. --=20 'peter'[:-1]@petertodd.org 0000000000000000092e056ab9c5a3242bfa911ba9a0a8a3836bcd4b5fcab2f8 --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUKO+ZXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxNGJiNDc0ZTZhYTFhN2M2ZDFiNzUyOTdjOGIxOTliMzA0 NDMzNjdiZDUyMjc0OWQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfui0wf8CzOlnJHMAyriZWnMdwRc3aqd MBIPbRAq2JTICV1HKl4WgXKFMMyrMtBFD1wEQ9/K9EsK4KyjJTp0BoJgUn46+RBG 3QBywQzx1llzraWMbHVMKoC12H1tNeLgr0cXmiApvxrsSsT5oDoE2ructNCBP9zd OHKT1aSWcVoLj1AbsmY90qHOjCbfcePHB+SzNiteZkoXmCAmHVogDs6C+drwACdC HYxLaYvEA81weMOOMZsl4wAaU4s8j3l2rg65v/S9rCqxiRJ8se8CL+sST6w9QCWQ VkKVbEtuKoc1rW1m74+lJ8pjW4wr6bEKqL+DcFESBsofBIWVt6xM23XBDcZ9lQ== =lY8i -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5--