From: mike@powx.org
To: Devrandom <c1.bitcoin@niftybox.net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Date: Tue, 18 May 2021 06:59:46 -0400 [thread overview]
Message-ID: <B3B200B0-73BE-46BC-A462-4A255486E6DC@powx.org> (raw)
In-Reply-To: <CAB0O3SUm0JJ7rdQZNuH+6AKhC3SiXSsoBAoGpLZS7YJawWBS3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]
Devrandom is correct to point out that there is nuance to these things and it’s better to look at the details rather than proclaiming that PoW is PoW. (I do agree though w the original point that other ideas often turn out to reduce to PoW despite their convoluted architecture)
A note on the key difference between hardware and energy as it relates to centralization:
Hardware is easily transferable. If you have low electricity costs, Bitcoin ASICS need to be physically located in proximity to use it. You can’t sell your low power costs on an open liquid market (you can sell your hash rate but that still requires all the miners next to the power plant). Hardware can be sold online freely to anyone anywhere in the world.
If a small number of foundries are producing low energy opow hardware (just as there are a small number producing SHA256 ASICS- in fact it would be the same set foundries, somewhat expanded because optical chips use larger, older nodes... for example Global Foundries has a great photonics process at 90nm), they can (and will) still sell the hardware to people all over the world.
There is a huge latent demand for BTC mining. Many people currently buying alt coins or even BTC would prefer to invest in mining if they could turn a profit despite their high energy cost.
Another clear benefit would be the difficulty of detecting and controlling low energy mining relative to the ASIC-warehouse-next-to-waterfall model used today. You can’t move a waterfall if the local government decides to regulate you.
Just some thoughts.
Sent from my iPhone
> On May 18, 2021, at 5:18 AM, Devrandom <c1.bitcoin@niftybox.net> wrote:
>
>
> On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj:
>>
>> 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.
>
> Let's not simplify away economic considerations, such as externalities. The whole debate about the current PoW is about negative externalities related to energy production.
>
> Depending on the details, CAPEX (R&D, real-estate, construction, production) may have less externalities, and if that's the case, we should be interested in adopting a PoW that is intensive in these types of CAPEX.
>
> On Mon, May 17, 2021 at 2:20 PM Keagan McClelland wrote:
>
>> 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 [...]
>
> I challenge you to substantiate these assertions. Real-estate and human cognitive work are not energy intensive and are a major factor in the expected costs of some alternative PoWs. The expected mining effort is such that the cost will reach the expected reward, no more, so there is every reason to believe that energy consumption will be small compared to the current PoW.
>
> Therefore, the total associated negative externalities for the alternative PoWs may well be much lower than the externalities of energy production. This needs detailed analysis, not a knee-jerk reaction.
>
[-- Attachment #2: Type: text/html, Size: 5621 bytes --]
next prev parent reply other threads:[~2021-05-18 10:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 19:32 [bitcoin-dev] Proposal: Low Energy Bitcoin PoW Bogdan Penkovsky
2021-05-17 21:13 ` Keagan McClelland
2021-05-18 6:46 ` ZmnSCPxj
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 [this message]
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=B3B200B0-73BE-46BC-A462-4A255486E6DC@powx.org \
--to=mike@powx.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=c1.bitcoin@niftybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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