public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: marshall ball <marshallball@gmail.com>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Date: Tue, 18 May 2021 12:58:19 +0000	[thread overview]
Message-ID: <U0VZGMC4DZ7OCRiGXZcErc8yeQQymKnIQVhvvHzUqB3JXqPUh283NLOXxYnoczjD-fnIvUK3snRHvDYaJY_6ZiW7edpoj-Xd1Qn1Sn7xKP8=@protonmail.com> (raw)
In-Reply-To: <gU6IuHMWVlb0523voCPVfZjdgWD2XSKyF73j2fbBC-YKQH9QKfoNkOmxxOU2tR1YMh0yiGrTRWvGAtn_MPhLx-GREUUsOYZ3rJkvYjSKSZs=@protonmail.com>

Good morning Michael,

> Good morning Michael,
>
> > Nothing in a dynamic system like PoW mining can be 100% anticipated, for example there might be advanced in manufacturing of chips which are patented and so on.
> > It sounds like your take is that this means no improvements can ever be made by any mechanism, however conservative.
>
> Not at all.
>
> Small-enough improvements over long-enough periods of time are expected and anticipated --- that is why there exists a difficulty adjustment mechanism.
> What is risky if a large-enough improvement over a short-enough time that overwhelms the difficulty adjustment mechanism.
> ASICBOOST was a massive enough improvement that it could be argued to potentially overwhelm this mechanism if it was not openly allowed for all miners.

Or to put it in another perspective:

* Small improvements to PoW mining are tolerated by Bitcoin.
  * Such improvements are expected to be common.
* Large improvements to PoW mining are potential extinction events for Bitcoin, due to massive centralization risk.
  * Such improvements are expected to be *rare* but *not* nonexistent.
* The number of possible circuit configurations is bounded by physical limits (matter is quantized, excssively-large chips are infeasible, etc.), thus the number of expected optimizations of a particular overall algorithm are bounded.

Suppose two manufacturers find two different small improvements to PoW mining.
In all likelihood, "the sum is better than its parts" and if the two have a cross-licensing deal, they can outcompete their *other* competition.
Further, even if some small competitor violates the patent, the improvement may be small enough that the patent owner may decide the competitor is too small to bother with all the legal fees involved to enforce the patent.
Thus, small improvements to PoW mining are expected to eventually spread widely, and that is what the difficulty adjustment mechanism exists to modulate.

But suppose a third manufacturer develops an ASICBOOST-level optimization of whatever the PoW mining algorithm is.
That manufacturer has no incentive to cross-license, since it can dominate the competition without cross-licensing a bunch of smaller optimizations (that may not even add up to compete against the ASICBOOST-level optimization).
And any small competitor that violates patent will be enforced against, due to the major improvement that the large optimization has and the massive monopolistic advantage the ASICBOOST-level optimization patent holder would have.


SHA256d-on-Bitcoin-block-header has already uncovered ASICBOOST, and thus the number of possible other large optimizations is that much smaller --- the number of possible optimizations is bounded by physical constraints.
Thus, the risk of a black-swan event where a new optimization of SHA256d-on-Bitcoin-block-header is large enough to massively centralize mining is reduced, compared to every other alternative PoW algorithm, which is an important reason to avoid changing PoW as much as possible, without some really serious study (which you might be engaged in --- I am not enough of a mathist to follow your papers).

We are more likely to want to change SHA256 for SHA3 on the txid and Merkle trees than on the PoW.


Regards,
ZmnSCPxj


  reply	other threads:[~2021-05-18 12:58 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 [this message]
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='U0VZGMC4DZ7OCRiGXZcErc8yeQQymKnIQVhvvHzUqB3JXqPUh283NLOXxYnoczjD-fnIvUK3snRHvDYaJY_6ZiW7edpoj-Xd1Qn1Sn7xKP8=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=marshallball@gmail.com \
    /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