Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5402093E for ; Tue, 6 Jun 2017 22:39:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 904F915F for ; Tue, 6 Jun 2017 22:39:29 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 12E6D10AFBD for ; Tue, 6 Jun 2017 15:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:to; s= taoeffect.com; bh=H4U9pMg2zgXM7zP6kzTAxwaNhrQ=; b=St2LFZXl5IyS/V 3+XhVq4z+Ku9LWpz9JhsDenPmlThL9acbO4xjNMoKkAuCsrWFhsuQsygH4cn2/TC riVROIxsXwLmWMYnXfCKdo1qfSY/cSCFPgKRs+XfxJ7LJkbYwEJFWDzgUdpeRvhO NGnl5/DRgRV6wpwGnAlUs80sw5Etg= Received: from [192.168.42.64] (184-23-255-227.fiber.dynamic.sonic.net [184.23.255.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id EB2CF10AFB0 for ; Tue, 6 Jun 2017 15:39:28 -0700 (PDT) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_18904166-6865-4812-ADAC-2AA8A3C86F3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 518481568.273181-4d665d410cc8ff134ddf24667c0a41b6 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com> Date: Tue, 6 Jun 2017 15:39:28 -0700 To: Bitcoin Dev X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 06 Jun 2017 22:45:02 +0000 Subject: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:39:30 -0000 --Apple-Mail=_18904166-6865-4812-ADAC-2AA8A3C86F3A Content-Type: multipart/alternative; boundary="Apple-Mail=_BD4A37B1-E1FD-474F-956F-BEB549195C3F" --Apple-Mail=_BD4A37B1-E1FD-474F-956F-BEB549195C3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=3D33rL3-p8cPw = Cheers, Greg Slepak -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_BD4A37B1-E1FD-474F-956F-BEB549195C3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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=3D33rL3-p8cPw

Cheers,
Greg Slepak

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

= --Apple-Mail=_BD4A37B1-E1FD-474F-956F-BEB549195C3F-- --Apple-Mail=_18904166-6865-4812-ADAC-2AA8A3C86F3A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZNy8gAAoJEOxnICvpCVJH8rgP/1dlob+uZotnWwrKRjjeppSx p1gb1A00swPNGakoy+zbSvm3TA2tXRDa5wYL7h9tY5Gb+waARoVpE+SKyGNp9190 d106zS/VN8FK+DUtjlK3h1hmBHjGgSJktLW+diftS+3Mru6yl91gPyPOqHiO7BfM 1sjzca63yHd5+O9mA9ofeod4b4woviZGoZGApSY5MjCRBGnJyprOH86p2cIPvS6B CwydYE2bxXY4soJM8bIB/S2qD7pd8SqCvRm+KN270AbQQMvCPRfvChoAHr7yLKX0 3t7OGrmq+y7wu5rlaCWE6zOPuTqyYhqeY94yAdiEYeXgjUwY3vHjBNrGNeEDIMdP 4O3kmnDU3whycwY+r+7Rz0izbDFMZs6ZU9Y4GxvSy2vAOPM1DZ8FgWdPBxXgb7Ka rMrK4kQjYsLroSo7P/jIZqk9pWr+hzjP3pY/0q8Fz8Sc64Gg7o/kH2Y4KqFK/RX3 Ka9bjkFiOHILqpnjs5F/4xX91HCmOu4Lmwe/tEXX+pu2u6gJImO4PkgAV3/YM2jf 3VPuGWgkwg133WsKjX7o50hEkv2JDM5oQD01W0iUZPx4EAeNEV+0h13OV6SfSB1X +H/tOCOAyg8SgaWIoTST4UnDjDgIFFbsFPRdwha58uozrl0pK8U27NOq7xxrrsQ4 Hbj8PG559oPdILpbiQot =UhKq -----END PGP SIGNATURE----- --Apple-Mail=_18904166-6865-4812-ADAC-2AA8A3C86F3A--