path: root/d0/288bd2c545d182eff94e95abf3bf673c019934

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7AC6FC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:11:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6279040283
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:11:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Dz7PaRPxoro6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:11:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [IPv6:2a00:1450:4864:20::62b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id EF1C04011A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:11:46 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id n2so32190737ejy.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 13:11:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=lq4F6oKvNKJBNikvoGb+WJTn4CWI8AVM0euyDDXbNyk=;
 b=JCfL+9ZE083qhvQmxY1VL6iCvCq0RFXVLesjTSmWvD1/UGXSQ5sPPcU/0E9BFHox1C
 Vc10hmL/kM5sPAXABHOkhRp/IN3GHuc6U0FwqZdP8SIiic3a/aLAwp3oGccsjspsq2yl
 ta63BcwAfGA7XR1NofBqaSCogQz+HT8FG1GMZFvioOD4UNREAwqps7w+C5IRZpbhJ0dv
 YLsIKKojMBqvl8bjqu9L+1W54Yeb0RMpq3OGv1E1bvwHXYSjPuxAwLopBjA8/70MKh7h
 rpcgUuFPujkFNtoYegOBvPz3eW039eiTJCjciwcNd08W54+1/hqMRStJVLT7fP5TBNyJ
 5cIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=lq4F6oKvNKJBNikvoGb+WJTn4CWI8AVM0euyDDXbNyk=;
 b=Hg15NJw+6Mj4fttxIRcMwlTr/8gcJKBLmmnlr8vpoymPcDr7tx1uWbZePZXwC3rpdU
 /NEbZ3FtF6xKCgKQeuPBVKAQimwTeybjrBBO7S4o7XkvQaGKmsAMAnqU/b2CqbfmOceK
 L9vBHEweLeVl+Tc6YrcnqKy3uvSpFK3VGvXbI2RGP+fy8i4MiD5k3jOWZZLMLASVFn4/
 ZEF6XfCK97qoNHW9938I2GvF/J8h/cXkzY3WaFHuwVu2O/GJVeLggYUgAXnFclLlHgMI
 G+rqhCrcIWXswRwmk3uCrI2wecAncobt/rpHxUxdoF9D64QnkpnXSNFUKiBvIi7Z0Tp9
 Mgaw==
X-Gm-Message-State: AOAM5308vbcju3aa5KpK03zfccGHBIfmXEqKqC+VhELoBFoIKCHlDtpE
 a222SQm31ViIQ78Ee18SaCClb7kcjEWckiCIZm5a1tA81dE=
X-Google-Smtp-Source: ABdhPJzm9ZTGzPNTinjBxNrGsSXT+LqmDC4EaTVf6r5KsFuQ1MAu8dShboShP/bfSb1eV0XOZ8XAU+D/BBhl9xbqzek=
X-Received: by 2002:a17:906:fc4:: with SMTP id
 c4mr12548178ejk.111.1621627905104; 
 Fri, 21 May 2021 13:11:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
 <20210417114717.GA8079@erisian.com.au>
In-Reply-To: <20210417114717.GA8079@erisian.com.au>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 21 May 2021 10:11:27 -1000
Message-ID: <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003df7fe05c2dcab0e"
X-Mailman-Approved-At: Fri, 21 May 2021 21:53:42 +0000
Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without
 a hard fork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 21 May 2021 20:11:48 -0000

--0000000000003df7fe05c2dcab0e
Content-Type: text/plain; charset="UTF-8"

The way I would think of doing this kind of thing (switching consensus
protocol), which includes switching to a different hash function for proof
of work, is to have a transitionary period where both consensus mechanisms
are used to mine. This transitionary period should be long (perhaps years)
to give miners time to manage the logistics of switching over. However,
because there would be no trustless mechanism to automatically relate the
amount of work (or burn, or whatever) done between the two consensus
mechanisms, there would need to be some manually determined estimate of
equivalence hard coded into the software. Eg, if we're talking about a
different hash function, we could define in software that 100 current
hashes is about equal to 10 hashes using the new algorithm. This could even
be set such that its marginally (but significantly) favorable to use the
new hash function, to give additional incentive to miners to switch. The
risk with that is that hardware that processes that new hash function might
innovate arbitrarily more quickly than the old hash function (which is
likely to have somewhat plateaued), and this might make the manually
estimated equivalence become inaccurate in a way that could significantly
reduce the security of the network. a change like this could be fraught
with perils if the miners using each mechanism don't end up cooperating to
ensure that equivalence is set fairly, and instead make efforts to attempt
to unfairly increase their share.

In any case, the idea is that you'd have a smooth switch over from (blocks
the old mechanism creates / blocks the new mechanism creates) 100%/0% ->
75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total
hashpower, (eg 95%) the old consensus mechanism could simply be shut off -
which would give additional incentive for miners to switch sooner rather
than later. However, it would probably be best to make this cut off more
like 99% than 95%, since screwing over 5% of the hashpower for a few months
is probably not necessary or ideal. It might actually just be better to
have a time-based cutoff. Or have the final switch over lock in at 95% with
a few months to give the other 5% time to switch over (and if they don't
then its on them).

I would think this could work for switch between any consensus mechanism.
However, how to do this in a soft fork is another story. It sounds like its
doable from other people's comments.

On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > The transition *could* look like this:
> >  - validating nodes begin to require proof-of-burn, in addition to
> > proof-of-work (soft fork)
> >  - the extra expense makes it more expensive for miners, so POW slowly
> drops
> >  - on a predefined schedule, POB required is increased to 100% of the
> > "required work" to mine
> > Given all of that, am I correct in thinking that a hard fork would not
> > be necessary?
>
> It depends what you mean by a "hard fork". By the definition that
> "the old software will consider the chain followed by new versions of
> the software as valid" it's a soft fork. But it doesn't maintain the
> property "old software continues to follow the same chain as new software,
> provided the economic majority has adopted the new software" -- because
> after the PoW part has dropped its difficulty substantitally, people can
> easily/cheaply make a new chain that doesn't include proof-of-burn, and
> has weak proof-of-work that's nevertheless higher than the proof-of-burn
> chain, so old nodes will switch to it, while new nodes will continue to
> follow the proof-of-burn chain.
>
> So I think that means it needs to be treated as a hard fork: everyone
> needs to be running the new software by some date to ensure they follow
> the same chain.
>
> (The same argument applies to trying to switch to a different PoW
> algorithm via a soft fork; I forget who explained this to me)
>
> Jeremy wrote:
> > I think you need to hard deprecate the PoW for this to work, otherwise
> > all old miners are like "toxic waste".
> >
> > Imagine one miner turns on a S9 and then ramps up difficulty for
> > everyone else.
>
> If it's a soft-fork, you could only ramp up the PoW difficulty by mining
> more than one block every ten minutes, but presumably the proof-of-burn
> scheme would have its own way of preventing burners from mining blocks
> too fast (it was assumption 2).
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000003df7fe05c2dcab0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The way I would think of doing this kind of thing (switchi=
ng consensus protocol), which includes switching to a different hash functi=
on for proof of work, is to have a transitionary period where both consensu=
s mechanisms are used to mine. This transitionary period should be long (pe=
rhaps years) to give miners time to manage the logistics of switching over.=
 However, because there would be no trustless mechanism to automatically re=
late the amount of work (or burn, or whatever) done between the two consens=
us mechanisms, there would need to be some manually determined estimate of =
equivalence hard coded into the software. Eg, if we&#39;re talking about a =
different hash function, we could define in software that 100 current hashe=
s is about equal to 10 hashes using the new algorithm. This could even be s=
et such that its marginally (but significantly) favorable to use the new ha=
sh function, to give additional incentive to miners to switch. The risk wit=
h that is that hardware that processes that new hash function might innovat=
e arbitrarily more quickly than the old hash function (which is likely to h=
ave somewhat plateaued), and this might make the manually estimated equival=
ence become inaccurate in a way that could significantly reduce the securit=
y of the network. a change like this could be fraught with perils if the mi=
ners using each mechanism don&#39;t end up cooperating to ensure that equiv=
alence is set fairly, and instead make efforts to attempt to unfairly incre=
ase their share.=C2=A0<div><br></div><div>In any case, the idea is that you=
&#39;d have a smooth switch over from (blocks the old mechanism creates / b=
locks the new mechanism creates) 100%/0% -&gt; 75%/25% -&gt; 50/50 -&gt; ev=
entually 0%/100%. Or at some fraction of total hashpower, (eg 95%) the old =
consensus mechanism could simply be shut off - which would give additional =
incentive for miners to switch sooner rather than later. However, it would =
probably be best to make this cut off more like 99% than 95%, since screwin=
g over 5% of the hashpower for a few months is probably not necessary or id=
eal. It might actually just be better to have a time-based cutoff. Or have =
the final switch over lock in at 95% with a few months to give the other 5%=
 time to switch over (and if they don&#39;t then its on them).=C2=A0</div><=
div><br></div><div>I would think this could work for switch between any con=
sensus mechanism. However, how to do this in a soft fork is another story. =
It sounds like its doable from other people&#39;s comments.=C2=A0</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
at, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-d=
ev wrote:<br>
&gt; The transition *could* look like this:<br>
&gt;=C2=A0 - validating nodes begin to require proof-of-burn, in addition t=
o<br>
&gt; proof-of-work (soft fork)<br>
&gt;=C2=A0 - the extra expense makes it more expensive for miners, so POW s=
lowly drops<br>
&gt;=C2=A0 - on a predefined schedule, POB required is increased to 100% of=
 the<br>
&gt; &quot;required work&quot; to mine<br>
&gt; Given all of that, am I correct in thinking that a hard fork would not=
<br>
&gt; be necessary?<br>
<br>
It depends what you mean by a &quot;hard fork&quot;. By the definition that=
<br>
&quot;the old software will consider the chain followed by new versions of<=
br>
the software as valid&quot; it&#39;s a soft fork. But it doesn&#39;t mainta=
in the<br>
property &quot;old software continues to follow the same chain as new softw=
are,<br>
provided the economic majority has adopted the new software&quot; -- becaus=
e<br>
after the PoW part has dropped its difficulty substantitally, people can<br=
>
easily/cheaply make a new chain that doesn&#39;t include proof-of-burn, and=
<br>
has weak proof-of-work that&#39;s nevertheless higher than the proof-of-bur=
n<br>
chain, so old nodes will switch to it, while new nodes will continue to<br>
follow the proof-of-burn chain.<br>
<br>
So I think that means it needs to be treated as a hard fork: everyone<br>
needs to be running the new software by some date to ensure they follow<br>
the same chain.<br>
<br>
(The same argument applies to trying to switch to a different PoW<br>
algorithm via a soft fork; I forget who explained this to me)<br>
<br>
Jeremy wrote:<br>
&gt; I think you need to hard deprecate the PoW for this to work, otherwise=
<br>
&gt; all old miners are like &quot;toxic waste&quot;.<br>
&gt;<br>
&gt; Imagine one miner turns on a S9 and then ramps up difficulty for<br>
&gt; everyone else.<br>
<br>
If it&#39;s a soft-fork, you could only ramp up the PoW difficulty by minin=
g<br>
more than one block every ten minutes, but presumably the proof-of-burn<br>
scheme would have its own way of preventing burners from mining blocks<br>
too fast (it was assumption 2).<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<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>
</blockquote></div>

--0000000000003df7fe05c2dcab0e--