This is the second in a series of posts where we discuss the core concepts behind the Blockchain, Bitcoin and Ethereum. At Verify, we’re building a reputation protocol on the Ethereum blockchain and are sharing these posts in an effort to share our knowledge with the wider crypto community.
In the previous post (link here) we talked about states and transactions in bitcoin’s network. In this post we will look into how bitcoin executes the transactions we talked about in a decentralized way. I mean who is in charge of running the transaction? This is a really interesting part of bitcoin that I am sure you’ll love.
We know now that bitcoin is a network and it is not a single entity or server in charge of running and executing transactions, it is the whole network. In the network there are many connected nodes; those nodes are in charge of processing the transactions. Having a group of nodes working on the transactions without any kind of constitution would create a chaos; an example would be say one node processed a transfer of 1 BTC from A to B. It completes the transfer before another node receives the same transaction notification and transfers 1 BTC from A to B (assuming A has enough BTCs). After both transactions are executed, A would have lost 2 BTCs and B gained 2 BTCs. So there has to be a protocol that governs operations; the protocol in bitcoin is as follows:
The transaction packages we introduced in the previous blog post are called blocks. So the block is a set of transactions (along with other information). The nodes in the bitcoin network compete to create a block roughly every 10 minutes. Each block has a header and a body. The body contains the list of transactions that took place since the last block creation. The header contains:
- a timestamp
- a nonce
- a hash reference to a previous block
- hashed list of all transactions that took place since the last created block.
Note: keep in mind that the block contains other components as well; which we will leave for other posts.
Timestamp and a hash reference to the previous block are self explanatory, however the hashed list of all transactions that took place since the last created block requires more details which I will leave for the next post.
The nonce is like a counter that is used to generate what is called the proof of work. Before moving forward we should be familiar with the term “proof of work”. It is actually what makes bitcoin special. The proof of work is what enabled decentralization. With it, the nodes in the network collectively agree on the ledger updates (addition of new blocks), protects against possible forgeries to the ledger and of course eliminated any influence of a central party.
The concept of proof of work originated before bitcoins; however, bitcoin tackled the drawbacks that existed. For example, previous attempts at proof of work involved money creation through computational puzzles, without any aspect of decentralization.
The proof of work is hard to generate but easy to verify. To generate a proof of work, you need to spend considerable amount of time and/or resources. The way a proof of work is generated is using an algorithm called hashcash, where you take a random number with the content and hash it using SHA-X (X means the type of SHA algorithm. In bitcoin it is SHA-256), and you try to generate a string or hash that conforms to a specific set of attributes: for example, the target may be a hash that starts with four “0”s.
Let us a take a simple example to fully grasp this idea:
Say you want to hash the string “verify”. You take a random number and hash it using SHA-256 (usually it is by appending the number to the end of content). You keep trying different random numbers until you find a hash that starts with four 0s.
You start with say the number 1:
SHA-256(“verify” , 1)→ 482a99bad1bbe90325421495553688c66577ec12981b4def8a02dba18ecb7512That does not conform to our requirement of starting with four 0s, so we increment the number:
SHA-256(“verify” , 2)→ 2ba93351148a920ec45c0d92f0a23e4311008c30ac76ca517c32c267c285966fStill not right… how about 3:
SHA-256(“verify” , 3)→ 3c86776ef83cdd590c1cc89108c693d69f96b9f2010a6e11ecdd6d5c979c77f3Still not right…
moments later…..
SHA-256(“verify” , 2196) → 0000aa6be5a8709934b206ecf2a7832f4701b038ed9be6030fa953588d197c30Now that worked so we got ourselves (after 2196 hashes) a proof of work. That is how it works in bitcoins as well; except that it is orders of magnitude harder and the target keeps automatically adjusting itself to keep the block generation within the 10 minute time frame.
In bitcoin, the proof of work is really difficult to generate and for it to be valid it has to match a dynamically adjusted target (currently at 2¹⁸⁷) and is a 256 bit number (of type double-SHA256 hash). This hard computation is meant to protect against remaking the blockchain. To get a sense on how difficult it is, to make a valid hash of 2¹⁸⁷, the network would try an average of 2⁶⁹ tries before a valid block is found. Keep in mind that the network keeps recalibrating the target (currently at 2¹⁸⁷) every 2016 blocks to maintain an average of one block every 10 minutes. The target is stored in every block in a compact form in the field called bits. The lower the target the difficult block generation is.
For your information this technique (proof of work) was actually used to fight email spammers before it was used in bitcoins. So before an email is sent, a proof of work was generated and added to the header that the recipient would just verify; however the proof of work was not easy to generate and this meant it was a somewhat costly operation, especially for spammers where they send many emails at once. It think it is now clear why it is called “proof of work”.
In the previous example where we hashed the word “verify”, the number that keeps changing to get the proof of work is what is called in bitcoin as a nonce. So if the node succeeded in getting the proof of work in the format desired the nonce will be stored in the block hence making it easy for others to verify it is correct.
The node that first generates the proof of work wins the creation of block and of course is rewarded some bitcoins for the effort (keep in mind that the total number of bitcoins that can ever exist is 21 million; if all coins are mined, the miners will be rewarded transaction fees (It is currently optional).
The way the winning miner is rewarded is; In general the miners are allowed to add a transaction to the block giving themselves 12.5 BTC out of nowhere; so when the proof of work is successfully generated and is valid, the miner that first generated it will get 12.5 BTC; also the winning miner gets to keep any excess from the transactions in that block. Say the input had cumulative of 10 BTC and in the output the change was 1 BTC and also was not claimed by the original sender of that transaction; in this case the excess or change goes to the miner (you can read more on this here).
Note here that when miners getting 12.5 BTC on successful block creation is the only way that bitcoins are generated. That is why nodes keep competing with each other to score those bitcoins. So a node in the network participates in the ledger not by how many coins it owns or its reputation or influence, but by its computing power. It’s worth noting here that there are other approaches on the table to replace the “proof of work”. The dominant one is called “Proof of stake” which basically shifts from computing power to currency holdings.
This competing approach is what made bitcoin stand out and achieve decentralization. It is also a powerful technique to combat attacks. Take for example a case where an attacker tries to fool the network by executing two transactions with the same balance. Say a customer(attacker in this case) wants to purchase an ebook for 10 BTC; the attacker creates the transaction of 10 BTC to the seller and awaits his ebook. The transactions gets added by some miner to the block say the block #30000; now that the block is created and the transaction is complete, the seller sends the ebook to the attacker (note the problem verify is trying to solve here?). The attacker tries to fool the network and “spends” the same 10 BTC at another seller, or sends it to one of his other accounts. By then there would be several other transactions across the whole network awaiting to be added to the block, as well as other blocks created after block #30000. So what happens?
His transaction will be rejected because the UTXO reference no longer exists. Say that attacker decides to forge the blockchain at the block 30000 where his original transaction happened and started generating a proof of work with the changes he made to the transaction in that block; it would take him forever to generate a newer block and it would be rejected anyways. Assuming the attacker had powerful machines and was able to generate a valid block creating a fork from the original blockchain, the network will still drop it because another 10 minutes have passed and the blockchain is already ahead, processing the block after that. It’s a vicious cycle that always results in the attacker facing an ever-increasing challenge of outrunning all of the other miners in the network that are processing the correct branch.
Assuming the attacker was able to generate blocks faster than the network and was able to generate more blocks for his forked blockchain ((51% attack)) then in this case his fork will be used as the ledger instead of the original one, since the network looks for the longest valid blockchain. Again, this is only if he was able to outrun the algorithm (remember it keeps getting harder) and also if he was able to outrun the whole network’s computing power. The potential reward from creating blocks on a valid blockchain may exceed that of breaking the chain.
And that is how bitcoins executes the transaction or what is called “mining”. When a proof of work is generated by the winning node (miner) some validations take place starting with verifying that the reference to the previous block is valid and that the block exist. Followed by the timestamp verification, it should not be later than the previous block’s timestamp and should not be 2 hours ahead in time and of course verification that the proof of work is valid.
