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
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.
Precedence: list

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