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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwzFL-0000Dg-M7 for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 19:40:43 +0000 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; Received: from mail-yk0-f179.google.com ([209.85.160.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwzFJ-0001UB-Tp for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 19:40:43 +0000 Received: by mail-yk0-f179.google.com with SMTP id 20so5567861yks.24 for ; Tue, 17 Jun 2014 12:40:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.31.135 with SMTP id m7mr47899845yha.104.1403034036373; Tue, 17 Jun 2014 12:40:36 -0700 (PDT) Sender: gavinandresen@gmail.com Received: by 10.170.223.70 with HTTP; Tue, 17 Jun 2014 12:40:36 -0700 (PDT) Date: Tue, 17 Jun 2014 15:40:36 -0400 X-Google-Sender-Auth: nPGq-eq9UqvjUesf9F7FL4VYm9g Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0160d100589dfb04fc0d5127 X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WwzFJ-0001UB-Tp Subject: [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: Tue, 17 Jun 2014 19:40:43 -0000 --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
Assuming there is rough consensus, I'll make this a pu= ll 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-si= gnature and other more complicated transaction forms in applications I thin= k 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 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.
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.

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

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' transact= ion.

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:
```
OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4= pubkey5 3 OP_CHECKMULTISIG OP_ENDIF
```
(this would count as 5 signa= ture operations)

Restricting arbitrary Scripts to P2SH transaction t= ypes limits unspent transaction output set bloat in two ways:
1. The Scripts are not stored in UTXO set.
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.

The reference implementation'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.

--
--
Gavin Andresen
Chief Scientist, Bitc= oin Foundation

--089e0160d100589dfb04fc0d5127--