rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2017-06-06 📝 Original message:On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev <bitcoin-dev at 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.