path: root/47/347bc7bb07e05c5faf9d2a2fb534b4d78476a9

Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2A8EA1226
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 11:28:14 +0000 (UTC)
Received: by iow1 with SMTP id 1so144722780iow.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
	<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
	<CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
	<CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
Date: Mon, 5 Oct 2015 13:28:13 +0200
Message-ID: <CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Jeff Garzik <jgarzik@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
>>
>>
>

--001a1141ef3c1640d0052159cf9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, let&#39;s agree to disagree on these two things:<div=
><br></div><div>- I define &quot;working&quot; for a full node as verifying=
 everything; if a node starts skipping bits then I&#39;d say it&#39;s not r=
eally &quot;working&quot; according to its original design goals</div><div>=
<br></div><div>- 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&#39;s considered undefined behavio=
ur by the C specification and programmers that rely on it can easily create=
 security holes.</div><div><br></div><div>In the same way, I&#39;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.</div><div><br></div><div>But these are arguments about the sem=
antics of words. I think we both know what each other is getting at.<br><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct 5, 2015 =
at 1:23 PM, Jeff Garzik <span dir=3D"ltr">&lt;<a href=3D"mailto:jgarzik@gma=
il.com" target=3D"_blank">jgarzik@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><br><div>- It is true that hard f=
orks produce a much cleaner outcome, in terms of well defined behavior acro=
ss the entire network.</div><div><br></div><div>- Replacing an opcode shoul=
d not result in undefined behavior.=C2=A0 The non-upgraded behavior is defi=
ned and deterministic.</div><div><br></div><div>- IsStandard remains an ass=
istant.=C2=A0 Miners may mine non-standard transactions.</div><div><br></di=
v><div>- &quot;<span style=3D"font-size:13px">Hard forks require everyone t=
o upgrade and soft forks don&#39;t&quot; =C2=A0 Doesn&#39;t require tons of=
 explanation: =C2=A0Non upgraded clients continue working on the network ev=
en after the rules are upgraded.</span></div><div><span style=3D"font-size:=
13px"><br></span></div><div><span style=3D"font-size:13px">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.</span></div><div><span style=3D"font-size:13px"><br></span></div><di=
v><span style=3D"font-size:13px"><br></span></div><div><span style=3D"font-=
size:13px"><br></span></div><div><span style=3D"font-size:13px"><br></span>=
</div><div><br></div><div><br></div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Oct =
5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div>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&#39;s =
in the BIP. How about the following:</div><div><br></div><div>A new flag is=
 introduced to Core, --scriptchecks=3D[all,standardonly,none]. The default =
is all. When set to &quot;standardonly&quot;, non-standard scripts are not =
checked but others are. This is similar to the behaviour during a soft fork=
. In &quot;none&quot; 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</div><div><br></div><div>This has the following advantages:</di=
v><div><ul><li>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.<br><br></li><li>But otherwise, nodes will prioritise correc=
tness by default, which is how it should be. This isn&#39;t PHP where nonse=
nsical code the interpreter doesn&#39;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 <i>if you opted into getting it. <=
/i>Otherwise it should be avoided whenever possible.<br><br></li><li>SPV wa=
llets do the right thing by default.<br><br></li><li>IsStandard doesn&#39;t=
 silently become a part of the consensus rules.<br><br></li><li>All other s=
oftware gets simpler. It&#39;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&#39;s just a=
n explosion of complexity.</li></ul><div>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.</div><div><br></div><div>So let me try addressing the counter-arguments=
 one more time:</div><div><ul><li>Hard forks require everyone to upgrade an=
d soft forks don&#39;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&#39;t or won&#39;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.<br><br></li><li>Ha=
rd forks are somehow bad or immoral or can lead to &quot;schisms&quot;. 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&#39;s not a rea=
son to not hold votes.<br><br>But at any rate, they can do that with soft f=
orks too: just decide that any output that contains OP_CLTV doesn&#39;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.<br></li></ul><div><br></div></div></div></div>
<br></div></div><span class=3D"">__________________________________________=
_____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>

--001a1141ef3c1640d0052159cf9f--