From: Gavin Andresen <gavin@bitcoinfoundation•org>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions
Date: Tue, 17 Jun 2014 15:40:36 -0400 [thread overview]
Message-ID: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
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/
[-- Attachment #2: Type: text/html, Size: 3188 bytes --]
next reply other threads:[~2014-06-17 19:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 19:40 Gavin Andresen [this message]
2014-06-18 0:15 ` Peter Todd
2014-06-18 12:52 ` Gavin Andresen
2014-06-19 10:09 ` Peter Todd
2014-06-19 13:54 ` Gavin Andresen
2014-06-20 0:45 ` Peter Todd
2014-09-29 2:35 ` [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions') Peter Todd
2014-09-29 4:30 ` Alan Reiner
2014-09-29 5:35 ` Peter Todd
2014-06-18 7:42 ` [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com' \
--to=gavin@bitcoinfoundation$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox