2
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.
1
related: What is a soft fork?
– Murch – 2017-06-16T06:20:32.3071As 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 – 2017-06-16T15:02:48.807
2What 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 – 2017-06-16T15:16:47.880
1Which 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 – 2017-06-16T15:53:47.020
It's forwards compatible and therefore a soft fork. – Murch – 2017-06-16T15:55:19.677
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 – 2017-06-16T16:16:02.937