path: root/fd/a017d7022c52238aea2c021c6f6c441439a32f

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 657E2C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:55:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4729B615BD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:55:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.299
X-Spam-Level: *
X-Spam-Status: No, score=1.299 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
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 DpvPszElGChd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:55:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
 [IPv6:2607:f8b0:4864:20::52c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 44289606C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 20:55:10 +0000 (UTC)
Received: by mail-pg1-x52c.google.com with SMTP id v14so12457696pgi.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 May 2021 13:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=;
 b=O9wFWnxio2vtq+YrMVvdzvD/byW8BmZef/+W01TREVlq0mnqh4AXWTInE3z/soc2tZ
 x8xqdIVpoJnDobdAA1nmuABAOSaHFHrwgaJC4GJN3/nBNENvG6rRwUYhlTlwmEZC/qYn
 DTenuxshXFi+aJs+aH+f9cRza+DIYzO96COlCd9RpQXA5F+Yf4vrw2nSG7NQtdiSW+Ll
 0tZcfLZNXE/u8LVjPX/3giR1LKKVjA+J6/6TaJGmQqZ3wRtmJUI1KB8jCbT5yHZHKNSC
 pbGaBBtTIOEIKksy7A1oIlyBwYfq2atFrbhWcz9BcTVS/WBUQOiZOsYFp5LvfcZHPlKu
 QUlw==
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:cc:content-transfer-encoding;
 bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=;
 b=Rzpt6dYYvSYVhmg+8AygdHp8U5XoM0ZkO7iK26NaY62sqauBTZszouG9/iqeALQWh5
 UH5pbIBzZhi9kzr7Sgz/kA070rxA2bNnch0q1Pg8L09PSv61wzH6vQhoYTBk0tVnO9h0
 6b+zTF+N3DM5VJnbMd7fiMY2LPk18q/Nm/oAfFS/kC66gKuvRD4BVVdKikSQQBfrKvOK
 DvYXkSkSkz7Ydx2Re+N1rPGf7EkTRTljgHJXqZiV5oLlUl+lV6Brw/h05HnQeEWj51PG
 f2aZv7hIXIjNN6JtVVOfva/n/USm/CFqHfv9+31l7CQ+uFT3FJX9Lccwknwvl1onZKYa
 0O/w==
X-Gm-Message-State: AOAM530ghyG+unCgezsTmzGc8AeDCLsK1zB4v3Y7pKVA7fak2qFavdxC
 fjD0Fxj/b3mFw+lUw0u7OX1SPL9FQzdHHbktyjaekY0=
X-Google-Smtp-Source: ABdhPJzMuddoc9B82SyNFETzK6CVhsK4P58aMwv+yEb1CZa2w0Fsnt7k1EYf4/ryLu34lN8kRP+5Jinvzm7L3OAAt8c=
X-Received: by 2002:a63:416:: with SMTP id 22mr605341pge.363.1621630509542;
 Fri, 21 May 2021 13:55:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
 <20210417114717.GA8079@erisian.com.au>
 <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com>
In-Reply-To: <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 21 May 2021 16:54:57 -0400
Message-ID: <CAJowKg+xG+7T+CcuCJ6cQpuW+BxhL-710YU-kNZVyU_p1XYjDQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 21 May 2021 21:53:42 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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, 21 May 2021 20:55:11 -0000

the original argument was correct: has to be a hard fork.

otherwise there's nothing to prevent a miner with leftover asics from
"tricking" old nodes to following another chain.

a hard fork is a really, really high bar - there would have to be
something very broken to justify it.

quantum-hashing or whatever (proof-of burn of course is as
quantum-safe as the underlying chain is... so it's nice to switch to,
should it be necessary)

On Fri, May 21, 2021 at 4:11 PM Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>
> The way I would think of doing this kind of thing (switching consensus pr=
otocol), which includes switching to a different hash function for proof of=
 work, is to have a transitionary period where both consensus mechanisms ar=
e used to mine. This transitionary period should be long (perhaps years) to=
 give miners time to manage the logistics of switching over. However, becau=
se there would be no trustless mechanism to automatically relate the amount=
 of work (or burn, or whatever) done between the two consensus mechanisms, =
there would need to be some manually determined estimate of equivalence har=
d coded into the software. Eg, if we're talking about a different hash func=
tion, we could define in software that 100 current hashes is about equal to=
 10 hashes using the new algorithm. This could even be set such that its ma=
rginally (but significantly) favorable to use the new hash function, to giv=
e additional incentive to miners to switch. The risk with that is that hard=
ware that processes that new hash function might innovate arbitrarily more =
quickly than the old hash function (which is likely to have somewhat platea=
ued), and this might make the manually estimated equivalence become inaccur=
ate in a way that could significantly reduce the security of the network. a=
 change like this could be fraught with perils if the miners using each mec=
hanism don't end up cooperating to ensure that equivalence is set fairly, a=
nd instead make efforts to attempt to unfairly increase their share.
>
> In any case, the idea is that you'd have a smooth switch over from (block=
s the old mechanism creates / blocks the new mechanism creates) 100%/0% -> =
75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total hashpo=
wer, (eg 95%) the old consensus mechanism could simply be shut off - which =
would give additional incentive for miners to switch sooner rather than lat=
er. However, it would probably be best to make this cut off more like 99% t=
han 95%, since screwing over 5% of the hashpower for a few months is probab=
ly not necessary or ideal. It might actually just be better to have a time-=
based cutoff. Or have the final switch over lock in at 95% with a few month=
s to give the other 5% time to switch over (and if they don't then its on t=
hem).
>
> I would think this could work for switch between any consensus mechanism.=
 However, how to do this in a soft fork is another story. It sounds like it=
s doable from other people's comments.
>
> On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>>
>> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev =
wrote:
>> > 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?
>>
>> It depends what you mean by a "hard fork". By the definition that
>> "the old software will consider the chain followed by new versions of
>> the software as valid" it's a soft fork. But it doesn't maintain the
>> property "old software continues to follow the same chain as new softwar=
e,
>> provided the economic majority has adopted the new software" -- because
>> after the PoW part has dropped its difficulty substantitally, people can
>> easily/cheaply make a new chain that doesn't include proof-of-burn, and
>> has weak proof-of-work that's nevertheless higher than the proof-of-burn
>> chain, so old nodes will switch to it, while new nodes will continue to
>> follow the proof-of-burn chain.
>>
>> So I think that means it needs to be treated as a hard fork: everyone
>> needs to be running the new software by some date to ensure they follow
>> the same chain.
>>
>> (The same argument applies to trying to switch to a different PoW
>> algorithm via a soft fork; I forget who explained this to me)
>>
>> Jeremy wrote:
>> > 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.
>>
>> If it's a soft-fork, you could only ramp up the PoW difficulty by mining
>> more than one block every ten minutes, but presumably the proof-of-burn
>> scheme would have its own way of preventing burners from mining blocks
>> too fast (it was assumption 2).
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev