inital commit, already did quite a few things.
This commit is contained in:
commit
a3619df8cf
6 changed files with 2321 additions and 0 deletions
65
mastering_bitcoin_notes.md
Normal file
65
mastering_bitcoin_notes.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
# Mastering Bitcoin notes
|
||||
|
||||
So, after years of messing around with Bitcoin, the time has finally come to
|
||||
reach the bottom of the rabbit hole and understand things down to the code
|
||||
level.
|
||||
|
||||
I'm going to use this document to keep my notes and thoughts while going
|
||||
through the book.
|
||||
|
||||
----------
|
||||
|
||||
"There's a lot more to Bitcoin than first meets the eye." Joder, ya te digo.
|
||||
|
||||
----------
|
||||
|
||||
Finally, I get to discover what the hell is an `SPV`: simplified payment
|
||||
verification, which is fancy pants language for a client that keeps keys and
|
||||
performs operations but relies on another full-node for following the protocol
|
||||
and getting the blockchain data from other peers. So, if I understand
|
||||
correctly, an Electrum Personal Server fits the definition of an SPV.
|
||||
|
||||
----------
|
||||
|
||||
Andreas mentions that we should talk about "mnemonic phrase", and not a "seed
|
||||
phrase", because "even though common, its use is incorrect". But, why? -> So
|
||||
it works this way: technically, the seed is a 512-bit piece of data, which is
|
||||
the actual piece of information used to generate the keys of a wallet. The
|
||||
mnemonic is just a human-readeable proxy to this seed, hence why mnemonic !=
|
||||
seed.
|
||||
|
||||
This sparked my curiosity and I have been reading more low level details on how
|
||||
seed generation works.
|
||||
|
||||
The first thing that's required is randomness. To get this, a series of bits is
|
||||
generated. Specifically, the entropy should be between 128 and 256 bits (that
|
||||
means, 128 to 256 random zeros and ones).
|
||||
|
||||
The checksum for this entropy is computed the following way:
|
||||
|
||||
- Generate the SHA256 hash of the entropy.
|
||||
- Starting from the left, grab one bit of the hash for every 32 bits of length
|
||||
in the original entropy (if the entropy is 128 bits, 128/32 = 4, you grab the 4
|
||||
first bits of the hash).
|
||||
|
||||
```python
|
||||
|
||||
entropy = "01000010011111001011100101101111001010010110101011011111000001101000110111111001010000101000000110011010110011110110010000011001"
|
||||
entropy_len = len(entropy)
|
||||
|
||||
import hashlib
|
||||
|
||||
hash_of_entropy = hashlib.sha256(entropy)
|
||||
|
||||
print(hash_of_entropy)
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
----------
|
||||
|
||||
Another interesting fact: miner fees for a transaction are not explicitly
|
||||
specified anywhere, but are simply calculated as the difference between the
|
||||
inputs and the outputs of the transaction.
|
||||
Loading…
Add table
Add a link
Reference in a new issue