From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Karl <gmkarl@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
Date: Sun, 24 May 2020 01:12:04 +0000 [thread overview]
Message-ID: <k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com> (raw)
In-Reply-To: <CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
Good morning Karl,
> Hi,
>
> I'd like to revisit the discussion of the digest algorithm used in hashcash.
>
> I believe migrating to new hashing algorithms as a policy would significantly 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 ensure commodity generic computation devices (GPUs) are the only practical target.
* Do not change the algorithm, to ensure that knowledge of how best to implement an ASIC for the algorithm becomes spread out (through corporate espionage, 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 speed at which we can practically develop new, cryptographically-secure hash algorithms.
* It requires coordinated hardforks over the entire network at an alarmingly 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 intermediate period where ASICs are developed, but not yet commoditized; and during this intermediate period, the centralization pressure of ASICs might not 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 practical 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 you 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 is improving the efficiency of energy transfer to increase the areas where cheap 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 gradually moving the block reward from the previous hash to the next (such that both are accepted with different rewards). An appropriate rate could possibly be calculated from the difficulty.
>
> You could develop the frequency of introduction of new hashes such that once present-day ASICs are effectively obsolete anyway due to competition, new ones do not have time to develop.
>
> I'm interested in hearing thoughts and concerns.
>
> Karl Semich
next prev parent reply other threads:[~2020-05-24 1:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
2020-05-23 11:00 ` Karl
2020-05-24 1:12 ` ZmnSCPxj [this message]
2020-05-24 9:02 ` Karl
2020-05-24 16:51 ` ZmnSCPxj
2020-05-24 19:50 ` Karl
2020-05-25 7:58 ` ZmnSCPxj
2020-05-25 11:54 ` Karl
2020-05-27 4:47 ` ZmnSCPxj
2020-05-27 14:12 ` Erik Aronesty
2020-05-24 23:51 ` Ariel Lorenzo-Luaces
2020-05-25 7:03 ` Karl
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='k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmkarl@gmail$(echo .)com \
/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