Opt-in, one-way replay protection without any consensus rule changes
jcansdale opened this issue · comments
I think there might be a way to implement opt-in, two-way replay protection purely from the 2x side.
First we come up with a well known P2SH that's more expensive to spend than create (in terms of tx size). This is to avoid frivolous spending of these outputs (it would require tx fees to spend).
We then create a 1MB tx (see #123 (comment)) with a bunch of 0-satoshi outputs to this P2SH. These might be created by an exchange that needs replay protection or a miner on the 2x side. If someone wants a tx that can only be spent on the 2x side, they grab a random output to this well know P2SH and spend it. Because it came from a 1MB tx, it can only be spent on the 2x side.
Users with a high tx throughput could create their own private 1MB+ tx with outputs to regular P2PKH addresses that could be used later (or sold as a service). This would avoid the overhead of the P2SH technique, but would only work at scale.
Replay protection on the 2x side can be done purely by convention, no need for any consensus rule changes.
For replay protection on the 1x side, we soft fork a rule that outputs to this well known PT2H can only be created on 1MB+ tx. If you want replay protection on the 1x side, you simply create an output to this well known PT2H.
We now have two-way, opt-in replay protection. Replay protection on the 1x side requires very little overhead (a single 0-satoshi P2SH output). On the 2x side it's more involved, but certainly easy enough for wallet providers and exchanges to implement.
What have I missed? 😉
UPDATE: Changed to 1-way only.
Here the simplified version...
- for replay protection on the 2x side, you simply spend a 1M+ tx output (which could only have been mined on the 2x side)
2. for replay protection on the 1x side, we add a rule to 2x nodes that bans outputs to a specific anyone-can-spend address
The advantage with 2. is that you can easily do replay protection without any special software. Send some dust to the burner address and then move all your coins (which includes the change from the burn) to a new address. Replay protection done.
The problem with 1. is that it requires a 1M tx, which could be a little expensive for a regular user to send (the tx fee). Trivial for an exchange to implement though.
Most of the complexity in my initial post was thinking about how to let regular users on the 2x side do replay protection without creating their own 1MB+ tx or buying replay protected outputs from a service.
AnyoneCanPay
I've created a PR with the 1x side of this here #127.
Transactions are limited to 1M base size for compatibility: https://github.com/btc1/specifications/blob/master/drafts/BIP-tx-size.md
Transactions are limited to 1M base size for compatibility.
Ah yes, sorry! There is a sweet spot when a tx is 1M (or just under) when it's valid on the 2x chain but impossible on the 1x chain. The replay protection tx would need to be exactly this size.
Here is an example tx which is 999999 bytes:
https://btc1.slack.com/files/U6CQ1M491/F7DNJ718V/mega-tx.txt
It has 29410 P2PKH outputs that could be used for replay protection on the 2x chain.
Please take a moment to read the thread below before considering adding -ANY- replay protection to SegWit2x. It's important that the Legacy 1x chain does -NOT- survive or continue after the 2MB upgrade. Try to ignore the politics and chatter in the thread as there are some good points made regarding the Legacy 1x chain's nodes mempool flooding/circle of death after the upgrade.
'How is 1x even going to survive a 50/50 hash power stand off?'
https://www.reddit.com/r/btc/comments/75xxws/core_shills_how_is_1x_even_going_to_survive_a/?st=j8pj8ati&sh=866e3125
NACK