Edited ch04_keys.adoc with Atlas code editor

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 <<bech32_length_extension_example>>.
@@ -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