Skip to content

Instantly share code, notes, and snippets.

@gavinandresen
Last active July 24, 2018 22:04
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gavinandresen/88be40c141bc67acb247 to your computer and use it in GitHub Desktop.
Save gavinandresen/88be40c141bc67acb247 to your computer and use it in GitHub Desktop.
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.

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.

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

@mappum
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