Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.179 as permitted sender)
	client-ip=209.85.160.179; envelope-from=gavinandresen@gmail.com;
	helo=mail-yk0-f179.google.com; 
MIME-Version: 1.0
Sender: gavinandresen@gmail.com
Date: Tue, 17 Jun 2014 15:40:36 -0400
Message-ID: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com>
From: Gavin Andresen <gavin@bitcoinfoundation.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0160d100589dfb04fc0d5127
Subject: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH
	transactions
Precedence: list

--089e0160d100589dfb04fc0d5127
Content-Type: text/plain; charset=UTF-8

Assuming there is rough consensus, I'll make this a pull request (see
https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
changes).

----

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 time
to open up the "IsStandard" transaction rules on the main Bitcoin network.

There are two main risks to doing this:

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.
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.

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.

This should be a simple change to the AreInputsStandard() method in the
reference implementation.

Discussion
----------
P2SH Scripts are limited to 520 bytes, and are currently limited to one of
the "standard" transaction forms on the main network. In practice that
means you can currently encode a n-of-15 OP_CHECKMULTISIG which can be
redeemed as a 'standard' transaction.

Allowing any P2SH Script would allow an attacker to craft a single standard
transaction output that requires on the order of 200 ECDSA signature
checking operations to validate-- an order of magnitude more than is
currently allowed. Therefore I am proposing that we keep the current
15-signature-checking-operations-per-transaction-output limit in place, but
allow any combination of enabled Script opcodes. So, for example, you might
have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using:
```
OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4
pubkey5 3 OP_CHECKMULTISIG OP_ENDIF
```
(this would count as 5 signature operations)

Restricting arbitrary Scripts to P2SH transaction types limits unspent
transaction output set bloat in two ways:
1. The Scripts are not stored in UTXO set.
2. They are limited to 520 bytes by the Script rule on the amount of data
that can be pushed onto the stack.

The reference implementation's wallet will still only recognize P2SH
transactions that use one of the standard transaction forms. To actually
USE a new transaction form will require specialized wallets or specialized
applications.

-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/

--089e0160d100589dfb04fc0d5127
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Assuming there is rough consensus, I&#39;ll make this a pu=
ll request (see <a href=3D"https://github.com/gavinandresen/bitcoin-git/tre=
e/relax_isstandard">https://github.com/gavinandresen/bitcoin-git/tree/relax=
_isstandard</a> for code changes).<br>
<br>----<br><br>Now that we are finally starting to see the use of multi-si=
gnature and other more complicated transaction forms in applications I thin=
k it is time to open up the &quot;IsStandard&quot; transaction rules on the=
 main Bitcoin network.<br>
<br>There are two main risks to doing this:<br><br>1. The risk that one of =
the seldom-used opcodes has a not-yet-discovered chain-forking bug. I belie=
ve that risk to be very low; we have never seen such a bug on the test netw=
ork (where all transaction forms are allowed) and have never found a bug af=
ter writing extensive unit tests.<br>
2. The risk of opening up a denial-of-service attack (either bloat the bloc=
kchain or use an excessive amount of CPU time) via a very expensive-to-stor=
e-or-verify transaction. This proposal does not entirely eliminate IsStanda=
rd checks to mitigate the potential for DoS attacks.<br>
<br>Proposal<br>--------<br>Allow any Script containing 15 or fewer signatu=
re operations as a pay-to-script-hash (P2SH) Script to be relayed and mined=
 by the reference implementation.<br><br>This should be a simple change to =
the AreInputsStandard() method in the reference implementation.<br>
<br>Discussion<br>----------<br>P2SH Scripts are limited to 520 bytes, and =
are currently limited to one of the &quot;standard&quot; transaction forms =
on the main network. In practice that means you can currently encode a n-of=
-15 OP_CHECKMULTISIG which can be redeemed as a &#39;standard&#39; transact=
ion. <br>
<br>Allowing any P2SH Script would allow an attacker to craft a single stan=
dard transaction output that requires on the order of 200 ECDSA signature c=
hecking operations to validate-- an order of magnitude more than is current=
ly allowed. Therefore I am proposing that we keep the current 15-signature-=
checking-operations-per-transaction-output limit in place, but allow any co=
mbination of enabled Script opcodes. So, for example, you might have a P2SH=
 Script that is redeemed with 2-of-2 OR 2-of-3 using:<br>
```<br>OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4=
 pubkey5 3 OP_CHECKMULTISIG OP_ENDIF<br>```<br>(this would count as 5 signa=
ture operations)<br><br>Restricting arbitrary Scripts to P2SH transaction t=
ypes limits unspent transaction output set bloat in two ways:<br>
1. The Scripts are not stored in UTXO set.<br>2. They are limited to 520 by=
tes by the Script rule on the amount of data that can be pushed onto the st=
ack.<br><br>The reference implementation&#39;s wallet will still only recog=
nize P2SH transactions that use one of the standard transaction forms. To a=
ctually USE a new transaction form will require specialized wallets or spec=
ialized applications.<br clear=3D"all">
<div><br></div>-- <br>--<div>Gavin Andresen</div><div>Chief Scientist, Bitc=
oin Foundation</div><div><a href=3D"https://www.bitcoinfoundation.org/" tar=
get=3D"_blank">https://www.bitcoinfoundation.org/</a></div><div><br></div>

</div>

--089e0160d100589dfb04fc0d5127--