Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wx3Wu-0004Sa-E0 for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 00:15:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Wx3Wr-0008Fp-SI for bitcoin-development@lists.sourceforge.net; Wed, 18 Jun 2014 00:15:07 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s5I0Ewf0042206; Wed, 18 Jun 2014 01:14:58 +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 s5I0EsdH059272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Jun 2014 01:14:57 +0100 (BST) Date: Tue, 17 Jun 2014 20:15:03 -0400 From: Peter Todd To: Gavin Andresen Message-ID: <20140618001503.GA8360@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 94b2c9b2-f67d-11e3-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwoUEkAaAgsB AmIbW1VeUVl7XGQ7 bAxPbAVDY01GQQRq WVdMSlVNFUsrBGUB c11KKhl3fgdBejBx YUZjXj5SWBZ4Jk8v QFMCE2pSeGZhPWMC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zBDkk QAsLGWdnB0ABTjV7 MxwrYn8HJ1oYNEk7 K1dpQ08cPgRaBApE fQl1WhR5b0UbTiww BAhGXEkYC1UA X-Authentic-SMTP: 61633532353630.1024: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: -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: 1Wx3Wr-0008Fp-SI Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal: 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: Wed, 18 Jun 2014 00:15:09 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 17, 2014 at 03:40:36PM -0400, Gavin Andresen wrote: > Assuming there is rough consensus, I'll make this a pull request (see > https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for co= de > changes). I'm also working on a very similar patch with some additional protections to ensure forwards compatibility during soft-fork upgrades and provide protections against transaction malleability. > Now that we are finally starting to see the use of multi-signature and > other more complicated transaction forms in applications I think it is ti= me > to open up the "IsStandard" transaction rules on the main Bitcoin network. Agreed. > There are two main risks to doing this: >=20 > 1. The risk that one of the seldom-used opcodes has a not-yet-discovered > chain-forking bug. I believe that risk to be very low; we have never seen > such a bug on the test network (where all transaction forms are allowed) > and have never found a bug after writing extensive unit tests. Agreed. The script execution code is probably in the 99.9th percentile of open source code in terms of code review. > 2. The risk of opening up a denial-of-service attack (either bloat the > blockchain or use an excessive amount of CPU time) via a very > expensive-to-store-or-verify transaction. This proposal does not entirely > eliminate IsStandard checks to mitigate the potential for DoS attacks. 3. The risk that non-upgraded miners produce invalid blocks after a soft-fork due to them mining transactions that are now invalid. 4. Transaction malleability. > Proposal > -------- > Allow any Script containing 15 or fewer signature operations as a > pay-to-script-hash (P2SH) Script to be relayed and mined by the reference > implementation. >=20 > This should be a simple change to the AreInputsStandard() method in the > reference implementation. In addition to these changes the soft-fork-safe patch I'm working on would do the following: a) Define an opcode whitelist of soft-fork-safe opcodes. This whitelist includes every opcode but the invalid opcodes, and most importantly, the OP_NOPx opcodes that may be redefined in a future soft-fork with new behavior. This rule, along with rejecting transations with unknown nVersion's, ensures that a miner still running an old version of Bitcoin Core will only mine transactions that the new version of Bitcoin Core considers valid. b) Consider scripts that leave extra items on the stack after execution to be non-standard. As per Pieter Wuille's BIP62 "Dealing with malleability" extra scriptSig pushes are a malleability source. If adding extra pushes causes a transaction to be invalid, scriptPubKeys will in most cases be automatically non-malleable. This change I've already submitted as a separate pull-req: https://github.com/bitcoin/bitcoin/pull/4311 I'd be happy to add the above to your existing patch and submit the pull-req for you. --=20 'peter'[:-1]@petertodd.org 0000000000000000407e409a626b01bfb275cb88768ca74f3ea9bd87b2e7e1d9 --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJToNoDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAyZDA1YTkyZTVhNzc4OTFmYTc5ODk0N2I2N2NiMGFhZTEz OTZkZGRkZjcwZWI1ODMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftt9Qf+PkIbmP7TZAt9CWjKRnzAzE+R /wRYxDm5Zg9eiaoYdb9vBEEfRMNA6H+VuVyP6pfxNU+FQ3GTqK0whVbsf9vXI/MR h1saqp3+p3V+sZ3Q14Ifb0MYY1OfuTMZzi6lThl9q6qF+Lz70KTP8G/Q0BqE9rIV bn3YKdAhpeYCa8fphWbljU97O1L2lZsLO+2IlythbrAT0y6f7g6eknZRxD+LBbTE zenSv1VLRxb7Raw7XzkvVp95Hlm/CLTpB1ilijIXWdQsVVMATpPQHVVKzigEUdmk TD5gwtHRISrJ+oo67hWCreoBIOEPrmvDDxiqeVWntvo+0YtRLpnED7XNO/bSug== =1qxz -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--