AVG s soup

Bitcoin mining Systems

Bitcoin Mining / March 22, 2021

This experiment explores the problem of consensus in distributed systems in the context of Bitcoin, a distributed currency.

This experiment should take about 60-120 minutes to run.

To reproduce this experiment on GENI, you will need an account on the GENI Portal, and you will need to have joined a project. You should have already uploaded your SSH keys to the portal and know how to log in to a node with those keys.

Background

This experiment explores the problem of reaching consensus in a distributed system. "Consensus" is the problem of getting members of a network to agree on something, e.g. a value. In some systems, there is a centralized control unit who can decide on the value and then broadcast it to the rest of a network. In a distributed consensus system, members of the group have to collectively reach consensus without the benefit of a centralized unit. Further complicating the problem, some members of the group may be lying or otherwise manipulating the group to try and reach a consensus that favors them over the "true" value.

There are various solutions to the problem of distributed consensus. In this experiment, we examine the approach used by Bitcoin, a distributed currency with no central bank or other authority. In order for a distributed currency to work, members of the network must agree on how many units of the currency each member holds at all times, in order to prevent members from double spending, i.e. re-using the same units of currency in multiple transactions. This is, of course, a distributed consensus problem.

Bitcoin uses a process called mining to reach a consensus. Members of the network who choose to take part in the process of reaching a distributed consensus are called miners. Mining involves forming a block containing a series of transaction records, then finding a valid proof of work for that block that satisfies certain rules. Specifically, miners increment a nonce until they find a value that gives the block's hash a certain number of leading zeros, thereby "finding" the next block in the blockchain. For example:

Once a block has been "found", it is broadcast to all other nodes in the network, who validate the transactions it holds and accept the block if it is valid.

Overall, the process is:

  1. New transactions are broadcast to all nodes in the network.
  2. Miner nodes collect the new transactions into a block.
  3. Miner nodes try to find a proof of work for the block.
  4. When a miner node finds a proof of work, it broadcasts it to all nodes in the network.
  5. Receiving nodes validate the new block and then start work on the next block, containing transactions that have not yet been placed in a block.
  6. The node that found the block is rewarded with some new Bitcoins, and also the value of the transactions fees for the transactions in the block.

Miners choose which transactions to include in the block they are mining based on priority algorithms that include metrics such as the age of the transaction and the value of its transaction fees. So it is possible for two nodes to arrive at different "next blocks, " potentially at the same time, and broadcast different blocks to the rest of the network. If this occurs, the blockchain is said to be forked, and the network needs some way to reach a consensus on which block to accept as the next block.

Bitcoin clients operate on a simple rule: always trust the longest chain of blocks. If a node received two "next blocks", it will save both and start to work on the next block in one of the chains. If in the meantime it receives a new block for one of the chains, it will discard the shorter chain and start to work on a next block for the longer chain. (Miners have an incentive to work on the longest chain, rather than continuing to work on the chain following from the orphaned blocks, because they want to earn the Bitcoins associated with finding the next block in the longest chain.)

The main chain (black) consists of the longest series of blocks from the genesis block (green) to the current block. Orphan blocks (purple) exist outside of the main chain. Image by Theymos CC BY 3.0, via Wikimedia Commons

A key property of these blocks is that in order to replace a block that is already in the blockchain with one of its own, a node would have to compute the proof of work for that block and all subsequent blocks that have been added to the blockchain after it, since in order to get Bitcoin clients to accept your version of the blockchain, you need to have the longest chain.

Finding proof of work is computationally difficult, so the more blocks have been added to the blockchain after the block containing a particular transaction, the more secure it is and the less likely it is that the block will be replaced (rolling back the transaction). Most Bitcoin clients consider the a Bitcoin transaction to be confirmed after six more blocks to be added to the chain, and the Bitcoins awarded for finding a new block are considered to be confirmed after 100 blocks.

This kind of consensus is not completely invulnerable to double spending. Suppose an attacker submits a transaction to the network that pays some of its Bitcoins to another party, while simultaneously mining a private blockchain fork in which it re-uses the same currency for another transaction. After waiting for n confirmations (i.e. n more blocks are added to the blockchain that the rest of the network sees), the other party considers the transaction to be secure and sends the attacker the good or service that it paid for. At this point, if the attacker has more than n blocks in its privately mined fork, he can broadcast his forked chain, including the double-spend transaction, to the network and effectively use the same Bitcoins twice. If not, he can continue to try extending his private fork in hopes of surpassing the rest of the network, at which point he will release the fork. The probability of this succeeding depends on n and on how much hashing power the attacker has relative to the rest of the network.

If an attacker controls more than half of the hashing power in the network (i.e. there is a 51% chance or greater that it computes the next proof of work), then the attack described above will succeed with 100% probability. Since the attacker can generate blocks faster than the rest of the network (on average), eventually his private fork will surpass the blockchain constructed by the rest of network. This is known as a majority attack.

There have been times when pools of Bitcoin miners have controlled more than 51% of the hashing power in the network, but they have not used it to carry out a majority attack. It is typically more profitable for a majority pool to use its hashing power honestly to generate new coins, than to use it to steal back payments made to other people.

In this experiment, we will see how multiple confirmations are required before a Bitcoin transaction or mining rewards become spendable. We will also see how a Bitcoin network reaches consensus when the blockchain is forked.

Results

In this experiment, we allow a fork to develop in a Bitcoin network. One side of the network has one hash for the last block in the chain:

ffund01@node-4:~$ bitcoin-cli -regtest getblockhash 121 5eaf42996bc3062e96f096eee12131f34f1e48c137eb4cfe2e9cf75f5a4826fc

while the other side of the network has another:

ffund01@node-0:~$ bitcoin-cli -regtest getblockhash 121 4e5545b5f3bf4f57914c11cf835aeccc5fd51e38139d9c25c4ecd67904ea9869

Source: witestlab.poly.edu