Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-29 📝 Original message:> > Other than the fact ...
📅 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>;
📝 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>;