Adding optin replay protection via bits 29 and 30 in tx.nVersion

[jheathco]

Alternative to using scripts for opt-in replay protection. Setting bit 29 in tx.nVersion will reject transactions on segwit2x.

Reduces blockchain bloat but does require reserving 2 bits of nVersion to signal the chain.

This was suggested by Jacob Elisoff and Sergio Lerner. Sergio also suggested ignoring transactions not using replay protection for a brief period of time after hard fork which was omitted but could be added.

[christophebiocca]

Question: How does TX_VERSION_REJECT_SEGWIT1X work? Is it just that we assume there'll be a mirroring implementation on the 1MB side?

[jheathco]

@christophebiocca Exactly.

[jcansdale]

Have you considered adding a sunset clause, so we don't take up bits 29 and 30 forever? Once the chains are established, an alternative replay protection method could be used (OP_CHECKBLOCKATHEIGHT perhaps) or the rule could be continued via another soft-fork if this is still deemed the best method.

We don't necessarily want to tie our hands and require another hard-fork further down the road. 😉

[Buck-Rogers]

NACK

[jheathco]

Adding a sunset clause is a good idea. We can't be certain that the 1x chain will need to hard fork for PoW change/difficulty adjustment (although it appears very likely).

Should discuss when the sunset clause would go into effect.

[argon2]

NACK

Replay protection MUST be permanent. This hack would have to be removed and is essentially a hard-fork to UNDO. Also this hack is vulnerable to many attack vectors because any node can send any these transaction version flags and cause a network split or node isolation which could lead to a network wide consensus failure which would result in transactions still being replayed.

Replay protection MUST be a consensus rule that is never removed. This hack provides no protection whatsoever as described.

[christophebiocca]

Replay protection MUST be permanent.

Because replaying a transaction on the other side of the split could otherwise happen 5 years down the road, or for some other reason?

This hack would have to be removed and is essentially a hard-fork to UNDO.

Any replay protection (any soft-fork, for that matter) requires a hard fork to undo. The advantage of sunsetting is precisely that it ensures anyone enforcing the new rule in the first place will also stop enforcing it at a future time, such that we don't need to re-coordinate all implementations again to remove the rule later.

Also this hack is vulnerable to many attack vectors because any node can send any these transaction version flags and cause a network split or node isolation which could lead to a network wide consensus failure which would result in transactions still being replayed.

This needs more detail. Can you explain which nodes end up split from which ones? Certainly all 2x nodes will enforce the same rule and never build nor accept blocks containing the wrong tx version. This is a pretty standard soft-fork. Are you worried about miners that run BU nodes or something else?

[jgarzik]

Closing as an unlikely merge, given the other methods. Much appreciate the work though - thanks!