Skip to content

Commit 27e2a6a

Browse files
committed
harding comments ch01-06
1 parent 914c4f2 commit 27e2a6a

File tree

5 files changed

+20
-23
lines changed

5 files changed

+20
-23
lines changed

ch01.asciidoc

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -64,15 +64,12 @@ That means 0 and 1 are in the set.
6464

6565
(4) means that we have the additive inverse.
6666
That is, if *a* is in the set, *-a* is in the set.
67-
Using this, we can define subtraction.
68-
Subtraction is the inverse of addition.
69-
Once again, we have to make sure subtraction is defined in a way as to make sure that the result is still in the set, that is, not go under 0.
70-
In other words, we need to define subtraction to be _closed_.
67+
Using the additive inverse, we can define subtraction.
7168

7269
(5) means that multiplication has the same property.
7370
If *a* is in the set, *a^-1^* is in the set.
7471
That is *a⋅a^-1^=1*.
75-
Using this, we can define division, the inverse of multiplication.
72+
Using the multiplicative inverse, we can define division.
7673
This will be the trickiest to define in a finite field.
7774

7875
=== Defining Finite Sets

ch03.asciidoc

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -517,7 +517,7 @@ The key operation that we need is `P=eG` which is an *asymmetric* equation.
517517
We can easily compute P when we know `e` and G, but we cannot easily compute `e` when we know P and G.
518518
This is the Discrete Log Problem described earlier.
519519
520-
We'll use the fact that Discrete Log is extremely difficult to create signing and verification.
520+
The difficulty of Discrete Log will be essential to understanding signing and verification algorithms.
521521
522522
Generally, we call `e` the Private Key and P the Public Key.
523523
We'll note here that the private key is a single 256-bit number and the public key is a coordinate `(x,y)` where `x` and `y` are _each_ 256-bit numbers.
@@ -651,7 +651,7 @@ It's worth mentioning again, make sure you're using truly random numbers for `k`
651651
==== Verification in-depth
652652
653653
Signatures sign some fixed-length value (our "contract"), in our case something that's 32 bytes.
654-
The fact that 32 bytes is 256 bits is not a coincidence as the thing we're signing needs to be a scalar for `G`.
654+
The fact that 32 bytes is 256 bits is not a coincidence as the thing we're signing will be a scalar for `G`.
655655
656656
In order to guarantee that the thing we're signing is 32 bytes, we hash the document first.
657657
In Bitcoin, the hashing function is hash256, or two rounds of sha256.
@@ -697,11 +697,11 @@ The calculation of `z` requires two rounds of sha256, or hash256.
697697
You may be wondering why there are two rounds when only 1 is necessary to get a 256-bit number.
698698
The reason is for security.
699699
700-
There is a well-known hash collision attack on sha1 called a _birthday attack_ which basically makes finding collisions much easier.
701-
This is how Google found a sha1 collision in 2017 (https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html).
702-
Using sha1 twice, or double-sha1 is the way to defeat this attack.
700+
There is a well-known hash collision attack on sha1 called a _birthday attack_ which makes finding collisions much easier.
701+
Google found a sha1 collision using some modifications of a birthday attack and a lot of other things in 2017 (https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html).
702+
Using sha1 twice, or double-sha1 is the way to defeat slow down some forms of this attack.
703703
704-
There is no known sha256 weakness like a birthday attack, but doing two rounds is a defense against similar potential weaknesses.
704+
Two rounds of sha256 don't necessarily prevent all possible attacks, but doing two rounds is a defense against some potential weaknesses.
705705
====
706706
707707
==== Verifying a Signature
@@ -875,7 +875,7 @@ This makes transactions less malleable (more on that in <<chapter_segwit>>)
875875
### Conclusion
876876
877877
We've covered Elliptic Curve Cryptography and we can now prove that we know a secret by signing something and we can also verify that the person with the secret actually signed a message.
878-
Even if you don't read another page in this book, you've learned to implement what was once considered "weapons grade cryptography".
878+
Even if you don't read another page in this book, you've learned to implement what was once considered "weapons grade munitions" (see https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States).
879879
This is a major step in your journey and will be essential for the rest of the book!
880880
881881
We now turn to serializing a lot of these structures so that we can store them on disk and send them over the network.

ch04.asciidoc

Lines changed: 4 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -314,8 +314,8 @@ include::code-ch04/answers.py[tag=exercise4]
314314

315315
=== Address Format
316316

317-
The 260 bits from a compressed SEC format is still a bit too long, not to mention a bit less secure (see <<chapter_script>>).
318-
To both shorten and increase security, we can use the ripemd160 hash to compress the public key to a 20-byte hash.
317+
The 264 bits from a compressed SEC format is still a bit too long, not to mention a bit less secure (see <<chapter_script>>).
318+
To both shorten and increase security, we can use the ripemd160 hash to reduce the size to a 20-byte hash.
319319

320320
By not using the SEC format directly, we can go from 33 bytes to 20 bytes, shortening the address significantly.
321321
Here is how a Bitcoin address is created:
@@ -349,8 +349,6 @@ We can implement this in `helper.py`.
349349
[source,python]
350350
----
351351
include::code-ch04/helper.py[tag=source4]
352-
def hash160(s):
353-
return hashlib.new('ripemd160', hashlib.sha256(s).digest()).digest() # <1>
354352
----
355353
<1> Note that `hashlib.sha256(s).digest()` does the sha256 and the wrapper around it does the ripemd160.
356354

@@ -398,7 +396,7 @@ include::code-ch04/answers.py[tag=exercise6]
398396
=== Big and Little Endian Redux
399397

400398
It will be very useful to know how Big and Little Endian are done in Python as the next few chapters will be parsing and serializing numbers to and from Big/Little Endian quite a bit.
401-
In particular, Satoshi used a lot of Little-Endian for Bitcoin and unfortunately, there's no easy rule for determining where Little-Endian was used and where Big-Endian was used.
399+
In particular, Satoshi used a lot of Little-Endian for Bitcoin and unfortunately, there's no easy-to-learn rule for where Little-Endian is used and where Big-Endian is used.
402400
Recall that SEC format uses Big-Endian encoding as do addresses and WIF.
403401
From <<chapter_tx_parsing>> onward, we will use Little-Endian encoding a lot more.
404402
For this reason, we turn to the next two exercises.
@@ -410,7 +408,7 @@ include::code-ch04/answers.py[tag=exercise8]
410408

411409
include::code-ch04/answers.py[tag=exercise9]
412410

413-
Go to a testnet faucet (https://faucet.programmingbitcoin.com) and send some testnet coins to that address (it should start with `m` or `n`).
411+
Go to a testnet faucet (https://faucet.programmingbitcoin.com) and send some testnet coins to that address (it should start with `m` or `n` or else something is wrong).
414412
If you succeeded, congrats!
415413
You're now the proud owner of some testnet coins!
416414

ch05.asciidoc

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,7 @@ If, for example, you are running Windows 3.1, that's a version number that's ver
9191
You could specify just "Windows", but specifying the version number after the operating system helps you know what features it has and what API's you can program against.
9292

9393
Similarly, Bitcoin transactions have version numbers.
94-
In Bitcoin's case, the transaction version is generally 1, but there are cases where it can be 2 (transactions using an opcode called `OP_CHECKSEQUENCEVERIFY` as defined in BIP68/BIP112/BIP113 require use of version > 1).
94+
In Bitcoin's case, the transaction version is generally 1, but there are cases where it can be 2 (transactions using an opcode called `OP_CHECKSEQUENCEVERIFY` as defined in BIP112 require use of version > 1).
9595

9696
You may notice here that the actual value in hexadecimal is `01000000`, which doesn't look like 1.
9797
Interpreted as a Little-Endian integer, however, this number is actually 1 (recall the discussion from <<chapter_serialization>>).
@@ -106,7 +106,7 @@ image::tx3.png[Inputs]
106106
Each input points to an output of a previous transaction.
107107
This fact requires more explanation as it's not intuitively obvious at first.
108108

109-
Bitcoin's inputs are spending outputs of another transaction.
109+
Bitcoin's inputs are spending outputs of a previous transaction.
110110
That is, you need to have received Bitcoins first to spend something.
111111
This makes intuitive sense.
112112
You cannot spend money unless you received money first.
@@ -226,7 +226,7 @@ include::code-ch05/tx.py[tag=source2]
226226

227227
A couple things to note here.
228228
The amount of each input is not specified.
229-
We have no idea how much is being spent unless we look up the transaction in the blockchain.
229+
We have no idea how much is being spent unless we look up in the blockchain for the transaction(s) that we're spending.
230230
Furthermore, we don't even know if the transaction is unlocking the right box, so to speak, without knowing about the previous transaction.
231231
Every node must verify that this transaction unlocks the right box and that it doesn't spend non-existent Bitcoins.
232232
How we do that is discussed more in <<chapter_tx>>.

ch06.asciidoc

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -415,7 +415,9 @@ This makes the compressed and uncompressed SEC formats 66 and 130 characters res
415415
To compound this, early Bitcoin transactions didn't use the compressed versions so the hexadecimal addresses were 130 characters each!
416416
This is not fun or easy for people to transcribe, much less communicate by voice.
417417

418-
That said, the original use-case for p2pk was for IP-to-IP payments where IP addresses were queried for their public keys, so communicating the public keys were done machine-to-machine, which meant that this wasn't necessarily a problem.
418+
That said, the original use-cases for p2pk were for IP-to-IP payments and mining outputs.
419+
For IP-to-IP payments, IP addresses were queried for their public keys, so communicating the public keys were done machine-to-machine, which meant that human communication wasn't necessarily a problem.
420+
Use for mining outputs also don't require human communication.
419421
Incidentally, this IP-to-IP payment system was phased out as it's not secure and prone to man-in-the-middle attacks.
420422

421423
.Why did Satoshi use the uncompressed SEC format?
@@ -459,7 +461,7 @@ These 20 bytes are the result of doing a hash160 operation on this (compressed)
459461

460462
`0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352`
461463

462-
Given p2pkh is shorter and more secure, p2pk is no longer used much on the network.
464+
Given p2pkh is shorter and more secure, p2pk use declined significantly after 2010, though it's still fully supported today.
463465

464466
=== p2pkh
465467

0 commit comments

Comments
 (0)