{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:Well, let's agree to disagree on these two things:\n\n- 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\n- Saying the pre-fork behaviour is defined and deterministic is true, but\nonly in the sense that reading an uninitialised variable in C is defined\nand deterministic. It reads whatever happens to be at that stack position:\neasily defined. For many programs, that may be the same value each time:\ndeterministic. Nonetheless, it's considered undefined behaviour by the C\nspecification and programmers that rely on it can easily create security\nholes.\n\nIn the same way, I'd consider a node running a script with a NOP and\nreaching the opposite conclusion from other nodes to be a case of undefined\nbehaviour leading to a non-fully-working node.\n\nBut these are arguments about the semantics of words. I think we both know\nwhat each other is getting at.\n\nOn Mon, Oct 5, 2015 at 1:23 PM, Jeff Garzik \u003cjgarzik at gmail.com\u003e wrote:\n\n\u003e\n\u003e - It is true that hard forks produce a much cleaner outcome, in terms of\n\u003e well defined behavior across the entire network.\n\u003e\n\u003e - Replacing an opcode should not result in undefined behavior.  The\n\u003e non-upgraded behavior is defined and deterministic.\n\u003e\n\u003e - IsStandard remains an assistant.  Miners may mine non-standard\n\u003e transactions.\n\u003e\n\u003e - \"Hard forks require everyone to upgrade and soft forks don't\"   Doesn't\n\u003e require tons of explanation:  Non upgraded clients continue working on the\n\u003e network even after the rules are upgraded.\n\u003e\n\u003e All those corrections aside, I do think there has been too much hysteria\n\u003e surrounding hard forks.  Hard forks, when done right, produce a much\n\u003e cleaner system for users.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Putting aside stupid arguments about who is older or who starting using\n\u003e\u003e the term SPV wallet first, let me try and make a better suggestion than\n\u003e\u003e what's in the BIP. How about the following:\n\u003e\u003e\n\u003e\u003e A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].\n\u003e\u003e The default is all. When set to \"standardonly\", non-standard scripts are\n\u003e\u003e not checked but others are. This is similar to the behaviour during a soft\n\u003e\u003e fork. In \"none\" you have something a bit like SPV mode, but still\n\u003e\u003e calculating the UTXO set. This flag is simple and can be implemented in a\n\u003e\u003e few lines of code. Then an unused opcode is used for CLTV, so making it a\n\u003e\u003e hard fork.\n\u003e\u003e\n\u003e\u003e This has the following advantages:\n\u003e\u003e\n\u003e\u003e    - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in\n\u003e\u003e    to it if they want it. This prioritises availability (in a sense) over\n\u003e\u003e    correctness.\n\u003e\u003e\n\u003e\u003e    - But otherwise, nodes will prioritise correctness by default, which\n\u003e\u003e    is how it should be. This isn't PHP where nonsensical code the interpreter\n\u003e\u003e    doesn't understand just does ...... something. This is financial software\n\u003e\u003e    where money is at risk. I feel very strongly about this: undefined\n\u003e\u003e    behaviour is fine *if you opted into getting it. *Otherwise it should\n\u003e\u003e    be avoided whenever possible.\n\u003e\u003e\n\u003e\u003e    - SPV wallets do the right thing by default.\n\u003e\u003e\n\u003e\u003e    - IsStandard doesn't silently become a part of the consensus rules.\n\u003e\u003e\n\u003e\u003e    - All other software gets simpler. It's not just SPV wallets. Block\n\u003e\u003e    explorers, for example, can just add a single line to their opcode map.\n\u003e\u003e    With a soft fork they have to implement the entire soft fork logic just to\n\u003e\u003e    figure out when an opcode transitioned from OP_NOP to CLTV and make sure\n\u003e\u003e    they render old scripts differently to new scripts. And they face tricky\n\u003e\u003e    questions - do they render an opcode as a NOP if the miner who built it was\n\u003e\u003e    un-upgraded, or do they calculate the flag day and change all of them after\n\u003e\u003e    that? It's just an explosion of complexity.\n\u003e\u003e\n\u003e\u003e Many people by now have accepted that hard forks are simpler,\n\u003e\u003e conceptually cleaner, and prioritise correctness of results over\n\u003e\u003e availability of results. I think these arguments are strong.\n\u003e\u003e\n\u003e\u003e So let me try addressing the counter-arguments one more time:\n\u003e\u003e\n\u003e\u003e    - Hard forks require everyone to upgrade and soft forks don't. I\n\u003e\u003e    still feel this one has never actually been explained. There is no\n\u003e\u003e    difference to the level of support required to trigger the change. With the\n\u003e\u003e    suggestion above, if someone can't or won't upgrade their full node but can\n\u003e\u003e    no longer verify the change, they can simply restart with\n\u003e\u003e    -scriptchecks=standardonly and get the soft fork behaviour. Or they can\n\u003e\u003e    upgrade and get their old security level back.\n\u003e\u003e\n\u003e\u003e    - Hard forks are somehow bad or immoral or can lead to \"schisms\".\n\u003e\u003e    This is just saying, if we hold a vote, the people who lose the vote might\n\u003e\u003e    try starting a civil war and refuse to accept the change. That's not a\n\u003e\u003e    reason to not hold votes.\n\u003e\u003e\n\u003e\u003e    But at any rate, they can do that with soft forks too: just decide\n\u003e\u003e    that any output that contains OP_CLTV doesn't make it into the UTXO set.\n\u003e\u003e    Eventually coins that trace back to such an output will become unusable in\n\u003e\u003e    the section of the economy that decided to pick a fight.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/1aabb5c5/attachment.html\u003e"}