rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 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>