Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-05 📝 Original message:Well, let's agree to ...
📅 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>;
📝 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>;