<p>All transactions would be replayable on both chains even after one was confirmed in a block on one chain, because since both chains start with the same UTXO set, the transactions spending those UTXOs are valid on both chains. The only exception is coins mined on each chain after the fork, because those coins will not be valid on the other chain. So that is how you can split your coins, you would need to mix your coins in transactions which use coins mined after the fork, so they are only valid on one chain. In the case of such a split I assume there would be some sort of service launched by the miners on both chains to start mixing people's coins and splitting them</p>

<p>EDIT: Ledger have announced they'll offer a tool to do that, its likely others will too: <a href="https://twitter.com/LedgerHQ/status/921730827117096960" rel="nofollow noreferrer">https://twitter.com/LedgerHQ/status/921730827117096960</a></p>

CC BY-SA 3.0
2017-11-07T04:53:26.653Z
Understood. In that case even the big (non-mining) exchanges are going to have a problem in that they won't be able to split coins as they have done for BCH and BGold. For example one of the coinbase.com posts state that BTC customers will get an equal amount of B2X but if that happens and a customer spends their B2X the receiver could also nab their BTC?
sipsorcery
CC BY-SA 3.0
2017-11-07T05:43:03.797Z
Withdrawals will most likely be disabled until that's all sorted :)
meshcollider
CC BY-SA 3.0
2017-11-07T07:23:02.277Z
There is one other (but not very relevant) alternative: using transactions with more than 4M weight. Such a txn would be invalid in Bitcoin, but only nonstandard on 2X.
Pieter Wuille
CC BY-SA 3.0
2017-11-07T04:19:01.083Z
2017-11-07T22:06:00.600Z
2017-11-07T22:06:00.600Z
meshcollider
<p>The high level <a href="https://docs.google.com/document/d/13c5YMqR72xaa23ohmg7M9heJbu59IvamSTQIVGFAY6c/edit#heading=h.g69txqfwbs97" rel="nofollow noreferrer">design doc</a> from chainspl.it outlines the 4 different mechanisms they will be using to create coins that are only valid on one of the forked chains. Details are in the doc but my quick summary is:</p>

<ul>
<li><p>New coinbase coins. As @MeshCollider pointed out if a utxo gets included in a block with a coinbase coin it's only valid on the chain that generated the coinbase tx. Coinbase coins can only be spent after 100 additional blocks and there would need to be some synchronisation with a miner to get a specific utxo in the same block as a coinbase one,</p></li>
<li><p>nLockTime. If the chains diverge enough by block height then a tx can use the nlocktime to immediately spend on one chain and then transfer the coins to yourself on the other chain BEFORE the lock time is reached,</p></li>
<li><p>Massive transaction. As per @Pieter Wuille's comment on the accepted answer. Get a tx included on a block that exceeds the Segwit1x size limits. It seems likely that this would necessitate a very large tx and would result in a very high fee,</p></li>
<li><p>High/Low Fees. A big difference between the fees on the chains could mean a tx with a low fee only gets accepted on one chain. This approach would be very risky as a miner on the expensive chain could arbitrarily or maliciously include the tx on the high fee chain.</p></li>
</ul>

CC BY-SA 3.0
2017-11-07T22:49:08.627Z
nLockTime idea is interesting, could potentially be usable here depending on how the hash power falls after the split, thanks!
meshcollider
CC BY-SA 3.0
2017-11-07T22:42:15.917Z
2017-11-07T22:42:15.917Z
sipsorcery
<p>Given the lack of replay protection when the SegWit2x fork splits off a different chain is there a safe mechanism to broadcast a tx so that it will only be accepted by the 1x or 2x chain nodes? </p>

<p>If the answer is no would an option be to run both a bitcoin-core and btc1 full node and send coins to myself on the btc1 node. Once that tx is accepted into the SegWit2x block and NOT the 1x block I'd have safely split my coins? If the tx got replayed onto the 1x chain I could try again, hopefully not too many times to avoid fees.</p>

<segwit2x><replay-attack>
Limit tx to SegWit1x or 2x chain
sipsorcery
# Limit tx to SegWit1x or 2x chain

(Asked by: username_0 on 2017-11-07)

Given the lack of replay protection when the SegWit2x fork splits off a different chain is there a safe mechanism to broadcast a tx so that it will only be accepted by the 1x or 2x chain nodes?

If the answer is no would an option be to run both a bitcoin-core and btc1 full node and send coins to myself on the btc1 node. Once that tx is accepted into the SegWit2x block and NOT the 1x block I'd have safely split my coins? If the tx got replayed onto the 1x chain I could try again, hopefully not too many times to avoid fees.

**Tags:** segwit2x, replay-attack


---

## 2 answers

### Answer by username_1 on 2017-11-07. Score: 3 | Accepted answer

All transactions would be replayable on both chains even after one was confirmed in a block on one chain, because since both chains start with the same UTXO set, the transactions spending those UTXOs are valid on both chains. The only exception is coins mined on each chain after the fork, because those coins will not be valid on the other chain. So that is how you can split your coins, you would need to mix your coins in transactions which use coins mined after the fork, so they are only valid on one chain. In the case of such a split I assume there would be some sort of service launched by the miners on both chains to start mixing people's coins and splitting them

EDIT: Ledger have announced they'll offer a tool to do that, its likely others will too: <https://twitter.com/LedgerHQ/status/921730827117096960>

> **Comments:**
> **username_0**: Understood. In that case even the big (non-mining) exchanges are going to have a problem in that they won't be able to split coins as they have done for BCH and BGold. For example one of the coinbase.com posts state that BTC customers will get an equal amount of B2X but if that happens and a customer spends their B2X the receiver could also nab their BTC?  
> **username_1**: Withdrawals will most likely be disabled until that's all sorted :)  
> **username_2**: There is one other (but not very relevant) alternative: using transactions with more than 4M weight. Such a txn would be invalid in Bitcoin, but only nonstandard on 2X.  

---

### Answer by username_0 on 2017-11-07. Score: 1

The high level [design doc](https://docs.google.com/document/d/13c5YMqR72xaa23ohmg7M9heJbu59IvamSTQIVGFAY6c/edit#heading=h.g69txqfwbs97) from chainspl.it outlines the 4 different mechanisms they will be using to create coins that are only valid on one of the forked chains. Details are in the doc but my quick summary is:

* New coinbase coins. As @MeshCollider pointed out if a utxo gets included in a block with a coinbase coin it's only valid on the chain that generated the coinbase tx. Coinbase coins can only be spent after 100 additional blocks and there would need to be some synchronisation with a miner to get a specific utxo in the same block as a coinbase one,
* nLockTime. If the chains diverge enough by block height then a tx can use the nlocktime to immediately spend on one chain and then transfer the coins to yourself on the other chain BEFORE the lock time is reached,
* Massive transaction. As per @username_2's comment on the accepted answer. Get a tx included on a block that exceeds the Segwit1x size limits. It seems likely that this would necessitate a very large tx and would result in a very high fee,
* High/Low Fees. A big difference between the fees on the chains could mean a tx with a low fee only gets accepted on one chain. This approach would be very risky as a miner on the expensive chain could arbitrarily or maliciously include the tx on the high fee chain.

> **Comments:**
> **username_1**: nLockTime idea is interesting, could potentially be usable here depending on how the hash power falls after the split, thanks!  

---

