rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-09-29 📝 Original message:> > Other 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 > All clients do *not* do this. Why would they? What action would they take? Try and simulate a hard fork in some complicated roundabout manner? Why not just do the real thing and keep things simple? > and make unknown noops nonstandard > They are already non-standard. That change was made last time I brought up the problems with soft forks. It brought soft forks that use OP_NOPs a bit closer to the ideal of a hard fork, but didn't go all the way. I pointed that out above in my reply to Peter's mail. So to answer your question, no, it wouldn't satisfy my concerns. My logic is this: Hard forks - simple, well understood, SPV friendly, old full nodes do not calculate incorrect ledgers whilst telling their users (via UI, RPC) that they are fully synced. Emphasis on simple: simple is good. Soft forks - to get the benefits of a hard fork back requires lots of extra code, silently makes IsStandard() effectively a part of the consensus rules when in the past it hasn't been, SPV unfriendly. Benefits? As far as I can tell, there are none. If someone could elucidate *what* the benefits actually are, that would be a good next step. So far everyone who tried to answer this question gave a circular answer of the form "soft forks are good because they are soft forks". -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/6cc51d05/attachment.html>