@ -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
wallets, to indicate that these private keys have been used to produce
compressed public keys.
compressed public keys.
[[p2sh_addresses]]
[[p2sh]]
==== Pay-to-Script Hash (P2SH) and Multisig Addresses
=== Legacy Pay-to-Script-Hash (P2SH)
((("keys and addresses", "advanced forms", "pay-to-script hash and
As we've seen in preceding sections, someone receiving Bitcoins (like
multisig addresses")))((("Pay-to-Script-Hash (P2SH)", "multisig
Bob) can require payments to him contain certain constraints in their
addresses and")))((("multisig addresses")))((("addresses", "multisig
scriptPubKeys. Bob will need to fulfill those constraints using a
addresses")))As we know, traditional Bitcoin addresses begin with the
scriptSig when he spends those bitcoins. In <<p2pk>>, the constraint
number “1” and are derived from the public key, which is derived from
was simply that the scriptSig needed to provide an appropriate
the private key. Although anyone can send bitcoin to a “1” address,
signature. In <<p2pkh>>, an appropriate public key also needed to be
that bitcoin can only be spent by presenting the corresponding private
provided.
key signature and public key hash.
In order for a spender (like Alice) to place the constraints Bob wants
((("bitcoin improvement proposals", "Pay to Script Hash
in the scriptPubKey she uses to pay him, Bob needs to communicate those
(BIP-16)")))Bitcoin addresses that begin with the number “3” are
constraints to her. This is similar to the problem of Bob needing to
pay-to-script hash (P2SH) addresses, sometimes erroneously called
communicate his public key to her. Like that problem, where
multisignature or multisig addresses. They designate the beneficiary of
public keys can be fairly large, the constraints Bob uses can also be
a Bitcoin transaction as the hash of a script, instead of the owner of a
quite large---potentially thousands of bytes. That's not only thousands
public key. The feature was introduced in January 2012 with BIP-16 (see
of bytes which need to be communicated to Alice, but thousands of bytes
<<appdxbitcoinimpproposals>>), and is being widely adopted because it
for which she needs to pay transaction fees every time she wants to spend
provides the opportunity to add functionality to the address itself.
money to Bob. However, the solution of using hash functions to create
Unlike transactions that "send" funds to traditional “1” Bitcoin
small commitments to large amounts of data also applies here.
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
The BIP16 upgrade to the Bitcoin protocol in 2013 allows a
key hash and one private key signature as proof of ownership. The
scriptPubKey to commit to a _redemption script_ (_redeemScript_). When
requirements are designated at the time the address is created, within
Bob spends his bitcoins, his scriptSig need to provide a redeemScript
the script, and all inputs to this address will be encumbered with the
that matches the commitment and also any data necessary to satisfy the
same requirements.
redeemScript (such as signatures). Let's start by imagining Bob wants
to require two signatures from different wallets he controls in
A P2SH address is created from a transaction script, which defines who
order to spend his bitcoins. He puts those conditions into a
can spend a transaction output (for more details, see <<p2sh>>).
redeemScript:
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:
<pubkey1> OP_CHECKSIGVERIFY <pubkey2> OP_CHECKSIG
----
----
script hash = RIPEMD160(SHA256(script))
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
The resulting "script hash" is encoded with Base58Check with a version
template:
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+,
OP_HASH160 <commitment> OP_EQUAL
+sha256+, +ripemd160+, and +base58check-encode+ (see <<appdx_bx>>) as
----
follows:
[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 \
$ echo \
@ -981,33 +1017,18 @@ $ bx script-encode < script | bx sha256 | bx ripemd160 \
[TIP]
[TIP]
====
====
P2SH is not necessarily the same as a multisignature standard
P2SH is not necessarily the same as a multisignature
transaction. A P2SH address _most often_ represents a multi- signature
transaction. A P2SH address _most often_ represents a multisignature
script, but it might also represent a script encoding other types of
script, but it might also represent a script encoding other types of
transactions.
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,
Currently, the most common implementation of the P2SH function is the
are only used in
multi-signature address script. As the name implies, the underlying
https://transactionfee.info/charts/payments-spending-segwit/[about 10% of transactions].
script requires more than one signature to prove ownership and therefore
Legacy addresses were supplanted by the bech32 family of addresses.
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
==== Key Formats
David A. Harding
1 year ago