fixed ordered lists

Author: jimmysong

ch01.asciidoc

@@ -36,15 +36,11 @@ A finite set of numbers and two operations *+* (addition) and *⋅* (multiplicat
 
 1. If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
 We call this property _closed_.
-2. The additive identity, *0* exists.
-This means *a + 0 = a*
-3. The multiplicative identity, *1* exists.
-This means *a ⋅ 1 = a*
-4. If *a* is in the set, *-a* is in the set.
-*-a* is defined as the value that makes *a + (-a) = 0*.
+2. The additive identity, *0* exists and has the property *a + 0 = a*.
+3. The multiplicative identity, *1* exists and has the property *a ⋅ 1 = a*.
+4. If *a* is in the set, *-a* is in the set, which is defined as the value that makes *a + (-a) = 0*.
 This is what we call the _additive inverse_.
-5. If *a* is in the set and is not 0, *a^-1^* is in the set.
-*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
+5. If *a* is in the set and is not 0, *a^-1^* is in the set, which is defined as the value that makes *a ⋅ a^-1^ = 1*.
 This is what we call the _multiplicative inverse_.
 
 Let's unpack each of the following.

ch02.asciidoc

@@ -200,12 +200,9 @@ While this doesn't prove the associativity of point addition, the visual should
 
 To code point addition, we're going to split it up into 3 steps:
 
-1.
-Where the points are in a vertical line or using the Identity.
-2.
-Where the points are not in a vertical line, but are different.
-3.
-Where the two points are the same.
+1. Where the points are in a vertical line or using the Identity.
+2. Where the points are not in a vertical line, but are different.
+3. Where the two points are the same.
 
 === Coding Point Addition
 

ch03.asciidoc

@@ -16,23 +16,11 @@ Pi, sqrt(2), e+7th root of 19, etc are all part of real numbers.
 This worked because _real_ numbers are also a field.
 Note unlike a _finite_ field, there are an _infinite_ number of real numbers, but otherwise the same properties hold:
 
-1.
-if *a* and *b* are in the set, *a+b* and *a⋅b* is in the set.
-We call this property _closed_
-2.
-The additive identity, *0* exists.
-This means *a + 0 = a*
-3.
-The multiplicative identity, *1* exists.
-This means *a ⋅ 1 = a*
-4.
-If *a* is in the set, *-a* is in the set.
-*-a* is defined as the value that makes *a + (-a) = 0*.
-This is what we call the _additive inverse_.
-5.
-If *a* is in the set and is not 0, *a^-1^* is in the set.
-*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
-This is what we call the _multiplicative inverse_.
+1. If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
+2. The additive identity, *0* exists and has the property *a + 0 = a*.
+3. The multiplicative identity, *1* exists and has the property *a ⋅ 1 = a*.
+4. If *a* is in the set, *-a* is in the set, which is defined as the value that makes *a + (-a) = 0*.
+5. If *a* is in the set and is not 0, *a^-1^* is in the set, which is defined as the value that makes *a ⋅ a^-1^ = 1*.
 
 Clearly, all of these are true as normal addition and multiplication apply for the first part, additive and multiplicative identities 0 and 1 exist, -x is the additive inverse and 1/x is the multiplicative inverse.
 
@@ -697,14 +685,10 @@ The only way we could know the details of R beforehand is if we know `e`.
 
 To whit, here are the steps:
 
-1.
-We are given (r, s) as the signature, `z` as the hash of the thing being signed and P, the public key (or public point) of the signer.
-2.
-We calculate u = z/s, v = r/s
-3.
-We calculate uG + vP = R
-4.
-If R's `x` coordinate equals `r`, the signature is valid.
+1. We are given (r, s) as the signature, `z` as the hash of the thing being signed and P, the public key (or public point) of the signer.
+2. We calculate u = z/s, v = r/s
+3. We calculate uG + vP = R
+4. If R's `x` coordinate equals `r`, the signature is valid.
 
 [NOTE]
 .Why two rounds of sha256?
@@ -774,17 +758,11 @@ We do this by choosing a random `k`.
 
 Signing Procedure:
 
-1.
-We are given `z`.
-We know `e` and eG=P.
-2.
-Choose a random `k`
-3.
-Calculate R=kG and r=x-coordinate of R
-4.
-Calculate s = (z+re)/k
-5.
-Signature is (r,s)
+1. We are given `z` and know `e` such that eG=P.
+2. Choose a random `k`
+3. Calculate R=kG and r=x-coordinate of R
+4. Calculate s = (z+re)/k
+5. Signature is (r,s)
 
 Note that the pubkey `P` has to be transmitted to whoever wants to verify and `z` must be known by the verifier.
 We'll see later that `z` is computed and P is sent along with the signature.

ch04.asciidoc

@@ -21,12 +21,9 @@ There are two forms of SEC format that we need to be concerned with and the firs
 
 Here is how the uncompressed SEC format for a given point P=(x,y) is generated:
 
-1.
-Start with the prefix byte which is `0x04`.
-2.
-Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
-3.
-Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
+1. Start with the prefix byte which is `0x04`.
+2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
+3. Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
 
 Here is what the uncompressed SEC format looks like:
 
@@ -99,11 +96,9 @@ We call this the *Compressed SEC format* because of how the y-coordinate is comp
 
 Here is the serialization of the Compressed SEC format for a given point P=(x,y):
 
-1.
-Start with the prefix byte.
+1. Start with the prefix byte.
 If `y` is even, it's `0x02`, otherwise it's `0x03`.
-2.
-Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
+2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
 
 The Compressed SEC format looks like this:
 
@@ -212,20 +207,14 @@ This was most likely because the standard was already defined in 2008, supported
 
 DER Signature format is defined like this:
 
-1.
-Start with the `0x30` byte
-2.
-Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
-3.
-Append the marker byte `0x02`
-4.
-Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`.
+1. Start with the `0x30` byte
+2. Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
+3. Append the marker byte `0x02`
+4. Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`.
 Prepend the resulting length to `r`.
 Add this to the result.
-5.
-Append the marker byte `0x02`
-6.
-Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`.
+5. Append the marker byte `0x02`
+6. Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`.
 Prepend the resulting length to `s`.
 Add this to the result.
 
@@ -331,16 +320,11 @@ To both shorten and increase security, we can use the ripemd160 hash to compress
 By not using the SEC format directly, we can go from 33 bytes to 20 bytes, shortening the address significantly.
 Here is how a Bitcoin address is created:
 
-1.
-For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
-2.
-Take the SEC format (compressed or uncompressed) and do a sha256 operation followed by the ripemd160 hash operation, the combination which is called a hash160 operation.
-3.
-Combine the prefix from #1 and resulting hash from #2
-4.
-Do a hash256 of the result from #3 and get the first 4 bytes.
-5.
-Take the combination of #3 and #4 and encode in Base58.
+1. For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
+2. Take the SEC format (compressed or uncompressed) and do a sha256 operation followed by the ripemd160 hash operation, the combination which is called a hash160 operation.
+3. Combine the prefix from #1 and resulting hash from #2
+4. Do a hash256 of the result from #3 and get the first 4 bytes.
+5. Take the combination of #3 and #4 and encode in Base58.
 
 Step 4 of this process is called the checksum.
 We can do steps 4 and 5 in one go this way:
@@ -393,18 +377,12 @@ WIF uses the same Base58 encoding that addresses use.
 
 Here is how the WIF format is created:
 
-1.
-For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
-2.
-Encode the secret in 32-byte Big-Endian.
-3.
-If the SEC format used for the public key address was compressed add a suffix of `0x01`.
-4.
-Combine the prefix from #1, serialized secret from #2 and suffix from #3
-5.
-Do a hash256 of the result from #4 and get the first 4 bytes.
-6.
-Take the combination of #4 and #5 and encode in Base58.
+1. For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
+2. Encode the secret in 32-byte Big-Endian.
+3. If the SEC format used for the public key address was compressed add a suffix of `0x01`.
+4. Combine the prefix from #1, serialized secret from #2 and suffix from #3
+5. Do a hash256 of the result from #4 and get the first 4 bytes.
+6. Take the combination of #4 and #5 and encode in Base58.
 
 We can now create the `wif` method on the `PrivateKey` class.
 

ch05.asciidoc

@@ -14,14 +14,10 @@ Let's first look at what Transactions in Bitcoin are, what they look like and ho
 At a high level, a Transaction really only has 4 components.
 They are:
 
-1.
-Version
-2.
-Inputs
-3.
-Outputs
-4.
-Locktime
+1. Version
+2. Inputs
+3. Outputs
+4. Locktime
 
 A general overview of these fields might be helpful.
 Version indicates what additional features the transaction uses, Inputs define what Bitcoins are being spent, Outputs define where the Bitcoins are going and Locktime defines when this Transaction starts being valid.

ch06.asciidoc

@@ -439,10 +439,8 @@ For example, quantum computing has the potential to reduce the calculation times
 
 Pay-to-pubkey-hash (p2pkh) is an alternative Script that has advantages over p2pk:
 
-1.
-The addresses are shorter.
-2.
-It's additionally protected by sha256 and ripemd160.
+1. The addresses are shorter.
+2. It's additionally protected by sha256 and ripemd160.
 
 Addresses are shorter due to the use of the sha256 and ripemd160 hashing algorithms.
 We do both in succession and call that hash160.

ch07.asciidoc

@@ -214,12 +214,9 @@ The rest of this chapter will be concerned with creating a transaction whose inp
 
 The construction of a transaction is most easily done by answering some basic questions:
 
-1.
-Where do we want the bitcoins to go?
-2.
-What outputs are assigned to our private key(s) that are unspent?
-3.
-How quickly do we want these transactions to get into the blockchain?
+1. Where do we want the bitcoins to go?
+2. What outputs are assigned to our private key(s) that are unspent?
+3. How quickly do we want these transactions to get into the blockchain?
 
 We'll be using testnet for this example, though this can easily be applied to mainnet.
 

ch08.asciidoc

@@ -116,18 +116,15 @@ Bare multisig is a bit ugly, but it's very much functional.
 You can have `m` of `n` signatures required to unlock a UTXO and there is plenty of utility in making outputs multisig, especially if you're a business.
 However, bare multisig suffers from a few problems:
 
-1.
-First problem: the long length of the ScriptPubKey.
+1. First problem: the long length of the ScriptPubKey.
 A hypothetical bare multisig address has to encompass many different public keys and that makes the ScriptPubKey extremely long.
 Unlike p2pkh or even p2pk, these are not easily communicated using voice or even text message.
 
-2.
-Second problem: because the output is so long, it's rather taxing on node software.
+2. Second problem: because the output is so long, it's rather taxing on node software.
 Nodes have to keep track of the UTXO set, so keeping a particularly big ScriptPubKey ready is onerous.
 A large output is more expensive to keep in fast-access storage (like RAM), being 5-20x larger than a normal p2pkh output.
 
-3.
-Third problem: because the ScriptPubKey can be so much bigger, bare multisig can and has been abused.
+3. Third problem: because the ScriptPubKey can be so much bigger, bare multisig can and has been abused.
 The entire pdf of the Satoshi's original whitepaper is actually encoded in this transaction in block 230009: `54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713`.
 The creator of this transaction actually split up the whitepaper pdf into 64 byte chunks which were then made into invalid uncompressed public keys.
 These are not valid points and the actual whitepaper was encoded into 947 outputs as 1 of 3 bare multisig outputs.

ch11.asciidoc

@@ -16,10 +16,8 @@ Is it possible to create a Bitcoin wallet on a phone without having all the data
 
 For any wallet, there are two scenarios that we're concerned with:
 
-1.
-Paying someone
-2.
-Getting paid by someone
+1. Paying someone
+2. Getting paid by someone
 
 If you are paying someone with your Bitcoin wallet, it is up to the person receiving your Bitcoins to verify that they've been paid.
 Once they've verified that the transaction has been included in a block sufficiently deep, they'll give you the good or service you are expecting in return.
@@ -42,17 +40,12 @@ The prerequisites are an ordered list of items and a hash function.
 In our case, transactions and hash256 are what we use.
 To construct the Merkle Tree, we follow this algorithm:
 
-1.
-Hash all the items of the ordered list with the provided hash function
-2.
-If there is exactly 1 hash, we are done
-3.
-If there is an odd number of hashes, we add a copy of the last hash in the list to the end so that we have an even number.
-4.
-We pair the hashes in order and hash the concatenation to get the parent level.
+1. Hash all the items of the ordered list with the provided hash function
+2. If there is exactly 1 hash, we are done
+3. If there is an odd number of hashes, we add a copy of the last hash in the list to the end so that we have an even number.
+4. We pair the hashes in order and hash the concatenation to get the parent level.
 We should have half the number of hashes as before.
-5.
-Go to 2.
+5. Go to 2.
 
 The idea is to come to a single hash that represents all of the hashes.
 The gist of getting the Merkle Tree looks like this:
@@ -385,12 +378,9 @@ The flags are a list of bits that tell us about nodes in depth-first order.
 
 The rules for the flags are:
 
-1.
-If the node is given to us (blue box in the Figure 11-7), the flag is 0 and the next hash is its hash value.
-2.
-If the node is an internal node and calculated, that is, calculated from its children (dotted outline in the Figure 11-7), the flag is 1.
-3.
-If the node is a leaf node and is a transaction we're interested in (green box in the Figure 11-7), the flag is 1 and the next hash is its hash value.
+1. If the node is given to us (blue box in the Figure 11-7), the flag is 0 and the next hash is its hash value.
+2. If the node is an internal node and calculated, that is, calculated from its children (dotted outline in the Figure 11-7), the flag is 1.
+3. If the node is a leaf node and is a transaction we're interested in (green box in the Figure 11-7), the flag is 1 and the next hash is its hash value.
 
 .Processing a Merkle Block
 image::merkleproof2.png[Merkle Blocks and Hashes]

ch12.asciidoc

@@ -50,12 +50,9 @@ image::bloomfilter1.png[Simple Bloom Filter]
 
 The actual filter consists of:
 
-1.
-The size of the bit field
-2.
-The hash function we used (and how we converted that to a number)
-3.
-The bit field, which tells the other node which bucket we're interested in.
+1. The size of the bit field
+2. The hash function we used (and how we converted that to a number)
+3. The bit field, which tells the other node which bucket we're interested in.
 
 This works great for a single item, so would be great if we only had a single address/ScriptPubKey/Transaction ID that we're interested in.
 What do we do when there's more than 1 item?
@@ -112,13 +109,10 @@ This means that we can manipulate our Bloom Filter to have the optimum number of
 BIP0037 defines exactly how Bitcoin uses Bloom Filters.
 As before, the things that we need to let the other node know about are:
 
-1.
-The size of the bit field.
+1. The size of the bit field.
 We send this in bytes (8 bits per byte) and round up if we need to.
-2.
-We also send over how many hash functions we want to use along with a "tweak" to be able to change our bloom filter if our filter hits too many items.
-3.
-Lastly, we need to send over the actual bit field that results from running the Bloom Filter over our items.
+2. We also send over how many hash functions we want to use along with a "tweak" to be able to change our bloom filter if our filter hits too many items.
+3. Lastly, we need to send over the actual bit field that results from running the Bloom Filter over our items.
 
 While we could define lots of hash functions (sha256, keccak, ripemd, blake, etc), in practice, we only really use a single hash function with a different seed.
 This allows the implementation to be simpler.