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 1V3ian-0002Jh-82 for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 08:14:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.111 as permitted sender) client-ip=62.13.148.111; envelope-from=pete@petertodd.org; helo=outmail148111.authsmtp.net; Received: from outmail148111.authsmtp.net ([62.13.148.111]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V3ial-00019i-DO for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 08:14:09 +0000 Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r6T8E0bc079455; Mon, 29 Jul 2013 09:14:00 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6T8DtaN093130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 09:13:58 +0100 (BST) Date: Mon, 29 Jul 2013 04:13:55 -0400 From: Peter Todd To: John Dillon Message-ID: <20130729081355.GB23180@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: d20af01f-f826-11e2-98a9-0025907ec6c5 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAsUEkAYAgsB AmUbW11eUV57XGo7 bAxPbAVDY01GQQRq WVdMSlVNFUsqB3gJ clpPLBl7dARFeDBx YERiWj4PXkQrI0Z8 FFMCHW8AeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4sBjU7 Sx1KAjUuAUABRj4v ZxIhMBYkRn0xZS0A X-Authentic-SMTP: 61633532353630.1020:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -0.4 (/) 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 1.1 TRACKER_ID BODY: Incorporates a tracking ID number X-Headers-End: 1V3ial-00019i-DO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Opcode whitelist for P2SH? 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 Jul 2013 08:14:09 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 28, 2013 at 07:39:08PM +0000, John Dillon wrote: > Peter Todd recently came up with two related, and IMO very good, uses for > non-standard transactions to implement both oracles and one-time-password > protection of wallet funds. While the wallet fund case could be implement= ed as > only a single standard type, at the cost of generality, the oracle case w= ould > be most useful with more arbitrary rules. More generally it is also usefu= l to > be able to have scriptPubKeys like the following: >=20 > n ... m CHECKMULTISIG CHECKSIG BOOLOR >=20 > and many other similar constructions. >=20 > What are your thoughts on creating a whitelist for specific opcodes that = would > apply to scripts serialized using P2SH, retaining the existing standard > whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pub= key > and pay-to-multisig due to their potential for dumping data in the UTXO s= et) One subtlety of what you are proposing is that we should still retain the IsStandard() check, or to be exact the AreInputsStandard() check, if a P2SH serialized script follows a standard form. The reason is transaction mutability. Right now other than BIP11 CHECKMULTISIG only miners can mutate transactions because any change to the scriptSig will render the transaction non-standard. As you know this is a good thing because it means unconfirmed transaction chains don't get broken in flight. BIP11 is an interesting case because CHECKMULTISIG consumes one extra stack item, so when you spend a BIP11 n ... m CHECKMULTISIG scriptPubKey you have to provide an additional item prior to the signatures; usually OP_0 is used. But we don't actually check that! You can put anything there provided it doesn't make the scriptSig go over the standard allowed scriptSig size of 500 bytes; for instance I (ab)used that feature just now to timestamp my Litecoin v0.8.3.6 audit report SHA256 hash: d0dfe270e8e8e4c0196f780d42e34d8a1121f2f8a249586aa1a2c5ebcada10b1 in transaction: 15bb08318335f94a8de154dc39b03db2cdebcc7a96ab6cec0379978676d00301 It's been suggested that we consider transactions non-standard, or just now allowed at all in a future soft-fork, if at the end of execution there is more than one stack item left; a opcode whitelist should probably do this. On the other hand I've come up with some soft-fork upgrade mechanisms that would leave extra items on the stack for non-upgraded nodes, suggesting a soft-fork imposing this is a bad idea. (though note how it suggests considering such tx's non-standard is reasonable in a few ways) CHECKMULTISIG isn't helped here because the value really is ignored - a soft-fork to force it to always be zero might not be a bad idea, though it's far from the only example of mutability. I'd be interested if you can come up with an example where imposing a one stack item at the end of execution rule causes problems. More generally, and getting a bit off topic, I think Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys, rather than txid:vout outputs, so that malleability wouldn't affect the validity of a signature. Of course, this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is a bad thing anyway! Not that I'll fault Satoshi here, type 2 deterministic wallets were unknown back then. (though we should be careful that a future CHECKSIG design can go back to txid:vout references - ECC is unique in allowing for type 2 wallets) --=20 'peter'[:-1]@petertodd.org 0000000000000053ef658095fb45c7a86955d70c76b44264c7abce79683a8a90 --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9iRDAAoJECSBQD2l8JH7EAYH/jwWU2Ww4hfqxrrJgOxwERfS 7somJMz2xq9/fWXsLKP5u+G4FG+ANFHvfOHLnioxuMCR+Ju339MpP25BHjM8YC84 /6o7tSLKHojr/W0BMvcJSK7a3V2b8kftypKe1lrNBDrY8r4RX+toPKXnVczS3BiM gB5MBW3arflQlbTEf/saw+eNfQwYrRj7aWVCKKM0glsFPn2NnZqO6pJWPSxluxJe 6UlRHimtxq7YG+lsz4UyNkNlTexS7hfPA24REHaJ3hJsCoSb/IbIp9b4xAsXOSWP d8ZlMW0DHjd5BdyjzENdzBgGypThuiq6Bkx+2n+oExp+p/SHMhrqKdMJg432gRo= =QMmk -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG--