Mining in bitcoins, the why and how

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” , 
)→ 482a99bad1bbe90325421495553688c66577ec12981b4def8a02dba18ecb7512

That does not conform to our requirement of starting with four 0s, so we
increment the number:

SHA-256(“verify” , 
)→ 2ba93351148a920ec45c0d92f0a23e4311008c30ac76ca517c32c267c285966f

Still not right… how about 3:

SHA-256(“verify” , 
)→ 3c86776ef83cdd590c1cc89108c693d69f96b9f2010a6e11ecdd6d5c979c77f3

Still not right…

moments later…..

SHA-256(“verify” , 
) → 0000aa6be5a8709934b206ecf2a7832f4701b038ed9be6030fa953588d197c30

Now 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.

Verify.as

Verify is a Reputation Protocol for buying and selling things using
cryptocurrencies → https://verify.as/