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

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

[Erik Aronesty]

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).

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

[Jeremy]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2322 bytes --]

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

[Erik Aronesty]

> I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste".

what would be the incentive?   a POB would be required on every block
(and would be lost if not used).   so any miner doing this would just
be doing "extra work" and strictly losing money over a miner that
doesn't.   a 99% reduction would be more than enough tho.

On Fri, Apr 16, 2021 at 5:24 PM Jeremy <jlrubin@mit.edu> 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.
>
> 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

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

[Devrandom]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2442 bytes --]

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

[Anthony Towns]

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

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

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 4737 bytes --]

The way I would think of doing this kind of thing (switching consensus
protocol), which includes switching to a different hash function for proof
of work, is to have a transitionary period where both consensus mechanisms
are used to mine. This transitionary period should be long (perhaps years)
to give miners time to manage the logistics of switching over. However,
because 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 hard coded into the software. Eg, if we're talking about a
different hash function, 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 marginally (but significantly) favorable to use the
new hash function, to give additional incentive to miners to switch. The
risk with that is that hardware that processes that new hash function might
innovate arbitrarily more quickly than the old hash function (which is
likely to have somewhat plateaued), and this might make the manually
estimated equivalence become inaccurate 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 mechanism don't end up cooperating to
ensure that equivalence is set fairly, and 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 (blocks
the old mechanism creates / blocks the new mechanism creates) 100%/0% ->
75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total
hashpower, (eg 95%) the old consensus mechanism could simply be shut off -
which would give additional incentive for miners to switch sooner rather
than later. However, it would probably be best to make this cut off more
like 99% than 95%, since screwing over 5% of the hashpower for a few months
is probably 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 months to give the other 5% time to switch over (and if they don't
then its on them).

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 its
doable from other people's comments.

On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@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 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5555 bytes --]

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

[Erik Aronesty]

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 protocol), which includes switching to a different hash function for proof of work, is to have a transitionary period where both consensus mechanisms are used to mine. This transitionary period should be long (perhaps years) to give miners time to manage the logistics of switching over. However, because 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 hard coded into the software. Eg, if we're talking about a different hash function, 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 marginally (but significantly) favorable to use the new hash function, to give additional incentive to miners to switch. The risk with that is that hardware that processes that new hash function might innovate arbitrarily more quickly than the old hash function (which is likely to have somewhat plateaued), and this might make the manually estimated equivalence become inaccurate 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 mechanism don't end up cooperating to ensure that equivalence is set fairly, and 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 (blocks the old mechanism creates / blocks the new mechanism creates) 100%/0% -> 75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total hashpower, (eg 95%) the old consensus mechanism could simply be shut off - which would give additional incentive for miners to switch sooner rather than later. However, it would probably be best to make this cut off more like 99% than 95%, since screwing over 5% of the hashpower for a few months is probably 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 months to give the other 5% time to switch over (and if they don't then its on them).
>
> 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 its doable from other people's comments.
>
> On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <bitcoin-dev@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 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[vjudeu]

Yes, transition from Proof of Work to Proof of Something Else is possible in a soft-fork way. All that is needed is getting miners and users support. Then, Proof of Work difficulty should drop to one, and the rest would be solved by Proof of Something Else. Old miners still could use ASIC miners to produce blocks with higher Proof of Work, but then their blocks would be rejected. Currently, you can also make a block with enormously low hash, but if this block would contain two transactions sending the same coins to two different places, it would be rejected, no matter how low that hash would be. As long as miners would produce enough Proof of Something Else and as long as most nodes would use upgraded software, it should be resistant to such attacks.

So, technically speaking, it is possible. The most difficult part is getting miners and users supporting it.

On 2021-04-16 23:47:44 user Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste".
> 
> what would be the incentive?   a POB would be required on every block
> (and would be lost if not used).   so any miner doing this would just
> be doing "extra work" and strictly losing money over a miner that
> doesn't.   a 99% reduction would be more than enough tho.
> 
> On Fri, Apr 16, 2021 at 5:24 PM Jeremy <jlrubin@mit.edu> 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.
> >
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>