Bitcoin: Dawn Of Innovation — Xord

Introduction

A common conception about Bitcoin is that it is a cryptocurrency. While that is true, it isn’t just a cryptocurrency. It is much more. Bitcoin is the foundation of digital currency, the first successful application of blockchain, which took decentralization to great heights. Bitcoin is an innovation in the distributed computing.

Bitcoin can do anything a conventional currency can, except it provides more security and ease of use. With Bitcoin, no central authority or a third party owns your assets. Either you own the assets or don’t. That is it.
The concept of decentralized currencies was introduced even earlier, but they had an issue with the resolution of a single state.

Moving towards a more textbook definition of Bitcoin, Bitcoin is a decentralized, distributed, peer-to-peer system.

This publication explores and puts together the working of Bitcoin blockchain.

Why Bitcoin?

Bitcoin offers multiple guarantees. Let’s discuss some of them over here.

1. Bitcoin prevents double-spending i.e no UTXO can be spent twice.
2. One can’t revert back to the state of a blockchain after the confirmation of the block[1].
3. Bitcoin ensures neutrality. It propagates only valid transactions which can be further verified by any node[2] on the network.
4. The consensus rule of bitcoin rejects all kinds of transactions which include timestamps too far ahead of past and future.
5. Verification of the transaction needs solving of a cryptographic puzzle with a difficulty value.
6. Scripts[3] containing the requirement for a valid signature can not be executed without the private key of the authorized holder.
7. All transactions are public and can be audited up to the genesis block[4].
8. Transaction outputs are discrete, in which either the UTXO is spent or unspent.
9. Any script which is enclosed with a relative or absolute time lock can never be executed before the specified time.
10. OP_RETURN can be used to commit a data value via the transaction in the block.

How Bitcoin Works?

Transaction Initiation & Propagation

A transaction implies the transfer of ownership to another address. Addresses are a virtual location for sending BTC. These addresses are owned by people. Transactions take some input BTC and give out some outputs. These inputs and outputs are referred to as UTXOs or unspent transaction outputs. We have a wallet that controls access to all the user’s money, keys, and addresses, tracking the UTXOs, creating and signing the transactions. A wallet is an application that serves as the primary user interface. To create a transaction, the owner of an account authorizes transferring ownership of funds to another account and signs the transaction[a]. A transaction can be sent to anyone as long as they are connected to a Bitcoin client[5]. When a transaction takes place, it is propagated to the network and spreads via the Gossip protocol[6].

Blocks & Blockchain

Blockchain is a data-storing space. It consists of back-linked blocks of transactions. Each block is linked back to the previous block via its hash. This means that every block has a hash of its own generated via the SHA 256 algorithm. Block header consists of its own as well as the previous block’s hash. This sequence enables the formation of a chain line structure from the first-ever, i.e., genesis block, to the most recent block.

Blocks can’t be changed without recalculation of their subsequent blocks. A change in the parent block will alter its hash, which is part of the next block. This is what makes the blockchain immutable, as recalculation would require enormous computational power.

Structure Of A Block

The block consists of:

• Block header
• Block size
• Transaction counter
• Transactions

Block header is an 80byte string, which further consists of three sets of metadata. This metadata includes:

• A version number to track software and protocol updates.
• Hash of the previous block.
• A hash is indicating the root value of the blocks’ Merkle tree.
• Seconds passed from Unix epoch. This is the approximate block creation time.
• The difficulty target for proof of work algorithm.
• Nonce, i.e., the counter for proof of work algorithm.

Block hash is not stored in the block’s data structure or is propagated to the network. Every node computes it as the block is received from the network. It may, however, be stored in separate disk space for the sake of quick retrieval and indexing. The same goes for block height. Also, blocks can be identified via block hash or block height.

Merkle Tree

Bitcoin blockchain stores data in blocks but in a summarized form. For this, Merkle trees are used. Merkle trees are Data structures that are used to efficiently summarize and verify large data sets.
Merkle tree is created by recursively hashing a pair of nodes until root hash/node is generated. This root is a fingerprint that can verify the existence of a transaction in it. Merkle tree has a bottom-up approach.

As the Merkle tree uses a pair of transactions to compute hash, a duplicate of it is used if the leaf node doesn’t have a pair. Hence balancing the pair, this tree is known as the balance tree. The Merkle root generated is 32 Bytes.
Any node can compute additional pairwise hashes and the Merkle tree root to verify the inclusion of transactions in a Merkle tree.
The block size increases as the number of transactions inside the block increases. However, the Merkle path required to prove the inclusion of a transaction increases relatively slow in size. Merkle tree has logarithmic space and time O(log2(N)). With Merkle trees, a node can download just the block headers (80 bytes per block) and still be able to identify a transaction’s inclusion in a block by retrieving a small Merkle path from a full node, without storing or transmitting the vast majority of the blockchain, which might be several gigabytes in size. SPV nodes use Merkle paths to verify transactions, so they don’t need to download full blocks.

Adding Transaction To Block

To put it simply, Transaction data is permanently recorded in files called blocks. Every block has a block header which serves as an identifier for a block. The validity of the transaction is determined by a node which we call a miner. Miners ensure that the transaction has valid inputs and outputs, is mature, and fulfills the unlocking script well before adding it to the memory pool. Until confirmed, the transaction is not part of the actual ledger or blockchain. Transactions are, however, added to temporary pools. These temporary pools are maintained by miners. Blocks, bundles of transactions, are mined through computation. This computation is enormous when it comes to proving but little when it comes to verification. Even after a transaction is added in a block, it still needs confirmation. Confirmation refers to a new block being added next to the previous block. Ideally, six-block confirmations make sure soft forks are not formed frequently.
You can imagine the computation as a game of Sudoku. The game takes time to solve, but verification doesn’t need too much time.

Bitcoin Network

The previous section explains how transactions become part of the network. In this section, we will have a look at the miners’ side.

Bitcoin’s architecture is peer-2-peer, which means that each node in the network is equal and connected to other nodes directly. The reason why the network has a flat topology is that it will help the network stay true to its goal of being decentralized.

Nodes

The Bitcoin nodes may store the whole blockchain, starting from genesis to recently mined blocks. They autonomously and authoritatively validate data without any external help as they have all the data they need. In the early years of Bitcoin, all the nodes were full nodes.

In contrast, there are light nodes, lightweight clients, or simplified payment verification nodes (SPV). SPV nodes do not download the whole block of data. Instead, they contain only the header. To verify data, SPV nodes ask full nodes.

Consider that a person is looking for an address. There are two ways he can proceed:
a) Get a map and use that.
b) Ask people around.
If the person decides to get a map, he can easily navigate it to reach the destination point. However, if the person decides to ask the people around for help, he may reach the correct destination, but there are chances that people may provide wrong information to him. So it will be better to ask multiple people, in our case, multiple nodes.

A full node verifies transactions by constructing a full chain of verified blocks all the way back to the genesis block. An SPV node verifies transactions by reference to their depth in the blockchain.

For example, To verify a transaction in block 500,000, a full node will link all 500,000 blocks down to the genesis block and build a full database of UTXO. Hence, establishing the validity of the transaction by confirming that the UTXO remains unspent.
Instead, the SPV node establishes a link between the transaction and the block that contains it. Then using a Merkle path, the SPV node waits until it sees the six blocks 500,001 through 500,006 piled on top of the block containing the transaction and verifies it by establishing its depth under blocks 500,006 to 500,001.
The fact that other nodes on the network accepted block 500,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double-spend.

SPV nodes can verify the existence of a transaction but cannot prove that a double spend of that same transaction doesn’t exist on its own.

As SPV nodes query data from full nodes, full nodes have a way to know which address is querying what transaction. To maintain privacy, SPV nodes can use bloom filters[b].

Network Discovery

When a node boots up, the only block it contains is the hardcoded genesis block. To discover other nodes on the network, the node must connect to at least one other node. Since the geography doesn’t affect the Bitcoin network, any random node can connect to this newly booted node.

To connect the nodes, use TCP protocol at port 8333, generally known to be used by Bitcoin(unless specified otherwise). The first message sent by a peer to another peer is a version message. To send a message, the node establishes a handshake. The version message contains:

• P2P protocol version i.e. nVersion.
• List of local services supported by node, i.e., nLocalServices.
• Current time, i.e., nTime.
• The IP address of the remote node as per this node, i.e., addrYou.
• The IP address of the local node as per discovery, i.e., addrMe.
• The type of software running on this node, i.e., subvert.
• Block height of this node, i.e., BestHeight.

The remotely connected node checks for compatibility. If the nodes are compatible, the remote peer will acknowledge the version message with a version acknowledgment, a.k.a. Verack. This informs the connected node that it can send messages.

The node finds peers by querying DNS using DNS Seeds. DNS seeds are DNS servers providing a list of Bitcoin nodes. The provided list may be a static list of IP addresses of Bitcoin listening nodes, or they may be a random subset from the comprehensive list collected by a crawler or long-running Bitcoin node once one or more connections are established. The new node will send addr message containing its IP to neighbors. The neighbor nodes forward this addr message to their neighbors. This makes sure that the overall network knows the node. After bootstrapping, a node will remember its successful peer connection, so if the node has to restart for whatever reason, it can reestablish the connection to those peers. However, if the nodes don’t respond to rebuilding the connection, the restarted node may again use DNS seeds.

Instead of automatically discovering and connecting to peers, the node setter may choose to connect to a selected IP address. For that user to provide connect = <IP Address> option. But then the note will abandon the automatic process of connecting.

If the connection of a node is traffic less, nodes communicate periodically to maintain the connection. So, if a node has not communicated on a connection for more than 90 minutes, it is assumed to be disconnected, and a new peer will be sought to take its place. Thus the network increases and decreases without any central control point.

Exchange Inventory

When the node sends a version message to its peers, the peers can determine the node’s current block height. The node can also see the block height of its peers via verack. Then peer nodes exchange a getblocks message. This message contains the hash of the top block on their local blockchain. The peer with the longest blockchain can identify that the received hash belongs to a block, not at the top. It can determine what blocks the peers need to catch up on and share the first 500 blocks to share and transmit their hashes via inv message. Inv message is used to share inventory. The peer will retrieve them by issuing a series of getdata messages requesting full blocks. The node keeps track of how many blocks are transitioned so that the node will only request new blocks as previous requests are fulfilled. This allows the peers to control the pace of updates and refrain from overwhelming the network. This process happens anytime the node goes offline or is missing blocks.

Proof-Of-Work

Proof Of Work prevents malicious miners from corrupting the blockchain. A hash algorithm takes arbitrary length input and gives out a deterministic output. The output remains the same for the same input. Proof-of-Work algorithm aims to calculate a value smaller than the predetermined yet unknown target value. A dice throw is a perfect example to imagine this.
In situation A: You want to throw a dice such that the throw gives you a value less than 6.
In situation B: You want to get a value less than 2.

Which will take more tries? It is the same with target difficulty. If, for every throw, we broadcast the answer to the network, the network can verify that work was done to reach that answer, even if it is not the required answer.

In Bitcoin, miners fill a candidate block with transactions, compute its root and header, then compute the hash of the block’s header. If the computed value is not smaller than the target value, the miner changes the nonce, i.e., number only used once, which is counter for the Proof-of-Work algorithm. Changing the nonce miner recalculates the target value until either the target is achieved or a hash of a mined block is received from the network. If the mining node receives a mined block from the network, it can verify that it was mined correctly and mining the next candidate block.

Target Value

The target value in Bitcoin is 256 bits long with a specified number of bits constrained to 0. As more bits are constrained, i.e., smaller target value, the difficulty will be higher.

The Bitcoin network mines a block with 10 minutes intervals. What happens when the block is mined before or after that interval?
The target value is adjusted after every 2016 Blocks. If 2016 blocks took more time than 20160 minutes to mine, the target value is lowered and vice versa.
The actual and desired timespan ratio is calculated, and then a proportionate adjustment is made to achieve the new target value.

New Target = Old target * ( Actual time of last 2016 blocks / 20160 minutes)

In Bitcoin, the words target and difficulty[c] go side by side, So let’s differentiate between them.
Target, in simpler words, tells the miners how small the resulting hash should be. The difficulty is a different representation of the target, which makes it a bit easy to understand.
The difficulty to find the current target of a block is referred to as “Difficulty.” The current difficulty of 13,912,524,048,946 means that at a given hash rate, it will, on average, take ~13.9Trillion times as many hashes to find a valid block as it would be at the difficulty of 1.

To avoid abrupt changes in difficulty, the retargeting must be less than four and greater than ¼. Target is irrespective of the number of transactions in the block. So, Bitcoin may scale up and get mass adopted; its security will remain unaltered.

Successfully Mining A Block

Mining nodes transmit a header to their mining hardware which then calculates the target by trying trillions of nonces per second till all 4 billion possibilities of nonce values are exhausted, or the target is found. These 4 billion possibilities are due to the nonce being a 32 Bit integer. Suppose all possibilities are tried without reaching the target. In that case, the node adjusts the block header by changing the value of coinbase extra nonce then resets the nonce counter, thus trying new combinations.
After almost 11 minutes, the node or any competing node will find the valid hash for the block, propagating it to the network to start the next round.
The network nodes validate the received block so that the block has a valid data structure, block header, timestamp, blocksize, coinbase transaction, and transactions within the block.

Extra Nonce

Miners initially altered timestamp values after checking all values for nonce, but as mining hardware got more efficient, it increased the difficulty. Now changing the timestamp too far in the future would render that block invalid.
The Bitcoin coinbase[d] script can store from 2 to 100 bytes of data. Miners started utilizing that as extra nonce space. This allows them to explore a much larger range of block header values to find a valid block. The coinbase transaction is part of the Merkle tree. Hence a change in the coinbase script causes a change in the Merkle root. Extra nonce, plus the standard nonce, allowed miners to explore more possibilities without modifying the timestamp. There is also more space in the coinbase script for future expansion of the extra nonce space & timestamp may also be utilized.

Mining Incentives

Miners use computational power, hence electricity and expensive hardware, to mine blocks. But why should they do that? The answer to that is incentives. Miners get mining rewards and transaction fees for mining blocks.

Mining Rewards

When a block is mined, BTC is mined and sent to miners as a block mining reward. These mined BTC are sent to miners; such a transaction is called coinbase transactions. Unlike regular transactions, coinbase transactions don’t consume UTXOs as inputs. The inputs are created from nothing. Miner sends these coinbase inputs to its address.

Starting with 50 BTC, the mining reward is halved at 210,000 blocks. Block rewards in how new BTC are minted to be added to the economy. The current mining reward is 6.3 BTC.

Bitcoin has a total supply of 21 Million. Out of which 18.76 Million BTC are in circulation. So the cap of 21 Million BTC will be reached by 2140.

The only way to mine Bitcoin is through block rewards. Once the total supply of Bitcoin is reached, and no more can be mined, then miners will receive incentives in terms of transaction fees.

Transaction Fees

Miners select transactions to add in blocks based on some sort of preference. It may be random, but miners mostly select transactions with higher transaction fees. Transaction fees are the amount users leave as a tip for miners to get their transaction picked up quickly. They do so by not adding a destination address for UTXOs. However, miners only get to keep the transaction fee if they mine the block.
The total transaction fee is calculated as follows:
Fee = Sum(inputs) — Sum(outputs)

Blockchain Forks

To have one main blockchain, a block must have one parent. However, if multiple blocks are mined simultaneously, the parent block may have multiple children. But whichever children get more confirmation is made part of the main blockchain, and the “fork” condition is resolved.

Mining Pools

Miners use their hardware and electricity to mine the blocks. The likelihood of mining a block to balance the cost is low for an individual mining node. Adding more ASIC chips to increase the possibility of mining a block adds to the cost and still wouldn’t ensure a 100% possibility of mining the next block.
So, miners now collaborate via forming mining pools. In mining pools, miners combine their computational resources over a network, thus, strengthening the possibilities of mining a block. They share the reward among all participants. By participating in a pool, miners get a smaller share of the overall reward but typically get rewarded every day, reducing uncertainty. The reward is shared based on how much work the participant does. To estimate that a similar mechanism as proof of work is used but with easier difficulty. For this easier mining pool difficulty, it’s like throwing the dice multiple times to reach a value. However, it is the number of throws that matter.

51% Attack

Alteration in the blockchain is possible if 51% of the network nodes are malicious. Which was not practical in real life. However, Mining pools make it possible to achieve this, but if mining pools own 51% of the network’s nodes, it will be more beneficial to operate honestly.
The 51% attacks enable attackers to create deliberate forks or include double-spent transactions.

Glossary

1 Block: Transaction data is permanently recorded in files called blocks. They can be thought of as the individual pages of a city recorder’s record book (where changes to title to real estate are recorded) or a stock transaction ledger. (“Blocks”, “Bitcoin Wiki”, 2021)

2 Nodes: A node is a computer connected to other computers which follows rules and shares information. (“Bitpanda”, n.d.)

3 Script: Script is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops. (“Script”, “Bitcoin Wiki”, 2021)

4 Genesis Block: A genesis block is the first block of a blockchain. (“Genesis Block”, “Bitcoin Wiki”, 2021)

5 Bitcoin Client: A Bitcoin client is an end-user software that facilitates private key generation and security, payment sending on behalf of a private key. (“Client”, “Bitcoin Wiki”, 2021)

6 Gossip Protocol: In gossip protocol, communication occurs when information is broadcasted from one computer to another until it is eventually spread across the network. (“Vitor Mesk”, “Gossip Protocol”, n.d.)

7 Cold Storage: Cold storage in the context of Bitcoin refers to storing Bitcoins offline and spending without the private keys controlling them ever being online. (“Cold Storage”, “Bitcoin Wiki”, 2021)

References

a. Redeem A Basic Transaction, “Stack Exchange”, (2012, October 31). Retrieved from https://bitcoin.stackexchange.com/a/5241.

b. Bloom Filters By Example, https://llimllib.github.io/bloomfilter-tutorial/.

c. Walker G. Difficulty, (2015, March 26), https://learnmeabitcoin.com/beginners/difficulty.

d. Coinbase, (2021, April 26). https://wiki.bitcoinsv.io/index.php/Coinbase.

e. Bitcoin Wiki, (2010, April 14). https://en.bitcoin.it/wiki/Main_Page.

You can also read on our latest publication Uncovering stable coins.

Originally published at https://xord.com on August 30, 2021.