MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
In-Reply-To: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 16 Apr 2021 14:24:30 -0700
Message-ID: <CAD5xwhjWHsEZjTKJA3e+mwKZxuXf043jKvqDG4_hYRhd1jR07g@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b8bca205c01d9bc7"
Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without
 a hard fork.
Precedence: list

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

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.

On Fri, Apr 16, 2021, 2: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
>

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

<div dir=3D"auto">I think you need to hard deprecate the PoW for this to wo=
rk, otherwise all old miners are like &quot;toxic waste&quot;.<div dir=3D"a=
uto"><br></div><div dir=3D"auto">Imagine one miner turns on a S9 and then r=
amps up difficulty for everyone else.</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021, 2:08 PM Er=
ik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">Not sure of the best place to workshop idea=
s, so 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" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000b8bca205c01d9bc7--