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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3D5CFC000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Mar 2021 05:05:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 31D3782E0E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Mar 2021 05:05:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.676
X-Spam-Level:
X-Spam-Status: No, score=0.676 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, LOTS_OF_MONEY=0.001,
MONEY_FREEMAIL_REPTO=0.274, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1qx_09unhSPe
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Mar 2021 05:05:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by smtp1.osuosl.org (Postfix) with ESMTPS id 4EAF28391F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Mar 2021 05:05:43 +0000 (UTC)
Date: Wed, 17 Mar 2021 05:05:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1615957540;
bh=3vjOdy7kTV64qkuF+Mq6aZWKIJAKpakgHPQC9Hm6hWY=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=IrFRQpi/RAnsu1HT1q99CQwxa448cuWnisyj6jOd753FHYNyPwq5bA9rANct4JQTT
Rv96h3aTq28g93H9gsz2/kHwkukP5R+jHFPT/z0Or69hlkeO/ZnsMQuAIwITKamsKl
DXq04FnNwDNPMfWq3xrtxZUJ3TMoUlSGb4dfLpss=
To: Lonero Foundation <loneroassociation@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <rJRQhaMpP-Rq5oJ8nscd81M3tq8PiaSGfvlF6xr0qIjJgcoN_p3azQ9-a-RAvIxDmRa1cfoBkJZnLXILDzhYKh3SDk9TE08wbX60d6EAjQw=@protonmail.com>
In-Reply-To: <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
References: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com>
<CALeFGL31M5DAULLRtCwjPYHaPVqsVqREUg6WQ2-cuj23SNk=BA@mail.gmail.com>
<CA+YkXXwBMG6YUAhf-2U5EV5Ep5RgG2foc9chramNFN5=AQ=-EA@mail.gmail.com>
<CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com>
<CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
<CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
<CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
<CA+YkXXw1AiMqCoPk_pUOdDMfkGF_T+aURGAjGK=MTa7jtAQchg@mail.gmail.com>
<CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
Datastore for Energy Efficient Mining
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: Wed, 17 Mar 2021 05:05:46 -0000
Good morning Andrew,
Looking over the text...
> # I am looking towards integrating memory hard compatibility w/ the minin=
g algorithm. Memory hard computation allows for time and space complexity f=
or data storage functionality, and there is a way this can likely be implem=
ented without disenfranchising current miners or their hardware if done rig=
ht.
I believe this represents a tradeoff between time and space --- either you =
use one spatial unit and take a lot of time, or you use multiple spatial un=
its and take smaller units of time.
But such time/space tradeoffs are already possible with the existing mechan=
ism --- if you cannot run your existing SHA256d miner faster (time), you ju=
st buy more miners (space).
Thus, I think the requirement for memory hardness is a red herring in the d=
esign of proof-of-work algorithms.
Memory hardness *prevents* this tradeoff (you cannot create a smaller miner=
that takes longer to mine, as you have a memory requirement that prevents =
trading off space).
It is also helpful to remember that spinning rust consumes electricity as w=
ell, and that any operation that requires changes in data being stored requ=
ires a lot of energy.
Indeed, in purely computational algorithms (e.g. CPU processing pipelines) =
a significant amount of energy is spent on *changing* voltage levels, with =
very little energy (negligible compared to the energy spent in changing vol=
tage levels in modern CMOS hardware) in *maintaining* the voltage levels.
> I don't see a reason why somebody with $2m of regular hardware can't mine=
the same amount of BTC as somebody with $2m worth of ASICs.
I assume here that "regular hardware" means "general-purpose computing devi=
ce".
The Futamura projections are a good reason I see: http://blog.sigfpe.com/20=
09/05/three-projections-of-doctor-futamura.html
Basically, any interpreter + fixed program can be converted, via Futamura p=
rojection, to an optimized program that cannot interpret any other program =
but runs faster and takes less resources.
In short, any hardware interpreter (i.e. general-purpose computing device) =
+ a fixed proof-of-whatever program, can be converted to an optimized hardw=
are that can only perform that proof-of-whatever program, but consuming les=
s energy and space and will (eventually) be cheaper per unit as well, so th=
at $2M of such a specific hardware will outperform $2M of general-purpose c=
omputing hardwre.
Thus, all application-specificity (i.e. any fixed program) will always take=
less resources to run than a generic hardware interpreter that can run any=
program.
Thus, if you ever nail down the specifics of your algorithm, and if a thous=
and-Bitcoin industry ever grows around that program, you will find that ASI=
Cs ***will*** arise that run that algorithm faster and less energy-consumin=
g than general-purpose hardware that has to interpret a binary.
**For one, memory/disk bus operations are limited only to actual data, with=
out requiring additional bus operations to fetch code.**
Data can be connected directly from the output of one computational sub-uni=
t to the input of another, without requiring (as in the general-purpose har=
dware case) that the intermediate outputs be placed in general-purpose stor=
age register (which, as noted, takes energy to *change* its contents, and a=
s general-purpose storage will also be used to hold *other* intermediate ou=
tputs).
Specialized HDDs can arise as well which are optimized for whatever access =
pattern your scheme requires, and that would also outperform general-purpos=
e HDDs as well.
Further optimizations may also exist in an ASIC context that are not readil=
y visible but which are likely to be hidden somewhere --- the more complica=
ted your program design, the more likely it is that you will not readily se=
e such hidden optimizations that can be achieved by ASICs (xref ASICBOOST).
In short, even with memory-hardness, an ASIC will arise which might need to=
be connected to an array of (possibly specialized) HDDs but which will sti=
ll outperform your general-purpose hardware connected to an array of genera=
l-purpose storage.
Indeed, various storage solutions already have different specializations: S=
MR HDDs replace tape drives, PMR HDDs serve as caches of SMR HDDs, SSDs ser=
ve as caches of PMR HDDs.
An optimized technology stack like that can outperform a generic HDD.
You cannot fight the inevitability of ASICs and other specialized hardware,=
just as you cannot fight specialization.
You puny humans must specialize in order to achieve the heights of your civ=
ilization --- I can bet you 547 satoshis that you yourself cannot farm your=
own food, you specialize in software engineering of some kind and just pay=
a farmer to harvest your food for you.
Indeed, you probably do not pay a farmer directly, but pay an intermediary =
that specializes in packing food for transport from the farm to your domici=
le. which itself probably delegates the actual transporting to another spec=
ialist.
Similarly, ASICs will arise and focus on particularly high-value fixed comp=
utations, inevitably.
Regards,
ZmnSCPxj
|
