MIME-Version: 1.0
In-Reply-To: <CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@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>
Date: Mon, 5 Oct 2015 07:23:39 -0400
Message-ID: <CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=e89a8f647253c8fb71052159be25
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--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

<div dir=3D"ltr"><br><div>- It is true that hard forks produce a much clean=
er outcome, in terms of well defined behavior across the entire network.</d=
iv><div><br></div><div>- Replacing an opcode should not result in undefined=
 behavior.=C2=A0 The non-upgraded behavior is defined and deterministic.</d=
iv><div><br></div><div>- IsStandard remains an assistant.=C2=A0 Miners may =
mine non-standard transactions.</div><div><br></div><div>- &quot;<span styl=
e=3D"font-size:13px">Hard forks require everyone to upgrade and soft forks =
don&#39;t&quot; =C2=A0 Doesn&#39;t require tons of explanation: =C2=A0Non u=
pgraded clients continue working on the network even after the rules are up=
graded.</span></div><div><span style=3D"font-size:13px"><br></span></div><d=
iv><span style=3D"font-size:13px">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></div><div><=
span style=3D"font-size:13px"><br></span></div><div><span style=3D"font-siz=
e:13px"><br></span></div><div><span style=3D"font-size:13px"><br></span></d=
iv><div><span style=3D"font-size:13px"><br></span></div><div><br></div><div=
><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>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&#39;s in the=
 BIP. How about the following:</div><div><br></div><div>A new flag is intro=
duced to Core, --scriptchecks=3D[all,standardonly,none]. The default is all=
. When set to &quot;standardonly&quot;, non-standard scripts are not checke=
d 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 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</div><div><br></div><div>This has the following advantages:</div><di=
v><ul><li>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.<br><br></li><li>But otherwise, nodes will prioritise correctness=
 by default, which is how it should be. This isn&#39;t PHP where nonsensica=
l code the interpreter doesn&#39;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 <i>if you opted into getting it. </i>Ot=
herwise it should be avoided whenever possible.<br><br></li><li>SPV wallets=
 do the right thing by default.<br><br></li><li>IsStandard doesn&#39;t sile=
ntly become a part of the consensus rules.<br><br></li><li>All other softwa=
re gets simpler. It&#39;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&#39;s just an exp=
losion of complexity.</li></ul><div>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.</=
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 and sof=
t forks don&#39;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&#39;t or won&#39;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.<br><br></li><li>Hard fo=
rks are somehow bad or immoral or can lead to &quot;schisms&quot;. 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&#39;s not a reason t=
o not hold votes.<br><br>But at any rate, they can do that with soft forks =
too: just decide that any output that contains OP_CLTV doesn&#39;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.=
<br></li></ul><div><br></div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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></blockquote></div><br></div>

--e89a8f647253c8fb71052159be25--