[encryptThrow32]

The dangers of tx replay mean that HF's like this can never be safe. Beware those that would tell you that these forks are safe, they are not. This is another scam from those that would try to usurp the blockchain.

You will be able to replay original bitcoin and abc tx's on each chain, unless you opt-in to some funny new untesed hash. This will hugely disrupt the minority chain ABC, as the mempools on cash chain fill with other valid tx's from main chain. Its going to be a bloodbath. Steer very clear!

From: https://bitcoin.stackexchange.com/questions/56867/bitcoin-ca...

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.

The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.

The second method uses an OP_RETURN output which has the exact string:

Bitcoin: A Peer-to-Peer Electronic Cash System as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.

[stale2002]

Uhh, protecting your transactions against replay attacks in Hard Fork scenarios like this is a solved problem.

There are a multitude of ways to split your coins, so that they are separate, and you don't risk selling the other chain when you don't mean to.

[encryptThrow32]

Solved, maybe, but apparently not in this case as the replay mitigation's are opt-in.

What would stop someone replaying a regular tx from core chain if this network accepts either replay protected or not tx's?

[stale2002]

Apparently it is 1 way protection.

So the answer is that if you spend a transaction on Core, yes, it can be stolen on the BCC chain.

Your core chain coins aren't stolen, though.

But it is safe on the BCC chain. The only people who get screwed are the main chain people, and NOT the BCC chain supporters/users.

So it is actually the opposite of what the original comment was claiming. It is MORE safe to be on the BCC chain, and LESS safe on the main chain, because the protection is 1 way.

Also, apparent segwit is not going to be activated on it, so that means that main chain segwit transactions can be stolen.

This is actually really clever, and is borderline adversarial development.

What this means is that miners on the BCC chain will be able to steal coins from segwit transactions on the main chain, and thus this would strongly incentivize BCC mining, while screwing over segwit supporters.

The people who it is "unsafe" for is Core and Segwit supporters, lol!

[kanzure]

> The only people who get screwed are the main chain people, and NOT the BCC chain supporters/users.

Sounds like definitely adversarial behavior to me, not "borderline". They have the opportunity to write secure opt-out (on-by-default) replay protection-- like by choosing a new address prefix (etc)--, and they choose not to.

Your "steal segwit coins" scenario wont work when the transaction tree is tainted by post-fork coinbase outputs.

[stale2002]

Hmm? The steal segwit coins senario would work as follows:

1. Person A does a segwit transaction and sends coins to the anyone-can-spend output on the main chain. These coins aren't really "anyone can spend" because segwit stops invalid transactions.

2. The transaction gets replayed on the BCC chain. Segwit transactions work by sending via the anyone can spend output, but since segwit is not activated on BCC, the thefts aren't blocked, and any-can-spend really DOES mean anyone-can-spend instead of meaning segwit.

Or am I misinterpreting how it works?

I thought that segwit uses the anyone-can-spend output in order to be backwards compatible. That means that legacy nodes, or unupgraded nodes that don't have segwit, are perfectly fine will "theft" transactions.

A legacy fork, that does not have segwit activated, would thus be able to replay segwit transactions, but instead of being segwit transactions they would just be normal, anyone can spend transactions that can be stolen.

Anyways, yeah it is adversarial development.

But the other side was planning on doing the same kind of stuff, with User Activated Soft Fork, and POW changes. User activated soft fork threatens the other side with theft by doing a Wipeout of the other chain.

This stuff could have been solved much earlier if Core just compromised and merged the 4MB blocksize increase.

[kanzure]

> Or am I misinterpreting how it works?

I had mentioned specifically post-fork coinbase output taint; if it's tainted, there's no way to replay, that's in fact one of the proposed replay protection mechanisms (unfortunately it's of the "opt-in" variety).

[kanzure]

> Sounds like definitely adversarial behavior to me, not "borderline". They have the opportunity to write secure opt-out (on-by-default) replay protection-- like by choosing a new address prefix (etc)--, and they choose not to.

looks like a change got merged, https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-31...