[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect <contact@taoeffect.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2050 bytes --]

This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama.

First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list, the reasons should be self-evident (one results in two incompatible chains, the other doesn't).

However, replay attacks are common to both possibilities (i.e. when BIP148 has <51% hash power).

I believe the severity of replay attacks is going unvoiced and is not understood within the bitcoin community because of their lack of experience with them.

I further believe that replay attacks are the #1 issue with BIP148, BIP149, etc., superseding wipeout attacks in severity.

These are not baseless beliefs, they're born out of experience and I think anyone will reach the same conclusion upon study.

In a nutshell, replay attacks mean that all talk of there being potentially "two coins" as a result of BIP148 is basically nonsense.

Replay attacks effectively eliminate that possibility.

When users go to "sell their legacy coins", they've just sold their 148 coins, and vice versa.

Both of the coin-splitting techniques given so far by the proponents BIP148 are also untenable:

- Double-spending to self with nLockTime txns is insanely complicated, risky, not guaranteed to work, extremely time consuming, and would likely result in a massive increase in backlogged transactions and increased fees.

- Mixing with 148 coinbase txns destroys fungibility.

Without a coin, there is no real threat from BIP148. Without that threat, there is no point to BIP148, and the miners know this.

These and other concerns are outlined and explained in more detail in this conversation I had yesterday with John Light:

https://www.youtube.com/watch?v=33rL3-p8cPw <https://www.youtube.com/watch?v=33rL3-p8cPw>

Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.


[-- Attachment #1.2: Type: text/html, Size: 5538 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]