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 "toxic waste".<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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= undation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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's<br> purposes, accurately-enough models the investment in and development<br> of ASICs to maintain miner incentive.<br> - assume the resulting timing problem "how much burn is enough to keep= <br> blocks 10 minutes apart and what does that even mean"=C2=A0 is also...= <br> perfectly solvable<br> - assume "everyone unanimously loves this idea"<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> "required work" 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 "required proof" - 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--