{"type":"rich","version":"1.0","author_name":"npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3","author_url":"https://nostr.ae/npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-06-06\n📝 Original message:Hey Greg,\n\nIt wasn't my intention to insult anyone (a bit defensive?).\n\nMaybe 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.\n\nBecause outside of this list it's been all about those 148 coins, and almost zero mention of replay attacks.\n\n\u003e BIP149 is arguably something of another matter in particular because\n\u003e it has a time-frame that allows dealing with replay and other issues--\n\u003e and particularly because it has a time-frame that can allow for the\n\u003e avoidance of a meaningful fork at all.\n\nAre there other, more reasonable / feasible ways of addressing replay attacks in Bitcoin / BIP149 scenario?\n\nCheers,\nGreg\n\n--\nPlease do not email me anything that you are not comfortable also sharing with the NSA.\n\n\u003e On Jun 6, 2017, at 4:02 PM, Gregory Maxwell \u003cgreg at xiph.org \u003cmailto:greg at xiph.org\u003e\u003e wrote:\n\u003e \n\u003e On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e I believe the severity of replay attacks is going unvoiced and is not\n\u003e\u003e understood within the bitcoin community because of their lack of experience\n\u003e\u003e with them.\n\u003e \n\u003e Please don't insult our community-- the issues with replay were\n\u003e pointed out by us to Ethereum in advance and were cited specifically\n\u003e in prior hardfork discussions long before Ethereum started editing\n\u003e their ledger for the economic benefit of its centralized\n\u003e administrators.\n\u003e \n\u003e The lack of extensive discussion on these issues you're seeing is\n\u003e rather symptomatic of engineers that take stability seriously not\n\u003e taking BIP148 seriously; not symptomatic of people not knowing about\n\u003e them. The same concerns also applies to all these HF proposals (which\n\u003e for some reason you don't mention), arguably even stronger.  The same\n\u003e basic pattern exists: There are people that just don't care about the\n\u003e technical issues who have made up their minds, and so you don't see\n\u003e technical discussion.  Those people who do see the issues already\n\u003e called out the proposals as being ill-advised.   Replay isn't even the\n\u003e largest of the technical issues (network partitioning, for example, is\n\u003e a much larger one).\n\u003e \n\u003e BIP149 is arguably something of another matter in particular because\n\u003e it has a time-frame that allows dealing with replay and other issues--\n\u003e and particularly because it has a time-frame that can allow for the\n\u003e avoidance of a meaningful fork at all.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.sig\u003e"}