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