<p>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.</p>

CC BY-SA 3.0
2017-06-15T19:07:19.783Z
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
CC BY-SA 3.0
2017-06-15T19:03:15.593Z
2017-06-15T19:03:15.593Z
Ava Chow
<p>Is there any protection against replay attacks in BIP148? </p>

<p>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? </p>

<p>Something like Ethereum with EIP155 / chain ID. </p>

CC BY-SA 3.0
2017-06-16T06:20:32.307Z
related: [What is a soft fork?](https://bitcoin.stackexchange.com/q/30817/5406)
Murch
CC BY-SA 3.0
2017-06-16T15:02:48.807Z
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
CC BY-SA 3.0
2017-06-16T15:16:47.880Z
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
CC BY-SA 3.0
2017-06-16T15:53:47.020Z
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
CC BY-SA 3.0
2017-06-16T15:55:19.677Z
It's forwards compatible and therefore a soft fork.
Murch
CC BY-SA 3.0
2017-06-16T16:16:02.937Z
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
<blockchain-fork><replay-attack><bip148-uasf><activation-mechanism>
Does BIP148 (UASF) offer any replay attack protection?
Karel Bílek
# Does BIP148 (UASF) offer any replay attack protection?

(Asked by: username_0 on 2017-06-15)

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.

**Tags:** blockchain-fork, replay-attack, bip148-uasf, activation-mechanism

> **Comments:**
> **username_1**: related: [What is a soft fork?](https://bitcoin.stackexchange.com/q/30817/5406)  
> **username_0**: 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  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_1**: It's forwards compatible and therefore a soft fork.  
> **username_0**: 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 :)  

---

## 1 answers

### Answer by username_2 on 2017-06-15. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  

---

