rich1.0npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58njumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:- It is true that hard forks produce a much cleaner outcome, in terms of well defined behavior across the entire network. - Replacing an opcode should not result in undefined behavior. The non-upgraded behavior is defined and deterministic. - IsStandard remains an assistant. Miners may mine non-standard transactions. - "Hard forks require everyone to upgrade and soft forks don't" Doesn't require tons of explanation: Non upgraded clients continue working on the network even after the rules are upgraded. All those corrections aside, I do think there has been too much hysteria surrounding hard forks. Hard forks, when done right, produce a much cleaner system for users. On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Putting aside stupid arguments about who is older or who starting using > the term SPV wallet first, let me try and make a better suggestion than > what's in the BIP. How about the following: > > A new flag is introduced to Core, --scriptchecks=[all,standardonly,none]. > The default is all. When set to "standardonly", non-standard scripts are > not checked but others are. This is similar to the behaviour during a soft > fork. In "none" you have something a bit like SPV mode, but still > calculating the UTXO set. This flag is simple and can be implemented in a > few lines of code. Then an unused opcode is used for CLTV, so making it a > hard fork. > > This has the following advantages: > > - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in > to it if they want it. This prioritises availability (in a sense) over > correctness. > > - But otherwise, nodes will prioritise correctness by default, which > is how it should be. This isn't PHP where nonsensical code the interpreter > doesn't understand just does ...... something. This is financial software > where money is at risk. I feel very strongly about this: undefined > behaviour is fine *if you opted into getting it. *Otherwise it should > be avoided whenever possible. > > - SPV wallets do the right thing by default. > > - IsStandard doesn't silently become a part of the consensus rules. > > - All other software gets simpler. It's not just SPV wallets. Block > explorers, for example, can just add a single line to their opcode map. > With a soft fork they have to implement the entire soft fork logic just to > figure out when an opcode transitioned from OP_NOP to CLTV and make sure > they render old scripts differently to new scripts. And they face tricky > questions - do they render an opcode as a NOP if the miner who built it was > un-upgraded, or do they calculate the flag day and change all of them after > that? It's just an explosion of complexity. > > Many people by now have accepted that hard forks are simpler, conceptually > cleaner, and prioritise correctness of results over availability of > results. I think these arguments are strong. > > So let me try addressing the counter-arguments one more time: > > - Hard forks require everyone to upgrade and soft forks don't. I still > feel this one has never actually been explained. There is no difference to > the level of support required to trigger the change. With the suggestion > above, if someone can't or won't upgrade their full node but can no longer > verify the change, they can simply restart with -scriptchecks=standardonly > and get the soft fork behaviour. Or they can upgrade and get their old > security level back. > > - Hard forks are somehow bad or immoral or can lead to "schisms". This > is just saying, if we hold a vote, the people who lose the vote might try > starting a civil war and refuse to accept the change. That's not a reason > to not hold votes. > > But at any rate, they can do that with soft forks too: just decide > that any output that contains OP_CLTV doesn't make it into the UTXO set. > Eventually coins that trace back to such an output will become unusable in > the section of the economy that decided to pick a fight. > > > > _______________________________________________ > 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/6fe4130c/attachment.html>