<blockquote>
  <p>What are the specific changes which have been made (ie relaxed standards)?</p>
</blockquote>

<p>Gavin Andresen made <a href="https://github.com/bitcoin/bitcoin/pull/4365" rel="nofollow">this pull request</a> proposing the change, as well as <a href="https://gist.github.com/gavinandresen/88be40c141bc67acb247" rel="nofollow">this rationale document</a> describing why he supported the change.</p>

<blockquote>
  <p>Does it only apply to P2SH Txns?</p>
</blockquote>

<p>It applies only to P2SH <a href="https://bitcoin.org/en/developer-guide#term-redeem-script" rel="nofollow">redeem scripts</a>, which is the script that is run to see if you have the data required to spend an output sent to a P2SH address.</p>

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

<ul>
<li><p><code>n-of-m OR y</code> 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.</p></li>
<li><p><code>hash-locked oracle</code> means, generally, that you can create a transaction that can only be spent when the hash of some data is provided.  For example, <a href="http://lightning.network/lightning-network.pdf" rel="nofollow">this PDF</a> (page 24) describes a hash-locked contract with three parties: Alice, Bob, and Charlie.</p>

<ul>
<li><p>Alice wants to pay 1.00 BTC to Charlie through Bob.</p></li>
<li><p>Charlie randomly generates a large number <em>r</em> and then hashes (HASH160) that number to produce <em>h</em>.  The value <em>r</em> is the oracle and the value <em>h</em> is the hash lock.</p></li>
<li><p>Charlie gives hash <em>h</em> to Alice.</p></li>
<li><p>(Transaction 1) Alice gets Bob's pubkey and pays him 1.01 BTC in an output with a script like: <code>&lt;Bob's pubkey&gt; CHECKSIGVERIFY HASH160 &lt;hash h&gt; EQUAL</code></p></li>
<li><p>(Transaction 2) Bob can't spend that output without the number <em>r</em> that generated hash <em>h</em>, but he knows Charlie has the number <em>r</em> so Bob gets Charlie's address and pays him 1.00 BTC with a script like: <code>&lt;Charlie's pubkey&gt; CHECKSIGVERIFY HASH160 &lt;hash h&gt; EQUAL</code></p></li>
<li><p>(Transaction 3) Charlie spends the output from transaction 2 by creating the signature script: <code>&lt;number r&gt; &lt;Charlie's signature&gt;</code>  This means <em>r</em> is revealed on the block chain.</p></li>
<li><p>(Transaction 4) Bob sees <em>r</em> on the block chain and uses it at some point to spend the output from transaction 1: <code>&lt;number r&gt; &lt;Bob's signature&gt;</code></p></li>
</ul>

<p>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.</p></li>
</ul>

CC BY-SA 3.0
2015-02-27T02:28:16.613Z
Wow that's fascinating. If possible can you clarify a working example of an Oracle script that could work without miner interception?
Wizard Of Ozzie
CC BY-SA 3.0
2015-02-27T09:31:55.057Z
@WizardOfOzzie I can't think of any examples of hash-locked oracles that are simpler than solving the same problem without hash-locked oracles---unless the spender is a miner and doesn't have to worry about miner interception.  Sorry.
David A. Harding
CC BY-SA 3.0
2015-02-27T15:40:08.737Z
@WizardOfOzzie I just read [this PDF](http://lightning.network/lightning-network.pdf) (starting page 24) which describes a hash-locked **contract**, which is what I guess Peter Todd was thinking of when he wrote about hash-locked oracles in the release notes.  I'll update my answer to describe the process in a few minutes.
David A. Harding
CC BY-SA 3.0
2015-02-26T17:18:03.650Z
2015-02-27T16:11:44.083Z
2015-02-27T16:11:44.083Z
David A. Harding
<p>From the <a href="https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md#standard-script-rules-relaxed-for-p2sh-addresses" rel="nofollow">Bitcoin Core 0.10.0 release notes</a>:</p>

<blockquote>
  <p><strong>Standard script rules relaxed for P2SH addresses</strong></p>
  
  <p>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.</p>
</blockquote>

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

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

CC BY-SA 3.0
2015-02-26T10:41:25.777Z
`IsStandard` doesn't seem to have changed at all; perhaps the developers meant to refer to `IsStandardTx`? In any case, I can't find the changed code.
Nick ODell
CC BY-SA 3.0
2015-02-26T12:28:45.187Z
@nickodell Yep, that was my understanding. I do still need clarification of `n-of-m OR y` and the Oracle addresses
Wizard Of Ozzie
<bitcoin-core><transactions><p2sh><non-standard-transaction>
What is meant by "relaxed standards" for P2SH redeem scripts in Bitcoin Core 0.10.0?
Wizard Of Ozzie
# What is meant by "relaxed standards" for P2SH redeem scripts in Bitcoin Core 0.10.0?

(Asked by: username_0 on 2015-02-26)

From the [Bitcoin Core 0.10.0 release notes](https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md#standard-script-rules-relaxed-for-p2sh-addresses):

> **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?

**Tags:** bitcoin-core, transactions, p2sh, non-standard-transaction

> **Comments:**
> **username_1**: `IsStandard` doesn't seem to have changed at all; perhaps the developers meant to refer to `IsStandardTx`? In any case, I can't find the changed code.  
> **username_0**: @username_1 Yep, that was my understanding. I do still need clarification of `n-of-m OR y` and the Oracle addresses  

---

## 1 answers

### Answer by username_2 on 2015-02-26. Score: 6 | Accepted answer

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

Gavin Andresen made [this pull request](https://github.com/bitcoin/bitcoin/pull/4365) proposing the change, as well as [this rationale document](https://gist.github.com/gavinandresen/88be40c141bc67acb247) describing why he supported the change.

> Does it only apply to P2SH Txns?

It applies only to P2SH [redeem scripts](https://bitcoin.org/en/developer-guide#term-redeem-script), 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](http://lightning.network/lightning-network.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.

> **Comments:**
> **username_0**: Wow that's fascinating. If possible can you clarify a working example of an Oracle script that could work without miner interception?  
> **username_2**: @username_0 I can't think of any examples of hash-locked oracles that are simpler than solving the same problem without hash-locked oracles---unless the spender is a miner and doesn't have to worry about miner interception.  Sorry.  
> **username_2**: @username_0 I just read [this PDF](http://lightning.network/lightning-network.pdf) (starting page 24) which describes a hash-locked **contract**, which is what I guess Peter Todd was thinking of when he wrote about hash-locked oracles in the release notes.  I'll update my answer to describe the process in a few minutes.  

---

