Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-05 📝 Original message:On Oct 5, 2015 1:28 PM, ...
📅 Original date posted:2015-10-05
📝 Original message:On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
But assuming the hashrate majority has upgraded (and we're using 95% as the
miner upgrade confirmation threshold to start activation, so that
assumption seems pretty safe), a non-upgraded full node and an upgraded
full will converge on what they see: "the most-work valid chain" will be
the same for both. A non-upgraded full node wallet waiting for several
confirmations (for example, 6 confirmations) will be just as safe as an
upgraded one. In that sense, it keeps working. On top of that, nodes (of
any kind) can use unknown block version numbers to notify the user or even
stop working (the same notification mechanism you would use with hardforks).
I agree that hardforks are necessary and we should deploy a hardfork asap
to show the world they are indeed possible (bip99 proposes a likely
uncontroversial one), but I still believe that is clear that softfork
deployment is preferrable in many cases like this one.
Are you going to produce a bip65 hardfork alternative to try to convince
people of its advantages over bip65 (it is not clear to me how you include
a new script operand via hardfork)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/b9f495ac/attachment.html>;
📝 Original message:On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
But assuming the hashrate majority has upgraded (and we're using 95% as the
miner upgrade confirmation threshold to start activation, so that
assumption seems pretty safe), a non-upgraded full node and an upgraded
full will converge on what they see: "the most-work valid chain" will be
the same for both. A non-upgraded full node wallet waiting for several
confirmations (for example, 6 confirmations) will be just as safe as an
upgraded one. In that sense, it keeps working. On top of that, nodes (of
any kind) can use unknown block version numbers to notify the user or even
stop working (the same notification mechanism you would use with hardforks).
I agree that hardforks are necessary and we should deploy a hardfork asap
to show the world they are indeed possible (bip99 proposes a likely
uncontroversial one), but I still believe that is clear that softfork
deployment is preferrable in many cases like this one.
Are you going to produce a bip65 hardfork alternative to try to convince
people of its advantages over bip65 (it is not clear to me how you include
a new script operand via hardfork)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/b9f495ac/attachment.html>;