{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:On Oct 5, 2015 1:28 PM, \"Mike Hearn via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Well, let's agree to disagree on these two things:\n\u003e\n\u003e - I define \"working\" for a full node as verifying everything; if a node\nstarts skipping bits then I'd say it's not really \"working\" according to\nits original design goals\n\nBut assuming the hashrate majority has upgraded (and we're using 95% as the\nminer upgrade confirmation threshold to start activation, so that\nassumption seems pretty safe), a non-upgraded full node and an upgraded\nfull will converge on what they see: \"the most-work valid chain\" will be\nthe same for both. A non-upgraded full node wallet waiting for several\nconfirmations (for example, 6 confirmations) will be just as safe as an\nupgraded one. In that sense, it keeps working. On top of that, nodes (of\nany kind) can use unknown block version numbers to notify the user or even\nstop working (the same notification mechanism you would use with hardforks).\n\nI agree that hardforks are necessary and we should deploy a hardfork asap\nto show the world they are indeed possible (bip99 proposes a likely\nuncontroversial one), but I still believe that is clear that softfork\ndeployment is preferrable in many cases like this one.\n\nAre you going to produce a bip65 hardfork alternative to try to convince\npeople of its advantages over bip65 (it is not clear to me how you include\na new script operand via hardfork)?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/b9f495ac/attachment.html\u003e"}