mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 07:08:13 +00:00
CH04::P2SH: remove multisig, describe p2sh rationale, give examples
- Start with a description of the problem that P2SH helps solve, the ability for the receiver to specify a script without having to communicate all the details of that script to the spender (and having the spender pay the tx fees for it). - Mention that P2SH uses base58check. Provide the prefix and continue using an existing example, but don't go into too much detail since bech32m addresses are now the preferred format
This commit is contained in:
David A. Harding
parent
708545a446
commit
91eae20099
139
ch04.asciidoc
139
ch04.asciidoc
@ -926,50 +926,86 @@ represent them is implemented slightly differently in newer Bitcoin
|
||||
wallets, to indicate that these private keys have been used to produce
|
||||
compressed public keys.
|
||||
|
||||
[[p2sh_addresses]]
|
||||
==== Pay-to-Script Hash (P2SH) and Multisig Addresses
|
||||
[[p2sh]]
|
||||
=== Legacy Pay-to-Script-Hash (P2SH)
|
||||
|
||||
((("keys and addresses", "advanced forms", "pay-to-script hash and
|
||||
multisig addresses")))((("Pay-to-Script-Hash (P2SH)", "multisig
|
||||
addresses and")))((("multisig addresses")))((("addresses", "multisig
|
||||
addresses")))As we know, traditional Bitcoin addresses begin with the
|
||||
number “1” and are derived from the public key, which is derived from
|
||||
the private key. Although anyone can send bitcoin to a “1” address,
|
||||
that bitcoin can only be spent by presenting the corresponding private
|
||||
key signature and public key hash.
|
||||
As we've seen in preceding sections, someone receiving Bitcoins (like
|
||||
Bob) can require payments to him contain certain constraints in their
|
||||
scriptPubKeys. Bob will need to fulfill those constraints using a
|
||||
scriptSig when he spends those bitcoins. In <<p2pk>>, the constraint
|
||||
was simply that the scriptSig needed to provide an appropriate
|
||||
signature. In <<p2pkh>>, an appropriate public key also needed to be
|
||||
provided.
|
||||
|
||||
((("bitcoin improvement proposals", "Pay to Script Hash
|
||||
(BIP-16)")))Bitcoin addresses that begin with the number “3” are
|
||||
pay-to-script hash (P2SH) addresses, sometimes erroneously called
|
||||
multisignature or multisig addresses. They designate the beneficiary of
|
||||
a Bitcoin transaction as the hash of a script, instead of the owner of a
|
||||
public key. The feature was introduced in January 2012 with BIP-16 (see
|
||||
<<appdxbitcoinimpproposals>>), and is being widely adopted because it
|
||||
provides the opportunity to add functionality to the address itself.
|
||||
Unlike transactions that "send" funds to traditional “1” Bitcoin
|
||||
addresses, also known as a pay-to-public-key-hash (P2PKH), funds sent to
|
||||
“3” addresses require something more than the presentation of one public
|
||||
key hash and one private key signature as proof of ownership. The
|
||||
requirements are designated at the time the address is created, within
|
||||
the script, and all inputs to this address will be encumbered with the
|
||||
same requirements.
|
||||
In order for a spender (like Alice) to place the constraints Bob wants
|
||||
in the scriptPubKey she uses to pay him, Bob needs to communicate those
|
||||
constraints to her. This is similar to the problem of Bob needing to
|
||||
communicate his public key to her. Like that problem, where
|
||||
public keys can be fairly large, the constraints Bob uses can also be
|
||||
quite large---potentially thousands of bytes. That's not only thousands
|
||||
of bytes which need to be communicated to Alice, but thousands of bytes
|
||||
for which she needs to pay transaction fees every time she wants to spend
|
||||
money to Bob. However, the solution of using hash functions to create
|
||||
small commitments to large amounts of data also applies here.
|
||||
|
||||
A P2SH address is created from a transaction script, which defines who
|
||||
can spend a transaction output (for more details, see <<p2sh>>).
|
||||
Encoding a P2SH address involves using the same double-hash function as
|
||||
used during creation of a Bitcoin address, only applied on the script
|
||||
instead of the public key:
|
||||
The BIP16 upgrade to the Bitcoin protocol in 2013 allows a
|
||||
scriptPubKey to commit to a _redemption script_ (_redeemScript_). When
|
||||
Bob spends his bitcoins, his scriptSig need to provide a redeemScript
|
||||
that matches the commitment and also any data necessary to satisfy the
|
||||
redeemScript (such as signatures). Let's start by imagining Bob wants
|
||||
to require two signatures from different wallets he controls in
|
||||
order to spend his bitcoins. He puts those conditions into a
|
||||
redeemScript:
|
||||
|
||||
----
|
||||
script hash = RIPEMD160(SHA256(script))
|
||||
<pubkey1> OP_CHECKSIGVERIFY <pubkey2> OP_CHECKSIG
|
||||
----
|
||||
|
||||
The resulting "script hash" is encoded with Base58Check with a version
|
||||
prefix of 5, which results in an encoded address starting with a +3+. An
|
||||
example of a P2SH address is +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which
|
||||
can be derived using the Bitcoin Explorer commands +script-encode+,
|
||||
+sha256+, +ripemd160+, and +base58check-encode+ (see <<appdx_bx>>) as
|
||||
follows:
|
||||
He then creates a commitment to the redeemScript using the same
|
||||
HASH160 mechanism used for P2PKH commitments, +RIPEMD160(SHA256(script))+.
|
||||
That commitment is placed into the scriptPubKey using a special
|
||||
template:
|
||||
|
||||
----
|
||||
OP_HASH160 <commitment> OP_EQUAL
|
||||
----
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
Payments to Script Hashes (P2SH) must use the specific P2SH template
|
||||
with no extra data or conditions in the scriptPubKey. If the
|
||||
scriptPubKey is not exactly +OP_HASH160 <20 bytes> OP_EQUAL+, the
|
||||
redeemScript will not be used and any bitcoins may either be unspendable
|
||||
or spendable by anyone (meaning anyone can take them).
|
||||
====
|
||||
|
||||
When Bob goes to spend the payment he received to the commitment for his
|
||||
script, he uses a scriptSig that includes the redeemScript, with it
|
||||
serialized as a single data element. He also provides the signatures
|
||||
he needs to satisfy the redeemScript, putting them in the order that
|
||||
they will be consumed by the opcodes:
|
||||
|
||||
----
|
||||
<signature2> <signature1> <redeemScript>
|
||||
----
|
||||
|
||||
When Bitcoin full nodes receive Bob's spend, they'll verify that the
|
||||
serialized redeemScript will hash to the same value as the commitment.
|
||||
Then they'll replace it on the stack with its deserialized value:
|
||||
|
||||
----
|
||||
<signature2> <signature1> <pubkey1> OP_CHECKSIGVERIFY <pubkey2> OP_CHECKSIG
|
||||
----
|
||||
|
||||
The script is executed and, if it passes and all of the other
|
||||
transaction details are correct, the transaction is valid.
|
||||
|
||||
Addresses for Pay-to-Script-Hash (P2SH) are also created with
|
||||
Base58Check. The version prefix is set to 5, which results in an
|
||||
encoded address starting with a +3+. An example of a P2SH address is
|
||||
+3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the
|
||||
Bitcoin Explorer commands +script-encode+, +sha256+, +ripemd160+, and
|
||||
+base58check-encode+ (see <<appdx_bx>>) as follows:
|
||||
|
||||
----
|
||||
$ echo \
|
||||
@ -981,33 +1017,18 @@ $ bx script-encode < script | bx sha256 | bx ripemd160 \
|
||||
|
||||
[TIP]
|
||||
====
|
||||
P2SH is not necessarily the same as a multisignature standard
|
||||
transaction. A P2SH address _most often_ represents a multi-signature
|
||||
P2SH is not necessarily the same as a multisignature
|
||||
transaction. A P2SH address _most often_ represents a multisignature
|
||||
script, but it might also represent a script encoding other types of
|
||||
transactions.
|
||||
====
|
||||
|
||||
===== Multisignature addresses and P2SH
|
||||
P2PKH and P2SH are the only two script templates used with Base58Check
|
||||
encoding. They are now known as legacy addresses and, as of early 2023,
|
||||
are only used in
|
||||
https://transactionfee.info/charts/payments-spending-segwit/[about 10% of transactions].
|
||||
Legacy addresses were supplanted by the bech32 family of addresses.
|
||||
|
||||
Currently, the most common implementation of the P2SH function is the
|
||||
multi-signature address script. As the name implies, the underlying
|
||||
script requires more than one signature to prove ownership and therefore
|
||||
spend funds. The bitcoin multi-signature feature is designed to require
|
||||
M signatures (also known as the “threshold”) from a total of N keys,
|
||||
known as an M-of-N multisig, where M is equal to or less than N. For
|
||||
example, Bob the coffee shop owner from <<ch01_intro_what_is_bitcoin>>
|
||||
could use a multisignature address requiring 1-of-2 signatures from a
|
||||
key belonging to him and a key belonging to his spouse, ensuring either
|
||||
of them could sign to spend a transaction output locked to this address.
|
||||
This would be similar to a “joint account” as implemented in traditional
|
||||
banking where either spouse can spend with a single signature. Or
|
||||
Gopesh,((("use cases", "offshore contract services"))) the web designer
|
||||
paid by Bob to create a website, might have a 2-of-3 multisignature
|
||||
address for his business that ensures that no funds can be spent unless
|
||||
at least two of the business partners sign a transaction.
|
||||
|
||||
We will explore how to create transactions that spend funds from P2SH
|
||||
(and multi-signature) addresses in <<transactions>>.
|
||||
|
||||
==== Key Formats
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user