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 <[email protected] > <mailto:[email protected]>> wrote: > > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > <[email protected] > <mailto:[email protected]>> 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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
