Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D20A4959 for ; Wed, 7 Jun 2017 08:45:33 +0000 (UTC) X-Greylist: delayed 12:02:04 by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DEFE20C for ; Wed, 7 Jun 2017 08:45:32 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id 05DCD8FA7B for ; Tue, 6 Jun 2017 13:43:29 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id EB2C210AFB8 for ; Tue, 6 Jun 2017 13:43:27 -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=YOmh7YIqQP3h9QqTxmKZdAyTlhU=; b=n0m1BrBO+dZcZF xB9O97MIwkb+OAx3fDd4pZ7H4Ya04h9h7xpfT1OuXQxKpWl1sRey+831TwGGDuV8 I81+cN7GA0bVRwwjS0qoEAYSOWO/Y9ONi99nwXFX8THhBEsazzpEZwwupZTZHrdy LHngkMX3PISnZaPFtHhNAgTcTdhdw= 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 95C2210AFB0 for ; Tue, 6 Jun 2017 13:43:27 -0700 (PDT) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_0F506E9B-75E8-4920-88BA-10D63164C495"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 518474605.026703-aed0dc3d7b2cf52d7ddccd5e0f5ab48b Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 6 Jun 2017 13:43:25 -0700 To: bitcoin-dev@lists.linuxfoundation.org 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: Wed, 07 Jun 2017 12:52:53 +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: Wed, 07 Jun 2017 08:45:33 -0000 --Apple-Mail=_0F506E9B-75E8-4920-88BA-10D63164C495 Content-Type: multipart/alternative; boundary="Apple-Mail=_2616429B-2602-47C7-9F0F-94C2A9322C75" --Apple-Mail=_2616429B-2602-47C7-9F0F-94C2A9322C75 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=_2616429B-2602-47C7-9F0F-94C2A9322C75 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=_2616429B-2602-47C7-9F0F-94C2A9322C75-- --Apple-Mail=_0F506E9B-75E8-4920-88BA-10D63164C495 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----- iQIcBAEBCgAGBQJZNxPtAAoJEOxnICvpCVJH/80QAIwlE+Iw8czuT0JSKEW24auw ty4GGNSdTY/f42Q52xMAvNqAhsBzBCSOkrxblgF5GymEMmVg+7ZB+Q7l+s9erlnO 0F2yjtBwNg21/dXI7uu0zZy+7fw7ctKC7CflW2DXGzmJa2/koeWrFTbty7uf51BX rP3Qj0OC01e0qu4afJv6bpFgDv0BSoUKxNZ3dA3XLbz7a62vmyshDVqOeALTiHfq Kv2SsgevoLlyC89CJNCYp9+Hr7oI2bi17DTo/KSrhM8GIzJ5ILiCuNJvRgBJ6ySc we2xd1KMLeLlaWqru4BDbjoDvGPSLCas5W43NmA0kj8oZiG/bOFIwCFxW2ROfhUS CK+US5TKp/LgWyyPO8nzT9sbXzT0CZUFvFLOTcG/dEMXYv8VJb0cRvwrGjuk4ekZ tqF5Hy+WfTJvq41o8W/4+q9v4rFZYH8OI9V7SggUX13FS+JJ8Lshl/FpOdDElrgL Rw9xlUTwMLrOyoMR/+rKbuLIcwS7AdcJtW5pTlddgdVMproJmn3vVkSIS/mZKrI1 KALleJdnOQTGajR8qohM+rOVgQzaXHhQL1pWkSzi5l9us6fmqTqUXHjGhOkOBaRL WaLG8i3ar9ZYoSTDuTc2fbQfIXWoPMn7PsGV5FkARcKiYnSGQL6joMOivKq+Ibyd +e3VS3uGSMCvd/Fpl1ML =FQxu -----END PGP SIGNATURE----- --Apple-Mail=_0F506E9B-75E8-4920-88BA-10D63164C495--