Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

[Anthony Towns <aj@erisian.com.au>]

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 software,
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