📅 Original date posted:2021-04-16 📝 Original message:> I think you need to hard ...

Erik Aronesty [ARCHIVE] /

npub1y22…taj0

2023-06-07 22:51:51

in reply to nevent1q…kwgg

📅 Original date posted:2021-04-16
📝 Original message:> 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

Author Public Key

npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0

Show more details

Published at

2023-06-07 22:51:51

Kind type

1 Short Text Note

Event JSON

{ "id": "15e79b6499657cdf84dddbf7e4824dbb7f2e43d6d8e3a1f37c56dc6ba4935850", "pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa", "created_at": 1686178311, "kind": 1, "tags": [ [ "e", "7c4fe2af4cefce813173b1793a8152b08d8889a3501dbd351d8c3d84b7b6f498", "", "root" ], [ "e", "e7b868eb3d4990ea5eac91a3451aac784ce96ad4485ac09112da7b5891c8623f", "", "reply" ], [ "p", "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4" ] ], "content": "📅 Original date posted:2021-04-16\n📝 Original message:\u003e I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like \"toxic waste\".\n\nwhat would be the incentive? a POB would be required on every block\n(and would be lost if not used). so any miner doing this would just\nbe doing \"extra work\" and strictly losing money over a miner that\ndoesn't. a 99% reduction would be more than enough tho.\n\nOn Fri, Apr 16, 2021 at 5:24 PM Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\u003e\n\u003e I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like \"toxic waste\".\n\u003e\n\u003e Imagine one miner turns on a S9 and then ramps up difficulty for everyone else.\n\u003e\n\u003e On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Not sure of the best place to workshop ideas, so please take this with\n\u003e\u003e a grain of salt.\n\u003e\u003e\n\u003e\u003e Starting with 3 assumptions:\n\u003e\u003e\n\u003e\u003e - assume that there exists a proof-of-burn that, for Bitcoin's\n\u003e\u003e purposes, accurately-enough models the investment in and development\n\u003e\u003e of ASICs to maintain miner incentive.\n\u003e\u003e - assume the resulting timing problem \"how much burn is enough to keep\n\u003e\u003e blocks 10 minutes apart and what does that even mean\" is also...\n\u003e\u003e perfectly solvable\n\u003e\u003e - assume \"everyone unanimously loves this idea\"\n\u003e\u003e\n\u003e\u003e The transition *could* look like this:\n\u003e\u003e\n\u003e\u003e - validating nodes begin to require proof-of-burn, in addition to\n\u003e\u003e proof-of-work (soft fork)\n\u003e\u003e - the extra expense makes it more expensive for miners, so POW slowly drops\n\u003e\u003e - on a predefined schedule, POB required is increased to 100% of the\n\u003e\u003e \"required work\" to mine\n\u003e\u003e\n\u003e\u003e Given all of that, am I correct in thinking that a hard fork would not\n\u003e\u003e be necessary?\n\u003e\u003e\n\u003e\u003e IE: We could transition to another \"required proof\" - such as a\n\u003e\u003e quantum POW or a POB (above) or something else .... in a back-compat\n\u003e\u003e way (existing nodes not aware of the rules would continue to\n\u003e\u003e validate).\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev", "sig": "c9fcb89b82859c712d42cf708fc1bfe28c1c132b42650f937344dbe95ce208ebe42a349acbc52f5088e3aaf35ed78bfd807a80b5af7ab2e5f0fc7bd66a3633d6" }