What is Segwit2x?
Segwit2x is a new altcoin based on Bitcoin, with only one change in it: blocks are now allowed to be up to 8 million in weight, up from 4 million in Bitcoin (this is the 2x part). This basically translates to blocks going from ~2 MB in size (if 100% segwit transactions) to ~4–5 MB, with a maximum around 7–8 MB.
It will be deployed somewhere around November 15, at block 494,784.
It will not have replay protection.
Update Oct 6 2017: opt-in replay protection has been added to Segwit2x, where users can send any amount to the address 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi. Doing so, after block 494,784, will make the transaction invalid on the Segwit2x chain. This approach will bloat the UTXO set on Bitcoin, and hopefully the Segwit2x developers will give a less obstructive option before the fork happens.
What is replay protection?
When an altcoin based on Bitcoin is created, like BCash or Segwit2x, it retains the entire history of all transactions in Bitcoin up to the block at which the fork occurred. This means if you are holding 100 bitcoin before the fork, you are holding 100 bitcoin and 100 of the new coin as well.
The problem is that in order to send these coins somewhere, you need to prove that you own them. If both chains worked exactly the same, proving that you own the coins on one chain means you also prove that you own them on the other chain.
Whenever you make a transaction, you prove that you own the inputs, and you designate the outputs. Let’s say we are sending 1 bitcoin to Alice. We make a transaction that says “input is these 10 bitcoins, and here is my proof that I own them: [proof]. output is 1 bitcoin to Alice’s address and 9 bitcoin to my change address”.
As you may notice, there is nothing in the above that tells you which chain the transaction belongs to. If you send this on the segwit2x chain, someone could (e.g. Alice) copy the bytes of your transaction and paste them into the bitcoin network, as is.
Although you only meant to send Alice a segwit2x coin, she now managed to get a whole bitcoin from you as well.
With replay protection, you insert an identifier into the transaction which makes it invalid on all but one chain. All BCash transactions are made this way; that’s why you can’t mistakenly put a BCash transaction on the bitcoin network or vice versa; BCash has replay protection.
And Segwit2x will not have replay protection.
Splitting coins
In order to stop the above from happening, you have a number of options available:
Replace-by-fee approach
The simplest approach is to make use of the RBF feature. It relies on the fact Segwit2x will, at least initially, process transactions faster than Bitcoin. You execute it as follows:
- Make a transaction ① sending the desired coins to a new address of yours. The transaction must have RBF (replace by fee) enabled. Set the fees to be close to zero e.g. 2 satoshis per byte (2000 sat/kB).
- Make a transaction ② sending the same coins to a different address of yours. Set the fees to be whatever you’re willing to pay for a normal transaction (i.e. not too low; must be higher than fee rate of ①).
- Broadcast ① on the Segwit2x network. Wait for it to be mined.
- Broadcast ② on the Bitcoin network. Once it’s been mined, you have successfully split your coins.
The one issue with this approach is that if ① is mined on Bitcoin side, you end up with unsplit coins and have to try again. (Luckily you paid a tiny fee, so you didn’t lose a lot from it, but you still failed to split.)
Lock-time approach
Update: I wrote a piece dedicated to lock-time transactions in Bitcoin Core here.
This is a bit trickier but has a higher probability of success. It relies on the fact one chain will move at a different speed from the other.
When Segwit2x activates, a number of miners will switch to it. Initially, they will be mining the same as bitcoin, but at some point, they will mine a block that is too big and this will be rejected by the bitcoin network. This may or may not be block 494,784 mentioned above, but it probably will be.
In any case, once this happens, one chain will most likely have more hashpower than the other. Because of this, blocks will on average be mined faster on one side. Eventually there’s a gap in the number of blocks.
Let’s say bitcoin is at block 494,800 while Segwit2x is at block 494,805.
You make a transaction ① sending your coins to yourself with a lock time that says “this transaction is only valid starting at block #494,805”. You want to enable RBF on this, for reasons I will explain below.
You make another transaction ② sending the same coins to a different address of yours with no lock time.
You broadcast ① on the Segwit2x network. Note that
- it is valid on Segwit2x, because Segwit2x has mined block 494,805, and
- it is invalid on Bitcoin, because Bitcoin has so far only mined block 494,800. It has to mine 5 more blocks before the transaction becomes valid.
After submitting the transaction, you wait for it to be included in a block on Segwit2x side. Once it has, you broadcast ② to the Bitcoin network. Note that
- it is invalid on Segwit2x, because ① has already been mined, and
- it is valid on Bitcoin, because ① was not valid and was thus not mined.
Once ② has been included in a block on Bitcoin, your split has succeeded. Note that you may want to have a higher than average fee on ② to avoid it being under-prioritized. Bitcoin will likely experience higher than usual traffic because of lower hashpower and blocks being mined less often, resulting in a pile-up of transactions in the mempool, so you may have to wait awhile. Note that if you did enable RBF, even if Bitcoin reaches block 494,805, ① will be discarded by Bitcoin nodes, because ② pays a higher fee and is replacing it.
In a sense, this approach falls back to the previous approach using RBF. Despite it all, it may still fail though, as miners are free to include ① in blocks if Bitcoin mines enough blocks to make it valid.
Why is this mess happening?
There are a lot of talk about this, but essentially, if Segwit2x is able to also include all Bitcoin transactions, it will appear to be a replacement for Bitcoin. If this gets a big enough momentum, companies and exchanges may decide that Bitcoin has been replaced with Segwit2x, and start listing Segwit2x as “BTC”.
If 100% of the users were on board with this, i.e. if everyone thought Segwit2x was a good approach and a nice upgrade to Bitcoin, then that wouldn’t be a problem, because users would already be transacting on the Segwit2x chain anyway.
However, even if this value drops to 0%, a couple of relay nodes connected to both networks could automatically shuffle transactions from one to the other, which would make it look like 100% of the users were on board, despite the fact it’s actually 0%.
If replay protection was enforced, and nobody used Segwit2x, it would become extremely obvious very quickly that people had chosen Bitcoin, and not Segwit2x. That’s a risk they’re simply not willing to take.