-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replay-protection against BCash #3
Comments
There are 3 levels we can go
Nodes that don't upgrade will continue to relay transactions, but upgraded pools will not add those transactions to blocks.
|
Another thing to consider is changing ports as per @prusnak Change default port number This would be a courtesy to both Bitcoin and Bitcoin Cash. But difficult to execute on live network. |
Other downstream considerations are Bisq & CryptoBridge, as well as functionality out of the box with Trezor with custom backend. |
Just to complement the current discussion, I'll be focusing on what can be done with current consensus rules. For a transaction to be replay protected, it must consume at least one output that is unique to the intended chain, or which has already been consumed on all other chains. Every output consumed by a normal transaction can be traced back to some initial coinbase outputs. All coinbase transactions before the split are shared, and all coinbase transactions after the split are unique to that chain. Mixing post-fork mined coins in a transaction is a reliable way of restricting it to one chain. Another possibility for replay protection is that given a valid txn, for every chain it may be replayed on, at least one of its inputs has been spent already. For a transaction to be replayable it must spend only outputs from the initial UTXO set. To fully determine that, one can envision a service that connects to multiple
This is fairly exhaustive and would allow a full appreciation of the risk of any given transaction, including 0 conf. Sticking to only confirmed transactions, something that takes as input txn IDs with optional output numbers and returns the recursive spendability information would be sufficient to allow users of any wallet to protect themselves (similar to how one might check txn state on an explorer). As for actually splitting coins, I think the safest way for users to obtain tainted coins would be joinmarket, I suspect pre-segwit versions would work on both bcash and bclashic. Alternatively maybe someone wants to spend a few bucks to mine a segwit activation period on clashic, but who knows if full nodes will actually enforce it ;-) Another way to obtain split coins is similar to electrum's method, using replayable but not replayed transactions, using different fees, An easy but identity linking (also on other chains!) method to ensure any wallet is replay protected is to receive some tainted dust and then consolidate all the inputs. Hopefully these pointers are helpful for anyone trying to split their coins. If there is any interest I'd be happy to put together a proof of concept of the UTXO checker thing, the simplest iteration, I initially was going to do one for @chainsplit but I kind of suspect the bcash hard fork would be the last non replay protected fork we'll ever see and I wasn't sure how much interest there actually was, and eventually got bogged down with other projects as activity on @chainsplit slack died down. |
Unfortunately when BitcoinABC implemented the Nov13th hardfork, they didn't add replay-protection.
Here are presented any proposals for getting replay-protection against BCash:
https://github.com/clashicly/bitcoin-clashic/tree/0.15.101
Open to more proposals, ideas & feedback of any kind.
The text was updated successfully, but these errors were encountered: