diff --git a/ch04_keys.adoc b/ch04_keys.adoc index d7708254..b8e51a6d 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -926,7 +926,7 @@ the HASH160 algorithm. This is a _second preimage attack_. However, this changes when an attacker is able to influence the original input value. For example, an attacker participates in the creation of a -multisignature script where tthey don't need to submit their public key until after he learns all of the other party's public keys. +multisignature script where tthey don't need to submit their public key until after they learn all of the other partys' public keys. In that case, the strength of hash algorithm is reduced to its square root. For HASH160, the probability becomes 1-in-2^80^. This is a _collision attack_. @@ -943,17 +943,17 @@ create collision attacks for it, but the existence of the Bitcoin network proves that collision attacks against 160-bit functions like HASH160 are practical. Bitcoin miners have spent the equivalent of billions of US dollars on special hardware, so creating a collision -attack wouldn't be cheap, but there are organizations which expect to +attack wouldn't be cheap, but there are organizations that expect to receive billions of dollars in bitcoins to addresses generated by processes involving multiple parties, which could make the attack profitable. -There are well established cryptographic protocols for preventing -collision attacks but a simple solution which doesn't require any +There are well-established cryptographic protocols for preventing +collision attacks but a simple solution that doesn't require any special knowledge on the part of wallet developers is to simply use a stronger hash function. Later upgrades to Bitcoin made that possible and newer Bitcoin addresses provide at least 128 bits of collision -resistance. To perform 2^128^ hash operations would require all current +resistance. To perform 2^128^ hash operations would take all current Bitcoin miners about 32 billion years. Although we do not believe there is any immediate threat to anyone @@ -961,7 +961,7 @@ creating new P2SH addresses, we recommend all new wallets use newer types of addresses to eliminate address collision attacks as a concern. **** -=== Bech32 addresses +=== Bech32 Addresses In 2017, the Bitcoin protocol was upgraded. When the upgrade is used, it prevents transaction @@ -989,10 +989,10 @@ upgrade to an entirely new address format, so several Bitcoin contributors set out to design the best possible address format. They 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 to a friend who you have transcribe it. Notice how you have to prefix - every letter with the words "uppercase" and "lowercase". Also note + every letter with the words "uppercase" and "lowercase." Also note when you review their writing that the uppercase and lowercase versions of some letters can look similar in many people's handwriting. @@ -1004,7 +1004,7 @@ identified several problems with base58check: located. It might take you several frustrating minutes to eventually discover the mistake. -- A mixed case alphabet also requires extra space to encode in QR codes, +- A mixed-case alphabet also requires extra space to encode in QR codes, which are commonly used to share addresses and invoices between wallets. That extra space means QR codes need to be larger at the same resolution or they become harder to scan quickly. @@ -1069,7 +1069,7 @@ image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and 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. -==== Problems with bech32 addresses +==== Problems with Bech32 Addresses Bech32 addresses would have been a success in every area except for one problem. The mathematical guarantees about their ability to detect @@ -1084,7 +1084,7 @@ users' funds were safe. 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 "q" in the penultimate position of an address that ends with the letter -"p". In those cases, you can also add or remove the letter "q" multiple +"p." In those cases, you can also add or remove the letter "q" multiple times. This will be caught by the checksum some of the time, but it will be missed far more often than the one-in-a-billion expectations for bech32's substitution errors. For an example, see <>. @@ -1114,7 +1114,7 @@ bc1pqqqsq9txsqqqqqqqqqqqp For the initial version of segwit (version 0), this wasn't a practical concern. Only two valid lengths were defined for v0 segwit outputs: 22 -bytes and 34 bytes. Those correspond to bech32 addresses 42 characters +bytes and 34 bytes. Those correspond to bech32 addresses that are 42 characters or 62 characters long, so someone would need to add or remove the letter "q" from the penultimate position of a bech32 address 20 times in order to send money to an invalid address without a wallet being able to detect @@ -1158,7 +1158,12 @@ need to know about the HRPs already chosen, shown in [[bech32_hrps_for_bitcoin]] .Bech32 HRPs for Bitcoin [cols="1,1"] +[options="header"] |=== + +| HRPs +| Network + | bc | Bitcoin mainnet