{"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-29\n📝 Original message:\u003e\n\u003e Other than the fact that doing this as a soft fork requires an extra\n\u003e OP_DROP, how would doing this as a hard fork make any difference to SPV\n\u003e clients? If, as others have suggested, all clients warn the user on\n\u003e unrecognized nVersion\n\u003e\n\nAll clients do *not* do this. Why would they? What action would they take?\nTry and simulate a hard fork in some complicated roundabout manner? Why not\njust do the real thing and keep things simple?\n\n\n\u003e and make unknown noops nonstandard\n\u003e\n\nThey are already non-standard. That change was made last time I brought up\nthe problems with soft forks. It brought soft forks that use OP_NOPs a bit\ncloser to the ideal of a hard fork, but didn't go all the way. I pointed\nthat out above in my reply to Peter's mail.\n\nSo to answer your question, no, it wouldn't satisfy my concerns. My logic\nis this:\n\nHard forks - simple, well understood, SPV friendly, old full nodes do not\ncalculate incorrect ledgers whilst telling their users (via UI, RPC) that\nthey are fully synced. Emphasis on simple: simple is good.\n\nSoft forks - to get the benefits of a hard fork back requires lots of extra\ncode, silently makes IsStandard() effectively a part of the consensus rules\nwhen in the past it hasn't been, SPV unfriendly. Benefits? As far as I can\ntell, there are none.\n\nIf someone could elucidate *what* the benefits actually are, that would be\na good next step. So far everyone who tried to answer this question gave a\ncircular answer of the form \"soft forks are good because they are soft\nforks\".\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/6cc51d05/attachment.html\u003e"}