[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).

[stale2002]

Ahh, yeah, of course. If you taint it. But if you don't taint and don't opt in, then it can be stolen.

So yes, if you are on the Core chain, you can protect against replay, but only if you opt in. If you don't opt in, then they can be stolen on the other chain.

[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...