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@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@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev