From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 30EF818EA for ; Mon, 5 Oct 2015 11:23:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1FB5E13C for ; Mon, 5 Oct 2015 11:23:42 +0000 (UTC) Received: by wicge5 with SMTP id ge5so115622191wic.0 for ; Mon, 05 Oct 2015 04:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RhRdyv6wHk+eIAB8ptWHutBBIFYW0h+Tn2+jeAHVPRA=; b=Slm4JQ1EjqybfOSdLJfAi0f8+X6bxz3F6Y3vsOZw2GhlNjw/lstiXV3I6f3XQ3VuGn tsAzrqhYNzXVKnLMxmy3X2BhtZEMwEz4naPfhhEe6spCMAYXlotr4H9UCg2HA1knLOzH LLZNtgej+u/ehJAxI7CpyDuiZYgVqWH5yfEr/iiXSUN/GNjxVUTSha4d0+WehX7NuWhI lwakDwEl44NHUlYLInOPh+G3DOaANkPt56qmhowomDnltrbOopCaOT3DCSU01Y7UumCs 8Lpa5J4a0+xADr8GrJ7yAsvAlgvG5XnNOuGxlebqe5zvMNGNMLkR0naRAjeE7Kb8u46T dkNg== MIME-Version: 1.0 X-Received: by 10.180.37.232 with SMTP id b8mr11741867wik.46.1444044220200; Mon, 05 Oct 2015 04:23:40 -0700 (PDT) Received: by 10.28.158.9 with HTTP; Mon, 5 Oct 2015 04:23:39 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 07:23:39 -0400 Message-ID: From: Jeff Garzik To: Mike Hearn Content-Type: multipart/alternative; boundary=e89a8f647253c8fb71052159be25 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 11:23:43 -0000 --e89a8f647253c8fb71052159be25 Content-Type: text/plain; charset=UTF-8 - 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 > > --e89a8f647253c8fb71052159be25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

- It is true that hard forks produce a much clean= er outcome, in terms of well defined behavior across the entire network.

- Replacing an opcode should not result in undefined= behavior.=C2=A0 The non-upgraded behavior is defined and deterministic.

- IsStandard remains an assistant.=C2=A0 Miners may = mine non-standard transactions.

- "Hard forks require everyone to upgrade and soft forks = don't" =C2=A0 Doesn't require tons of explanation: =C2=A0Non u= pgraded clients continue working on the network even after the rules are up= graded.

All those corrections aside, I do think t= here has been too much hysteria surrounding hard forks.=C2=A0 Hard forks, w= hen done right, produce a much cleaner system for users.
<= span style=3D"font-size:13px">







On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev= <bitcoin-dev@lists.linuxfoundation.org>= wrote:
Putting asi= de stupid arguments about who is older or who starting using the term SPV w= allet first, let me try and make a better suggestion than what's in the= BIP. How about the following:

A new flag is intro= duced to Core, --scriptchecks=3D[all,standardonly,none]. The default is all= . When set to "standardonly", non-standard scripts are not checke= d but others are. This is similar to the behaviour during a soft fork. In &= quot;none" you have something a bit like SPV mode, but still calculati= ng 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.= =C2=A0

This has the following advantages:
  • Nodes that want the pseudo-SPV behaviour of a soft fork can opt i= n to it if they want it. This prioritises availability (in a sense) over co= rrectness.

  • But otherwise, nodes will prioritise correctness= by default, which is how it should be. This isn't PHP where nonsensica= l code the interpreter doesn't understand just does ...... something. T= his is financial software where money is at risk. I feel very strongly abou= t this: undefined behaviour is fine if you opted into getting it. Ot= herwise it should be avoided whenever possible.

  • SPV wallets= do the right thing by default.

  • IsStandard doesn't sile= ntly become a part of the consensus rules.

  • All other softwa= re gets simpler. It's not just SPV wallets. Block explorers, for exampl= e, can just add a single line to their opcode map. With a soft fork they ha= ve to implement the entire soft fork logic just to figure out when an opcod= e transitioned from OP_NOP to CLTV and make sure they render old scripts di= fferently to new scripts. And they face tricky questions - do they render a= n opcode as a NOP if the miner who built it was un-upgraded, or do they cal= culate the flag day and change all of them after that? It's just an exp= losion of complexity.
Many people by now have accepted that h= ard 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 sof= t 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 cha= nge. With the suggestion above, if someone can't or won't upgrade t= heir full node but can no longer verify the change, they can simply restart= with -scriptchecks=3Dstandardonly and get the soft fork behaviour. Or they= can upgrade and get their old security level back.

  • Hard fo= rks 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 star= ting a civil war and refuse to accept the change. That's not a reason t= o 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/mail= man/listinfo/bitcoin-dev


--e89a8f647253c8fb71052159be25--