path: root/98/fa2c58168849d487722927a4619c7f7e38cf0f

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 76C38C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:24:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5DCBD60894
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:24:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QObdc6ujaFG2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:24:46 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3FC1A60685
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 21:24:46 +0000 (UTC)
Received: from mail-io1-f51.google.com (mail-io1-f51.google.com
 [209.85.166.51]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13GLOgBZ029095
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 16 Apr 2021 17:24:43 -0400
Received: by mail-io1-f51.google.com with SMTP id a11so26954374ioo.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 14:24:43 -0700 (PDT)
X-Gm-Message-State: AOAM533InxW4xdaLhyOwhO++KXz1cpWbDH//pCQAXf1uMk5dWn3oKh+6
 +PDOPWF2TC8ox1CEMcVHd9Skey7xb2JKQBSAi28=
X-Google-Smtp-Source: ABdhPJzF6XrTZADFPYI74YxSokxFiNPmVAPQpLSrNPvlowzuq/8pvpDYxF5lrNpwR1gIZiTl+9oeiezuMCEDMDWybTI=
X-Received: by 2002:a02:5d82:: with SMTP id w124mr5943572jaa.21.1618608282711; 
 Fri, 16 Apr 2021 14:24:42 -0700 (PDT)
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
X-Gmail-Original-Message-ID: <CAD5xwhjWHsEZjTKJA3e+mwKZxuXf043jKvqDG4_hYRhd1jR07g@mail.gmail.com>
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.
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, 16 Apr 2021 21:24:50 -0000

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