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
138
139
140
141
142
143
144
145
146
147
|
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 86F61C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 16:51:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 8167F8772A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 16:51:45 +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 6lAj--jPhEnq
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 16:51:43 +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 77A1386AFF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 May 2020 16:51:43 +0000 (UTC)
Date: Sun, 24 May 2020 16:51:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1590339100;
bh=G2aHVGnBUhPSt8rptUWtmXf6b3yvUmyxpnHTCQoQ8Lk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=lrciD/4JP2Fuy1gfHgX114f6aXT3AvuqSxUuGkquPzOjmgR9Mu/tpHgH3+Hl8q+8F
tLtUHtwCP/6uUtlZlAtrej5dYEfWy3ikz+opDlS9GMfdmt1WxwHBl9Kyw0sLETWprm
/UkYRuSQkIFMYMXu2XX/ozYDOUOXkscWYvT3NAe8=
To: Karl <gmkarl@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
In-Reply-To: <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
References: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
<CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
<k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
<CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 16:51:45 -0000
Good morning Kari,
> You mention ASICs becoming commoditized.=C2=A0 I'd remind you that eventu=
ally there will be a public mathematical breaking of the algorithm, at whic=
h point all ASICs will become obsolete regardless.=C2=A0 Would you agree it=
would be better to prepare for this by planning algorithm change?
Possibly, but then the reason for change is no longer to promote decentrali=
zation, would it?
It helps to be clear about what your goals are, because any chosen solution=
might not be the best way to fix it.
I admit that, if the problem were to be avoid the inevitable obsoletion of =
SHA-2, then this is the only solution, but that is not the problem you stat=
ed you were trying to solve in the first place.
>
> You mention many coordinated hardforks.=C2=A0 Would you agree that if we =
came up with a way of programmatically cycling the algorithm, that only one=
hardfork work be needed?=C2=A0 For example one could ask nodes to consent =
to new algorithm code written in a simple scripting language, and reject ol=
d ones slowly enough to provide for new research.
Even *with* a scripting language, the issue is still what code written in t=
hat language is accepted, and *how*.
Do miners vote on a new script describing the new hashing algorithm?
What would their incentive be to obsolete their existing hardware?
(using proof-of-work to lock in a hashing change feels very much like a chi=
cken-and-egg problem: the censorship-resistance provided by Bitcoin is base=
d on evicting any censors by overpowering their hashpower, but requires som=
e method of measuring that hashpower: it seems unlikely that you can safely=
change the way hashpower is measured via a hashpower election)
Do nodes install particular scripts and impose a switchover schedule of som=
e sort?
Then how is that different from a hardfork, especially for nodes that do no=
t update?
(notice that softforks allow nodes to remain non-updated, at degraded secur=
ity, but still in sync with the rest of the network and capable of transact=
ing with them)
>
> You mention the cost of power as the major factor influencing decentraliz=
ed mining.=C2=A0 Would you agree that access to hardware that can do the mi=
ning is an equally large factor?=C2=A0 Even without ASICs you would need th=
e physical cycles.=C2=A0 Including this factor helps us discuss the same se=
t of expected situations.
No, because anyone who is capable of selling hardware, or the expertise to =
design and build it, can earn by taking advantage of their particular exper=
tise.
Generally, such experts can saturate the locally-available energy sources, =
until local capacity has been saturated, and they can earn even more by sel=
ling extra hardware to entities located at other energy sources whose local=
capacities are not still underutilized, or expanding themselves to those s=
ources.
Other entities might be in better position to take advantage of particular =
local details, and it may be more lucrative for the expert-at-building-hard=
ware to just sell the hardware to them than to attempt to expand in places =
where they have little local expertise.
And expertise is easy to copy, it is only the initial expertise that is har=
d to create in the first place, once knowledge is written down it can be co=
pied.
>
> You describe improving electricity availability in expensive areas as a w=
ay to improve decentralization.=C2=A0 Honestly this sounds out of place to =
me and I'm sorry if I've upset you by rehashing this old topic.=C2=A0 I bel=
ieve this list is for discussing the design of software, not international =
energy infrastructure: what is the relation?=C2=A0 There is a lot of power =
to influence behavior here but I thought the tools present are software des=
ign.
I doubt there is any good software-only solution to the problem; the physic=
al world remains the basis of the virtual one, and the virtual utterly depe=
ndent on the physical, and abstractions are always leaky (any non-toy softw=
are framework inevitably gains a way to query the operating system the appl=
ication is running under, because abstractions inevitably leak): and energy=
, or the lack thereof, is the hardest to abstract away, which is the entire=
point of using proof-of-work as a reliable, unfakeable (i.e. difficult to =
virtualize) clock in the first place.
Still, feel free to try: perhaps you might succeed.
Regards,
ZmnSCPxj
|
