Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2015-10-05 š Original message:- It is true that hard ...
š
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>;
š 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>;