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 2A8EA1226 for ; Mon, 5 Oct 2015 11:28:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3610415E for ; Mon, 5 Oct 2015 11:28:14 +0000 (UTC) Received: by iow1 with SMTP id 1so144722780iow.1 for ; Mon, 05 Oct 2015 04:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckb8jPci2UEq99KoDFl+NcYaAf1zWScA/5nR9hmO7WA=; b=dvNtgBTpZO8hfeY+Fv67QSwhbAFuZ94ap40c/zJLnjukyjXSRbbbzTgXfvmGMqeRZb Al/0cS8dilqu8zBg0xBXJCm1YCUXmwdMmlZ75WFhPRGZ3wnOikbq/raT8VtAlrTXqVE/ eRbnU61yZdTqoKxiRlWbWKe0EnxVlIZt2lDsc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ckb8jPci2UEq99KoDFl+NcYaAf1zWScA/5nR9hmO7WA=; b=ZlWKrNqAujSfOgQ4rJDGmHEgs+mkjwONZ3LnLZ0sOMECS/AAUwPfiVQIqYmYn5x1xm UhgdJKa3GvLbHIXCxYmvlFsukeQmY0OG+XD2s/RQUisbi7zg+gNQTre7aHlaCIWG4rWi IxPR/EPhxEM6YO5f/mY8yXqS92N3aLa/BmWVGyaOyToVAVkioEZ1lruPOo1Xbm/QxFP/ vPot4EWsB8/JQTUKCHKUadku/zDEDBHJ1HQLb8NbaL3MCg9lPsq9TzT2dyfPouRUNj81 Uy1DT8sXcZ34QIvlpVsmuUc6/WZxW+dJZKOVQG97gbL07bKNEgOcwqCRXkPeV6skBUo1 yHQA== X-Gm-Message-State: ALoCoQkc4b208SlMneFMvNbXZnDcy1xrRGL3YbYpQqcWBM2xUs2nUh2PSaONRf2hNuBndnlV/6qj MIME-Version: 1.0 X-Received: by 10.107.166.139 with SMTP id p133mr28475699ioe.113.1444044493697; Mon, 05 Oct 2015 04:28:13 -0700 (PDT) Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 04:28:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 13:28:13 +0200 Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1141ef3c1640d0052159cf9f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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:28:15 -0000 --001a1141ef3c1640d0052159cf9f Content-Type: text/plain; charset=UTF-8 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 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 >> >> > --001a1141ef3c1640d0052159cf9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 r= eally "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 stac= k position: easily defined. For many programs, that may be the same value e= ach time: deterministic. Nonetheless, it's considered undefined behavio= ur 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 fr= om other nodes to be a case of undefined behaviour leading to a non-fully-w= orking node.

But these are arguments about the sem= antics 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 f= orks produce a much cleaner outcome, in terms of well defined behavior acro= ss the entire network.

- Replacing an opcode shoul= d not result in undefined behavior.=C2=A0 The non-upgraded behavior is defi= ned and deterministic.

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

- "Hard forks require everyone t= o upgrade and soft forks don't" =C2=A0 Doesn't require tons of= explanation: =C2=A0Non upgraded clients continue working on the network ev= en after the rules are upgraded.

All those correc= tions aside, I do think there has been too much hysteria surrounding hard f= orks.=C2=A0 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 <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
Putti= ng 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=3D[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 cal= culating 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 in to it if they want it. This prioritises availability (in a sense) ov= er correctness.

  • But otherwise, nodes will prioritise correc= tness by default, which is how it should be. This isn't PHP where nonse= nsical code the interpreter doesn't understand just does ...... somethi= ng. 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. <= /i>Otherwise it should be avoided whenever possible.

  • SPV wa= llets do the right thing by default.

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

  • All other s= oftware gets simpler. It's not just SPV wallets. Block explorers, for e= xample, can just add a single line to their opcode map. With a soft fork th= ey 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 scrip= ts differently to new scripts. And they face tricky questions - do they ren= der an opcode as a NOP if the miner who built it was un-upgraded, or do the= y calculate the flag day and change all of them after that? It's just a= n explosion of complexity.
Many people by now have accepted t= hat hard forks are simpler, conceptually cleaner, and prioritise correctnes= s of results over availability of results. I think these arguments are stro= ng.

So let me try addressing the counter-arguments= one more time:
  • Hard forks require everyone to upgrade an= d soft forks don't. I still feel this one has never actually been expla= ined. There is no difference to the level of support required to trigger th= e change. With the suggestion above, if someone can't or won't upgr= ade their full node but can no longer verify the change, they can simply re= start with -scriptchecks=3Dstandardonly and get the soft fork behaviour. Or= they can upgrade and get their old security level back.

  • Ha= rd forks are somehow bad or immoral or can lead to "schisms". Thi= s 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 rea= son to not hold votes.

    But at any rate, they can do that with soft f= orks too: just decide that any output that contains OP_CLTV doesn't mak= e 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 f= ight.


__________________________________________= _____
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--001a1141ef3c1640d0052159cf9f--