Quote from: aleksej996 on September 20, 2017, 03:09:47 PM

Quote from: Kogs on September 20, 2017, 11:40:52 AM

Quote from: aleksej996 on September 20, 2017, 11:11:16 AM

The lack of replay protection is a huge problem as well, I don't think there is a way to safely transact your coins only on one chain. It would be a race in the best case scenario and one chain will almost always win and put the coins in danger on the other chain.

The just means that the it is unlikely that these chains will coexist. As they won't be able to safely so a compromise might be necessary.
This puts everything on bigger stakes as well. I think this could be a very big deal. It is basically miners vs developers. And users might be on the Core side, but no one can be sure. So anything ca happen.

There is a safe way to prevent a replay attack with the nLocktime feature of bitcoin.

Checkout the link which explains how it works.
https://freedomnode.com/blog/79/how-to-prevent-replay-attack-by-splitting-coins-in-the-event-of-a-bitcoin-chain-split#h-locktime

Well, the article makes some assumptions, but ok. Either way it still rests on the race. There are quite real risks, you can't deny that.
Transactions get stuck really often, sometimes for days. You do this and the other chain could very well catch up at that point.
For example, even tho Bitcoin Cash had a smaller block height it also had emptier blocks (kinda goes together as a consequence of lower support, but doesn't have to be as in this one user and mining support could differ a lot more, also Bitcoin Cash had 8 times the capacity of Bitcoin and S2x will have only 2 times).
Either way, the transactions got accepted in Bitcoin Cash in the next block while Bitcoin had a huge problem with too many transactions of which some have to be stuck for days, just because there were to many of them for what Bitcoin could handle. So this article didn't talk about the average block times after the fork which will change rapidly and the transaction increase that might follow and clog the network. It is a lot more complicated that that.

The point is that if your transaction is stuck for long enough on the bigger chain, the shorter one will catch up. That is a risk. A quite real risk.
10 blocks given here as an example is nothing for the time your transactions can get stuck for more then you expected. No fee estimation will give you such a precise approximation due to transaction acceleration and the possible rapid increase in new transactions.
People had their transaction stuck for weeks during the last fork. Those are thousands of blocks, not 10. 10 blocks is like an hour and 40 minutes.
You need to be very precise in your estimation for this to work, which we saw is a very very difficult job, which is far from the "safe" option.

You are right. This is something what could be a real problem. If the same chain hopping happens like with Bitcoin Cash, you can run in exactly your described situation.
I guess the only secure way would be just to wait until both chains have a stable hash rate to minimize this risk.

Nevertheless I also would prefere that the Segwit2x devs implement a replay protection. Even if the timelock trick would work 100%, with the current clients it is too complicated to do for the average user.