mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-02-02 10:51:24 +00:00
CH04::P2SH: move only
Put it after base58check in the history of addresses, rather than in the advanced addresses section at the end.
This commit is contained in:
David A. Harding
parent
8c5b2fd291
commit
708545a446
165
ch04.asciidoc
165
ch04.asciidoc
@ -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
|
wallets, to indicate that these private keys have been used to produce
|
||||||
compressed public keys.
|
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
|
==== Key Formats
|
||||||
|
|
||||||
((("keys and addresses", "Bitcoin addresses", "key formats")))Both
|
((("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,
|
such as encrypted private keys, script and multisignature addresses,
|
||||||
vanity addresses, and paper wallets.
|
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
|
==== Vanity Addresses
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user