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

Erik Aronesty erik at q32.com
Fri Apr 16 21:47:44 UTC 2021


> 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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


More information about the bitcoin-dev mailing list