Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-17 📝 Original message:Hi Erik, Here's a scheme I ...

📅 Original date posted:2021-04-17
📝 Original message: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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/1d1d8922/attachment.html>;