If the term ‘orphan’ comes up in everyday life, it comes with an implication of misfortune, and perhaps that's why there has been some misunderstanding about Bitcoin’s orphan blocks as a feature which incentivises performance within the Bitcoin system.
Contextualising orphaned blocks
The proof-of-work process for Bitcoin mining involves massive arrays of networked hashing machines dedicating their resources toward mutating an 80-byte value into a unique 32-byte value via the SHA256 hash function. Each networked machine will perform this mutation in excess of 100 trillion times per second.
The chance of finding a valid proof-of-work will generally have a likelihood with somewhere around a 0.0000000000000000000000001% probability for a correct solution per trial.
How Nakamoto consensus judges a winning block
Despite these slim odds, there are still instances where two competing miners produce a valid solution within a few seconds of one another.
This seems easy enough to resolve. Shouldn't the one who found a valid solution first be the correct one to be time stamped into the blockchain?
Firstly, Bitcoin does not have an agreed upon timing for when these blocks were produced, as the timestamps applied to a valid block need only be accurate to approximately two hours.
Additionally, on occasion, blocks are produced so close together that they may share identical timestamps. And yet, network latency could result in different miners holding contradicting chronologies of their first-seen block proposal.
To resolve this, part of Nakamoto consensus stipulates that it is the first-seen valid block by a miner that they will extend the chain upon. When they have validated the proposed block, they will signal their acceptance of that block by using its 32-byte hash to populate the PrevBlockHash field in the next block template.
This all seems rather straightforward, albeit with some subtle intricacies.
However, what happens as network throughput increases and validating all the transactions in a block proposal involves checking tens to hundreds of billions of transactions contained in a block?
If the receiving nodes are to validate every transaction after the block announcement, this process is sure to delay the validation of that block. This in turn could lead to a miner producing a block in the interim before these transactions are validated.
The Bitcoin white paper on dealing with close competitors
Section 5 of the Bitcoin white paper documents the steps to running the network.
‘1. New transactions are broadcast to all nodes’
Bitcoin white paper
Step 1 has been misconstrued by many to mean you broadcast your transaction to all the nodes. However, these steps are for the Bitcoin miners rather than users, and in that context, we should see that each miner who receives a transaction is obligated to broadcast new transactions to all nodes.
This means that by the time a miner produces a valid block, most transactions in it should have already been seen and validated by other network nodes. Therefore, a node may only be required to request the few transactions that hadn’t yet been piped to the rest of the network from the proposing node, which in turn significantly reduces the delay before a node can signal their approval of a block.
This sharing of transactions in real time benefits the network greatly. It is this open and honest communication of network events as they are seen that is critical for the implementation of Simplified Payment Verification (SPV) and scalability.
How Nakamoto consensus breaks a tie
When two blocks are produced in quick succession, it is said that an Orphan Race has been initiated. This race will be resolved when either:
- All miners switch to only one of the contenders.
- When another block is found which builds upon one of the contenders, extending that chain tip to the longest proof-of-work chain.
- Occasionally the next blocks will also be found within a few seconds of one another and will again be resolved by either step a or b.
If you are the miner who produced the block which failed to be built upon to extend the chain, then you do not get any spendable reward, since the block maturity rule says a coinbase transaction which awards the fees and block subsidy can only be spent after 100 blocks have been built upon it.
This has the effect of incentivising nodes make sure they are as well connected to other nodes as possible so as not to cause any delay before all transactions can be validated and minimise the possibility of them wasting money on building a block that has a less likelihood of being built upon by the majority of hash power.
When an orphan race is resolved, as long as neither chain tip has any invalid transactions or double spends included in it, then there will be no problems with switching a transactional chronology of ABCDEF with ABDCFE.
If one chain tip did indeed have double spends in it, then those blocks can be discarded just as usually occurs. The race can only occur when there are two valid block proposals.
Orphan races incentivise a low latency, high bandwidth network
Without the feedback mechanism of the orphan blocks and the coinbase maturity rule, there would not be the same incentives for the nodes to have such low latency, high bandwidth connections to one another. Without these low latency, high bandwidth connections the network wouldn’t perform as well as it does.
Because of the risk of orphans, the most well-connected miners are the most economically fit with the lowest chance of either producing or building upon a block which will likely be orphaned.
This incentive structure is critical to forming the network topology which is exclusive to the BSV blockchain. The near complete ultra-small world network of mining nodes is what allows Simplified Payment Verification (SPV) to be a secure process for handling billions of transactions a second.
Orphaned blocks are a feature, not a bug
This elegant solution demonstrates the careful consideration for developing the incentives on the network which eliminate the need for any intermediary to resolve this inevitable outcome of near simultaneous solving of the hash puzzle.
In effect, Satoshi Nakamoto turned something which would normally be a problem that needs to be dealt with, into a feature of the network which drives all miners to perform to their highest potential, or else!
