{"type":"rich","version":"1.0","author_name":"npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x","author_url":"https://nostr.ae/npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:It will get correct results about :\n- the existence every block\n- the existence of every transaction\n\nIt will get incorrect results :\n- about the *nature* of some transactions\n- and therefore, about the balances of some wallets.\n\nI fully agree with Mike here.\n\nLe lun. 5 oct. 2015 à 14:04, Jorge Timón \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e\n\u003e On Oct 5, 2015 1:28 PM, \"Mike Hearn via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Well, let's agree to disagree on these two things:\n\u003e \u003e\n\u003e \u003e - I define \"working\" for a full node as verifying everything; if a node\n\u003e starts skipping bits then I'd say it's not really \"working\" according to\n\u003e its original design goals\n\u003e\n\u003e But assuming the hashrate majority has upgraded (and we're using 95% as\n\u003e the miner upgrade confirmation threshold to start activation, so that\n\u003e assumption seems pretty safe), a non-upgraded full node and an upgraded\n\u003e full will converge on what they see: \"the most-work valid chain\" will be\n\u003e the same for both. A non-upgraded full node wallet waiting for several\n\u003e confirmations (for example, 6 confirmations) will be just as safe as an\n\u003e upgraded one. In that sense, it keeps working. On top of that, nodes (of\n\u003e any kind) can use unknown block version numbers to notify the user or even\n\u003e stop working (the same notification mechanism you would use with hardforks).\n\u003e\n\u003e I agree that hardforks are necessary and we should deploy a hardfork asap\n\u003e to show the world they are indeed possible (bip99 proposes a likely\n\u003e uncontroversial one), but I still believe that is clear that softfork\n\u003e deployment is preferrable in many cases like this one.\n\u003e\n\u003e Are you going to produce a bip65 hardfork alternative to try to convince\n\u003e people of its advantages over bip65 (it is not clear to me how you include\n\u003e a new script operand via hardfork)?\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/eea49466/attachment.html\u003e"}