1

Is there any protection against replay attacks in BIP148?

Despite the popular name (UASF), it's effectively a hard fork (in the sense users with old nodes will be on a different chain), is there any protection against taking the transaction from the longer chain and putting it on "UASFCoin" chain, or vice versa?

Something like Ethereum with EIP155 / chain ID.

Michael Folkson
  • 15,313
  • 3
  • 17
  • 53
Karel Bílek
  • 2,695
  • 3
  • 24
  • 45
  • 2
  • 1
    As is stated there - "if less than 51% of the hashing power switches to the new version, it behaves like a hardfork" - which can very well happen in UASF – Karel Bílek Jun 16 '17 at 15:02
  • 3
    What I meant there when I wrote this two years ago was: A soft fork with minority hash support will lead to a persistent chain split as a hard fork would. It is still distinctly different from a hard fork as the software is forwards compatible, and this split could still self-mend if more hashrate converges on the soft fork chain. – Murch Jun 16 '17 at 15:16
  • 1
    Which applies to BIP148 too though. If it has minoritity - which it can, since it has a flag day and not a miner requirement. So it's something in between. – Karel Bílek Jun 16 '17 at 15:53
  • It's forwards compatible and therefore a soft fork. – Murch Jun 16 '17 at 15:55
  • It's not fully forwards compatible - if the segwit chain has less hashpower, the old nodes will be on a different chain, as you yourself noted in the answer :) – Karel Bílek Jun 16 '17 at 16:16

1 Answers1

4

No. BIP 148 is a soft fork as the BIP 148 chain is valid to all non-BIP148 nodes and can wipe out the non-BIP 148 chain if it were to be longer than it. Because it is a soft fork, there cannot be any replay protection otherwise it would become a hard fork.

Ava Chow
  • 70,382
  • 5
  • 81
  • 161
  • 1
    Hm. But it has a big chance of being shorter than the other chain (that's because it's "user activated" and not "miner activated"), so replay attacks are still possible, if both chains keep being mined and used. But it's true that replay attack protection is impossible in this case. – Karel Bílek Jun 15 '17 at 19:07