MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
In-Reply-To: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Sat, 17 Apr 2021 13:19:46 +0200
Message-ID: <CAB0O3SXT7k42Q=DH_PxVzV4W3HCEajfFqHuNW-YyEfP6W=zhfg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e6b3d905c0294600"
Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without
 a hard fork.
Precedence: list

--000000000000e6b3d905c0294600
Content-Type: text/plain; charset="UTF-8"

Hi Erik,

Here's a scheme I posted here a few years ago, which smoothly transitions
using geometric mean chain weight / difficulty:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html

On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not sure of the best place to workshop ideas, so please take this with
> a grain of salt.
>
> Starting with 3 assumptions:
>
> - assume that there exists a proof-of-burn that, for Bitcoin's
> purposes, accurately-enough models the investment in and development
> of ASICs to maintain miner incentive.
> - assume the resulting timing problem "how much burn is enough to keep
> blocks 10 minutes apart and what does that even mean"  is also...
> perfectly solvable
> - assume "everyone unanimously loves this idea"
>
> 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?
>
> IE: We could transition to another "required proof" - such as a
> quantum POW or a POB (above) or something else ....  in a back-compat
> way (existing nodes not aware of the rules would continue to
> validate).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi Erik,</div><div><br></div><div>Here&#39;s a scheme=
 I posted here a few years ago, which smoothly transitions using geometric =
mean chain weight / difficulty:</div><div><br></div><div><a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/0152=
36.html</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Not sure of the best place to workshop ideas, s=
o please take this with<br>
a grain of salt.<br>
<br>
Starting with 3 assumptions:<br>
<br>
- assume that there exists a proof-of-burn that, for Bitcoin&#39;s<br>
purposes, accurately-enough models the investment in and development<br>
of ASICs to maintain miner incentive.<br>
- assume the resulting timing problem &quot;how much burn is enough to keep=
<br>
blocks 10 minutes apart and what does that even mean&quot;=C2=A0 is also...=
<br>
perfectly solvable<br>
- assume &quot;everyone unanimously loves this idea&quot;<br>
<br>
The transition *could* look like this:<br>
<br>
=C2=A0- validating nodes begin to require proof-of-burn, in addition to<br>
proof-of-work (soft fork)<br>
=C2=A0- the extra expense makes it more expensive for miners, so POW slowly=
 drops<br>
=C2=A0- on a predefined schedule, POB required is increased to 100% of the<=
br>
&quot;required work&quot; to mine<br>
<br>
Given all of that, am I correct in thinking that a hard fork would not<br>
be necessary?<br>
<br>
IE: We could transition to another &quot;required proof&quot; - such as a<b=
r>
quantum POW or a POB (above) or something else ....=C2=A0 in a back-compat<=
br>
way (existing nodes not aware of the rules would continue to<br>
validate).<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>

--000000000000e6b3d905c0294600--