From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 76C38C000A for ; 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 ; 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 ; 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 ; 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 ; Fri, 16 Apr 2021 17:24:43 -0400 Received: by mail-io1-f51.google.com with SMTP id a11so26954374ioo.0 for ; 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: In-Reply-To: From: Jeremy Date: Fri, 16 Apr 2021 14:24:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
I think you need to hard deprecate the PoW for this to wo= rk, otherwise all old miners are like "toxic waste".

Imagine one miner turns on a S9 and then r= amps up difficulty for everyone else.

On Fri, Apr 16, 2021, 2:08 PM Er= ik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Not sure of the best place to workshop idea= s, 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"=C2=A0 is also...=
perfectly solvable
- assume "everyone unanimously loves this idea"

The transition *could* look like this:

=C2=A0- validating nodes begin to require proof-of-burn, in addition to
proof-of-work (soft fork)
=C2=A0- the extra expense makes it more expensive for miners, so POW slowly= drops
=C2=A0- on a predefined schedule, POB required is increased to 100% of the<= br> "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 ....=C2=A0 in a back-compat<= br> way (existing nodes not aware of the rules would continue to
validate).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000b8bca205c01d9bc7--