rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:Well, let's agree to disagree on these two things: - I define "working" for a full node as verifying everything; if a node starts skipping bits then I'd say it's not really "working" according to its original design goals - Saying the pre-fork behaviour is defined and deterministic is true, but only in the sense that reading an uninitialised variable in C is defined and deterministic. It reads whatever happens to be at that stack position: easily defined. For many programs, that may be the same value each time: deterministic. Nonetheless, it's considered undefined behaviour by the C specification and programmers that rely on it can easily create security holes. In the same way, I'd consider a node running a script with a NOP and reaching the opposite conclusion from other nodes to be a case of undefined behaviour leading to a non-fully-working node. But these are arguments about the semantics of words. I think we both know what each other is getting at. On Mon, Oct 5, 2015 at 1:23 PM, Jeff Garzik <jgarzik at gmail.com> wrote: > > - 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/1aabb5c5/attachment.html>