From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Keagan McClelland <keagan.mcclelland@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Michael Dubrovsky <mike@powx•org>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Date: Tue, 18 May 2021 06:46:58 +0000 [thread overview]
Message-ID: <ZFVpoVGcwTTpDDlAXLn8cCwic0l40b3DmE_UoKIv4IvmFDDX9W2F1sRHYwido1X7OK0fX1QAx5J8I5DokM4pcIKziNAgAwc6emrHulfbRE8=@protonmail.com> (raw)
In-Reply-To: <CALeFGL3U2yb2WVz4rwcBqO25kd0B7NcgrN4iMjDyackrTTegpw@mail.gmail.com>
> A few things jump out at me as I read this proposal
>
> First, deriving the hardness from capex as opposed to opex switches the privilege from those who have cheap electricity to those who have access to chip manufacturers/foundries. While this is similarly the case for Bitcoin ASICS today, the longevity of the PoW algorithm has led to a better distribution of knowledge and capital goods required to create ASICS. The creation of a new PoW of any kind, hurts this dimension of decentralization as we would have to start over from scratch on the best way to build, distribute, and operate these new pieces of hardware at scale. While I have not combed over the PoW proposed here in fine detail, the more complicated the algorithm is, the more it privileges those with specific knowledge about it and the manufacturing process.
>
> The competitive nature of Bitcoin mining is such that miners will be willing to spend up to their expected mining reward in their operating costs to continue to mine. Let's suppose that this new PoW was adopted, miners will continue to buy these chips in ever increasing quantities, turning the aforementioned CAPEX into a de facto OPEX. This has a few consequences. First it just pushes the energy consumption upstream to the chip manufacturing process, rather than eliminating it. And it may trade some marginal amount of the energy consumption for the set of resources it takes to educate and create chip manufacturers. The only way to avoid that cost being funneled back into more energy consumption is to make the barrier to understanding of the manufacturing process sufficiently difficult so as to limit the proliferation of these chips. Again, this privileges the chip manufacturers as well as those with close access to the chip manufacturers.
>
> As far as I can tell, the only thing this proposal actually does is create a very lucrative business model for those who sell this variety of chips. Any other effects of it are transient, and in all likelihood the transient effects create serious centralization pressure.
>
> At the end of the day, the energy consumption is foundational to the system. The only way to do away with authorities, is to require competition. This competition will employ ever more resources until it is unprofitable to do so. At the base of all resources of society is energy. You get high energy expenditure, or a privileged class of bitcoin administrators: pick one. I suspect you'll find the vast majority of Bitcoin users to be in the camp of the energy expenditure, since if we pick the latter, we might as well just pack it in and give up on the Bitcoin experiment.
Keagan is quite correct.
Ultimately all currency security derives from energy consumption.
Everything eventually resolves down to proof-of-work.
* Proof-of-space simply moves the work to the construction of more storage devices.
* Proof-of-stake simply moves the work to stake-grinding attacks.
* The optical proof-of-work simply moves the work to the construction of more miners.
* Even government-enforced fiat is ultimately proof-of-work, as the operation and continued existence of any government is work.
It is far better to move towards a more *direct* proof-of-work, than to add more complexity and come up with something that is just proof-of-work, but with the work moved off to somewhere else and with additional moving parts that can be jammed or hacked into.
When considering any new proof-of-foo, it is best to consider all effects until you reach the base physics of the arrow of time, at which point you will realize it is ultimately just another proof-of-work anyway.
At least, proof-of-work is honest about its consumption of resources.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-05-18 6:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 19:32 Bogdan Penkovsky
2021-05-17 21:13 ` Keagan McClelland
2021-05-18 6:46 ` ZmnSCPxj [this message]
2021-05-18 9:18 ` Devrandom
2021-05-18 10:58 ` ZmnSCPxj
2021-05-18 11:05 ` mike
2021-05-18 11:36 ` ZmnSCPxj
2021-05-18 11:43 ` mike
2021-05-18 11:58 ` ZmnSCPxj
2021-05-18 12:17 ` mike
2021-05-18 12:22 ` ZmnSCPxj
2021-05-18 12:58 ` ZmnSCPxj
2021-05-18 10:59 ` mike
2021-05-18 12:46 ` Claus Ehrenberg
2021-05-18 16:47 ` Keagan McClelland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ZFVpoVGcwTTpDDlAXLn8cCwic0l40b3DmE_UoKIv4IvmFDDX9W2F1sRHYwido1X7OK0fX1QAx5J8I5DokM4pcIKziNAgAwc6emrHulfbRE8=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=keagan.mcclelland@gmail$(echo .)com \
--cc=mike@powx$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox