Frequently asked questions

# How do I switch to XT?

Upgrading is easy: just download and run from our website as normal. Bitcoin XT uses the same data directories and configuration as Bitcoin Core, so if you were previously running that you won't need to download the block chain again. And you can switch back again at any time if you want, again, without redownloading the block chain.

# Is there any risk involved in running XT?

No. If the big blocks change doesn't obtain enough support to be successful then you are unaffected. If it does, then you will follow the new consensus and are unaffected.

# Why did the Bitcoin XT fork happen?

Bitcoin XT was created due to a series of fundamental disagreements between Bitcoin core developers. The disagreements revolve around questions like "Should the block chain grow to match user demand?", "What data should the Bitcoin protocol provide to clients?" and "How should technical decisions be made?".

The biggest and most intractable disagreement is about the block size: the XT community believes the block size must grow in order to support Bitcoin's expanding user base. The Bitcoin Core project has made no move towards increasing the limit, in order to incentivise the creation and use of alternative, non-block chain based financial systems such as the so-called Lightning network. This is an irreconcilable difference of vision that has proven impossible to surmount.

Additionally, the Bitcoin Core developers have made statements that imply they no longer care about unconfirmed transactions or lightweight peer to peer wallets, although both are relied upon by many users. It is unclear that these features will remain viable without a fork.

The final area of disagreement is around how decisions are made. Bitcoin Core has no process for resolving disagreements amongst its developers or defining who those developers actually are.

After a long series of attempts to find compromise in 2015, it became clear that there was no way to resolve these differences except via a fork.

You can read a longer article on the topic called "Why is Bitcoin forking?".

# How does the change to 2 megabyte blocks work?

Anyone who mines with XT or a client that implements BIP109 by Gavin Andresen marks their blocks with a version number that indicates support for larger blocks. If 75% of blocks are indicating support a flag is set in all supporting nodes and a two week grace period begins. All nodes will be printing upgrade alerts to their logs. Miners, merchants and service providers then know to upgrade before the four week period elapses if they haven't already. Note that once the 75% threshold is reached the change is locked in and will occur after two weeks even if support dips back below 75%.

Once the fork occurs, nodes that are still following the 1mb-only chain will continue to receive and process transactions as before. However miners are incentivised to quickly switch to the larger chain as long as merchants, exchanges and other users do because otherwise their newly mined coins cannot be sold. Users are also incentivised to use the chain supported by the majority of mining hash power. Thus once the switch happens it is not likely that the 1mb-only side of the chain will continue for very long.

# Why can't alternative approaches to the hard fork be used?

The max block size limit is a rule that every node checks. It was put in as a temporary measure by Satoshi and always intended to be removed, which implies a hard fork as older nodes will reject blocks created by newer nodes. The alternative most heavily promoted is the "Lightning network" by Blockstream, which is an entirely different system: it would require completely different wallets, a replacement for Bitcoin addresses/QR codes, new node software and so on. Lightning posits a set of relationships between quasi-institutional entities that settle up between each other on the block chain from time to time. It is unimplemented and many design elements are not yet defined.

In short, the only alternative seriously proposed involves abandoning Bitcoin as we know it today and attempting to convince users to move to a largely undesigned and potentially worse alternative.

# Can a soft fork be used instead? Is that better?

In the case of a block size change, no soft fork is possible because old nodes will realise they are not checking the same rules as soon as they see a block larger than what they are expecting. Any attempts to trick them into believing the 1mb rule is still being followed would require radical modifications to the protocol and major changes to all wallets, which is impractical. Additionally, as old nodes would have to upgrade anyway in order to preserve their security level, there is no benefit to doing a soft fork.

# Does a hard fork cause Bitcoin to become two separate currencies?

The idea that people can speculate or dump coins on one side of the block chain is a common misconception. The Bitcoin protocol does not have a field for transactions to specify a chain, so ordinary transactions made just after the fork will be included in both assuming there is sufficient capacity on both sides.

Eventually, if both chains were to be in active use, newly mined coins would start to enter circulation and at that point transactions involving them would start to become valid on only one chain. Sending coins to someone on the other chain would have no effect if they use a fully validating node: they would simply never see the payment appear.

A situation where both chains are advancing simultaneously is not likely to last for long. After a hard fork with 75% of hashing power support the less supported side would be rapidly abandoned, as confirmation times on the 25% side would be much higher than normal. This in turn means the transaction backlog would get much larger until the next retargeting interval was reached, meaning a higher risk of double spending for people still on the weaker chain. Merchants and exchanges should therefore prefer the side with the most hashing power, and growth of Bitcoin is good for their businesses anyway. This would make coins mined on the 25% side after the fork unspendable with those traders, so also incentivising miners to rapidly switch to the main chain.

Because of this dynamic any actual disruption during the fork should be minimal, especially as the grace period means it will have been clear to everyone that the change is about to happen.

# Why does XT include non-block size related changes? Can there be a bigblocks only version?

Bitcoin XT follows the original vision of Bitcoin: simple, reliable, low-cost transactions for everyone in the world. Bitcoin Core developers have de-prioritised these goals. This split is most visible in the block size debate but frequently impacts other issues too, such as support for lightweight P2P wallets and unconfirmed transactions. XT is intended to resolve many issues with Bitcoin Core development that work against widespread user adoption, of which the need for better capacity planning is only one.

Whilst we do not provide downloadable binaries of a Core that includes only the bigger block changes, the Bitcoin Classic fork is currently a one-feature patch on Bitcoin Core for increasing block size.

# What will happen with the testnet?

Bitcoin XT is programmed to start trying to fork the testnet chain immediately upon release. We do not expect testnet to smoothly transition in the same way as the main network, as single miners can easily dominate the testnet and then leave, so the idea of miner consensus doesn't apply in the same way there. The point of exercising the code on the testnet is to put the transition logic through its paces and ensure that chain reorgs back and forth are working correctly.

# How are decisions made?

Decisions are made by the current maintainer with input from the Bitcoin XT development team. When there is a disagreement the current maintainer will have the final say. If a patch seems in line with the principles of the project it will be considered for inclusion. If the developer is willing to assist with rebasing work, that also helps build the case for inclusion.