|
|
|
@ -926,6 +926,89 @@ 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
|
|
|
|
|
|
|
|
|
|
((("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.
|
|
|
|
|
|
|
|
|
|
((("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.
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
script hash = RIPEMD160(SHA256(script))
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
$ echo \
|
|
|
|
|
'DUP HASH160 [89abcdefabbaabbaabbaabbaabbaabbaabbaabba] EQUALVERIFY CHECKSIG' > script
|
|
|
|
|
$ bx script-encode < script | bx sha256 | bx ripemd160 \
|
|
|
|
|
| bx base58check-encode --version 5
|
|
|
|
|
3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
[TIP]
|
|
|
|
|
====
|
|
|
|
|
P2SH is not necessarily the same as a multisignature standard
|
|
|
|
|
transaction. A P2SH address _most often_ represents a multi-signature
|
|
|
|
|
script, but it might also represent a script encoding other types of
|
|
|
|
|
transactions.
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
===== Multisignature addresses and P2SH
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
((("keys and addresses", "Bitcoin addresses", "key formats")))Both
|
|
|
|
@ -1236,88 +1319,6 @@ following sections we will look at advanced forms of keys and addresses,
|
|
|
|
|
such as encrypted private keys, script and multisignature addresses,
|
|
|
|
|
vanity addresses, and paper wallets.
|
|
|
|
|
|
|
|
|
|
[[p2sh_addresses]]
|
|
|
|
|
==== Pay-to-Script Hash (P2SH) and Multisig Addresses
|
|
|
|
|
|
|
|
|
|
((("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.
|
|
|
|
|
|
|
|
|
|
((("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.
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
script hash = RIPEMD160(SHA256(script))
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
$ echo \
|
|
|
|
|
'DUP HASH160 [89abcdefabbaabbaabbaabbaabbaabbaabbaabba] EQUALVERIFY CHECKSIG' > script
|
|
|
|
|
$ bx script-encode < script | bx sha256 | bx ripemd160 \
|
|
|
|
|
| bx base58check-encode --version 5
|
|
|
|
|
3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
[TIP]
|
|
|
|
|
====
|
|
|
|
|
P2SH is not necessarily the same as a multisignature standard
|
|
|
|
|
transaction. A P2SH address _most often_ represents a multi-signature
|
|
|
|
|
script, but it might also represent a script encoding other types of
|
|
|
|
|
transactions.
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
===== Multisignature addresses and P2SH
|
|
|
|
|
|
|
|
|
|
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>>.
|
|
|
|
|
|
|
|
|
|
==== Vanity Addresses
|
|
|
|
|
|
|
|
|
|