July 31st update – We’ve issued a complete list of who supports the fork and who doesn’t.
This post complements the previous post we’ve written about the controversy within the Bitcoin community on March 2017. If you want a deeper understanding of what’s going on please read the original post. If you just want the gist of it, continue reading…
Recently people have been asking about SegWit, August 1st and the possibility of a split in the bitcoin network. In this article we’ll explain what it’s all about and how can you can prepare for what’s coming. This topic is EXTREMELY complicated for non technical users, so in order to make it easier for anyone who doesn’t want to dig too deep into the details here’s the TL;DR version:
- It is currently estimated the most likely there will be no split on August 1st. If there will be a split at all it will likely take place in a few months.
- It’s always recommended to keep your coins on a self hosted wallet wallet which gives you full control over your private keys. Make sure you keep a backup to your wallet. With most modern wallets the backup is in the form of a 12-word passphrase.
- In the week leading up to august 1st we’ll know more about whether we’re heading towards a split or not. If we are, it’s recommended to avoid sending and receiving coins in the days following the split until things clear up.
- This is a dynamic issue. Even though it seems like a compromise was achieved there can always be changes. Check in with r/Bitcoin and r/BTC for the latest developments.
The general background of the story
The source of the issue is Bitcoin’s scalability – It’s ability to handle a growing number of transactions. The current protocol limits the size of each block to 1MB (once every 10 minutes on average). This, in turn, limits the growth potential for bitcoin’s usage.
There’s a need to upgrade the protocol, but there is a disagreement about the best way of doing so. This disagreement has been a hot topic for over two years, and has gone beyond just a technical discussion, into a two camps schism about politics, governance, philosophy, identity, side picking, propaganda and more.
One of the consequences of the inability to decisively reach a solution is that it that none of the proposed solutions have been implemented and therefore the network’s capacity is still limited. As a result, there are periods where the transaction fees rise dramatically, due to inability to fit all of the transactions in the upcoming block. In other words, people are paying more in transaction fees in order to “cut in line” and get their transaction confirmed quicker.
Many proposals were made, but two leading solutions have been brought forward. The 2MB Hard Fork and the SegWit Soft Fork.
About them forks…
There are two main ways in which you can upgrade the bitcoin protocol, a hard fork (HF) or a soft fork (SF).
Hard forks loosen up the rules of the protocol. Blocks which were invalid by the old protocol become valid in the new one.
Soft forks tighten the rules of the protocol – Blocks which were valid by the old protocol become invalid by the new one.
A hard fork obligates all of the nodes in the network to upgrade in order to be implemented . A node that does not upgrade to the newer version, will run into blocks which are invalid by his version, will reject them and the rest of the chain, refusing to recognize what’s taking place on the network.
A soft fork doesn’t require all of the nodes to upgrade. The main chain, valid by the strict new rules, is also valid by the older rules enforced by a node that did not upgrade. Therefore it will accept all of the transactions in it.
Having said that, nodes that are taking a part in mining do need to upgrade. This is needed so they won’t mine blocks that are invalid by the new stricter rules, which will be rejected by other miners. Nodes that want to explicitly use new features enabled by the soft fork must also upgrade.
Due to the inability to make sure all of the nodes in the network have upgraded, and the damage done to a user that did not upgrade in a hard fork, hard forks are considered by many to be a riskier solution. Hard forks should be used mainly as a last resort and need to be carefully planned. Soft forks, on the other hand, are considered a safer, successfully tested solution.
Holders of this position, including the community of the reference client (Bitcoin Core) are advocating for a solution called SegWit (Segregated Witness). The witness refers to the signature of a transaction, and the segregated refers to the possibility to separate it from the block and keep it in a separate database.
This mechanism has a number of advantages:
- It solves a problem called transaction malleability, which allows for the same transaction to appear with different transaction IDs and confuse the system.
- This fix will allow the use of bitcoin for more advanced transaction types, such as a payment channel network called the lightning network, which aims to dramatically increase Bitcoin’s scalability, allowing for instant, cheap and safe transactions.
- It also gives an immediate effective block size increase, and does it through a soft fork. This is why the development community rather start with SegWit as a solution to the current network congestion, and then consider if and how to implement further solutions.
User Activated Soft Fork (UASF)
Bitcoin’s development team, which supports SegWit, has released a new version of the software that enforces the new SegWit rules after 95% of miners show for it as well. When a miner mines a block he can signal his support for SegWit, and when enough miners do so the soft fork becomes valid.
Unfortunately, Not enough miners have signaled for SegWit support, so the protocol does not change.
Some of SegWit’s eager supporters decided to take action despite the miners signaling and developed a procedure called UASF, or User Activated Soft Fork..
The most widely known version of UASF is called BIP148. It’s a protocol change saying that beginning on August 1st, blocks that do not signal for SegWit are invalid.
This change was not merged into the bitcoin core reference client code, but only to an alternative version of it for users that explicitly support a UASF. The idea is to force miners to signal for SegWit support. This is due to the fact that miners would want their blocks to be accepted by nodes that enforce UASF. When miners start signaling support for SegWit, all of the nodes will start enforcing it, even if they don’t explicitly support UASF.
Splits in the Bitcoin network
The problem arises when some of the miners go by the new UASF rules and others don’t.
For UASF enforcing nodes, blocks of non-UASF miners are considered invalid.
For nodes that do not enforce UASF, the UASF blocks will look valid but irrelevant, since they are mined on top of the shorter end of the chain (assuming UASF miners are the minority).
This causes different miners and different nodes to have a different view of which blocks are valid, what the blockchain actually looks like and which transactions are included in it.
Different nodes will give different answers regarding the funds in a given address. For an address that contained funds before the UASF day, there is no problem. Both sides of the split will recognize the validity of blocks, their transactions and the bitcoins in the address. However, a transaction that was conducted a day after UASF was in place may be considered as legitimate by one node and not by the other.
This phenomenon causes bitcoin to actually split into two coins – UASF Bitcoin and Non-UASF Bitcoin, or to be more generic we can call them Bitcoin A and Bitcoin B.
Each coin has its own nodes, its own blockchain and its own balance for each address. Each user that had coins before the split could use these coins separately on the Bitcoin A network or on the Bitcoin B network. This will cause each of the coins to have their own exchange rate as well.
So if someone had X bitcoins before the split, he’ll now have X bitcoins A and X Bitcoins B, which he could do whatever he pleases with.
Possible Consequences of the Split
The only precedent of this sort of split took place with a cryptocurrency called Ethereum, which split into “Ethereum” and “Ethereum Classic”. Let’s analyze the meaning of such a split.
First, lets see what happens to investors that are holding Bitcoin and how does it cope with Bitcoin’s non-inflationary definition. It might look as if there is a contrast, since there should only be 21 million bitcoins, and there will now be 42 million.
However in essence, the purpose of the fixed limit is that when you hold a certain percentage of the total currency base, you’ll keep on having that percentage, and no one can issue more than the total currency base and dilute your holdings. So however you define Bitcoin, as either one of the sides of the split or as both of them, you’re still holding the same percentage of the total currency, because you have X of both.
Of course, the combined dollar value of both coins can drop or rise after the split, but that’s no different than how Bitcoin’s price can change due to changes in demand.
A split could be short, medium or long term. The chain might split and then, after a while, one of the sides will lose support and become abandoned, while the other one rises to be the one and only Bitcoin. Under such a scenario it is like the split never existed.
It could be that it takes a long time until only one side is left, and it could also be that both sides of the chain are long-lasting as independent currencies. In this scenario, a struggle is expected over the Bitcoin brand name. At some point one or both coins will have to change their name to something else.
Such scenarios are referring to a split that’s done in a smooth clean manner. Nevertheless, due to our inexperience with such splits, there could be a few problems, the biggest of which is a Replay Attack. Since both coins are based on the same original protocol, a transaction meant for one of the networks might get processed in the other network.
This means a user that meant to pay for something with Bitcoin A, will accidentally also send his Bitcoin B. This means he might lose his Bitcoin B, depending on who he sent it to. Mechanisms to resolve this will have to be developed. But that’s an issue for a whole other post….
The New York Agreement
To further a solution for the protocol upgrade without causing a split, a compromise has been put forward between the SegWit camp and the 2MB Hard Fork Camp. This compromise has many names – The “New York Agreement”, “Silbert Accord”, “SegWit2x” or “BTC1”.
The idea is simple – Activate SegWit first, and then hard fork to 2MB within a few months. Numerous companies and miners have already signed this compromise.
The mechanism works as follows:
Every miner enforcing the agreement will signal his agreement in the blocks he mines. If more than 80% of the miners support the agreement, there will be a new rule determining that block not signaling for SegWit adoption are invalid. If this happens, all of the miners will start signaling for SegWit in order to not have their blocks ignored.
Meaning – the final state for a node that support the NY Agreement is identical to a node supporting UASF, only the condition for activiation is different. If a big enough majority of miners support the NY agreement, UASF becomes irrelevant – everyone will only mine blocks signaling SegWit and there will be nothing for them to deem invalid.
Signaling for the NY agreement starts about a week before August 1st, by then we’ll know much better where things are headed.
Nevertheless, even if we are spared from this split on August 1st, Miners supporting the NY Agreement have also agreed to do a hard fork early in November. This may reopen the possibility of a split. If the NY agreement fails, there could be a number of different splits possible on August 1st and the following weeks.
So what should you do now?
Stay calm. Right now the most likely scenario is that there will be no split. And even if there will be, you can prepare for it with a few simple steps.
Keep your coins in self hosted wallet with control over your private keys, and back them up. That’s always a best practice, but more so towards a possible split. If you hold your coins in an exchange you can’t tell how it’s going to handle the split or if it can handle a Replay Attack. Examples of self hosted wallets are Electreum (desktop wallet), Ledger (hardware wallet), TREZOR (hardware wallet) and MyCelium (mobile wallet).
If a split seems likely, don’t receive or send any payments from the time of the split until things clear up. The Uncertainty period is likely to be between hours and days, in which the behaviour of even the most recommended wallets is unpredictable. When secure methods to transact without risk of Replay Attacks are introduced, you can return to transact while following the required instructions. If the wallet you’re using is different than the one recommended for use you can, export your backup key and then import it into a recommended wallet.
Only invest in what you understand and believe in. Also invest an amount you can afford to lose. Turbulent times are ahead, with bitcoin’s exchange rate projected to be even more volatile than usual.
Remember that this is a very dynamic issue. Even though it seems like a compromise was achieved there can always be changes. Check in with r/Bitcoin and r/BTC for the latest developments.
Coindesk just created this flow chart summarizing the (current) possible options. Perhaps it will help make things clearer.
This post was translated to English by Alon Goll based on the Israeli Bitcoin Association guidelines.
Meni Rosenfeld is a mathematics M.Sc. graduate of the Weizmann Institute of Science, specializing in machine learning. After being exposed to Bitcoin in March 2011, he has focused exclusively on activity in this field. He has established the Bitcoin community in Israel, founded Israel’s first Bitcoin exchange service, and performed mathematical research on the algorithms that underlie the functioning of the Bitcoin and blockchain system. He now serves as the chairman of the Israeli Bitcoin Association.
Latest posts by Meni Rosenfeld (see all)