Principles for dealing with network splits

Hardforks without industry-wide consensus

We consider contentious hardforks to be altcoins, regardless of the hashing power backing them. We might eventually support them as separate altcoins, if we see customer demand and if executed responsibly (see below).

Hardforks without on-chain coordination, a grace period and clear activation strategy

We consider hardforks without a planned activation procedure to be extremely unsafe and unpredictable. We do not feel it would be responsible for us to run such code in production before, at or near the time of the split, but might re-evaluate this 6 months following the split, after allowing ample time for coordination to finish taking place off-chain and for the ecosystem to properly assess the situation.

Hardforks without wipe-out and replay attack protections

Hardforks, especially contentious ones, without these safety measures are irresponsible and could result in loss of funds for our customers. We could never support any such forks, and will take no active steps to ensure orderly withdrawals for them.

Hardforks to unbounded block size / “emergent consensus”

We cannot reliably participate as a fully-validating node in such networks and therefore cannot offer services for them, for the following reasons:

Unpredictable resource usage growth. As a small bitcoin business that is operating with no outside capital, we cannot in good faith commit to continuously and reliably operating a full-node that has unpredictable operational costs which could massively inflate at any time and with no warning. An unbounded block size would deny us the ability to fully self-validate the chain in a reliable and continuous manner.

As a small bitcoin business that is operating with no outside capital, we cannot in good faith commit to continuously and reliably operating a full-node that has unpredictable operational costs which could massively inflate at any time and with no warning. An unbounded block size would deny us the ability to fully self-validate the chain in a reliable and continuous manner. Unpredictable network splits. Bitrated is not equipped to deal with the possibility of spontaneous network splits due to varying block-size configurations across the network. This requires considerable additional effort and diligence for keeping up with manual off-chain block-size coordination, requires short-notice devops availability for emergency server upgrades, and would put a significant burden on our support team for dealing with customers experiencing the inevitable delays and confusion when such spontaneous splits arise.

Bitrated is not equipped to deal with the possibility of spontaneous network splits due to varying block-size configurations across the network. This requires considerable additional effort and diligence for keeping up with manual off-chain block-size coordination, requires short-notice devops availability for emergency server upgrades, and would put a significant burden on our support team for dealing with customers experiencing the inevitable delays and confusion when such spontaneous splits arise. Degrading full-node security. Bitrated does not and will not use external API providers or SPV clients to obtain blockchain data, as we consider it unsafe and irresponsible towards our users.

(This might change as technological improvements like SPV fraud proofs are implemented.)

For these reasons, Bitrated is technically, financially and logistically unable to safely and reasonably support networks with unbounded block size or with the “emergent consensus” mechanism.

In the case of the mainline Bitcoin client adopting an unbounded block size proposal, we will be forced to shut our full-nodes off and cease offering services for the BTC currency. We believe that this is more responsible than continuing to operate with an unreliable full-node or without a full-node at all. We will provide a grace period of 18 months during which BTC funds could be withdrawn using the Bitrated web interface, but no new deposits could be made (we’re able to safely process withdrawals without a full-node, but not deposits). After these 18 months, withdrawing funds will still always be possible using an open-source CLI tool, your account mnemonic passphrase, and your password (which together represents your multi-signature private keys).

Hardforks with industry-wide consensus, safety measures and predictable operational costs

If we see that a hardfork proposal has wide industry support and a very strong consensus among the bitcoin user base, we might consider re-assigning the “Bitcoin” name to that new protocol.

However, even then, we will always allow withdrawing funds in the original chain used for the deposit (assuming it is technically possible).