{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-06-06\n📝 Original message:On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I believe the severity of replay attacks is going unvoiced and is not\n\u003e understood within the bitcoin community because of their lack of experience\n\u003e with them.\n\nPlease don't insult our community-- the issues with replay were\npointed out by us to Ethereum in advance and were cited specifically\nin prior hardfork discussions long before Ethereum started editing\ntheir ledger for the economic benefit of its centralized\nadministrators.\n\nThe lack of extensive discussion on these issues you're seeing is\nrather symptomatic of engineers that take stability seriously not\ntaking BIP148 seriously; not symptomatic of people not knowing about\nthem. The same concerns also applies to all these HF proposals (which\nfor some reason you don't mention), arguably even stronger.  The same\nbasic pattern exists: There are people that just don't care about the\ntechnical issues who have made up their minds, and so you don't see\ntechnical discussion.  Those people who do see the issues already\ncalled out the proposals as being ill-advised.   Replay isn't even the\nlargest of the technical issues (network partitioning, for example, is\na much larger one).\n\nBIP149 is arguably something of another matter in particular because\nit has a time-frame that allows dealing with replay and other issues--\nand particularly because it has a time-frame that can allow for the\navoidance of a meaningful fork at all."}