<p>yes, given that there is miners and nodes to process the transactions on the opposite chain.</p>

CC BY-SA 3.0
2017-10-29T22:33:28.000Z
Wouldn't this require someone to go to the effort of broadcasting these transactions? ie it wouldn't happen automatically. I'd be surprised if it happened by default. Either way though, I don't think it matters, as someone is sure to try to throw a spanner into the works if they can...
Highly Irregular
CC BY-SA 3.0
2017-10-29T09:30:18.287Z
2017-10-29T09:30:18.287Z
Jonathan Silverblood
<p>Since 2x has decided not to implement replay protection, transactions will be indeed compatible to both chains. If a transactions is simply broadcast to the other chain, it will enter the mempools there as well and may eventually get confirmed. This doesn't mean that one is completely helpless though. Here are some methods of making transactions valid only to one chain:</p>

<ol>
<li><strong>Input derived from a coinbase transaction</strong><br>
<a href="https://bitcoin.stackexchange.com/q/4571/5406">Coinbase transactions</a> will only ever be valid on one chain. Therefore, including an output that derives from a coinbase transaction will make a transaction only valid on a single chain. Coinbase transactions need to mature to 100 confirmations before their outputs may be spent, so transactions based dependent on a coinbase will become valid about 17 hours later at the earliest.</li>
<li><strong><code>nLocktime</code> and doublespend</strong><br>
If one of the blockchains has significantly more frequent blocks than the other, one can create two transactions sending to oneself: One with a <code>nLocktime</code> for the next block on the faster chain, and another that spends at least one of the inputs from the first transaction with a very high fee. First, you broadcast the transaction with the <code>nLocktime</code> which will hopefully get included in the next block on the fast chain. Once it is confirmed, the doublespend is broadcast with a very high fee to the slower chain, hoping that it will get confirmed before the height of the <code>nLocktime</code> of the first transaction is reached. After waiting some more confirmations for safety, the outputs of these two transactions can now be used to create transactions specific to only one chain.</li>
<li><strong>Doublespending</strong><br>
Create a pair of transactions with different recipient addresses that you own that spend the same funds. Broadcast both at the same time and hope that one gets confirmed on one chain while the other gets confirmed on the second. If unsuccessful, repeat.</li>
</ol>

<p>Generally, as soon as one has some unspent transaction outputs that are unique to one of the chains, these can be used to make other transactions safe as well.</p>

CC BY-SA 3.0
2017-10-29T11:21:47.837Z
really helpful. This doesn't sound great though...
Kristoffer Nolgren
CC BY-SA 3.0
2017-10-29T12:23:04.410Z
How does coinbase solve this?
Kristoffer Nolgren
CC BY-SA 3.0
2017-10-30T00:47:29.137Z
@KristofferNolgren coinbase transactions generate new BTC.  Those new BTC would not be valid unless someone did the effort of mining the other block simply to give their coins away.  Therefore, the coinbase coins are safe.
Elliot A.
CC BY-SA 3.0
2017-10-30T13:04:30.880Z
@KristofferNolgren: Not as in Coinbase.com the company, but [coinbase transaction](https://bitcoin.stackexchange.com/q/4571/5406) as in the transaction that collects block subsidy and fees. It is unique because it changes with the transactions collected in the block as well as the miner payout address.
Murch
CC BY-SA 3.0
2017-10-29T10:31:03.973Z
2017-10-30T13:04:58.130Z
2017-10-30T13:04:58.130Z
Murch
<p>I believe btc will have a lot higher economic activity at the time of the fork. If anyone sends funds in btc, what stops someone who don't like btc2x to just replay that same transaction on btc2x? This will shuffle around funds, to different adresses and cause lots of funds to end up in wallets that are never found.</p>

<p>One of the protections against replay attacks is to first move the other coin to a new wallet first, but if someone automatically moves the coins in the other wallet aswell by publishing the same transaction to the other network, this protection won't work.</p>

<segwit2x><replay-attack>
If Btc2x doesn't have replay protection does that mean all transactions can be automatically replayed in btc2x?
Kristoffer Nolgren
# If Btc2x doesn't have replay protection does that mean all transactions can be automatically replayed in btc2x?

(Asked by: username_0 on 2017-10-29)

I believe btc will have a lot higher economic activity at the time of the fork. If anyone sends funds in btc, what stops someone who don't like btc2x to just replay that same transaction on btc2x? This will shuffle around funds, to different adresses and cause lots of funds to end up in wallets that are never found.

One of the protections against replay attacks is to first move the other coin to a new wallet first, but if someone automatically moves the coins in the other wallet aswell by publishing the same transaction to the other network, this protection won't work.

**Tags:** segwit2x, replay-attack


---

## 2 answers

### Answer by username_3 on 2017-10-29. Score: 4 | Accepted answer

Since 2x has decided not to implement replay protection, transactions will be indeed compatible to both chains. If a transactions is simply broadcast to the other chain, it will enter the mempools there as well and may eventually get confirmed. This doesn't mean that one is completely helpless though. Here are some methods of making transactions valid only to one chain:

1. **Input derived from a coinbase transaction**  
   [Coinbase transactions](https://bitcoin.stackexchange.com/q/4571/5406) will only ever be valid on one chain. Therefore, including an output that derives from a coinbase transaction will make a transaction only valid on a single chain. Coinbase transactions need to mature to 100 confirmations before their outputs may be spent, so transactions based dependent on a coinbase will become valid about 17 hours later at the earliest.
2. **`nLocktime` and doublespend**  
   If one of the blockchains has significantly more frequent blocks than the other, one can create two transactions sending to oneself: One with a `nLocktime` for the next block on the faster chain, and another that spends at least one of the inputs from the first transaction with a very high fee. First, you broadcast the transaction with the `nLocktime` which will hopefully get included in the next block on the fast chain. Once it is confirmed, the doublespend is broadcast with a very high fee to the slower chain, hoping that it will get confirmed before the height of the `nLocktime` of the first transaction is reached. After waiting some more confirmations for safety, the outputs of these two transactions can now be used to create transactions specific to only one chain.
3. **Doublespending**  
   Create a pair of transactions with different recipient addresses that you own that spend the same funds. Broadcast both at the same time and hope that one gets confirmed on one chain while the other gets confirmed on the second. If unsuccessful, repeat.

Generally, as soon as one has some unspent transaction outputs that are unique to one of the chains, these can be used to make other transactions safe as well.

> **Comments:**
> **username_0**: really helpful. This doesn't sound great though...  
> **username_0**: How does coinbase solve this?  
> **username_4**: @username_0 coinbase transactions generate new BTC.  Those new BTC would not be valid unless someone did the effort of mining the other block simply to give their coins away.  Therefore, the coinbase coins are safe.  
> **username_3**: @username_0: Not as in Coinbase.com the company, but [coinbase transaction](https://bitcoin.stackexchange.com/q/4571/5406) as in the transaction that collects block subsidy and fees. It is unique because it changes with the transactions collected in the block as well as the miner payout address.  

---

### Answer by username_1 on 2017-10-29. Score: 0

yes, given that there is miners and nodes to process the transactions on the opposite chain.

> **Comments:**
> **username_2**: Wouldn't this require someone to go to the effort of broadcasting these transactions? ie it wouldn't happen automatically. I'd be surprised if it happened by default. Either way though, I don't think it matters, as someone is sure to try to throw a spanner into the works if they can...  

---

