Update 8_3_Scripting_a_Multisig.md

This commit is contained in:
Shannon Appelcline 2017-05-23 15:07:07 -07:00 committed by GitHub
parent b7373b9f07
commit 77c2b082a4

View File

@ -2,7 +2,7 @@
> **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning.
Ever since [§6.1: Sending a Transaction to a Multisig](6_1_Sending_a_Transaction_to_a_Multisig.md), we've been casually noting that the `bitcoin-cli` interface wraps its multisig transaction in a P2SH transaction. In fact, this is the standard methodology for creating multisigs on the Blockchain. You'll now see how that works, in depth.
Before we close out this intro to P2SH scripting, it's worth examining an even more notable example. Ever since [§6.1: Sending a Transaction to a Multisig](6_1_Sending_a_Transaction_to_a_Multisig.md), we've been casually saying that the `bitcoin-cli` interface wraps its multisig transaction in a P2SH transaction. In fact, this is the standard methodology for creating multisigs on the Blockchain. Here's how that works, in depth.
## Understand the Multisig Code
@ -14,13 +14,13 @@ Multisig transactions are created in Bitcoin using the `OP_CHECKMULTISIG` code.
2. Pop "n" values from the stack as Bitcoin addresses (hashed public keys).
3. Pop the next value from the stack (`<m>`).
4. Pop "m" values from the stack as potential signatures.
5. Pop a `0` from the stack due to a mistake in the original coding.
5. Pop an `0` from the stack due to a mistake in the original coding.
6. Compare the signatures to the Bitcoin adddresses.
7. Push a `True` or `False` depending on the result.
The operands of `OP_MULTISIG` are typically divided, with the `0` and the signatures coming from the unlocking script and everything else being laid out in the locking script.
The operands of `OP_MULTISIG` are typically divided, with the `0` and the signatures coming from the unlocking script and the "m", "n", and addresses being detailed by the locking script.
The requirement for that `0` as the first operand for `OP_CHECKMULTISIG` is a consensus rule. Because the original version of `OP_CHECKMULTISIG` accidentally popped an extra item off the stack, Bitcoin must forever follow that rule, lest complex redemption scripts from that time period accidentally be broken, rendering old funds unredeemable.
The requirement for that `0` as the first operand for `OP_CHECKMULTISIG` is a consensus rule. Because the original version of `OP_CHECKMULTISIG` accidentally popped an extra item off the stack, Bitcoin must forever follow that standard, lest complex redemption scripts from that time period accidentally be broken, rendering old funds unredeemable.
_What is a consensus rule?_ These are the rules that the Bitcoin nodes follow to work together. In large part they're defined by the Bitcoin Core code. These rules include lots of obvious mandates, such as the limit to how many Bitcoins are created for each block and the rules for how transactions may be respent. However, they also include fixes for bugs that have appeared over the years, because once a bug has been introduced into the Bitcoin codebase, it must be continually supported, lest old Bitcoins become unspendable.
@ -28,51 +28,54 @@ _What is a consensus rule?_ These are the rules that the Bitcoin nodes follow to
As discussed in [§8.1: Building a Bitcoin Script with P2SH](8_1_Building_a_Bitcoin_Script_with_P2SH.md), multisigs are one of the standard Bitcoin transaction types. A transaction can be created with a locking script that uses the raw `OP_CHECKMULTISIG` command, and it will be accepted into a block. This is the classic methodology for using multisigs in Bitcoin.
As an example, we can revisit the multisig created in [§6.1](6_1_Sending_a_Transaction_to_a_Multisig.md) and build a new locking script for it using this methodology. As you may recall, that was a 1-of-2 multisig built from `$address1` and `$address2`.
As an example, we will revisit the multisig created in [§6.1](6_1_Sending_a_Transaction_to_a_Multisig.md) one final time and build a new locking script for it using this methodology. As you may recall, that was a 2-of-2 multisig built from `$address1` and `$address2`.
An `OP_CHECKMULTISIG` locking script requires the "m" (`1`), the addresses, and the "n" (`2`). You can write the following `scriptPubKey`:
An `OP_CHECKMULTISIG` locking script requires the "m" (`2`), the addresses, and the "n" (`2`). You can write the following `scriptPubKey`:
```
1 $address1 $address2 2 OP_CHECKMULTISIG
2 $address1 $address2 2 OP_CHECKMULTISIG
```
If this looks familiar, that's because it's the multisig that you deserialized in [§8.1](8_1_Building_a_Bitcoin_Script_with_P2SH.md).
```
2 0307fd375ed7cced0f50723e3e1a97bbe7ccff7318c815df4e99a59bc94dbcd819 0367c4f666f18279009c941e57fab3e42653c6553e5ca092c104d1db279e328a28 2 OP_CHECKMULTISIG
```
> **WARNING:** For classic `OP_CHECKMULTISIG` signatures, "n" must be ≤ 3 for the transaction to be standard.
## Unlock a Raw Multisig
The `scriptSig` for a standard multisig address must then submit the missing operands for `OP_CHECKMULTISIG`: a `0` followed by "m" signatures. You could submit either of the following:
```
0 $signature1
```
Or:
```
0 $signature2
0 $signature1 signature2
```
### Run a Raw Multisig Script
In order to reuse the multisig UTXO, run the `scriptSig` and `scriptPubKey` as follows:
```
Script: 0 $signature1 1 $address1 $address2 2 OP_CHECKMULTISIG
Script: 0 $signature1 $signature2 2 $address1 $address2 2 OP_CHECKMULTISIG
Stack: [ ]
```
You place all the constants on the stack:
```
Script: OP_CHECKMULTISIG
Stack: [ 0 $signature1 1 $address1 $address2 2 ]
Stack: [ 0 $signature1 $signature2 2 $address1 $address2 2 ]
```
Then, the `OP_CHECKMULTISIG` begins to run. First, the "2" is popped:
```
Script: OP_CHECKMULTISIG
Stack: [ 0 $signature1 1 $address1 $address2 ]
Stack: [ 0 $signature1 $signature2 2 $address1 $address2 ]
```
Then, the "2" tells `OP_CHECKMULTISIG `to pop two addresses:
```
Script: OP_CHECKMULTISIG
Stack: [ 0 $signature1 1 ]
Stack: [ 0 $signature1 $signature2 2 ]
```
Then, the "1" is popped:
Then, the next "2" is popped:
```
Script: OP_CHECKMULTISIG
Stack: [ 0 $signature1 ]
Stack: [ 0 $signature1 $signature2 ]
```
Then, the "1" tells `OP_CHECKMULTISIG` to pop one signature:
Then, the "2" tells `OP_CHECKMULTISIG` to pop two signatures:
```
Script: OP_CHECKMULTISIG
Stack: [ 0 ]
@ -87,7 +90,7 @@ Then, `OP_CHECKMULTISIG` completes its operation by comparing the "m" signatures
Script:
Stack: [ True ]
```
### Understand the Limitations of Raw Multisig Scripts
## Understand the Limitations of Raw Multisig Scripts
Unfortunately, the technique of embedding a raw multisig into a transaction has some notable drawbacks:
@ -96,36 +99,46 @@ Unfortunately, the technique of embedding a raw multisig into a transaction has
These were generally problems with any sort of complex Bitcoin script, but they quickly became very real problems when applied to multisigs, which were some of the first complex scripts to be widely used on the Bitcoin network. P2SH transactions were created to solve these problems, starting in 2012.
_What is a P2SH multisig?_ P2SH multisigs were the first implementation of P2SH transactions, in 2012. They simply package up a standard multisig transaction into a standard P2SH transaction. This allows for address standardization; reduced data storage; and increased "m" and "n" counts.
_What is a P2SH multisig?_ P2SH multisigs were the first implementation of P2SH transactions. They simply package up a standard multisig transaction into a standard P2SH transaction. This allows for address standardization; reduced data storage; and increased "m" and "n" counts.
## Create a P2SH Multisig
P2SH multisigs are the modern methodology for creating multisigs on the Blockchains. What follows is a new example that uses the same 1-of-2 multisig, but now packages it in a P2SH using the technique described in [§8.1](8_1_Building_a_Bitcoin_Script_with_P2SH.md). This offers a practical first example of how P2SHes really work.
P2SH multisigs are the modern methodology for creating multisigs on the Blockchains. They can be created very simply, using the same process seen in the prvious two sections.
### Create the Lock for the P2SH Multisig
To create a P2SH multisig, follow the standard steps for creating a P2SH locking script:
1. Serialize `1 $address1 $address2 2 OP_CHECKMULTISIG` (`<serializedMultiSig>`) then SHA-256 and RIPEMD-160 hash it (`<hashedMultisig>`).
2. Save `<serializedMultiSig>` for future reference as the `redeemScript`.
3. Produce a P2SH Multisig locking script that includes the hashed script (`OP_HASH160 <hashedMultisig> OP_EQUAL`).
4. Create a transaction using that `scriptPubKey`.
1. Serialize `2 $address1 $address2 2 OP_CHECKMULTISIG`.
1. `<serializedMultiSig>` = "52210307fd375ed7cced0f50723e3e1a97bbe7ccff7318c815df4e99a59bc94dbcd819210367c4f666f18279009c941e57fab3e42653c6553e5ca092c104d1db279e328a2852ae"
2. SHA-256 and RIPEMD-160 hash the serialized script.
1. `<hashedMultiSig>` = "babf9063cee8ab6e9334f95f6d4e9148d0e551c2"
3. Save `<serialized99Equal>` for future reference as the redeemScript.
1. `<redeemScript>` = "52210307fd375ed7cced0f50723e3e1a97bbe7ccff7318c815df4e99a59bc94dbcd819210367c4f666f18279009c941e57fab3e42653c6553e5ca092c104d1db279e328a2852ae"
4. Produce a P2SH Multisig locking script that includes the hashed script (`OP_HASH160 <hashedMultisig> OP_EQUAL`).
1. `scriptPubKey` = "a914babf9063cee8ab6e9334f95f6d4e9148d0e551c287"
You can then create a transaction using that `scriptPubKey`.
## Unlock the P2SH Multisig
To unlock this multisig transaction requires that the recipient produce a scriptSig that includes the two signatures and the `redeemScript`.
### Run the First Round of P2SH Validation
To unlock the P2SH multisig, first confirm the script:
1. Produce an unlocking script of `0 $signature1 <serializedMultiSig>` or `0 $signature2 <serializedMultiSig>`.
1. Produce an unlocking script of `0 $signature1 $signature2 <serializedMultiSig>`.
2. Concatenate that with the locking script of `OP_HASH160 <hashedMultisig> OP_EQUAL`.
3. Validate `0 $signature1 <serializedMultiSig> OP_HASH160 <hashedMultisig> OP_EQUAL` or `0 $signature2 <serializedMultiSig> OP_HASH160 <hashedMultisig> OP_EQUAL`.
3. Validate `0 $signature1 $signature2 <serializedMultiSig> OP_HASH160 <hashedMultisig> OP_EQUAL`.
### Run the Second Round of P2SH Validation
Then, run the multisig script:
1. Deserialize `<serializedMultiSig>` to `1 $address1 $address2 2 OP_CHECKMULTISIG`.
2. Concatenate that with the earlier operands in the unlocking script, `0 $signature1` or `0 $signature2`.
3. Validate `0 $signature1 1 $address1 $address2 2 OP_CHECKMULTISIG` or `0 $signature2 1 $address1 $address2 2 OP_CHECKMULTISIG`.
1. Deserialize `<serializedMultiSig>` to `2 $address1 $address2 2 OP_CHECKMULTISIG`.
2. Concatenate that with the earlier operands in the unlocking script, `0 $signature1 $signature2`.
3. Validate `0 $signature1 $signature2 2 $address1 $address2 2 OP_CHECKMULTISIG`.
Now you know how the multisig transaction in [§6.1](6_1_Sending_a_Transaction_to_a_Multisig.md) was actually created, how it was validated for spending, and why that `redeemScript` was so important.