rich1.0npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7xhttps://nostr.ae/npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7xnjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:It will get correct results about : - the existence every block - the existence of every transaction It will get incorrect results : - about the *nature* of some transactions - and therefore, about the balances of some wallets. I fully agree with Mike here. Le lun. 5 oct. 2015 à 14:04, Jorge Timón < bitcoin-dev at lists.linuxfoundation.org> a écrit : > > 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)? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/eea49466/attachment.html>