Skip to content

Commit 48eaeca

Browse files
committed
fixed ordered lists
1 parent d351f35 commit 48eaeca

File tree

10 files changed

+71
-150
lines changed

10 files changed

+71
-150
lines changed

ch01.asciidoc

Lines changed: 4 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -36,15 +36,11 @@ A finite set of numbers and two operations *+* (addition) and *⋅* (multiplicat
3636

3737
1. If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
3838
We call this property _closed_.
39-
2. The additive identity, *0* exists.
40-
This means *a + 0 = a*
41-
3. The multiplicative identity, *1* exists.
42-
This means *a ⋅ 1 = a*
43-
4. If *a* is in the set, *-a* is in the set.
44-
*-a* is defined as the value that makes *a + (-a) = 0*.
39+
2. The additive identity, *0* exists and has the property *a + 0 = a*.
40+
3. The multiplicative identity, *1* exists and has the property *a ⋅ 1 = a*.
41+
4. If *a* is in the set, *-a* is in the set, which is defined as the value that makes *a + (-a) = 0*.
4542
This is what we call the _additive inverse_.
46-
5. If *a* is in the set and is not 0, *a^-1^* is in the set.
47-
*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
43+
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*.
4844
This is what we call the _multiplicative inverse_.
4945

5046
Let's unpack each of the following.

ch02.asciidoc

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -200,12 +200,9 @@ While this doesn't prove the associativity of point addition, the visual should
200200

201201
To code point addition, we're going to split it up into 3 steps:
202202

203-
1.
204-
Where the points are in a vertical line or using the Identity.
205-
2.
206-
Where the points are not in a vertical line, but are different.
207-
3.
208-
Where the two points are the same.
203+
1. Where the points are in a vertical line or using the Identity.
204+
2. Where the points are not in a vertical line, but are different.
205+
3. Where the two points are the same.
209206

210207
=== Coding Point Addition
211208

ch03.asciidoc

Lines changed: 14 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -16,23 +16,11 @@ Pi, sqrt(2), e+7th root of 19, etc are all part of real numbers.
1616
This worked because _real_ numbers are also a field.
1717
Note unlike a _finite_ field, there are an _infinite_ number of real numbers, but otherwise the same properties hold:
1818

19-
1.
20-
if *a* and *b* are in the set, *a+b* and *a⋅b* is in the set.
21-
We call this property _closed_
22-
2.
23-
The additive identity, *0* exists.
24-
This means *a + 0 = a*
25-
3.
26-
The multiplicative identity, *1* exists.
27-
This means *a ⋅ 1 = a*
28-
4.
29-
If *a* is in the set, *-a* is in the set.
30-
*-a* is defined as the value that makes *a + (-a) = 0*.
31-
This is what we call the _additive inverse_.
32-
5.
33-
If *a* is in the set and is not 0, *a^-1^* is in the set.
34-
*a^-1^* is defined as the value that makes *a ⋅ a^-1^ = 1*.
35-
This is what we call the _multiplicative inverse_.
19+
1. If *a* and *b* are in the set, *a+b* and *a⋅b* are in the set.
20+
2. The additive identity, *0* exists and has the property *a + 0 = a*.
21+
3. The multiplicative identity, *1* exists and has the property *a ⋅ 1 = a*.
22+
4. If *a* is in the set, *-a* is in the set, which is defined as the value that makes *a + (-a) = 0*.
23+
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*.
3624

3725
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.
3826

@@ -697,14 +685,10 @@ The only way we could know the details of R beforehand is if we know `e`.
697685
698686
To whit, here are the steps:
699687
700-
1.
701-
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.
702-
2.
703-
We calculate u = z/s, v = r/s
704-
3.
705-
We calculate uG + vP = R
706-
4.
707-
If R's `x` coordinate equals `r`, the signature is valid.
688+
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.
689+
2. We calculate u = z/s, v = r/s
690+
3. We calculate uG + vP = R
691+
4. If R's `x` coordinate equals `r`, the signature is valid.
708692
709693
[NOTE]
710694
.Why two rounds of sha256?
@@ -774,17 +758,11 @@ We do this by choosing a random `k`.
774758
775759
Signing Procedure:
776760
777-
1.
778-
We are given `z`.
779-
We know `e` and eG=P.
780-
2.
781-
Choose a random `k`
782-
3.
783-
Calculate R=kG and r=x-coordinate of R
784-
4.
785-
Calculate s = (z+re)/k
786-
5.
787-
Signature is (r,s)
761+
1. We are given `z` and know `e` such that eG=P.
762+
2. Choose a random `k`
763+
3. Calculate R=kG and r=x-coordinate of R
764+
4. Calculate s = (z+re)/k
765+
5. Signature is (r,s)
788766
789767
Note that the pubkey `P` has to be transmitted to whoever wants to verify and `z` must be known by the verifier.
790768
We'll see later that `z` is computed and P is sent along with the signature.

ch04.asciidoc

Lines changed: 22 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -21,12 +21,9 @@ There are two forms of SEC format that we need to be concerned with and the firs
2121

2222
Here is how the uncompressed SEC format for a given point P=(x,y) is generated:
2323

24-
1.
25-
Start with the prefix byte which is `0x04`.
26-
2.
27-
Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
28-
3.
29-
Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
24+
1. Start with the prefix byte which is `0x04`.
25+
2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
26+
3. Next, append the y-coordinate in 32 bytes as a Big-Endian integer.
3027

3128
Here is what the uncompressed SEC format looks like:
3229

@@ -99,11 +96,9 @@ We call this the *Compressed SEC format* because of how the y-coordinate is comp
9996

10097
Here is the serialization of the Compressed SEC format for a given point P=(x,y):
10198

102-
1.
103-
Start with the prefix byte.
99+
1. Start with the prefix byte.
104100
If `y` is even, it's `0x02`, otherwise it's `0x03`.
105-
2.
106-
Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
101+
2. Next, append the x-coordinate in 32 bytes as a Big-Endian integer.
107102

108103
The Compressed SEC format looks like this:
109104

@@ -212,20 +207,14 @@ This was most likely because the standard was already defined in 2008, supported
212207

213208
DER Signature format is defined like this:
214209

215-
1.
216-
Start with the `0x30` byte
217-
2.
218-
Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
219-
3.
220-
Append the marker byte `0x02`
221-
4.
222-
Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`.
210+
1. Start with the `0x30` byte
211+
2. Encode the length of the rest of the signature (usually `0x44` or `0x45`) and append
212+
3. Append the marker byte `0x02`
213+
4. Encode `r` as a Big-Endian integer, but prepend with `0x00` byte if `r`'s first byte >= `0x80`.
223214
Prepend the resulting length to `r`.
224215
Add this to the result.
225-
5.
226-
Append the marker byte `0x02`
227-
6.
228-
Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`.
216+
5. Append the marker byte `0x02`
217+
6. Encode `s` as a Big-Endian integer, but prepend with `0x00` byte if `s`'s first byte >= `0x80`.
229218
Prepend the resulting length to `s`.
230219
Add this to the result.
231220

@@ -331,16 +320,11 @@ To both shorten and increase security, we can use the ripemd160 hash to compress
331320
By not using the SEC format directly, we can go from 33 bytes to 20 bytes, shortening the address significantly.
332321
Here is how a Bitcoin address is created:
333322

334-
1.
335-
For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
336-
2.
337-
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.
338-
3.
339-
Combine the prefix from #1 and resulting hash from #2
340-
4.
341-
Do a hash256 of the result from #3 and get the first 4 bytes.
342-
5.
343-
Take the combination of #3 and #4 and encode in Base58.
323+
1. For mainnet addresses, start with the prefix `0x00`, for testnet `0x6f`.
324+
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.
325+
3. Combine the prefix from #1 and resulting hash from #2
326+
4. Do a hash256 of the result from #3 and get the first 4 bytes.
327+
5. Take the combination of #3 and #4 and encode in Base58.
344328

345329
Step 4 of this process is called the checksum.
346330
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.
393377

394378
Here is how the WIF format is created:
395379

396-
1.
397-
For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
398-
2.
399-
Encode the secret in 32-byte Big-Endian.
400-
3.
401-
If the SEC format used for the public key address was compressed add a suffix of `0x01`.
402-
4.
403-
Combine the prefix from #1, serialized secret from #2 and suffix from #3
404-
5.
405-
Do a hash256 of the result from #4 and get the first 4 bytes.
406-
6.
407-
Take the combination of #4 and #5 and encode in Base58.
380+
1. For mainnet private keys, start with the prefix `0x80`, for testnet `0xef`.
381+
2. Encode the secret in 32-byte Big-Endian.
382+
3. If the SEC format used for the public key address was compressed add a suffix of `0x01`.
383+
4. Combine the prefix from #1, serialized secret from #2 and suffix from #3
384+
5. Do a hash256 of the result from #4 and get the first 4 bytes.
385+
6. Take the combination of #4 and #5 and encode in Base58.
408386

409387
We can now create the `wif` method on the `PrivateKey` class.
410388

ch05.asciidoc

Lines changed: 4 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -14,14 +14,10 @@ Let's first look at what Transactions in Bitcoin are, what they look like and ho
1414
At a high level, a Transaction really only has 4 components.
1515
They are:
1616

17-
1.
18-
Version
19-
2.
20-
Inputs
21-
3.
22-
Outputs
23-
4.
24-
Locktime
17+
1. Version
18+
2. Inputs
19+
3. Outputs
20+
4. Locktime
2521

2622
A general overview of these fields might be helpful.
2723
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

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -439,10 +439,8 @@ For example, quantum computing has the potential to reduce the calculation times
439439

440440
Pay-to-pubkey-hash (p2pkh) is an alternative Script that has advantages over p2pk:
441441

442-
1.
443-
The addresses are shorter.
444-
2.
445-
It's additionally protected by sha256 and ripemd160.
442+
1. The addresses are shorter.
443+
2. It's additionally protected by sha256 and ripemd160.
446444

447445
Addresses are shorter due to the use of the sha256 and ripemd160 hashing algorithms.
448446
We do both in succession and call that hash160.

ch07.asciidoc

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -214,12 +214,9 @@ The rest of this chapter will be concerned with creating a transaction whose inp
214214

215215
The construction of a transaction is most easily done by answering some basic questions:
216216

217-
1.
218-
Where do we want the bitcoins to go?
219-
2.
220-
What outputs are assigned to our private key(s) that are unspent?
221-
3.
222-
How quickly do we want these transactions to get into the blockchain?
217+
1. Where do we want the bitcoins to go?
218+
2. What outputs are assigned to our private key(s) that are unspent?
219+
3. How quickly do we want these transactions to get into the blockchain?
223220

224221
We'll be using testnet for this example, though this can easily be applied to mainnet.
225222

ch08.asciidoc

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -116,18 +116,15 @@ Bare multisig is a bit ugly, but it's very much functional.
116116
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.
117117
However, bare multisig suffers from a few problems:
118118

119-
1.
120-
First problem: the long length of the ScriptPubKey.
119+
1. First problem: the long length of the ScriptPubKey.
121120
A hypothetical bare multisig address has to encompass many different public keys and that makes the ScriptPubKey extremely long.
122121
Unlike p2pkh or even p2pk, these are not easily communicated using voice or even text message.
123122

124-
2.
125-
Second problem: because the output is so long, it's rather taxing on node software.
123+
2. Second problem: because the output is so long, it's rather taxing on node software.
126124
Nodes have to keep track of the UTXO set, so keeping a particularly big ScriptPubKey ready is onerous.
127125
A large output is more expensive to keep in fast-access storage (like RAM), being 5-20x larger than a normal p2pkh output.
128126

129-
3.
130-
Third problem: because the ScriptPubKey can be so much bigger, bare multisig can and has been abused.
127+
3. Third problem: because the ScriptPubKey can be so much bigger, bare multisig can and has been abused.
131128
The entire pdf of the Satoshi's original whitepaper is actually encoded in this transaction in block 230009: `54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713`.
132129
The creator of this transaction actually split up the whitepaper pdf into 64 byte chunks which were then made into invalid uncompressed public keys.
133130
These are not valid points and the actual whitepaper was encoded into 947 outputs as 1 of 3 bare multisig outputs.

ch11.asciidoc

Lines changed: 10 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -16,10 +16,8 @@ Is it possible to create a Bitcoin wallet on a phone without having all the data
1616

1717
For any wallet, there are two scenarios that we're concerned with:
1818

19-
1.
20-
Paying someone
21-
2.
22-
Getting paid by someone
19+
1. Paying someone
20+
2. Getting paid by someone
2321

2422
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.
2523
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.
4240
In our case, transactions and hash256 are what we use.
4341
To construct the Merkle Tree, we follow this algorithm:
4442

45-
1.
46-
Hash all the items of the ordered list with the provided hash function
47-
2.
48-
If there is exactly 1 hash, we are done
49-
3.
50-
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.
51-
4.
52-
We pair the hashes in order and hash the concatenation to get the parent level.
43+
1. Hash all the items of the ordered list with the provided hash function
44+
2. If there is exactly 1 hash, we are done
45+
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.
46+
4. We pair the hashes in order and hash the concatenation to get the parent level.
5347
We should have half the number of hashes as before.
54-
5.
55-
Go to 2.
48+
5. Go to 2.
5649

5750
The idea is to come to a single hash that represents all of the hashes.
5851
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.
385378

386379
The rules for the flags are:
387380

388-
1.
389-
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.
390-
2.
391-
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.
392-
3.
393-
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.
381+
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.
382+
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.
383+
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.
394384

395385
.Processing a Merkle Block
396386
image::merkleproof2.png[Merkle Blocks and Hashes]

ch12.asciidoc

Lines changed: 6 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -50,12 +50,9 @@ image::bloomfilter1.png[Simple Bloom Filter]
5050

5151
The actual filter consists of:
5252

53-
1.
54-
The size of the bit field
55-
2.
56-
The hash function we used (and how we converted that to a number)
57-
3.
58-
The bit field, which tells the other node which bucket we're interested in.
53+
1. The size of the bit field
54+
2. The hash function we used (and how we converted that to a number)
55+
3. The bit field, which tells the other node which bucket we're interested in.
5956

6057
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.
6158
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
112109
BIP0037 defines exactly how Bitcoin uses Bloom Filters.
113110
As before, the things that we need to let the other node know about are:
114111

115-
1.
116-
The size of the bit field.
112+
1. The size of the bit field.
117113
We send this in bytes (8 bits per byte) and round up if we need to.
118-
2.
119-
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.
120-
3.
121-
Lastly, we need to send over the actual bit field that results from running the Bloom Filter over our items.
114+
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.
115+
3. Lastly, we need to send over the actual bit field that results from running the Bloom Filter over our items.
122116

123117
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.
124118
This allows the implementation to be simpler.

0 commit comments

Comments
 (0)