Skip to content

Instantly share code, notes, and snippets.

Last active July 24, 2018 22:04
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
Proposal: open up IsStandard for P2SH transactions

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.


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.


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.

Copy link

skajake commented Aug 20, 2014

I look forward to the scripting engine being opened up. In my opinion this is where bitcoin holds the most potential.

Copy link

mappum commented Nov 12, 2014

This proposal was merged into Bitcoin Core on June 27: bitcoin/bitcoin#4365

(Just posting this comment for people like me who didn't realize this was already pulled).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment