{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-29\n📝 Original message:Mike,\n\nInsults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.\n\nOther than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward.\n\n- Eric\n\nOn September 28, 2015 5:54:33 AM PDT, Mike Hearn \u003chearn at vinumeris.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e we have NO hard fork mechanism in place that isn't highly prone to\n\u003e\u003e systemic consensus failure.\n\u003e\u003e\n\u003e\n\u003eJust use an opcode that isn't currently defined. Done. What about that\n\u003emechanism is prone to failure?\n\u003e\n\u003eRe: coma. No need for insults. Please read my article and address the\n\u003epoints raised there, which, by the way, do not include any mention of\n\u003eSPV\n\u003ewallets. Although your belief that SPV wallets are \"inherently\n\u003einsecure\"\n\u003eseems needlessly trollish - I certainly would disagree, but it's a\n\u003edifferent debate.\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/f4f3138f/attachment-0001.html\u003e"}