What is meant by "relaxed standards" for P2SH redeem scripts in Bitcoin Core 0.10.0?

Question

From the Bitcoin Core 0.10.0 release notes:

Standard script rules relaxed for P2SH addresses

The IsStandard() rules have been almost completely removed for P2SH redemption scripts, allowing applications to make use of any valid script type, such as "n-of-m OR y", hash-locked oracle addresses, etc. While the Bitcoin protocol has always supported these types of script, actually using them on mainnet has been previously inconvenient as standard Bitcoin Core nodes wouldn't relay them to miners, nor would most miners include them in blocks they mined.

So essentially the core software will now relay more intricate P2SH Txns which would previously be deemed non-standards transactions.

What are the specific changes which have been made (ie relaxed standards)? Does it only apply to P2SH Txns? Finally, "n-of-m OR y" and hash-locked oracle addresses are mentioned as examples: what does this refer to exactly?

Answer 1

What are the specific changes which have been made (ie relaxed standards)?

Gavin Andresen made this pull request proposing the change, as well as this rationale document describing why he supported the change.

Does it only apply to P2SH Txns?

It applies only to P2SH redeem scripts, which is the script that is run to see if you have the data required to spend an output sent to a P2SH address.

Finally, "n-of-m OR y" and hash-locked oracle addresses are mentioned as examples: what does this refer to exactly?

• n-of-m OR y refers to a script that checks for multiple signatures from a set of keys OR a single signature from another key. For example, if Alice owns a business and Bob and Charlie are her employees, she can allow Bob and Charlie to work together to spend her bitcoins (2-of-2) or Alice ("y") can spend her bitcoins on her own.

• hash-locked oracle means, generally, that you can create a transaction that can only be spent when the hash of some data is provided. For example, this PDF (page 24) describes a hash-locked contract with three parties: Alice, Bob, and Charlie.

  • Alice wants to pay 1.00 BTC to Charlie through Bob.

  • Charlie randomly generates a large number r and then hashes (HASH160) that number to produce h. The value r is the oracle and the value h is the hash lock.

  • Charlie gives hash h to Alice.

  • (Transaction 1) Alice gets Bob's pubkey and pays him 1.01 BTC in an output with a script like: <Bob's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL

  • (Transaction 2) Bob can't spend that output without the number r that generated hash h, but he knows Charlie has the number r so Bob gets Charlie's address and pays him 1.00 BTC with a script like: <Charlie's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL

  • (Transaction 3) Charlie spends the output from transaction 2 by creating the signature script: <number r> <Charlie's signature> This means r is revealed on the block chain.

  • (Transaction 4) Bob sees r on the block chain and uses it at some point to spend the output from transaction 1: <number r> <Bob's signature>

  The example above seems overly contrived, but the PDF linked above uses it as part of a micropayment channel that allows settling transactions off the block chain in a distributed and low-trust manner, possibly allowing Bitcoin to scale much better than it does without such a system.