> > 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".
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
