2 Describe a practical hash-locked oracle
source | link

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, I could say "I'm thinking of a number between 0 and 248, here'sthis PDF (page 24) describes a 10 BTC outputhash-locked contract with the scriptthree parties: HASH160 <hash of my number> CHECKEQUAL" Now anyone who guesses the number that matches that hash can spend that 10 BTC outputAlice, 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>

    (In regular use The example above seems overly contrived, a hash-locked oracle would be more complicated because the signature script spendingbut the output describedPDF linked above could be intercepted by any mineruses it as part of a micropayment channel that allows settling transactions off the block chain in a distributed and redirectedlow-trust manner, possibly allowing Bitcoin to themselvesscale much better than it does without such a system.)

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, I could say "I'm thinking of a number between 0 and 248, here's a 10 BTC output with the script: HASH160 <hash of my number> CHECKEQUAL" Now anyone who guesses the number that matches that hash can spend that 10 BTC output.

    (In regular use, a hash-locked oracle would be more complicated because the signature script spending the output described above could be intercepted by any miner and redirected to themselves.)

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.

1
source | link

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, I could say "I'm thinking of a number between 0 and 248, here's a 10 BTC output with the script: HASH160 <hash of my number> CHECKEQUAL" Now anyone who guesses the number that matches that hash can spend that 10 BTC output.

    (In regular use, a hash-locked oracle would be more complicated because the signature script spending the output described above could be intercepted by any miner and redirected to themselves.)