You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ch03.asciidoc
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -517,7 +517,7 @@ The key operation that we need is `P=eG` which is an *asymmetric* equation.
517
517
We can easily compute P when we know `e` and G, but we cannot easily compute `e` when we know P and G.
518
518
This is the Discrete Log Problem described earlier.
519
519
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.
521
521
522
522
Generally, we call `e` the Private Key and P the Public Key.
523
523
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`
651
651
==== Verification in-depth
652
652
653
653
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`.
655
655
656
656
In order to guarantee that the thing we're signing is 32 bytes, we hash the document first.
657
657
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.
697
697
You may be wondering why there are two rounds when only 1 is necessary to get a 256-bit number.
698
698
The reason is for security.
699
699
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.
703
703
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.
705
705
====
706
706
707
707
==== Verifying a Signature
@@ -875,7 +875,7 @@ This makes transactions less malleable (more on that in <<chapter_segwit>>)
875
875
### Conclusion
876
876
877
877
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).
879
879
This is a major step in your journey and will be essential for the rest of the book!
880
880
881
881
We now turn to serializing a lot of these structures so that we can store them on disk and send them over the network.
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.
402
400
Recall that SEC format uses Big-Endian encoding as do addresses and WIF.
403
401
From <<chapter_tx_parsing>> onward, we will use Little-Endian encoding a lot more.
404
402
For this reason, we turn to the next two exercises.
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).
Copy file name to clipboardExpand all lines: ch05.asciidoc
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,7 @@ If, for example, you are running Windows 3.1, that's a version number that's ver
91
91
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.
92
92
93
93
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).
95
95
96
96
You may notice here that the actual value in hexadecimal is `01000000`, which doesn't look like 1.
97
97
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]
106
106
Each input points to an output of a previous transaction.
107
107
This fact requires more explanation as it's not intuitively obvious at first.
108
108
109
-
Bitcoin's inputs are spending outputs of another transaction.
109
+
Bitcoin's inputs are spending outputs of a previous transaction.
110
110
That is, you need to have received Bitcoins first to spend something.
111
111
This makes intuitive sense.
112
112
You cannot spend money unless you received money first.
Copy file name to clipboardExpand all lines: ch06.asciidoc
+4-2Lines changed: 4 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -415,7 +415,9 @@ This makes the compressed and uncompressed SEC formats 66 and 130 characters res
415
415
To compound this, early Bitcoin transactions didn't use the compressed versions so the hexadecimal addresses were 130 characters each!
416
416
This is not fun or easy for people to transcribe, much less communicate by voice.
417
417
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.
419
421
Incidentally, this IP-to-IP payment system was phased out as it's not secure and prone to man-in-the-middle attacks.
420
422
421
423
.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)
0 commit comments