1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id DE494C0176
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 01:12:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id C60D187A3D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 01:12:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id sOi5r0ZfPNGH
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 01:12:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by whitealder.osuosl.org (Postfix) with ESMTPS id 4893287A18
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 01:12:12 +0000 (UTC)
Date: Sun, 24 May 2020 01:12:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1590282729;
bh=AJwREk36X4yVpuzp0sjVS8Aez2q0WGQWwaWcJcOyEYk=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=CwjRqF62E9lJEtWseCtPHim39xb3AE3C1abr82ELqzvGl8RHYaoEDbwdmYc3T1W0x
Dnyzj30+26xcfgLAAZ3lXVA0KL6q6dCOknuLR2oK7vj5m0+TKdz/ZFbuMFdpT2oeok
fyHvX1FS2ptW25LZaqFgOIcZoRe5Hwwdk1M3HBNE=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 01:12:15 -0000
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
|
