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.