public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Keagan McClelland <keagan.mcclelland@gmail.com>
To: Claus Ehrenberg <aubergemediale@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Date: Tue, 18 May 2021 10:47:29 -0600	[thread overview]
Message-ID: <CALeFGL3SJw94DOgOHjwTSM+6Vc74tTuCHFu1QjDM+FjYSGxGNA@mail.gmail.com> (raw)
In-Reply-To: <CANPykMoM4+3svpUNQBwa8xrsKnEv48FVT1fu0+wpnTB4PXkg4g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7557 bytes --]

>One needs a cost/benefit analysis, not just an account of the cost. For
example, if PoW could do calculations that are otherwise useful (maybe
solve a queue of standardized math-jobs, such as climate simulations) there
would be more benefit, or, let's say the data storage in proof-of-space is
useful.

Any discussion on whether Proof of Work is suitable for the task needs to
recognize that the "waste" is what creates the security. If you manage to
make the proof of work useful for tasks external to the protocol, you
reintroduce the "nothing at stake" problem in a roundabout way. Useful
computation is something people will pay for. If they pay for it, miners
can be compensated in such a way that choosing to mine one of the
Not-The-Heaviest-Chain's becomes costless. This erodes the security of the
network substantially. It is not a matter of coming up with the "right"
kind of useful computation that is not subject to these problems. These
problems are a natural consequence of it being useful outside the protocol
*at all*.

Keagan

On Tue, May 18, 2021 at 8:24 AM Claus Ehrenberg via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Ultimately all currency security derives from energy consumption.
> > Everything eventually resolves down to proof-of-work.
> This is ideology. Yes, without energy and work, not many things happen.
> But the amounts of energy and work to achieve a goal vary widely. Detailed
> analysis comparing one alternative with the other in depth  is required.
> And I would not look for order-of-magnitude improvements, 25% better is
> also a big deal, if discovered.
>
> > * Proof-of-space simply moves the work to the construction of more
> storage devices.
> One needs a cost/benefit analysis, not just an account of the cost. For
> example, if PoW could do calculations that are otherwise useful (maybe
> solve a queue of standardized math-jobs, such as climate simulations) there
> would be more benefit, or, let's say the data storage in proof-of-space is
> useful.
>
> > * Proof-of-stake simply moves the work to stake-grinding attacks.
> Simply not true, there are PoS implementations that are immune to
> stake-grinding attacks, and even where not, the possible amount of
> computations is limited compared to PoW
>
> > * The optical proof-of-work simply moves the work to the construction of
> more miners.
> The idea was to shift from energy to cap-ex. We can get a
> financial penalty for misbehavior from three sources:
> - cost of energy/labor (PoW)
> - cost of capital (PoS)
> - cost of cap-ex
> There might be a better mix than PoW only. I have written code for mixed
> PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense,
> but the environmental impact needs to be analyzed, it could also make it
> worse than just the use of electricity. At least electricity as such does
> not leave waste behind. Mining in orbit with solar power would be totally
> acceptable.
>
> > At least, proof-of-work is honest about its consumption of resources.
> Agreed, but we can't be satisfied with that. If we try hard enough we can
> do better.
>
> Cheers
> Claus
>
> On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> > 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 8795 bytes --]

      reply	other threads:[~2021-05-18 16:47 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
2021-05-18 12:46     ` Claus Ehrenberg
2021-05-18 16:47       ` Keagan McClelland [this message]

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=CALeFGL3SJw94DOgOHjwTSM+6Vc74tTuCHFu1QjDM+FjYSGxGNA@mail.gmail.com \
    --to=keagan.mcclelland@gmail.com \
    --cc=aubergemediale@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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