Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F105955 for ; Tue, 6 Jun 2017 23:12:31 +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 8F95F15F for ; Tue, 6 Jun 2017 23:12:27 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 108FF10AFB5; Tue, 6 Jun 2017 16:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=gxmjHt9SVdM1h1B1g 4SMNOYnKkE=; b=atwyrQ9+M8xjDZvB63Rw8z01Nex8h0QxDwpx2XjSUKvvHDg48 ugfwqygFnlzdrwX9wJcBL5N/GrjViHPJaZoIvEae2d/2/R+qTfvxyA8/EaON7SgC f3iI9awen1KogkAUsXTMuMhSWMTgzudF28YhptwGAK9iyIaF1k9kGDpLDc= 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 DE86310AFB0; Tue, 6 Jun 2017 16:12:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0BD8C917-84BF-42C4-838A-CABA3B5FDA63"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: Date: Tue, 6 Jun 2017 16:12:26 -0700 X-Mao-Original-Outgoing-Id: 518483546.214948-ccdee8c8a2381643cac7bf9da1a27a3c Message-Id: <7117CE7C-3C6F-4342-8A43-072605EB3D1E@taoeffect.com> References: <31833011-7179-49D1-A07E-8FD9556C4534@taoeffect.com> To: Gregory Maxwell 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 23:22:18 +0000 Cc: Bitcoin Dev Subject: Re: [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 23:12:31 -0000 --Apple-Mail=_0BD8C917-84BF-42C4-838A-CABA3B5FDA63 Content-Type: multipart/alternative; boundary="Apple-Mail=_C5232B32-55E4-4545-A3E5-425A67E7309D" --Apple-Mail=_C5232B32-55E4-4545-A3E5-425A67E7309D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey Greg, It wasn't my intention to insult anyone (a bit defensive?). Maybe this is yet another example of a recurring criticism of Core: that = core doesn't community these issues very well to journalists / reports / = media / community outside of this list. Because outside of this list it's been all about those 148 coins, and = almost zero mention of replay attacks. > BIP149 is arguably something of another matter in particular because > it has a time-frame that allows dealing with replay and other issues-- > and particularly because it has a time-frame that can allow for the > avoidance of a meaningful fork at all. Are there other, more reasonable / feasible ways of addressing replay = attacks in Bitcoin / BIP149 scenario? Cheers, Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jun 6, 2017, at 4:02 PM, Gregory Maxwell > wrote: >=20 > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > > wrote: >> 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. >=20 > Please don't insult our community-- the issues with replay were > pointed out by us to Ethereum in advance and were cited specifically > in prior hardfork discussions long before Ethereum started editing > their ledger for the economic benefit of its centralized > administrators. >=20 > The lack of extensive discussion on these issues you're seeing is > rather symptomatic of engineers that take stability seriously not > taking BIP148 seriously; not symptomatic of people not knowing about > them. The same concerns also applies to all these HF proposals (which > for some reason you don't mention), arguably even stronger. The same > basic pattern exists: There are people that just don't care about the > technical issues who have made up their minds, and so you don't see > technical discussion. Those people who do see the issues already > called out the proposals as being ill-advised. Replay isn't even the > largest of the technical issues (network partitioning, for example, is > a much larger one). >=20 > BIP149 is arguably something of another matter in particular because > it has a time-frame that allows dealing with replay and other issues-- > and particularly because it has a time-frame that can allow for the > avoidance of a meaningful fork at all. --Apple-Mail=_C5232B32-55E4-4545-A3E5-425A67E7309D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hey Greg,

It wasn't my intention to insult anyone (a bit = defensive?).

Maybe = this is yet another example of a recurring criticism of Core: that core = doesn't community these issues very well to journalists / reports / = media / community outside of this list.

Because outside of this list it's been = all about those 148 coins, and almost zero mention of replay = attacks.

BIP149 is arguably = something of another matter in particular because
it has a = time-frame that allows dealing with replay and other issues--
and particularly because it has a time-frame that can allow = for the
avoidance of a meaningful fork at all.

Are there other, more reasonable / feasible ways of = addressing replay attacks in Bitcoin / BIP149 scenario?

Cheers,
Greg

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

On Jun 6, 2017, at 4:02 PM, Gregory Maxwell <greg@xiph.org> = wrote:

On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via = bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
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.

Please = don't insult our community-- the issues with replay were
pointed out by us to Ethereum in advance and were cited = specifically
in prior hardfork discussions long before = Ethereum started editing
their ledger for the economic = benefit of its centralized
administrators.
The lack of extensive discussion on these issues you're = seeing is
rather symptomatic of engineers that take = stability seriously not
taking BIP148 seriously; not = symptomatic of people not knowing about
them. The same = concerns also applies to all these HF proposals (which
for = some reason you don't mention), arguably even stronger.  The = same
basic pattern exists: There are people that just = don't care about the
technical issues who have made up = their minds, and so you don't see
technical discussion. =  Those people who do see the issues already
called = out the proposals as being ill-advised.   Replay isn't even = the
largest of the technical issues (network partitioning, = for example, is
a much larger one).

BIP149 is arguably something of another matter in particular = because
it has a time-frame that allows dealing with = replay and other issues--
and particularly because it has = a time-frame that can allow for the
avoidance of a = meaningful fork at all.

= --Apple-Mail=_C5232B32-55E4-4545-A3E5-425A67E7309D-- --Apple-Mail=_0BD8C917-84BF-42C4-838A-CABA3B5FDA63 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----- iQIcBAEBCgAGBQJZNzbaAAoJEOxnICvpCVJH2NAP/1weE6JxAUcP0axh4UVJKEpk oS0LOceuDM6A7+Hc7tumoNq+2wRhZER5g0PBMPMqHrpeVeuVPN02Pse0Wu8boV8b 7odg9I415pixHzaZ/4NFxT++x19HYBL/rO40QFs7QMgpjkvoDiqkDsozJTiifviH m/5UBHefvXXWrIwle7vNBzFqjR3wwYSMZfU/oqWH03WAL6l21IW7/gVrjPRUJnFI rgskk+FUSR9Mt3YIa9xVQpmwZzLDN+9wRluKrO/3qjXiyXPuXuPFEjdjiJJkEfLY EUel6D1z1yGLfZ5hkm/CebALX2dWulxx8rjd7VOkWUUitliL6hStNtsCjewgjl9n qhp0DNPP4QVEbb1VLGttoDmBVlXUW1zp2vLIOWs352pQPYNcug83FLfMUoq/H2Ol ibwy4E+ZQDR7e4Y9dSdTz+uhYjTEmy7GbP/cIxyZiiytocSAliVsWp985ZeCWQpe 6hMCHzGTllABsijEl4ZrAT+Cv1f70uW225N+D8BXBxmgwpH6j/UEezKM6vTOmmq8 hsqCKVgkcEoj0v1UWD60kkFDJw1lrygpAapQdvyqcUHhCwp6S5t498nRr7w5quqF tWE3r18T3DG5AcEZD74Bbt120NByVMSyWAdAlnYMFn+7sxbf/hiRM4NGl4NK6CEo 4sD6BdTmrgDHxQzKlqVr =MufQ -----END PGP SIGNATURE----- --Apple-Mail=_0BD8C917-84BF-42C4-838A-CABA3B5FDA63--