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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Return-Path: <mike@powx.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 762AAC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 12:17:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 627D4405FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 12:17:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=powx-org.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ThzyAwk_yf6G
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 12:17:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com
[IPv6:2607:f8b0:4864:20::834])
by smtp4.osuosl.org (Postfix) with ESMTPS id 3FB7F40509
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 12:17:48 +0000 (UTC)
Received: by mail-qt1-x834.google.com with SMTP id t20so7207557qtx.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 05:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=powx-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=Vr7hrV0SZsnUwlSoTy5jZXZBIycmVog5OfFEOraTLZs=;
b=E0s97VdInt2rFQ1qGgXIaq+8qEVYiuIO7BqNEo9AA6eVtqxbh8SjPAog2Dhd/f8Yv7
zDcWo5gLAqqEoRQMiwCFgu6ttv/88NhuA4w3PP4lV1S4R7CEX130Tkb24uaPKAT4hnGC
/w5FlTnsfAv1jxS5NDdBFTaxUaUQGqsUd9NjH5gWe/fhZ96oYMGELZPcrz3sQsOQ0+06
+BmkFoJk3nrIHkXNbv27Mt1ZPn+E8iIxPABVrpZtW0UNhfWI7HNjgIJbHUcqGkBCjO2r
p9AFJy6VZHLzMn/W5TF5p3jRA0nv46G7h8+sfeRjduEwzmCdQtYwTKunwZCSYJ5fFXB8
TvrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=Vr7hrV0SZsnUwlSoTy5jZXZBIycmVog5OfFEOraTLZs=;
b=TlY/qWQb0mw4tf1daXwlPbAznjiRu1kqqA/bKbmcFd2jGH8V58PRjqt+QJoUDs9hQI
SWElFM+eK3shs3V4+PTEYHybGS4e1MMpm/rZ+9QskS1W8lU4zIJAdoRaSCwH+HROILAs
wrvvHibpKKbup267VhJwq1C6iGBQwZZAaEO+bTQNjVuIUiJcDpKu1llAgMyWzVzN1pVA
4PCCURG0Y1F2MBhxc+jvLZMgwaTACXpNJn2cMvoJyFCMtj2sc8QZKzWKVzJbLmgfcPdU
i5tABX7Pv6HM7LJzfMJGgyEkCH5ftFUnBsSnlpORsu6k4M22ki18+J4mVP3CEBLZBNuP
V8RA==
X-Gm-Message-State: AOAM531BouPMOzG58hMlmt+5CkSC58XwsvekGNnFhI3xuWo/w5/CO5ZM
PAjHQ2X0d27PmVBWGHBUwz6lR519ludOEwju
X-Google-Smtp-Source: ABdhPJyLmHy7NOiWfh9bzk7SOrpFLe2kzP4KM2L6VE3F9LuyHAX4ZS0j1uoin+ViMj/WIUy3YQdowQ==
X-Received: by 2002:ac8:6b0a:: with SMTP id w10mr4365538qts.60.1621340267008;
Tue, 18 May 2021 05:17:47 -0700 (PDT)
Received: from [192.168.4.35] ([73.143.249.71])
by smtp.gmail.com with ESMTPSA id z187sm12652153qkb.129.2021.05.18.05.17.46
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 18 May 2021 05:17:46 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-1E226B23-1DD8-4164-843B-0B81FBF43D4B
Content-Transfer-Encoding: 7bit
From: mike@powx.org
Mime-Version: 1.0 (1.0)
Date: Tue, 18 May 2021 08:17:46 -0400
Message-Id: <864F983C-841D-4334-94F4-5A9F7D617B70@powx.org>
References: <vTGmO3qpvd7XawxARg2vvWmeP2LOCLAIBgMRWmNNmf7mok0DRhIes5JsBnooflSNk4DX2vQCuOB7hBmSjcUT_RvtF6l8gJ9Tt69TWEeowmg=@protonmail.com>
In-Reply-To: <vTGmO3qpvd7XawxARg2vvWmeP2LOCLAIBgMRWmNNmf7mok0DRhIes5JsBnooflSNk4DX2vQCuOB7hBmSjcUT_RvtF6l8gJ9Tt69TWEeowmg=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
X-Mailer: iPhone Mail (18D70)
X-Mailman-Approved-At: Tue, 18 May 2021 14:24:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
marshall ball <marshallball@gmail.com>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
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: Tue, 18 May 2021 12:17:51 -0000
--Apple-Mail-1E226B23-1DD8-4164-843B-0B81FBF43D4B
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Nothing in a dynamic system like PoW mining can be 100% anticipated, for exa=
mple there might be advanced in manufacturing of chips which are patented an=
d so on.=20
It sounds like your take is that this means no improvements can ever be made=
by any mechanism, however conservative.
We do go into a fair amount of detail about Minimum Effective Hardness in ou=
r paper https://assets.pubpub.org/xi9h9rps/01581688887859.pdf , which is act=
ually a special case of hardness that we invented for the context of adding a=
n operation to a PoW, and how it applies to random matrix mults. =20
Sent from my iPhone
> On May 18, 2021, at 7:58 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> =EF=BB=BFGood morning Michael,
>=20
>> That=E2=80=99s interesting. I didn=E2=80=99t know the history of ASICBOOS=
T.
>=20
> History is immaterial, what is important is the technical description of A=
SICBOOST.
> Basically, by fixing the partial computation of the second block of SHA256=
, we could selectively vary bits in the first block of SHA256, while reusing=
the computation of the second block.
> This allows a grinder to grind more candidate blocks without recomputing t=
he second block output, reducing the needed power consumption for the same n=
umber of hashes attempted.
>=20
> Here is an important writeup: https://www.mit.edu/~jlrubin/public/pdfs/Asi=
cboost.pdf
> It should really be required reading for anyone who dreams of changing PoW=
algorithms to read and understand this document.
>=20
> There may be similar layer-crossings in any combined construction --- or e=
ven just a simple hash function --- when it is applied to a specific Bitcoin=
block format.
>=20
>>=20
>> Our proposal (see Implementation) is to phase in oPoW slowly starting at a=
very low % of the rewards (say 1%). That should give a long testing period w=
here there is real financial incentive for things like ASICBOOST
>>=20
>> Does that resolve or partially resolve the issue in your eyes?
>=20
> It does mitigate this somewhat.
>=20
> However, such a mechanism is an additional complication and there may be f=
urther layer-crossing violations possible --- there may be an optimization t=
o have a circuit that occasionally uses SHA256d and occasionally uses oPoW, t=
hat is not possible with a pure SHA256d or pure oPoW circuit.
> So this mitigation is not as strong as it might appear at first glance; ad=
ditional layers means additional possibility of layer-crossing violations li=
ke ASICBOOST.
>=20
>=20
>=20
>=20
> Regards,
> ZmnSCPxj
>=20
--Apple-Mail-1E226B23-1DD8-4164-843B-0B81FBF43D4B
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">Nothing in a dynamic system like PoW mining=
can be 100% anticipated, for example there might be advanced in manufacturi=
ng of chips which are patented and so on. <div><br></div><div>It sounds=
like your take is that this means no improvements can ever be made by any m=
echanism, however conservative.<div><br></div><div>We do go into a fair amou=
nt of detail about Minimum Effective Hardness in our paper <a href=3D"h=
ttps://assets.pubpub.org/xi9h9rps/01581688887859.pdf">https://assets.pubpub.=
org/xi9h9rps/01581688887859.pdf</a> , which is actually a special case o=
f hardness that we invented for the context of adding an operation to a PoW,=
and how it applies to random matrix mults. </div><div><br><div d=
ir=3D"ltr">Sent from my iPhone</div><div dir=3D"ltr"><br><blockquote type=3D=
"cite">On May 18, 2021, at 7:58 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com>=
wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr"=
>=EF=BB=BF<span>Good morning Michael,</span><br><span></span><br><blockquote=
type=3D"cite"><span>That=E2=80=99s interesting. I didn=E2=80=99t know the h=
istory of ASICBOOST.</span><br></blockquote><span></span><br><span>History i=
s immaterial, what is important is the technical description of ASICBOOST.</=
span><br><span>Basically, by fixing the partial computation of the second bl=
ock of SHA256, we could selectively vary bits in the first block of SHA256, w=
hile reusing the computation of the second block.</span><br><span>This allow=
s a grinder to grind more candidate blocks without recomputing the second bl=
ock output, reducing the needed power consumption for the same number of has=
hes attempted.</span><br><span></span><br><span>Here is an important writeup=
: https://www.mit.edu/~jlrubin/public/pdfs/Asicboost.pdf</span><br><span>It s=
hould really be required reading for anyone who dreams of changing PoW algor=
ithms to read and understand this document.</span><br><span></span><br><span=
>There may be similar layer-crossings in any combined construction --- or ev=
en just a simple hash function --- when it is applied to a specific Bitcoin b=
lock format.</span><br><span></span><br><blockquote type=3D"cite"><span></sp=
an><br></blockquote><blockquote type=3D"cite"><span>Our proposal (see Implem=
entation) is to phase in oPoW slowly starting at a very low % of the rewards=
(say 1%). That should give a long testing period where there is real financ=
ial incentive for things like ASICBOOST</span><br></blockquote><blockquote t=
ype=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>D=
oes that resolve or partially resolve the issue in your eyes?</span><br></bl=
ockquote><span></span><br><span>It does mitigate this somewhat.</span><br><s=
pan></span><br><span>However, such a mechanism is an additional complication=
and there may be further layer-crossing violations possible --- there may b=
e an optimization to have a circuit that occasionally uses SHA256d and occas=
ionally uses oPoW, that is not possible with a pure SHA256d or pure oPoW cir=
cuit.</span><br><span>So this mitigation is not as strong as it might appear=
at first glance; additional layers means additional possibility of layer-cr=
ossing violations like ASICBOOST.</span><br><span></span><br><span></span><b=
r><span></span><br><span></span><br><span>Regards,</span><br><span>ZmnSCPxj<=
/span><br><span></span><br></div></blockquote></div></div></body></html>=
--Apple-Mail-1E226B23-1DD8-4164-843B-0B81FBF43D4B--
|