Date: Sun, 24 May 2020 01:12:04 +0000
To: Karl <gmkarl@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
In-Reply-To: <CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
References: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
 <CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] hashcash-newhash
Precedence: list

Good morning Karl,

> Hi,
>
> I'd like to revisit the discussion of the digest algorithm used in hashca=
sh.
>
> I believe migrating to new hashing algorithms as a policy would significa=
ntly increase decentralization and hence security.

Why do you believe so?

My understanding is that there are effectively two strategies for ensuring =
decentralization based on hash algorithm:

* Keep changing the hash algorithm to prevent development of ASICs and ensu=
re commodity generic computation devices (GPUs) are the only practical targ=
et.
* Do not change the algorithm, to ensure that knowledge of how best to impl=
ement an ASIC for the algorithm becomes spread out (through corporate espio=
nage, ASIC reverse-engineering, patent expiry, and sheer engineering effort=
) and ASICs for the algorithm are as commoditized as GPUs.

The former strategy has the following practical disadvantages:

* Developing new hash algorithms is not cheap.
  The changes to the hashcash algorithm may need to occur faster than the s=
peed at which we can practically develop new, cryptographically-secure hash=
 algorithms.
* It requires coordinated hardforks over the entire network at an alarmingl=
y high rate.
* It arguably puts too much power to the developers of the code.

On the other hand, the latter strategy requires us only to survive an inter=
mediate period where ASICs are developed, but not yet commoditized; and dur=
ing this intermediate period, the centralization pressure of ASICs might no=
t be more powerful than other centralization pressures

--

Which brings us to another point.

Non-ASIC-resistance is, by my understanding, a non-issue.

Regardless of whether the most efficient available computing substrate for =
the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner earnings are =
determined by cost of power supply.

Even if you imagine that changing the hashcash algorithm would make CPUs pr=
actical again, you will still not run it on the CPU of a mobile, because a =
mobile runs on battery, and charging a battery takes more power than what y=
ou can extract from the battery afterwards, because thermodynamics.

Similarly, geographic locations with significant costs of electrical power =
will still not be practical places to start a mine, regardless if the mine =
is composed of commodity server racks, commodity video cards, or commodity =
ASICs.

If you want to solve the issue of miner centralization, the real solution i=
s improving the efficiency of energy transfer to increase the areas where c=
heap energy is available, not stopgap change-the-algorithm-every-6-months.


Regards,
ZmnSCPxj


>
> I believe the impact on existing miners could be made pleasant by gradual=
ly moving the block reward from the previous hash to the next (such that bo=
th are accepted with different rewards).=C2=A0 An appropriate rate could po=
ssibly be calculated from the difficulty.
>
> You could develop the frequency of introduction of new hashes such that o=
nce present-day ASICs are effectively obsolete anyway due to competition, n=
ew ones do not have time to develop.
>
> I'm interested in hearing thoughts and concerns.
>
> Karl Semich