INTROIf you are interested in discussing technology related topics about the basics of the Bitcoin protocol, I would be glad if you could join me to clarify some of my misconceptions.:
GOALSMy end goal is to understand the exact difference between memory hard and non memory hard mining processes by making a parallel step-by-step flow chart comparing Bitcoin and Litecoin mining algorithms, using a theoretical, three-phase state transition scenario. Before doing so, I wanted to dig through myself the basics and make sure that I understand everything.
To deepen my understanding I will also include an address generation process and a more detailed payee transaction which took place between the second and third phase of state transitions.
I’ve tried to read all of the rules. Despite that my end goal is to understand the mining algorithms behind the memory hard Lite Coin protocol, all of my questions in this post will be about Bitcoin. Consequently I’ve found it permitted to open a post about the following topics.:
TOPICS AND METHOD OF QUESTIONINGI plan to discuss the subjects in different posts in order to avoid long and untraceable conversations, hence I broke down the concept into the following volumes.:
1) State transitions, order of transactions, changes and merkle tree.
2) Private key / public key and transactions.
3) Proof of work - SHA-256 in practice.
4) Block header - Nonce and timestamp as the key of entropy?
5) Lite Coin protocol - will be available in the mining (altcoin) forum.
The questions in the aforementioned subjects require full elaboration or simple yes/no answers to ‘is there any fault in this logic’ type of questions. To make my questions clear I’ve made some drawings, which are available through a publicly available google drive link.
Somewhere I quoted from sources, somewhere I used simple deduction. If you find inconsistencies in the definitions I used, or any error in my logic, correct it please!
I hope that the end result of the Q/A nature of the conversations could merge into a coherent tutorial for anyone interested in the basics of proof of work protocols.
Please answer the questions as simply as possible. Despite the detailed nature of my questions It’s not the technological proficiency the main reason behind my initiative. Thank you for your help and patience!
VOL. 1.: State transitions, order of transactions, changes and merkle treeState phase 1-3For starters imagine a three-phase state transition scenario where the first phase is a theoretical genesis state with a 50 Bitcoins coinbase transaction, sent to miner_godel. Before the first successful proof of work, 6 parties - defined as public addresses - joined the network with access to 0 Bitcoins - obviously.
Between the first and second successful proof of work the following transactions took place: miner_godel distributes 30 Bitcoins proportionally between the 6 public address. While mining_godel tries to find the next valid proof of work, additional miners (miner_escher and miner_bach) join the network. Despite that miner_escher has only 20% cpu capacity, he successfully solves the second proof of work requirement.
Illustration:
https://drive.google.com/file/d/1zA65-SpFFx52vaec_M4pB8d101ccj-aZ/view?usp=sharingQ: Is there any logical inconsistency in the drawing?
Q: address_alister can spend his Bitcoins only after the second proof of work, despite the block size would be sufficient enough to store additional transaction datas. True?
Assumption: Bitcoin ledger can be defined as a sequence of block headers, where the bodies of each block header contain transaction hashes.
Q: The body of block contains only the hashes of each raw transaction, listed in the transaction log below and illustrated in the flow chart, right?
Transaction log of second block:
1.: coinbase_tx; network → miner_godel <50btc>
2.: direct_tx; miner_godel → address_alister <50btc>
3.: change_tx; address_alister → miner godel <45btc>
4.: direct_tx; miner_godel → address_bernard <45btc>
5.: change_tx; address_bernard → miner godel <40btc>
6.: direct_tx; miner_godel → address_carmine <40btc>
7.: change_tx; address_carmine → miner godel <35btc>
8.: direct_tx; miner_godel → address_dominic <35btc>
9.: change_tx; address_dominic → miner godel <30btc>
10.: direct_tx; miner_godel → address_emmanuel <30btc>
11.: change_tx; address_emmanuel → miner godel <25btc>
12.: direct_tx; miner_godel → address_ferdinand <25btc>
13.: change_tx; address_ferdinand → miner godel <20btc>
Assumption: Bitcoin transactions are the distribution of transaction inputs and outputs. Every transaction sends the whole amount of available Bitcoins to the payee. After that, the remaining amount of Bitcoin will be sent back to sender, as changes.
Q: The miners are the only entities in the whole Bitcoin protocol, which organize individual transactions into blocks, where each raw transaction output will be converted to a SHA-256 digest. Nodes, which can’t be defined as miners only responsible for validation. Are that statements true?
Q: I’ve made an illustration about the exact structure of the merkle tree of the second block. Is the categorization valid? (I am particularly interested in the exact execution order of the transactions and the changes.)
Merkle tree of transactions:
https://docs.google.com/spreadsheets/d/1RSEejWUTq2rF_s0hhtnL8Atf0wVlmQ5cAj759r-p980/edit?usp=sharingAssumption: The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.
Q: What does it mean ‘hashed indirectly’?
Q: ‘hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.’ This statement wouldn’t be better like this: ‘finding a proof of work of a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.’?
Assumption: Each miner pack the transactions individually, hence every given transaction hashes - including the coinbase tx - has a unique digest in each miner’s block, despite the fact, that the raw transaction data is the same (see the transactions in various mining blocks).
Q: Is that correct?
Transactions in various mining blocks.:
block_godel_rawtransaction_ID1234 → hash → B0C1D099F81BC06AC880E8E8FF9DAF3102234D74079730D55AB9C312DDAD5A61
block_escher_rawtransaction_ID1234 → hash →
715E6980F0FCF22762FD0B45FD0273B9F72A71C0D7F9F73997A112E809BB5608
Q: However I find it somewhat contradictory that every single hash of tx in blocks is different between miners, because intuitively most of the transactions shouldn’t be different (link posted below). Why would they change, if they are independently hashed from the nonce?
Q: Why the green hashes are not the same between various miners?
https://docs.google.com/spreadsheets/d/12rGTdd4DyD3SIt9HVTTxSGAxnr5ZZNq6lzoImP9hZI4/edit?usp=sharingQ: What is the input format of a transaction which the miner converts into a SHA-256 digest? Could you please post here a raw transaction format?
Thank you for paricipating!
