📅 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>;
Devrandom [ARCHIVE] /
npub1j0…w9k8n
2023-06-07 22:51:52
in reply to nevent1q…ev2k
Author Public Key
npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8nPublished at
2023-06-07 22:51:52Event JSON
{
"id": "087298f3a4b4fc32be5c873c4ff1253adb28b006823e9f8525c1e4db9381581f",
"pubkey": "93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85",
"created_at": 1686178312,
"kind": 1,
"tags": [
[
"e",
"7c4fe2af4cefce813173b1793a8152b08d8889a3501dbd351d8c3d84b7b6f498",
"",
"root"
],
[
"e",
"759f22e181cc5e7266fac7295ab9a2e4913762c9e4f7fde0e991f8902507e424",
"",
"reply"
],
[
"p",
"d984ab5821a89fe36a833387a442d06971374de052be63faabd45b7d739f813c"
]
],
"content": "📅 Original date posted:2021-04-17\n📝 Original message:Hi Erik,\n\nHere's a scheme I posted here a few years ago, which smoothly transitions\nusing geometric mean chain weight / difficulty:\n\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html\n\nOn Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Not sure of the best place to workshop ideas, so please take this with\n\u003e a grain of salt.\n\u003e\n\u003e Starting with 3 assumptions:\n\u003e\n\u003e - assume that there exists a proof-of-burn that, for Bitcoin's\n\u003e purposes, accurately-enough models the investment in and development\n\u003e of ASICs to maintain miner incentive.\n\u003e - assume the resulting timing problem \"how much burn is enough to keep\n\u003e blocks 10 minutes apart and what does that even mean\" is also...\n\u003e perfectly solvable\n\u003e - assume \"everyone unanimously loves this idea\"\n\u003e\n\u003e The transition *could* look like this:\n\u003e\n\u003e - validating nodes begin to require proof-of-burn, in addition to\n\u003e proof-of-work (soft fork)\n\u003e - the extra expense makes it more expensive for miners, so POW slowly\n\u003e drops\n\u003e - on a predefined schedule, POB required is increased to 100% of the\n\u003e \"required work\" to mine\n\u003e\n\u003e Given all of that, am I correct in thinking that a hard fork would not\n\u003e be necessary?\n\u003e\n\u003e IE: We could transition to another \"required proof\" - such as a\n\u003e quantum POW or a POB (above) or something else .... in a back-compat\n\u003e way (existing nodes not aware of the rules would continue to\n\u003e validate).\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/1d1d8922/attachment.html\u003e",
"sig": "55c81338a756ee7e6ca501226ce37eba65414f003e87b270506f1fb6709d58f309562fe1c83844bfe8de297798cd85466136959db38eba2aa0801540704c85d0"
}