Reducing the risk of Bitcoin forks during network upgrades

How to manage forks and the split in the forking process, a guide for exchanges and enterprises

(Translator's note: In this article, Fork is translated as "fork", which only refers to one way of protocol upgrade, which can be divided into hard fork and soft fork. Split is translated as "split", which refers to the process of splitting the blockchain into two chains during the fork process. Fork Split means that a split occurs after the fork process.)

summary

In the Bitcoin community, everyone is advocating their own expansion plan, even at the expense of the system's broad consensus or compromise. Since the birth of Bitcoin, the risk of splitting during the Bitcoin fork is the highest. One thing is certain at present. If the deadlock in the Bitcoin expansion plan continues, the only result is that we cannot achieve Bitcoin expansion. In this sense, although it is somewhat unfair, for all members, splitting after forking is the best result. Under the assumption that Bitcoin is going to fork and split, this article attempts to explain the technical processing methods for enterprises and users to fork and split on the Bitcoin blockchain, as well as how to manage Bitcoin blocks.

The motivation for this article is that the recent news from the Core community about the implementation of UASF (an implementation that only requires the support of a minority of computing power, but still requires the support of a majority of economic nodes) is a clear and imminent threat to the stability of the network, especially for exchanges and enterprises operating Bitcoin. In the case of UASF, the blockchain has the potential to split into 2 or 3 branches. If UASF is implemented without warning, enterprises, especially exchanges, may face the risk of losing customer funds if they are unable to cope with this special situation. Regardless of whether they actually intend to support various forks, the purpose of this article is to prepare enterprises so that they can continue to protect customer funds in such a situation.

Types of blockchain forks

First we list the types of forks that may occur

Soft Fork

A soft fork is a new consensus rule that is a subset of the current rules. On the new chain, blocks that comply with the new, stricter rules will be valid blocks, while on the old chain, blocks produced according to the looser rules on the old chain may be invalid blocks on the new chain.

Hard Fork

A hard fork is a fork that removes or relaxes consensus rules. On the new chain, blocks that comply with the new rules are valid blocks, but only valid on the new chain and invalid on the old chain. However, blocks produced by the old chain are valid on the new chain.

Small hashrate (hard/soft) forks

A small computing power fork occurs when a small computing power blockchain intentionally forks the network by producing blocks that are not accepted by the large computing power. In addition, a small computing power blockchain can arbitrarily create rules to force all future blocks produced on the main chain to be invalid on the small computing power blockchain.

High hashrate (hard/soft) forks

A large computing power fork occurs when a blockchain with large computing power support intentionally forks the network by publishing a block that a small computing power blockchain does not accept.

User Activated Soft Fork

This type of soft fork is done when a majority of user nodes (wallets, full nodes) upgrade to a software version that can coordinate a block height that enforces certain new validity rules. For example, there is a rule that states that if a block's UXTO set does not pay a new segregated witness output, then it is invalid. This rule can be enforced even without the support of a majority of hashrate. In general, this is a special type of small hashrate fork. Large hashrate forks tend to have majority hashrate support, and UASFs tend to have majority support from economic nodes.

This small hashrate fork has the additional risk of creating three branches. Because this small hashrate fork is driven by nodes, this means that once this fork occurs, the other branch will have the majority of hashrate. As a reaction to avoid being reorganized (see below), the majority hashrate will immediately perform a large hashrate soft fork, resulting in three blockchains: the large hashrate soft fork, the small hashrate soft fork, and the original blockchain. This state is temporary, because the original blockchain will eventually be surpassed or merged/reorganized by one of the soft fork blockchains after the fork.

This type of fork may prevent customers from seeing the process of withdrawing funds from the exchange, causing after-sales service problems for the exchange. Exchanges tend to upgrade their nodes to support both branches and ensure that customer withdrawal requests are processed through this upgraded node. Supporting this policy implicitly means that the exchange agrees to split Bitcoin products in the future. This means that customers must create and hold their balances on other chains in the exchange's accounting system. We recommend that exchanges complete the split Bitcoin before making withdrawals to avoid mixing up account balances. (See the process of splitting Bitcoin below)

Technical characteristics of forks

Restructuring risks

The risk of reorganization is that after the fork, the original small computing power blockchain may surpass the large computing power blockchain, causing the longer blockchain to return to the small computing power chain, which will cause all transactions on this (large computing power) blockchain from the fork point to be cancelled. In fact, this is the orphan block of the normal Bitcoin network, but it is not uncommon for several blocks to be reorganized several times a week. The reorganization that occurs on the branch chain after the fork is unilateral, which means that it will only occur on one chain on the fork side or the original chain side.

Due to the inherent characteristics of soft forks, that is, under the existing rules, soft forks tighten the rules of block validity, so it will bring the risk of block reorganization on the original chain. The forked side will never accept the blocks of the original chain. Because the blocks of the original chain do not conform to the newly added rules of the soft fork, the newly added blocks of the original chain are invalid blocks in the eyes of the forked side. The reverse is not true. Because on the forked side, these blocks that conform to more additional rules obviously also conform to the rules of the original chain. Therefore, there is a certain small probability that the growth rate of the blockchain on the forked side may exceed the growth rate of the original chain, which will lead to the reorganization of the blocks on the original chain. For hard forks, the above situation is just the opposite: that is, reorganization may only occur on the forked chain, and no block reorganization will occur on the original chain. This is because the newly added rules of the forked chain are incompatible with the original chain. Therefore, hard forks may only have the risk of block reorganization on the forked side, and the original chain will not be affected, that is, the original chain is not at risk.

There is only one factor for this risk. If there is a greater profit-seeking PoW computing power on the chain with tightened rules, which exceeds the computing power of the original chain, this will lead to more consecutive blocks being mined on this chain than on the original chain. At this time, the original chain must consider the risk of reorganization. If this risk is too great, a one-time checkpoint can be established after the forked block, and reorganization will not occur. One feasible implementation method is to add a soft fork rule, which makes any block that does not contain the forked block as its ancestor block invalid.

Reorg risk is a trade-off between the risk of following a small-hash chain and the risk of following a small-hash chain. If one always wants to pursue the longest proof-of-work chain, then reorg risk is inevitable. Adding a checkpoint to avoid reorg risk will in turn introduce the risk of following a small-hash chain and lead to separation from the majority economic side.

Separating Bitcoin Assets

There will be three possible types of coins after the Bitcoin fork: pre-fork, post-fork Red, or post-fork Blue. It is easier to understand from the perspective of UTXOs. A pre-fork UTXO set will become a post-fork AorB UTXO set, but not vice versa (a post-fork A or B UTXO set cannot be converted into a pre-fork UTXO set). These UTXO sets can only exist on one blockchain or the other, but not on both blockchains at the same time.

A pre-fork UTXO may continue to exist and be available on both forks A and B as long as they are not spent. Once spent on one chain, the transaction is confirmed on either fork A or B, then the UTXO can be said to be permanently separated.

Worry about creating additional “value”

When Ethereum split, many people were concerned about the extra "value" generated. There is also an article on Coindesk that explains this issue. But in general, in the case of Bitcoin splits, it is impossible to quickly perform "arbitrage" because it is not easy to separate Bitcoins and it requires considerable work for exchanges and participants. In addition, the supply of pure blockchain A and blockchain B is very small at first, and the rate of increase is very slow. This rate is determined by the natural diffusion rate of newly mined Bitcoins and the natural growth rate of UTXO. The natural growth rate of the UTXO set in a small computing power blockchain is greatly hindered due to the small computing power and small transaction processing capacity. This avoids a large number of speculative investments in ETC, where these speculators have lost a lot of money due to high risks, but still expect that if they all buy ETC, most miners will follow suit to mine ETC.

Double Spending Attack

Blockchain splits are often pointed out as problematic, in other words, if a fork occurs, a transaction that is valid on one blockchain is also valid on both blockchains, which increases the risk of double spending after the split. Double spending can happen when your recipient is on one blockchain and you are on another blockchain. You can send a transaction to your recipient on one blockchain, but spend the same UXTO again on another blockchain, paying yourself. This is a false attack because usually the person you are paying to will not pay attention to receiving payments on both blockchains.

Replaying transactions

This vulnerability is a variation of the double-spend attack, which first emerged when Ethereum forked into ETC and ETH, and mainly affected exchanges that were not well prepared for the fork. This issue is described in this article (insert article link). This attack is preventable with adequate preparation. In summary, exchanges that wish to support both forked blockchains and facilitate trading of the two new coins as independent products need to distinguish the two coins equally. In addition, the process of splitting coins (described below) must be implemented so that exchanges do not accidentally send out one coin. This is especially important to prevent those who want to use the split coin strategy to obtain the other coin when withdrawing coins.

Notes - Bitcoin Exchange

Support for division

The main strategies that exchanges use to support both coins fall into several categories: 1) Running nodes on both blockchains; 2) Private key management; 3) Purchasing split coins; 4) Monitoring forked blocks; 5) Separation coin process

Running nodes on both blockchains

All exchanges should run client nodes for each fork, so they can monitor activity on both blockchains and avoid potential loss of customer funds. Running nodes on both blockchains allows you to manually split your coins effectively, while providing you with accurate account balances in your hot wallets. You should run a node for each possible fork before the actual fork, so that you can monitor which fork your customers' deposits are coming from by looking at the hot wallet balances.

Private Key Management

It is important for the exchange to synchronize its private keys on both chains. The hot wallet address used for reserves on both chains should be the same, which ensures that if a user accidentally transfers funds, the exchange has the ability to refund.

Buy Splitcoin

Using the UTXOs in the coinbase txn of the higher block after the fork to separate the UTXOs of the two chains after the fork is a way to separate customer deposits while ensuring that withdrawals are not mixed up. Exchanges can buy newly produced coins directly from miners, pure coinbase coins, or manually separate coins themselves.

Buy Pure Coinbase Coin

Purchase coinbase coins directly from miners on both forked blockchains and place them into separate "pure" bitcoin pools (addresses) that clearly identify which branch chain they belong to (coinbase transactions). These pure post-fork coinbase coins will be the key to separating the coins. You must verify the history of each utxo to ensure that they originated from the coinbase transactions of their respective corresponding chains after the fork block appeared. Note that exchanges only need to purchase a sample of pure coinbase UTXO sets, and then exchanges can use this initial sample to separate the entire "inventory" into red coins and blue coins. If exchanges do not want to separate all UTXO sets, or cannot afford to separate them all, then we recommend that exchanges do not support coins on both blockchains separately.

Manually separate coins

The manual method of separating coins is relatively simple. You can also manually separate coins without purchasing pure coinbase coins mined by miners. However, for absolute security, use 1 pure separated coin UTXO set as "contamination separation". The exchange can decide whether to split the entire reserve or only separate the money put into the hot wallet when it is needed. The process is as follows: Assume that the exchange controls 3 addresses, A, B and R. A is an address with pre-fork coins (mixed) Bitcoin, such as cold wallet storage. That is, there are large computing power chains and small computing power chains, which we call red chains and blue chains respectively. B is the hot wallet address used to store pure blue coins, and R is the address used to store red coins. This example assumes that the exchange plans to mainly support large computing power chains, but if you want to mainly operate small computing power chains, this process can be modified.

• Starting from A (A may use a cold wallet), create a transaction to send Bitcoin to B, mix 1 simple separation with UTXO as input, called: A->B,

Alternatively, you can create a transaction with a length of 999,999 bytes, which is only valid on blockchains > 1MB.

• Submit the transaction to the network (it doesn't matter which blockchain it is on). Wait until A->B is confirmed on the expected blockchain. (The transaction will be confirmed on the same blockchain as the one that used the tainted UTXO)

• On a suitable node, use a library that can assemble raw transactions from UTXOs (such as bitcore), and use this library to create a raw transaction whose UTXO is created by the confirmed A->B transaction

• Send this UXTO collection to address R, in this transaction B->R. Once B->R is confirmed on the red chain, now you have pure separated coins. Blue coins are in B, and red coins are in R.

Note: It is not necessary to use two different addresses, you can just put both split coins in address B, but using different addresses can avoid some confusion in accounting systems, which would require running on two blockchains at the same time. Separating Bitcoin into two different addresses makes it easier to maintain internal settlement and accounting reconciliation processes, because Bluecoin and Redcoin can be considered two different products.

Detecting forked blocks

For each split chain, it is important to know at which block height the split occurred. We call this block the fork block. The fork block is the first block after the last common block (LCB) shared by the two blockchains after the split. To detect a fork block, you first need to find the LCB shared by both blockchains. This only needs to be done once, and you need to query the block hash values ​​from the top of the blockchain on each node of each chain until you find the LCB. The fork block on each blockchain is the block immediately after the LCB.

It is worth mentioning that it is much easier to detect forked blocks on the nodes running the big computing power chain. This is because the orphan block pool on the big computing power chain contains the blocks of the small computing power chain, which can be scanned. On the contrary, the blocks generated by the big computing power chain are not stored on the small computing power chain, because the small computing power chain considers these blocks to be invalid and will most likely abandon them.

Coin Separation Management

Exchanges that want to support both forks should split their hot wallets into 3 parts: red, blue, and a pre-fork "neutral" set. Exchanges need to separate the coins around deposits (or withdrawals) and manage the two coins as different products on the trading platform. This ensures that withdrawals are only processed from the corresponding mining pool when used by each.

Complete the three processes of currency separation:

Deposit Process

Managing user deposits on a split chain is simple, just give the user a different deposit address for each chain, and monitor which chain the deposit is confirmed. This is possible because the exchange runs nodes and blockchain explorers on both blockchains. This needs to be handled when a customer accidentally deposits to the wrong address, or when a customer deposits both Red and Blue coins. In both cases, the exchange simply needs to contact the customer and return the funds, and return the coins on the other chain from the exchange's own clean coin reserves.

There is a simpler method for exchanges that do not support two chains. Just check the input of each deposit transaction to confirm whether all the inputs of the parent block are from the block after the forked block. If so, the customer may have stored Bitcoin at the same address on the other blockchain (unless they deliberately double-spend). Then in order to withdraw funds for customers, it is necessary to run a node with a large computing power chain.

Reserve Separation Process

There are two strategies for managing exchange reserves: 1) convert all reserves at once; 2) convert reserves only when withdrawals are needed from hot wallets

The first option is to convert all reserves into split coins by the method of splitting coins described above. Alternatively, the tainted separation procedure described below can be used, which is easier to calculate. Because the remaining red coins are stored in a specific HD wallet branch, while the blue coins are in another independent address tree. Some people think this is impractical, on the grounds that some of the exchange's reserves are stored off-chain, some in cold wallets, and some in wallet management companies.

The second option is to leave the reserves there and rely on splitting off the pre-fork coins as part of the withdrawal process. This method is simpler but does mean that some accounting procedures will be involved. It is important that the exchange run back-office systems on both chains in order to keep the reserve balances of each coin accurate.

Withdrawal Process

Bitcoin withdrawals are the most important part of managing the split coin process. This involves ensuring that the correct coins are sent to the client when they make a withdrawal request. This means that performing the split coin procedure is mandatory for withdrawals, if the exchange’s main reserves have not been split.

Pollution separation process

In order to separate the spending coins, a "tainted separation" process can be used. In this process, when a client attempts to withdraw funds, a withdrawal transaction is manually created on the corresponding blockchain, and a UTXO from a pure post-fork coin address is added to the transaction to "taint" the transaction. This additional post-fork UTXO is to come from the 'pure' UTXO mining pool to ensure that the withdrawal transaction is not valid on both the red chain and the blue chain at the same time.

Notes for Exchange Users

Current Currency Balance Policy

After a fork, if the exchange decides to support both branches, what will happen to the user's Bitcoin balance (off-chain balance)? When a fork occurs, the exchange should inform customers in advance that the coins in the exchange will be saved on any branch, but the exchange will suspend withdrawals until it forks into one or two chains, until the risk of block reorganization has passed. (Each exchange has the right to decide the safe time point, but a better evaluation standard is to reach a depth of 100 blocks on a minority hashrate chain, which can be considered a reasonable low-risk time point.)

At that stage, the remaining Bitcoin balance should be split and separated from the exchange's own reserves via one of the split coin methods. For each fork supported by the exchange, 1 pre-fork coin should be equal to 1 post-fork coin. After that, there should be no pre-fork balances.

Notes for wallet users

If two forked coins are supported at the same time, and when one of the coins already supports withdrawals, it must be emphasized to users that the coins they are receiving are the split coins, and users must use a node wallet that can recognize the split blockchain.

For SPV wallets, depending on the node they are connected to, they may see potential confirmation conflicts (at different block heights) for the same transaction. As long as the transaction is confirmed, this is of no concern. Wallets running on one blockchain or the other will only see the transaction confirmed when they see the corresponding blockchain information. If the prefork UTXO is spent, all wallets will see the transaction (0-conf). If it is a post-split coin, you will not see the transaction on the other fork.

What customer service needs to know is that it is possible for a withdrawal on one blockchain to not show up on the user's wallet. This is not a problem as it is simple to retrieve the bitcoins and change the wallet to read blocks from other blockchains. No coins are actually lost, they just can't see it for the time being.

Does not support splitting

The simplest option is to only support the longest chain, without using a specific process to separate coins, and only make withdrawals and deposits on one fork and ignore the others. However, this may put customer funds at risk.

Even if an exchange does not publicly support the idea of ​​listing both split coins for trading, if both blockchains survive the fork and are more than 100 blocks deep, the exchange is still obligated to provide withdrawal services to customers who want to withdraw coins from both chains. Supporting this policy means complying with the policy for managing coin separation described above in this article so that there are enough forked coins for the exchange to use for withdrawals.

This policy is safe as long as customers are aware of it. If the exchange does not intend to support two split-chain coins and there are customers who are unaware of this policy, there may be a problem, that is, customers try to deposit Red Coins to exchanges that do not recognize or trust Red Coins. How this problem is solved depends on the exchange's policy. However, in order to protect customer funds, every exchange should adopt the coin separation policy mentioned in the "Support Split" section above.

Notes - Wallet Users

Users can choose to ignore the split or make money by selling the Bitcoin they do not support. To hold the split coins, you need to use a wallet that supports each blockchain. Whether it can support the small hashrate chain depends on the wallet.

The most important thing for wallet developers who support both blockchains is to make sure there is a good source of market data showing the price of the less powerful chain, so that they can be informed when they have paid the wrong bitcoins by the relevant price difference.

Additionally, if a server-based wallet is connected to a low-hash "blue" chain, either by accident or carelessness, customers need to consider why they do not see the bitcoins they received in their wallet balance. The best approach in this case is for the wallet developer to upgrade the software to support the high-hash chain so that users can see their money again. If the wallet developer is unwilling to update the software, it may be difficult to get coins from the wallet on other blockchains. Therefore, we recommend only using wallets that support the longest proof-of-work, or the blockchain with the majority of hashrate.

Online Wallet

This will depend on which blockchains the website supports. It is questionable whether they will support both blockchains, most likely only the longest one. If they decide to support both blockchains, they may be able to let you choose which one you want to connect to.

SPV Wallet

SPV wallets are by default independent of block size, so they will only follow the highest block height. Unfortunately, if an SPV wallet is connected to all nodes on only one blockchain, then the balance values ​​it displays will be different than if it is connected to all nodes on another chain. If it is connected to a hybrid node, then it will display the balance of the longest chain. (This is why the "longest chain is correct" policy is relatively safe)

Hardware wallets

This depends on the specific wallet. Some wallets are paired with their own node, while others use a server backend. Find out which category your hardware wallet falls into, and further advice will be given based on the wallet category. You should be able to set up a wallet that connects to the blockchain of your choice. It is important to know which blockchains your hardware wallet supports, because if you want to withdraw funds from the hardware wallet by confirming transactions, you need to know which blockchain to look at. In fact, in the event of a fork, the bitcoins that appear in your hardware wallet will be pre-fork coins, and it is relatively safe to send funds from the wallet. Receiving coins to a hardware wallet after a fork may cause problems if the wallet is not listening to the chain you expected. In the worst case, the coins are sent to the wrong blockchain, resulting in the loss of your coins, unless the developer of the hardware wallet decides to add support for this blockchain. If you want to use a hardware wallet, we recommend that you make sure you only use the hardware wallet on the blockchain they support. (Most likely the longest blockchain)

Server-based wallets

If you can control which node your wallet points to, you must have your wallet use a node on the low-computing chain. If you don't control the server your wallet connects to, then you will be locked into transacting on the blockchain supported by your wallet provider. If they decide to support two blockchains, they may be able to provide some details that allow you to choose which blockchain to connect to.

Client node wallet

The simplest option is that you can just run the software for the blockchain you want to connect to. For clients who want to separate their own bitcoins, they can send bitcoins individually, which requires running nodes on both blockchains.

Notes - Business and Payments

Payment Processors

As a business, the best option is to follow the longest chain. Supporting all blockchains will confuse your customers and cause customer service issues. You may be asked to refund a split coin to a fork chain they did not intend to pay with because the customer accidentally sent you a prefork coin. Unlike exchanges, supporting minor chains does not generate additional profit, like exchanges can charge more transaction fees. Supporting minor chains is just a net cost to your business, but if you want to support two blockchains for ideological reasons, then refer to the chapter on exchange considerations to keep the coins separate. One suggestion is to run a client node on each fork chain, which allows you to see all transactions on the other chains. This helps to ensure customer satisfaction in case a customer accidentally pays with the wrong coin and then needs to refund. This is necessary for businesses in the payment processing business.

Furthermore, unless there is reliable market data on the price of small hashrate coins, the processors of enterprises cannot support small hashrate chains. In any case, supporting payments that exceed payment processing capabilities is risky, as there is a risk of a customer requesting a refund when an unexpected payment occurs.

General risks of forks

UASF Risks

UASF activates forks without the support of the majority of computing power, which will bring some inherent risks that large computing power chains do not have. In other words, UASF may temporarily generate at least 3 forks.

One possible scenario is if a UASF is initiated by an influential group, resulting in a small hashrate soft fork that activates Segwit. This could trigger a third hard fork based on the potential demand for a hard fork that increases the block size of Bitcoin (e.g., to 4MB). For the original UASF, this is possible. Because, assuming that all Segwit supporters have already forked on their own blockchains, there is no opposition to the hard fork to increase the block size, and the remaining hashrate supporting the hard fork will become a majority, enough to initiate a safe hard fork. This will result in 3 forks, a Segwit fork, a 4MB fork, and the original blockchain. The 4MB blockchain is likely to create checkpoints to eliminate the risk of reorganization on the Segwit fork chain, leaving only one original chain vulnerable to attack, thus encouraging remaining participants to join the 4MB fork or the Segwit fork. However, the 3 blockchains will remain for a period of time, during which time it becomes more important for businesses to be prepared to protect customer deposits.

Speculation Risk

Whenever a blockchain splits and creates (potentially temporary) new coin account balances, there will be traders who will try to profit on exchanges by buying the cheaper, less-hash-powered fork of the chain, or by selling all of one split coin and buying the other (if anyone can predict how the fork will resolve). This is a high-risk activity and should be avoided unless you are prepared to lose everything. The safest way to protect your money during a coin-split is to not move any coins until the split is complete, either by failing back to one blockchain or forming two stable new blockchains.

Professional terminology

Fork Block

A forked block is the block that starts the split on a blockchain. Its complement block is on another blockchain. Assume that this first block is considered illegal on one chain network, but legal on the other chain. In other words, the forked block is the first block on each blockchain, and they are not on the same ancestor blockchain.

UTXO

There are some unspent transaction outputs in a transaction. The set of UTXOs in a node's memory is the sum of all unspent coins in the system. (Not including unspent coins generated by coinbase)

Prefork UTXOs, Prefork coins

These UTXOs sets are the unspent transaction output sets formed by the blocks before the fork block (excluding the fork block). Sometimes referred to as "mixed UTXOs" because these sets can be used for both the red chain and the blue chain.

Red coins, blue coins, collectively referred to as post-fork UTXOs or "split coins"

These UTXOs are generated from the fork block and the subsequent coinbase transactions. If a UTXO set is traced back to the coinbase transaction formed from the fork block and the subsequent coinbase transactions, then these are called "split coins". Because there are two sets of split coins, one from blockchain A and one from blockchain B, in short, they should be treated separately and they are different coins.  

Coins​

For the purposes of this article, the term is sometimes equated with the UTXO set, as described in the text.

Coinbase

In addition to referring to the "Genesis Transaction", it also refers to the first transaction generated in a block.

Node​

A node is a client software that connects to and participates in a consensus network. Sometimes it refers to client node software with block browser functionality.