{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-28\n📝 Original message:\u003e\n\u003e Go ahead and object to soft forks...but at least try not to make arguments\n\u003e based on changing the definitions of terms we all generally agree upon.\n\u003e\n\nI don't intend to do that, and I don't think I am - I know what the\ndifference between a soft and hard fork is and am not trying to confuse or\nblur the two.\n\nTo reiterate: this current BIP implements a soft fork. I am not debating\nthat. I am saying it should use a hard fork instead. This will ensure no\nrepeat of the P2SH case where invalid blocks were being found for weeks (or\nwas it months?) after the new rules kicked in, thus exposing SPV wallets\nand old nodes to unnecessary risk for no benefit.\n\nAdditionally, I am making it clear that there's no consensus for rolling\nout the new opcode in this way. As you say, the mechanism has issues. If\nyou read the comments when I wrote my article, you can see that others\nshare the same concerns:\n\nhttps://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/a7bdf845/attachment-0001.html\u003e"}