From 4fc698ef10fdd1ae76f93b8a8c831cb66354b88d Mon Sep 17 00:00:00 2001 From: rgordon Date: Sat, 30 Sep 2023 00:17:32 +0000 Subject: [PATCH] Edited ch04_keys.adoc with Atlas code editor --- ch04_keys.adoc | 65 ++++++++++++++++++++++++++------------------------ 1 file changed, 34 insertions(+), 31 deletions(-) diff --git a/ch04_keys.adoc b/ch04_keys.adoc index b8e51a6d..39c483a6 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -621,7 +621,7 @@ but omitting some characters that are frequently mistaken for one another and can appear identical when displayed in certain fonts. Specifically, base58 is base64 without the 0 (number zero), O (capital 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. <> shows the full base58 alphabet. @@ -1171,21 +1171,21 @@ need to know about the HRPs already chosen, shown in | Bitcoin testnet |=== -The HRP is followed by a separator, the number "1". Earlier proposals +The HRP is followed by a separator, the number "1." Earlier proposals for a protocol separator used a colon but some operating systems and -applications which allow a user to double click on a word to highlight +applications that allow a user to double-click a word to highlight it for copy and pasting won't extend the highlighting to and past a colon. A number ensured double-click highlighting would work with any program that supports bech32m strings in general (which include other numbers). The number "1" was chosen because bech32 strings don't otherwise use it in order to prevent accidental transliteration between -the number "1" and the lowercase letter "l". +the number "1" and the lowercase letter "l." -The other part of a bech32m address is called the "data part". There +The other part of a bech32m address is called the "data part." There are three elements to this part: Witness version:: - A single byte which encodes as a single character + A single byte that encodes as a single character in a bech32m Bitcoin address immediately following the separator. This letter represents the segwit version. The letter "q" is the encoding of "0" for segwit v0, the initial version of segwit where @@ -1213,7 +1213,7 @@ bech32 and bech32m addresses. For all of the following examples, we'll use the https://github.com/sipa/bech32/tree/master/ref[bech32m reference code for Python]. -Let's start by generating four output scripts, one for each of the +We'll start by generating four output scripts, one for each of the different segwit outputs in use at the time of publication, plus one for a future segwit version that doesn't yet have a defined meaning. The scripts are listed in <>. @@ -1233,7 +1233,12 @@ scripts are listed in <>. [[scripts_for_diff_segwit_outputs]] .Scripts for different types of segwit outputs [cols="1,1"] +[options="header"] |=== + +|Output type +|Example script + | P2WPKH | OP_0 2b626ed108ad00a944bb2922a309844611d25468 @@ -1249,7 +1254,7 @@ scripts are listed in <>. For the P2WPKH output, the witness program contains a commitment constructed in exactly the same way as the commitment for a P2PKH output seen in <>. A public key is passed into a SHA256 hash -function. The resultant 32 byte digest is then passed into a RIPEMD-160 +function. The resultant 32-byte digest is then passed into a RIPEMD-160 hash function. The digest of that function (the commitment) is placed in the witness program. @@ -1261,7 +1266,7 @@ some cases; for details, see <>. A result of using SHA256 without RIPEMD160 is that P2WSH commitments are 32 bytes (256 bits) instead 20 bytes (160 bits). -For the Pay-to-Taproot (P2TR) output, the witness program is a point on +For the pay-to-taproot (P2TR) output, the witness program is a point on the secp256k1 curve. It may be a simple public key, but in most cases it should be a public key that commits to some additional data. We'll learn more about that commitment in <>. @@ -1297,10 +1302,10 @@ encode(hrp, witver, witprog) 'bc1sqqqqkfw08p' ---- -If we open the file +segwit_addr.py+ and look at what the code is doing, +If we open the file __segwit_addr.py__ and look at what the code is doing, the first thing we will notice is the sole difference between bech32 (used for segwit v0) and bech32m -(used for later segwit versions) is the constant. +(used for later segwit versions) is the constant: ---- BECH32_CONSTANT = 1 @@ -1357,11 +1362,11 @@ When implementing bech32m encoding or decoding, we very strongly recommend that you use the test vectors provided in BIP350. We also ask that you ensure your code passes the test vectors related to paying future segwit versions that haven't been defined yet. This will help make your -software is usable for many years to come even if you aren't able to add +software usable for many years to come even if you aren't able to add support for new Bitcoin features as soon as they become available. [[priv_formats]] -==== Private key formats +==== Private Key Formats The private key can be represented in a number of different formats, all of which @@ -1372,7 +1377,7 @@ internally in software and rarely shown to users. The WIF is used for import/export of keys between wallets and often used in QR code (barcode) representations of private keys. -.Modern relevancy of private key formats +.Modern Relevancy of Private Key Formats **** Early Bitcoin wallet software generated one or more independent private keys when a new user wallet was initialized. When the initial set of @@ -1385,7 +1390,7 @@ Later Bitcoin wallets began using deterministic wallets where all private keys are generated from a single seed value. These wallets only ever need to be backed up once for typical onchain use. However, if a user exports a single private key from one of these wallets and an -attacker acquires that key plus some non-private data about the wallet, +attacker acquires that key plus some nonprivate data about the wallet, they can potentially derive any private key in the wallet--allowing the attacker to steal all of the wallet funds. Additionally, keys cannot be imported into deterministic wallets. This means almost no modern @@ -1403,7 +1408,7 @@ For more information, see <>. |======= |Type|Prefix|Description | 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 |======= @@ -1424,10 +1429,9 @@ number, the same private key. They look different, but any one format can easily be converted to any other format. [[comp_priv]] -===== Compressed private keys +==== Compressed Private Keys - -the commonly used term "compressed private key" is a misnomer, because when a private +The commonly used term "compressed private key" is a misnomer, because when a private key is exported as WIF-compressed it is actually one byte _longer_ than an "uncompressed" private key. That is because the private key has an added one-byte suffix (shown as 01 in hex in <>), which @@ -1510,7 +1514,7 @@ Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoins in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same -Elliptic Curve Cryptography (ECC) and SHA as any other address. You can +elliptic curve cryptography (ECC) and SHA as any other address. You can no more easily find the private key of an address starting with a vanity pattern than you can any other address. @@ -1592,7 +1596,7 @@ Vanity addresses were popular in the early years of Bitcoin but have almost entirely disappeared from use as of 2023. There are two likely causes for this trend: -1. Deterministic wallets: as we saw in <>, it's possible to +Deterministic wallets:: As we saw in <>, it's possible to back up every key in most modern wallets by simply writing down a few words or characters. This is achieved by deriving every key in the wallet from those words or characters using a deterministic algorithm. @@ -1602,9 +1606,9 @@ create. More practically, most wallets using deterministic key generation simply don't allow importing a private key or key tweak from a vanity generator. -2. Avoiding address reuse: using a vanity address to receive multiple +Avoiding address reuse:: Using a vanity address to receive multiple payments to the same address creates a link between all of those -payments. This might be acceptable to Eugenia if her non-profit needs +payments. This might be acceptable to Eugenia if her nonprofit needs to report its income and expenditures to a tax authority anyway. However, it also reduces the privacy of people who either pay Eugenia or receive payments from her. For example, Alice may want to donate @@ -1614,7 +1618,7 @@ gives discount pricing to Eugenia. // https://github.com/MakisChristou/vanitybech We don't expect to see many vanity addresses in -the future unless the above problems are solved. +the future unless the preceding problems are solved. [[paper_wallets]] ==== Paper Wallets @@ -1627,11 +1631,10 @@ from the private key. [WARNING] ==== Paper wallets are an OBSOLETE technology and are dangerous for most -users. There are many subtle pitfalls involved in generating them, not -least of which the possibility that the generating code is compromised -with a "back door". Many bitcoins have been stolen this way. Paper +users. There are many subtle pitfalls involved in generating them, not least of which is the possibility that the generating code is compromised +with a "back door." Many bitcoins have been stolen this way. Paper wallets are shown here for informational purposes only and should not be -used for storing bitcoin. Use a recovery code to backup your +used for storing bitcoin. Use a recovery code to back up your keys, possibly with a hardware signing device to store keys and sign transactions. DO NOT USE PAPER WALLETS. ==== @@ -1656,7 +1659,7 @@ features. <> shows a sample paper wallet. image::images/mbc3_0410.png[] Some are intended to be given as gifts and have seasonal themes, such as -Christmas and New Year's themes. Others are designed for storage in a +Christmas and New Year's. Others are designed for storage in a bank vault or safe with the private key hidden in some way, either with opaque scratch-off stickers, or folded and sealed with tamper-proof adhesive foil. Other designs feature additional copies of the key and @@ -1669,9 +1672,9 @@ other natural disasters. image::images/mbc3_0411.png[] From the original public-key focused design of Bitcoin to modern addresses -and scripts like bech32m and pay-to-taproot--and even addresses for +and scripts like bech32m and pay to taproot--and even addresses for future Bitcoin upgrades--you've learned how the Bitcoin protocol allows -spenders to identify the wallets which should receive their payments. +spenders to identify the wallets that should receive their payments. But when it's actually your wallet receiving the payments, you're going to want the assurance that you'll still have access to that money even if something happens to your wallet data. In the next chapter, we'll