{"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 Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn \u003chearn at vinumeris.com\u003e wrote:\n\u003e Hi Jorge,\n\u003e\n\u003e I'm glad we seem to be reaching agreement that hard forks aren't so bad\n\u003e really and can even have advantages. It seems the remaining area of\n\u003e disagreement is this rollout specifically.\n\u003e\u003e\n\u003e\u003e a non-upgraded full node and an upgraded full will converge on what they\n\u003e\u003e see: \"the most-work valid chain\" will be the same for both.\n\u003e\n\u003e Indeed it will, but the point of fully verifying is to not converge with the\n\u003e miner majority, if something goes wrong and they aren't following the same\n\u003e rules as you. Defining \"work\" as \"converge with miner majority\" is fine for\n\u003e SPV wallets and a correct or at least reasonable definition. But not for\n\u003e fully verifying nodes, where non-convergence is an explicit design goal!\n\u003e That's the only thing that stops miners awarding themselves infinite free\n\u003e money!\n\nAs Greg explained to you repeatedly, a softfork won't cause a\nnon-upgraded full node to start accepting blocks that create more\nsubsidy than is valid.\nIt's only the new rule (in this case, BIP65) that they won't validate.\nThat's very different security from an SPV node, and as Greg also\nexplained, SPV nodes could be much more secure than bitcoinj nodes\n(they could, for example, validate the coinbase transaction of every\nblock).\nIf a non-upgraded node it's not a \"full node\" for you, that's fine,\nbut it is for everyone else. So please stop confusing other people.\nAssuming the majority of the hashrate upgraded, there's almost no risk\nfor non-upgraded full nodes.\n\n\u003e\u003e Are you going to produce a bip65 hardfork alternative to try to convince\n\u003e\u003e people of its advantages over bip65 (it is not clear to me how you include a\n\u003e\u003e new script operand via hardfork)?\n\u003e\n\u003e No, I'm focused on the block size issue right now. I don't think there's\n\u003e much point in improving the block chain protocol if most users are going to\n\u003e be unable to use it. But the modification is simple, right? You just replace\n\u003e this bit:\n\u003e\n\u003e   CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode\n\u003e\n\u003e with this\n\u003e\n\u003e   CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)\n\u003e\n\u003e and that's it. The section upgrade and testing plan only says TBD so that\n\u003e part doesn't even need to change at all, as it's not written yet.\n\nThanks, I wasn't aware that there was room for new opcodes that\nweren't noops already.\nCan you give an example of an attack in which a non-upgraded full node\nwallet is defrauded with BIP65 but could not with the hardfork\nalternative (that nobody seems to be willing to implement)?\nPlease, don't assume 0 confirmation transactions or similar\nunreasonable assumptions (ie see section 11 \"Calculations\" of the\nBitcoin whitepaper)."}