arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2025-06-08 00:58:49 +00:00
Code Issues Releases Wiki Activity

CH04: minor edits for consistency, voice, and correctness

Browse Source
This commit is contained in:
David A. Harding 2023-02-07 14:38:28 -10:00
parent 3a3d2181d4
commit 23340d43bf
1 changed files with 93 additions and 100 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

191
ch04.asciidoc
View File

@ -31,31 +31,32 @@ the addresses used by modern Bitcoin software.
((("keys and addresses", "overview of", "public key ((("keys and addresses", "overview of", "public key
cryptography")))((("digital currencies", "cryptocurrency")))Public key cryptography")))((("digital currencies", "cryptocurrency")))Public key
cryptography was invented in the 1970s and is a mathematical foundation cryptography was invented in the 1970s and is a mathematical foundation
for computer and information security. for modern computer and information security.
Since the invention of public key cryptography, several suitable Since the invention of public key cryptography, several suitable
mathematical functions, such as prime number exponentiation and elliptic mathematical functions, such as prime number exponentiation and elliptic
curve multiplication, have been discovered. These mathematical functions curve multiplication, have been discovered. These mathematical functions
are practically irreversible, meaning that they are easy to calculate in are easy to calculate in
one direction and infeasible to calculate in the opposite direction. one direction and infeasible to calculate in the opposite direction
using the computers and algorithms available today.
Based on these mathematical functions, cryptography enables the creation Based on these mathematical functions, cryptography enables the creation
of digital secrets and unforgeable digital signatures. Bitcoin uses of unforgeable digital signatures. Bitcoin uses
elliptic curve multiplication as the basis for its cryptography. elliptic curve addition and multiplication as the basis for its cryptography.
In bitcoin, we use public key cryptography to create a key pair that In Bitcoin, we can use public key cryptography to create a key pair that
controls access to bitcoin. The key pair consists of a private key controls access to bitcoin. The key pair consists of a private key
and--derived from it--a unique public key. The public key is used to and a public key derived from the private key. The public key is used to
receive funds, and the private key is used to sign transactions to spend receive funds, and the private key is used to sign transactions to spend
the funds. the funds.
There is a mathematical relationship between the public and the private There is a mathematical relationship between the public and the private
key that allows the private key to be used to generate signatures on key that allows the private key to be used to generate signatures on
messages. This signature can be validated against the public key without messages. These signatures can be validated against the public key without
revealing the private key. revealing the private key.
[TIP] [TIP]
==== ====
((("keys and addresses", "overview of", "key pairs")))In most wallet ((("keys and addresses", "overview of", "key pairs")))In some wallet
implementations, the private and public keys are stored together as a implementations, the private and public keys are stored together as a
_key pair_ for convenience. However, the public key can be calculated _key pair_ for convenience. However, the public key can be calculated
from the private key, so storing only the private key is also possible. from the private key, so storing only the private key is also possible.
@ -63,7 +64,7 @@ from the private key, so storing only the private key is also possible.
((("keys and addresses", "overview of", "private and public key ((("keys and addresses", "overview of", "private and public key
pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic
curve cryptography")))A bitcoin wallet contains a collection of key curve cryptography")))A Bitcoin wallet contains a collection of key
pairs, each consisting of a private key and a public key. The private pairs, each consisting of a private key and a public key. The private
key (k) is a number, usually derived from a number picked at random. key (k) is a number, usually derived from a number picked at random.
From the private key, we From the private key, we
@ -92,7 +93,7 @@ signatures.
((("keys and addresses", "overview of", "private key ((("keys and addresses", "overview of", "private key
generation")))((("warnings and cautions", "private key protection")))A generation")))((("warnings and cautions", "private key protection")))A
private key is simply a number, picked at random. Ownership and control private key is simply a number, picked at random. Control
over the private key is the root of user control over all funds over the private key is the root of user control over all funds
associated with the corresponding Bitcoin public key. The private key is associated with the corresponding Bitcoin public key. The private key is
used to create signatures that are used to spend bitcoin by proving used to create signatures that are used to spend bitcoin by proving
@ -105,21 +106,21 @@ forever lost, too.
[TIP] [TIP]
==== ====
The bitcoin private key is just a number. You can pick your private keys A bitcoin private key is just a number. You can pick your private keys
randomly using just a coin, pencil, and paper: toss a coin 256 times and randomly using just a coin, pencil, and paper: toss a coin 256 times and
you have the binary digits of a random private key you can use in a you have the binary digits of a random private key you can use in a
bitcoin wallet. The public key can then be generated from the private Bitcoin wallet. The public key can then be generated from the private
key. Be careful, though, as any process that's less than completely key. Be careful, though, as any process that's less than completely
random can significantly reduce the security of your private key and the random can significantly reduce the security of your private key and the
bitcoins it controls. bitcoins it controls.
==== ====
The first and most important step in generating keys is to find a secure The first and most important step in generating keys is to find a secure
source of entropy, or randomness. Creating a bitcoin key is essentially source of randomness (which computer scientists call _entropy_). Creating a Bitcoin key is almost
the same as "Pick a number between 1 and 2^256^." The exact method you the same as "Pick a number between 1 and 2^256^." The exact method you
use to pick that number does not matter as long as it is not predictable use to pick that number does not matter as long as it is not predictable
or repeatable. Bitcoin software uses cryptographically-secure random or repeatable. Bitcoin software uses cryptographically-secure random
number generators to produce 256 bits of entropy (randomness). number generators to produce 256 bits of entropy.
More precisely, the private key can be any number between +0+ and +n - More precisely, the private key can be any number between +0+ and +n -
1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less 1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
@ -234,8 +235,7 @@ P = (550662630222773436695787188951685343262506034537775941755001873603891167292
==== ====
[source, pycon] [source, pycon]
---- ----
Python 3.4.0 (default, Mar 30 2014, 19:23:13) Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information. Type "help", "copyright", "credits" or "license" for more information.
>>> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663 >>> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
>>> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240 >>> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
@ -405,7 +405,7 @@ scriptPubKey which acts like a public key, and bitcoin spending is
authorized by a scriptSig which acts like a signature. authorized by a scriptSig which acts like a signature.
[[p2pk]] [[p2pk]]
=== IP Addresses: The Original Address For Bitcoin === IP Addresses: The Original Address For Bitcoin (P2PK)
We've established that Alice can pay Bob by assigning some of her We've established that Alice can pay Bob by assigning some of her
bitcoins to one of Bob's public keys. But how does Alice get one of bitcoins to one of Bob's public keys. But how does Alice get one of
@ -470,7 +470,7 @@ removing them from the stack. It verifies the signature corresponds to
the public key and also commits to (signs) the various fields in the the public key and also commits to (signs) the various fields in the
transaction. If the signature is correct, OP_CHECKSIG replaces itself transaction. If the signature is correct, OP_CHECKSIG replaces itself
on the stack with the value 1; if the signature was not correct, it on the stack with the value 1; if the signature was not correct, it
replaces itself with a 0. If the top of the stack is non-zero at the replaces itself with a 0. If there's a non-zero item on top of the stack at the
end of evaluation, the script passes. If all scripts in a transaction end of evaluation, the script passes. If all scripts in a transaction
pass, and all of the other details about the transaction are valid, then pass, and all of the other details about the transaction are valid, then
full nodes will consider the transaction to be valid. full nodes will consider the transaction to be valid.
@ -497,14 +497,14 @@ using Network Address Translation (NAT).
This brings us back to the problem of receivers like Bob having to give This brings us back to the problem of receivers like Bob having to give
spenders like Alice a long public key. The shortest version of Bitcoin spenders like Alice a long public key. The shortest version of Bitcoin
public keys known to the developers of early Bitcoin were 65 bytes, or public keys known to the developers of early Bitcoin were 65 bytes, the
about 130 characters when written in hexadecimal. However, Bitcoin equivalent of 130 characters when written in hexadecimal. However, Bitcoin
already contained several data structures much larger than 65 bytes already contained several data structures much larger than 65 bytes
which needed to be securely referenced in other parts of Bitcoin using the which needed to be securely referenced in other parts of Bitcoin using the
smallest amount of data that was secure. smallest amount of data that was secure.
Bitcoin accomplishes that with a _hash function_, a function which takes Bitcoin accomplishes that with a _hash function_, a function which takes
a potentially large amount of data and scrambles (hashes) it into a a potentially large amount of data, scrambles it (hashes it), and outputs a
fixed amount of data. A cryptographic hash function will always produce fixed amount of data. A cryptographic hash function will always produce
the same output when given the same input, and a secure function will the same output when given the same input, and a secure function will
also make it impractical for somebody to choose a different input that also make it impractical for somebody to choose a different input that
@ -515,7 +515,7 @@ produce output _X_.
For example, imagine I want to ask you a question and also give you my For example, imagine I want to ask you a question and also give you my
answer in a form that you can't read immediately. Let's say the answer in a form that you can't read immediately. Let's say the
question is, "in what year did Satoshi Nakamoto start working on question is, "in what year did Satoshi Nakamoto start working on
Bitcoin?" I'll give you my commitment to the answer in the form of Bitcoin?" I'll give you a commitment to my answer in the form of
output from the SHA256 hash function, the function most commonly used in output from the SHA256 hash function, the function most commonly used in
Bitcoin: Bitcoin:
@ -616,9 +616,9 @@ look at compact encoding and reliable checksums.
[[base58]] [[base58]]
=== Base58Check Encoding === Base58Check Encoding
((("keys and addresses", "Bitcoin addresses", "Base58 and Base58check ((("keys and addresses", "Bitcoin addresses", "base58 and base58check
encoding")))((("Base58 and Base58check encoding", encoding")))((("base58 and base58check encoding",
id="base5804")))((("addresses", "Base58 and Base58check encoding", id="base5804")))((("addresses", "base58 and base58check encoding",
id="Abase5804")))In order to represent long numbers in a compact way, id="Abase5804")))In order to represent long numbers in a compact way,
using fewer symbols, many computer systems use mixed-alphanumeric using fewer symbols, many computer systems use mixed-alphanumeric
representations with a base (or radix) higher than 10. For example, representations with a base (or radix) higher than 10. For example,
@ -626,44 +626,41 @@ whereas the traditional decimal system uses 10 numerals, 0 through 9,
the hexadecimal system uses 16, with the letters A through F as the six the hexadecimal system uses 16, with the letters A through F as the six
additional symbols. A number represented in hexadecimal format is additional symbols. A number represented in hexadecimal format is
shorter than the equivalent decimal representation. Even more compact, shorter than the equivalent decimal representation. Even more compact,
Base64 representation uses 26 lowercase letters, 26 capital letters, 10 base64 representation uses 26 lowercase letters, 26 capital letters, 10
numerals, and 2 more characters such as “`+`” and "/" to numerals, and 2 more characters such as "+" and "/" to
transmit binary data over text-based media such as email. Base64 is most transmit binary data over text-based media such as email.
commonly used to add binary attachments to email.
Base58 is a text-based binary-encoding format that offers a balance Base58 is a similar encoding to
between compact representation and readability. Base58 is similar to base64, using upper- and lowercase letters and numbers,
Base64, using upper- and lowercase letters and numbers,
but omitting some characters that are frequently mistaken for one but omitting some characters that are frequently mistaken for one
another and can appear identical when displayed in certain fonts. another and can appear identical when displayed in certain fonts.
Specifically, Base58 is Base64 without the 0 (number zero), O (capital Specifically, base58 is base64 without the 0 (number zero), O (capital
o), l (lower L), I (capital i), and the symbols “`+`” and o), l (lower L), I (capital i), and the symbols "+" and
"/". Or, more simply, it is a set of lowercase and capital letters and "/". Or, more simply, it is a set of lowercase and capital letters and
numbers without the four (0, O, l, I) just mentioned. <<base58alphabet>> numbers without the four (0, O, l, I) just mentioned. <<base58alphabet>>
shows the full Base58 alphabet. shows the full base58 alphabet.
[[base58alphabet]] [[base58alphabet]]
.Bitcoin's Base58 alphabet .Bitcoin's base58 alphabet
==== ====
---- ----
123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
---- ----
==== ====
To add extra security against typos or transcription errors, Base58Check To add extra security against typos or transcription errors, base58check
is a Base58 encoding format, frequently used in Bitcoin, which has a adds an error-checking code to the base58 alphabet. The checksum is an additional four bytes
built-in error-checking code. The checksum is an additional four bytes
added to the end of the data that is being encoded. The checksum is added to the end of the data that is being encoded. The checksum is
derived from the hash of the encoded data and can therefore be used to derived from the hash of the encoded data and can therefore be used to
detect transcription and typing errors. When presented with detect transcription and typing errors. When presented with
Base58Check code, the decoding software will calculate the checksum of base58check code, the decoding software will calculate the checksum of
the data and compare it to the checksum included in the code. If the two the data and compare it to the checksum included in the code. If the two
do not match, an error has been introduced and the Base58Check data is do not match, an error has been introduced and the base58check data is
invalid. This prevents a mistyped Bitcoin address from being accepted by invalid. This prevents a mistyped Bitcoin address from being accepted by
the wallet software as a valid destination, an error that would the wallet software as a valid destination, an error that would
otherwise result in loss of funds. otherwise result in loss of funds.
To convert data (a number) into a Base58Check format, we first add a To convert data (a number) into a base58check format, we first add a
prefix to the data, called the "version byte," which serves to easily prefix to the data, called the "version byte," which serves to easily
identify the type of data that is encoded. For example, the prefix zero identify the type of data that is encoded. For example, the prefix zero
(0x00 in hex) indicates that the data should be used as the commitment (hash) in (0x00 in hex) indicates that the data should be used as the commitment (hash) in
@ -682,24 +679,24 @@ four bytes. These four bytes serve as the error-checking code, or
checksum. The checksum is appended to the end. checksum. The checksum is appended to the end.
The result is composed of three items: a prefix, the data, and a The result is composed of three items: a prefix, the data, and a
checksum. This result is encoded using the Base58 alphabet described checksum. This result is encoded using the base58 alphabet described
previously. <<base58check_encoding>> illustrates the Base58Check previously. <<base58check_encoding>> illustrates the base58check
encoding process. encoding process.
[[base58check_encoding]] [[base58check_encoding]]
.Base58Check encoding: a Base58, versioned, and checksummed format for unambiguously encoding bitcoin data .Base58Check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data
image::images/mbc2_0406.png["Base58CheckEncoding"] image::images/mbc2_0406.png["Base58CheckEncoding"]
In Bitcoin, more than just addresses are presented to the user in In Bitcoin, other data besides public key commitmens are presented to the user in
Base58Check encoding to make it compact, easy to read, and easy to detect base58check encoding to make that data compact, easy to read, and easy to detect
errors. The version prefix in Base58Check encoding is used to create errors. The version prefix in base58check encoding is used to create
easily distinguishable formats, which when encoded in Base58 contain easily distinguishable formats, which when encoded in base58 contain
specific characters at the beginning of the Base58Check-encoded payload. specific characters at the beginning of the base58check-encoded payload.
These characters make it easy for humans to identify the type of data These characters make it easy for humans to identify the type of data
that is encoded and how to use it. This is what differentiates, for that is encoded and how to use it. This is what differentiates, for
example, a Base58Check-encoded Bitcoin address that starts with a 1 from example, a base58check-encoded Bitcoin address that starts with a 1 from
a Base58Check-encoded private key WIF that starts with a 5. Some example a base58check-encoded private key WIF that starts with a 5. Some example
version prefixes and the resulting Base58 characters are shown in version prefixes and the resulting base58 characters are shown in
<<base58check_versions>>. <<base58check_versions>>.
[[base58check_versions]] [[base58check_versions]]
@ -715,7 +712,7 @@ version prefixes and the resulting Base58 characters are shown in
| BIP-32 Extended Public Key | 0x0488B21E | xpub | BIP-32 Extended Public Key | 0x0488B21E | xpub
|======= |=======
Putting together public keys, hash-based commitments, and Base58Check Putting together public keys, hash-based commitments, and base58check
encocding, we can see the illustration of the conversion of a public key encocding, we can see the illustration of the conversion of a public key
into a Bitcoin address in <<pubkey_to_address>>. into a Bitcoin address in <<pubkey_to_address>>.
@ -728,7 +725,7 @@ image::images/mbc2_0405.png["pubkey_to_address"]
The Bitcoin Explorer commands (see <<appdx_bx>>) make it easy to write The Bitcoin Explorer commands (see <<appdx_bx>>) make it easy to write
shell scripts and command-line "pipes" that manipulate bitcoin keys, shell scripts and command-line "pipes" that manipulate bitcoin keys,
addresses, and transactions. You can use Bitcoin Explorer to decode the addresses, and transactions. You can use Bitcoin Explorer to decode the
Base58Check format on the command line. base58check format on the command line.
We use the +base58check-decode+ command to decode the uncompressed key: We use the +base58check-decode+ command to decode the uncompressed key:
@ -769,8 +766,8 @@ alternative encoding for public keys that used only 33 bytes and which
was backwards compatible with all Bitcoin full nodes at the time, was backwards compatible with all Bitcoin full nodes at the time,
so there was no need to change the Bitcoin protocol. Those 33-byte so there was no need to change the Bitcoin protocol. Those 33-byte
public keys are known as _compressed public keys_ and the original 65 public keys are known as _compressed public keys_ and the original 65
byte keys are known as _uncompressed public keys_. Smaller public keys byte keys are known as _uncompressed public keys_. Using smaller public keys
was smaller transactions, allowing more payments to be made in the same results in smaller transactions, allowing more payments to be made in the same
block. block.
As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an
@ -891,12 +888,12 @@ scriptPubKey to commit to a _redemption script_ (_redeemScript_). When
Bob spends his bitcoins, his scriptSig need to provide a redeemScript Bob spends his bitcoins, his scriptSig need to provide a redeemScript
that matches the commitment and also any data necessary to satisfy the that matches the commitment and also any data necessary to satisfy the
redeemScript (such as signatures). Let's start by imagining Bob wants redeemScript (such as signatures). Let's start by imagining Bob wants
to require two signatures from different wallets he controls in to require two signatures to spend his bitcoins, one signature from his
order to spend his bitcoins. He puts those conditions into a desktop wallet and one from a hardware signing device. He puts those
redeemScript: conditions into a redeemScript:
---- ----
<pubkey1> OP_CHECKSIGVERIFY <pubkey2> OP_CHECKSIG <public key 1> OP_CHECKSIGVERIFY <public key 2> OP_CHECKSIG
---- ----
He then creates a commitment to the redeemScript using the same He then creates a commitment to the redeemScript using the same
@ -939,7 +936,7 @@ The script is executed and, if it passes and all of the other
transaction details are correct, the transaction is valid. transaction details are correct, the transaction is valid.
Addresses for Pay-to-Script-Hash (P2SH) are also created with Addresses for Pay-to-Script-Hash (P2SH) are also created with
Base58Check. The version prefix is set to 5, which results in an 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 encoded address starting with a +3+. An example of a P2SH address is
+3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the
Bitcoin Explorer commands +script-encode+, +sha256+, +ripemd160+, and Bitcoin Explorer commands +script-encode+, +sha256+, +ripemd160+, and
@ -961,7 +958,7 @@ script, but it might also represent a script encoding other types of
transactions. transactions.
==== ====
P2PKH and P2SH are the only two script templates used with Base58Check 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, encoding. They are now known as legacy addresses and, as of early 2023,
are only used in are only used in
https://transactionfee.info/charts/payments-spending-segwit/[about 10% of transactions]. https://transactionfee.info/charts/payments-spending-segwit/[about 10% of transactions].
@ -969,8 +966,7 @@ Legacy addresses were supplanted by the bech32 family of addresses.
[[p2sh_collision_attacks]] [[p2sh_collision_attacks]]
.P2SH collision attacks .P2SH collision attacks
[WARNING] ****
====
All addresses based on hash functions are theoretically vulnerable to an All addresses based on hash functions are theoretically vulnerable to an
attacker finding two different inputs (e.g. redeemScripts) that produce attacker finding two different inputs (e.g. redeemScripts) that produce
the same hash function output (commitment). For addresses created the same hash function output (commitment). For addresses created
@ -980,7 +976,7 @@ strength of the hash algorithm. For a secure 160-bit algorithm like
HASH160, the probability is 1-in-2^160^. This is a _second pre-image HASH160, the probability is 1-in-2^160^. This is a _second pre-image
attack_. attack_.
However, this changes when an attacker is able to influence the input However, this changes when an attacker is able to influence the original input
value. For example, an attacker participates in the creation of a value. For example, an attacker participates in the creation of a
multisignature script where the attacker doesn't need to submit his multisignature script where the attacker doesn't need to submit his
public key until after he learns all of the other party's public keys. public key until after he learns all of the other party's public keys.
@ -1010,13 +1006,13 @@ collision attacks but a simple solution which doesn't require any
special knowledge on the part of wallet developers is to simply use special knowledge on the part of wallet developers is to simply use
a stronger hash function. Later upgrades to Bitcoin made that possible a stronger hash function. Later upgrades to Bitcoin made that possible
and newer Bitcoin addresses provide at least 128 bits of collision and newer Bitcoin addresses provide at least 128 bits of collision
resistance--a number of hash operations that would require all current resistance. To perform 2^128^ hash operations would require all current
Bitcoin miners about about 50 billion years to perform. Bitcoin miners about 50 billion years to perform.
Although we do not believe there is any immediate threat to anyone Although we do not believe there is any immediate threat to anyone
creating new P2SH addresses, we recommend all new wallets use newer creating new P2SH addresses, we recommend all new wallets use newer
types of addresses to eliminate address collision attacks as a concern. types of addresses to eliminate address collision attacks as a concern.
==== ****
=== Bech32 addresses === Bech32 addresses
@ -1039,12 +1035,12 @@ need Alice's wallet to pay him using a different type of script. That
would require Alice's wallet to upgrade to supporting the new scripts. would require Alice's wallet to upgrade to supporting the new scripts.
At first, Bitcoin developers proposed BIP142, which would continue using At first, Bitcoin developers proposed BIP142, which would continue using
Base58Check with a new version byte, similar to the P2SH upgrade. But base58check with a new version byte, similar to the P2SH upgrade. But
getting all wallets to upgrade to new scripts with a new Base58Check getting all wallets to upgrade to new scripts with a new base58check
version was expected to require almost as much work as getting them to version was expected to require almost as much work as getting them to
upgrade to an entirely new address format, so several Bitcoin upgrade to an entirely new address format, so several Bitcoin
contributors set out to design the best possible address format. They contributors set out to design the best possible address format. They
identified several problems with Base58Check: identified several problems with base58check:
- Its mixed case presentation made it inconvenient to read aloud or - Its mixed case presentation made it inconvenient to read aloud or
transcribe. Try reading one of the legacy addresses in this chapter transcribe. Try reading one of the legacy addresses in this chapter
@ -1078,19 +1074,19 @@ bech32 (pronounced with a soft "ch", as in "besh thirty-two"). The
"bech" stands for BCH, the initials of the three individuals who "bech" stands for BCH, the initials of the three individuals who
discovered the cyclic code in 1959 and 1960 upon which bech32 is based. discovered the cyclic code in 1959 and 1960 upon which bech32 is based.
The "32" stands for the number of characters in the bech32 alphabet The "32" stands for the number of characters in the bech32 alphabet
(similar to the 58 in Base58Check). (similar to the 58 in base58check).
- Bech32 uses only numbers and a single case of letters (preferably - Bech32 uses only numbers and a single case of letters (preferably
rendered in lowercase). Despite its alphabet being almost half the rendered in lowercase). Despite its alphabet being almost half the
size of the Base58Check alphabet, bech32 addresses are only slightly size of the base58check alphabet, bech32 addresses are only slightly
longer than the longest equivalent P2PKH legacy addresses. longer than the longest equivalent P2PKH legacy addresses.
- Bech32 can both detect and help correct errors. In an address of an - Bech32 can both detect and help correct errors. In an address of an
expected length, it is mathematically guaranteed to detect any error expected length, it is mathematically guaranteed to detect any error
affecting four characters or less; that's more reliable than affecting four characters or less; that's more reliable than
Base58Check. For longer errors, it will fail to detect them less than base58check. For longer errors, it will fail to detect them less than
one time in a billion, which is roughly the same reliability as one time in a billion, which is roughly the same reliability as
Base58Check. Even better, for an address typed with just a few base58check. Even better, for an address typed with just a few
errors, it can tell the user where those errors occurred, allowing them errors, it can tell the user where those errors occurred, allowing them
quickly correct minor transcription mistakes. See <<bech32_typo_detection>> quickly correct minor transcription mistakes. See <<bech32_typo_detection>>
for an example of an address entered with errors. for an example of an address entered with errors.
@ -1119,9 +1115,9 @@ image::images/bech32-qrcode-uc-lc.png["The same bech32 address QR encoded in upp
- Bech32 takes advantage of an upgrade mechanism designed as part of - Bech32 takes advantage of an upgrade mechanism designed as part of
segwit to make it possible for spender wallets to be able to pay segwit to make it possible for spender wallets to be able to pay
output types that aren't in use yet. The goal was to allow developers output types that aren't in use yet. The goal was to allow developers
to build a wallet today that allows spending to a bech32 address which to build a wallet today that allows spending to a bech32 address
will work without changes even years from now when a later protocol and have that wallet remain able to spend to bech32 addresses for
upgrade adds a new feature for users who receive bitcoins. It was users of new features added in future protocol upgrades. It was
hoped that we might never again need to go through the system-wide hoped that we might never again need to go through the system-wide
upgrade cycles necessary to allow people to fully use P2SH and segwit. upgrade cycles necessary to allow people to fully use P2SH and segwit.
@ -1133,8 +1129,9 @@ errors only apply if the length of the address you enter into a wallet
is the same length of the original address. If you add or remove any is the same length of the original address. If you add or remove any
characters during transcription, the guarantee doesn't apply and your characters during transcription, the guarantee doesn't apply and your
wallet may spend funds to a wrong address. However, even without the wallet may spend funds to a wrong address. However, even without the
guarantee, it was thought that it would be unlikely that a user adding guarantee, it was thought that it would be very unlikely that a user adding
or removing characters would produce a string with a valid checksum. or removing characters would produce a string with a valid checksum, ensuring
users' funds were safe.
Unfortunately, the choice for one of the constants in the bech32 Unfortunately, the choice for one of the constants in the bech32
algorithm just happened to make it very easy to add or remove the letter algorithm just happened to make it very easy to add or remove the letter
@ -1256,8 +1253,7 @@ Checksum::
//TODO //TODO
Let's illustrate these rules by walking through an example of creating Let's illustrate these rules by walking through an example of creating
bech32 and bech32m addresses. We'll use the bech32 and bech32m addresses. For all of the following examples, we'll use the
For all of the following examples, we'll use the
https://github.com/sipa/bech32/tree/master/ref[bech32m reference code https://github.com/sipa/bech32/tree/master/ref[bech32m reference code
for Python]. for Python].
@ -1325,7 +1321,7 @@ deeper look at what's happening:
wget https://raw.githubusercontent.com/sipa/bech32/master/ref/python/segwit_addr.py wget https://raw.githubusercontent.com/sipa/bech32/master/ref/python/segwit_addr.py
2023-01-30 11:59:10 (46.3 MB/s) - ‘segwit_addr.py’ saved [5022/5022] 2023-01-30 11:59:10 (46.3 MB/s) - ‘segwit_addr.py’ saved [5022/5022]
python $ python
>>> from segwit_addr import * >>> from segwit_addr import *
>>> from binascii import unhexlify >>> from binascii import unhexlify
@ -1411,7 +1407,7 @@ support for new Bitcoin features as soon as they become available.
((("public and private keys", "private key formats")))The private key ((("public and private keys", "private key formats")))The private key
can be represented in a number of different formats, all of which can be represented in a number of different formats, all of which
correspond to the same 256-bit number. <<table_4-2>> shows three common correspond to the same 256-bit number. <<table_4-2>> shows several common
formats used to represent private keys. Different formats are used in formats used to represent private keys. Different formats are used in
different circumstances. Hexadecimal and raw binary formats are used different circumstances. Hexadecimal and raw binary formats are used
internally in software and rarely shown to users. The WIF is used for internally in software and rarely shown to users. The WIF is used for
@ -1450,11 +1446,11 @@ For more information, see <<hd_wallets>>.
|Type|Prefix|Description |Type|Prefix|Description
| Raw | None | 32 bytes | Raw | None | 32 bytes
| Hex | None | 64 hexadecimal digits | Hex | None | 64 hexadecimal digits
| WIF | 5 | Base58Check encoding: Base58 with version prefix of 128- and 32-bit checksum | WIF | 5 | Base58Check encoding: base58 with version prefix of 128- and 32-bit checksum
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding | WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|======= |=======
<<table_4-3>> shows the private key generated in these three formats. <<table_4-3>> shows the private key generated in several different formats.
[[table_4-3]] [[table_4-3]]
.Example: Same key, different formats .Example: Same key, different formats
@ -1483,7 +1479,6 @@ $ bx wif-to-ec KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
---- ----
[[comp_priv]] [[comp_priv]]
===== Compressed private keys ===== Compressed private keys
@ -1516,14 +1511,14 @@ confusion
|======= |=======
Notice that the hex-compressed private key format has one extra byte at Notice that the hex-compressed private key format has one extra byte at
the end (01 in hex). While the Base58 encoding version prefix is the the end (01 in hex). While the base58 encoding version prefix is the
same (0x80) for both WIF and WIF-compressed formats, the addition of one same (0x80) for both WIF and WIF-compressed formats, the addition of one
byte on the end of the number causes the first character of the Base58 byte on the end of the number causes the first character of the base58
encoding to change from a 5 to either a _K_ or _L_. Think of this as the encoding to change from a 5 to either a _K_ or _L_. Think of this as the
Base58 equivalent of the decimal encoding difference between the number base58 equivalent of the decimal encoding difference between the number
100 and the number 99. While 100 is one digit longer than 99, it also 100 and the number 99. While 100 is one digit longer than 99, it also
has a prefix of 1 instead of a prefix of 9. As the length changes, it has a prefix of 1 instead of a prefix of 9. As the length changes, it
affects the prefix. In Base58, the prefix 5 changes to a _K_ or _L_ as affects the prefix. In base58, the prefix 5 changes to a _K_ or _L_ as
the length of the number increases by one byte. the length of the number increases by one byte.
Remember, these formats are _not_ used interchangeably. In a newer Remember, these formats are _not_ used interchangeably. In a newer
@ -1542,12 +1537,11 @@ compressed. The compressed public keys will be used to produce Bitcoin
addresses and those will be used in transactions. When exporting private addresses and those will be used in transactions. When exporting private
keys from a new wallet that implements compressed public keys, the WIF keys from a new wallet that implements compressed public keys, the WIF
is modified, with the addition of a one-byte suffix +01+ to the private is modified, with the addition of a one-byte suffix +01+ to the private
key. The resulting Base58Check-encoded private key is called a key. The resulting base58check-encoded private key is called a
"compressed WIF" and starts with the letter _K_ or _L_, instead of "compressed WIF" and starts with the letter _K_ or _L_, instead of
starting with "5" as is the case with WIF-encoded (noncompressed) keys starting with "5" as is the case with WIF-encoded (uncompressed) keys
from older wallets. from older wallets.
[TIP] [TIP]
==== ====
"Compressed private keys" is a misnomer! They are not compressed; "Compressed private keys" is a misnomer! They are not compressed;
@ -1564,7 +1558,6 @@ because it has the added +01+ suffix to distinguish it from an
following sections we will look at advanced forms of keys and addresses, following sections we will look at advanced forms of keys and addresses,
such as vanity addresses and paper wallets. such as vanity addresses and paper wallets.
==== Vanity Addresses ==== Vanity Addresses
((("keys and addresses", "advanced forms", "vanity ((("keys and addresses", "advanced forms", "vanity
@ -1572,7 +1565,7 @@ addresses")))((("vanity addresses", id="vanity04")))((("addresses",
"vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin "vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin
addresses that contain human-readable messages. For example, addresses that contain human-readable messages. For example,
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
the letters forming the word "Love" as the first four Base-58 letters. the letters forming the word "Love" as the first four base58 letters.
Vanity addresses require generating and testing billions of candidate Vanity addresses require generating and testing billions of candidate
private keys, until a Bitcoin address with the desired pattern is found. private keys, until a Bitcoin address with the desired pattern is found.
Although there are some optimizations in the vanity generation Although there are some optimizations in the vanity generation
@ -1601,7 +1594,7 @@ it means for the security of Eugenia's charity.((("use cases",
===== Generating vanity addresses ===== Generating vanity addresses
It's important to realize that a Bitcoin address is simply a number It's important to realize that a Bitcoin address is simply a number
represented by symbols in the Base58 alphabet. The search for a pattern represented by symbols in the base58 alphabet. The search for a pattern
like "1Kids" can be seen as searching for an address in the range from like "1Kids" can be seen as searching for an address in the range from
+1Kids11111111111111111111111111111+ to +1Kids11111111111111111111111111111+ to
+1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^ +1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^