From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D136C0019 for ; Sat, 17 Apr 2021 11:20:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8BAF584C0F for ; Sat, 17 Apr 2021 11:20:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqoScTK2AYBg for ; Sat, 17 Apr 2021 11:20:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by smtp1.osuosl.org (Postfix) with ESMTPS id 463358355F for ; Sat, 17 Apr 2021 11:20:00 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id g5so39113787ejx.0 for ; Sat, 17 Apr 2021 04:20:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fRGPvS58NQaASK9CTvFKCOlEFxq45Tb70sG2ZhrIRmI=; b=sGqE8OkFexuCY8Abyh/O9RZRF8zQDLUYyu2tF3ne6SwRvT2czMHZugRsra/mCneLGV hSJsg8kAX8/Pe/PqT3h/tS0W1IZlB5cwpb7bjla93/oPCeHnxFUBZLX+bj2Z6Ezaratf LShRA6poFueaKoqSEjEeRMu1syOYXj1cj9+ICtWt+ecxcxnUUddVerEEQzpS21lcvsnV lTMKtav5I5oSX539Mu4gsoIZ7MjlrjISi7TCFTzh2HQuLXhgH9P/1t3c9URSUtIZ3+8x wcU9ERzMNuKY6QWXnigKDZZmbOxUBDk4sgd3lz9sTfGB21EmJr1hsFtPGJ912JBkhYAk ddiA== X-Gm-Message-State: AOAM5322JvpnbjFXV/OA0r+mgpq7ptdpEI6cYWnjhTlvjqY9/aqgIe+v 3mwfPTACLy+5s0aLE3rQ9hZ+2ngrOmsqEDO1dazdTSXzn7w1nHI9dq8= X-Google-Smtp-Source: ABdhPJwg5HMUTmIkAJOJqwugDKIUgAaudyFcisA27tuqhsS8m/QQ9kaaXHxh36ieTtu57Du5hYFZ68APTZ6Z5NGwZWI= X-Received: by 2002:a17:906:278e:: with SMTP id j14mr12655519ejc.224.1618658399262; Sat, 17 Apr 2021 04:19:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Devrandom Date: Sat, 17 Apr 2021 13:19:46 +0200 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e6b3d905c0294600" X-Mailman-Approved-At: Sat, 17 Apr 2021 11:43:40 +0000 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: Sat, 17 Apr 2021 11:20:05 -0000 --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
Hi Erik,

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


On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin= -dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
Not sure of the best place to workshop ideas, s= o 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.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e6b3d905c0294600--