rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:Hi Jorge, I'm glad we seem to be reaching agreement that hard forks aren't so bad really and can even have advantages. It seems the remaining area of disagreement is this rollout specifically. > 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. > Indeed it will, but the point of fully verifying is to *not* converge with the miner majority, if something goes wrong and they aren't following the same rules as you. Defining "work" as "converge with miner majority" is fine for SPV wallets and a correct or at least reasonable definition. But not for fully verifying nodes, where non-convergence is an explicit design goal! That's the only thing that stops miners awarding themselves infinite free money! > 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)? > No, I'm focused on the block size issue right now. I don't think there's much point in improving the block chain protocol if most users are going to be unable to use it. But the modification is simple, right? You just replace this bit: CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode with this CHECKLOCKTIMEVERIFY defines a new opcode (0xc0) and that's it. The section *upgrade and testing plan* only says TBD so that part doesn't even need to change at all, as it's not written yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/46cc6d47/attachment.html>