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
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
|
Delivery-date: Thu, 15 Aug 2024 20:47:23 -0700
Received: from mail-qv1-f63.google.com ([209.85.219.63])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDBNTKFG4EDRBQUX7O2QMGQEZ3SXR7Q@googlegroups.com>)
id 1senvv-0001Iw-42
for bitcoindev@gnusha.org; Thu, 15 Aug 2024 20:47:23 -0700
Received: by mail-qv1-f63.google.com with SMTP id 6a1803df08f44-6bf6da864a6sf16864666d6.3
for <bitcoindev@gnusha.org>; Thu, 15 Aug 2024 20:47:22 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1723780036; cv=pass;
d=google.com; s=arc-20160816;
b=hvsUB8j6ugou9AfS4K3ig7uOqzFQeaa1MNw/aAI2tVhNQNQO3FEEQOECeOcYRyYbHH
9Fa7Y/Ikq+FuXlvZPEK2wmxiuFornEvIiSU//UGOEy/0vvSupqR5TN+OJRKAo2jApiUx
ArPQWFVf2gSiwgSc/nOPgMe6P2MMWET0ZwzlnrNMlL6APEmOPHKxFZMQeifvRst1wZf6
2j76Ryl2/TuMHjI4xBIg0HwkOL29G2hUzi8DYbqu0FDGRw+t32NhUo5+kw4gu6nLcFD7
1wa9TdFUvsBFaJpJM/m4DlHtekHRJAodAS1uMQYn+fnfPfxykj57Bws07kCJA5sEwuTL
g8uQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:content-disposition
:mime-version:references:message-id:subject:cc:to:from:date:sender
:dkim-signature;
bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=;
fh=9D5/xjpgDdICoQW0xKDYkXScpiECRgIL0UaWjZfrzao=;
b=FbJFKn2jSwMobQcQgLrSnvQyJFEHJ5YfPn9/lzFQRJ8CfD/9p0N832Am4B28ZTuqXV
lS66U53s/vDT6YeasyvhT9SzrLWg9sIu1VWyMUZYYmwPnqgX1vbngBUHVeiZsPsmZ+F6
mpbsn7GyLLDrsWz7eVqae+Lh6LQBo46CeLcRyNd48ubHSJihmWa9J+azn6UH4Q2lI777
pVu0D9JHTjoNgfcepRtx+RdaDVI0Uo3Z+ESgSzG9Zp1O6vB7jV3O7J8rlF6TMvmc3O6w
Jhj04p/wRMe2GlVy8GYtULiDkQGoULEpIcY7AZRGrkqU0Onyb+khEnkqkFnuuDbZ0Pnk
daTg==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1723780036; x=1724384836; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=;
b=gxnps2rS8xXtjATylMIVxDixMDEeBqzWjFurupjT6/Qyzoeq67ltns2uXWvLOQ8vbC
qaHatNnriGOu4dmapDod1dU/MEXoJrGloSCqAiX3UUrprAoc2YIBeMmhYUC/Y/VB2NrT
6zRbM9woCu3FuJqJc1lajUKIksYDsJ9Pbh7/4tYg1nw6zl2SsFhpTE3ASo26G+JOuX7G
hFdYIrutXe4lxiGTI/kCHuA9ySDzCAQbHZ77CtgcqdFlzkE7EHfRtTq8fZGq9kw3HO0T
SpjB1poee47uhz9LqmVOCi+iUlkAjUkocXnF5WXY/tgIg2kSre0h2ltfOdH5qbuexlH3
OYAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1723780036; x=1724384836;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=;
b=BtOjeaLfcpi0PDwk+wjtS047RX9XnjJ1pIz7nHTdAJrGOhZulpiCGf+TArTLoeAZSs
/9ssknSw0OWkGCmTcHKqY5o1Z/qXCcMp25DsxyiClDBT0lPZa2WE3Tz0KCWkUl5IjQQB
C3rvmIezotAWJprD36OsQs50AvEvovja2tMp7o98rgMGFO/4Z+gw+bcn7muUYRz5x9vh
Wpy0/AL/mG35vKPJhR8If1dVt18VE0wCqqvGTaZZ3b6PUqFtWP1103ybabs0cSc0Rb+2
BvyQVpVoB0ebpaBAHlXhzbnEfH7uLAAWA350NcLq6kAtiGM8+zOAsPJ6tBmVabh1gCG7
egnw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCU8e2+pyXd7Y1x1wDJTkaOs6fGHzaAWqpJwBDx4hY7/mlmGY3mIL1mMTDzGxt9ARbHnen27AIMRWt4yAauO6c2AXweuSMw=
X-Gm-Message-State: AOJu0YwZ4V1rH5V0OXbMivrD6dDVyqnJP/XuGMk3TR/54v+s6CTgbiZH
xu4uwyLywNKvq6/3vJxzxI++BATBZtjXyt6wUch2sdtLKLaWNZyr
X-Google-Smtp-Source: AGHT+IHfUYjc4mLsBLscGCeWGVZ4Fd4nkq7dwjyeDpszDZzEbQ5eX9u23xD9LtfXO4TAN/7uVCxHTw==
X-Received: by 2002:ad4:4bb1:0:b0:6bf:7f11:3fac with SMTP id 6a1803df08f44-6bf7f114174mr7549966d6.44.1723780036207;
Thu, 15 Aug 2024 20:47:16 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:2607:b0:6b5:f4e:9d67 with SMTP id
6a1803df08f44-6bf6d39ef92ls31659036d6.0.-pod-prod-05-us; Thu, 15 Aug 2024
20:47:14 -0700 (PDT)
X-Received: by 2002:a05:6214:21a1:b0:6b7:ab15:a5c7 with SMTP id 6a1803df08f44-6bf7ce7b149mr1122146d6.12.1723780034044;
Thu, 15 Aug 2024 20:47:14 -0700 (PDT)
Received: by 2002:a05:620a:1:b0:79c:bd3:58c5 with SMTP id af79cd13be357-7a507f7f1b3ms85a;
Thu, 15 Aug 2024 19:11:13 -0700 (PDT)
X-Received: by 2002:a05:620a:2483:b0:79f:1809:afc2 with SMTP id af79cd13be357-7a5069d1afbmr149895885a.45.1723774272603;
Thu, 15 Aug 2024 19:11:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1723774272; cv=none;
d=google.com; s=arc-20160816;
b=vdl4qHTMvfmOhSCDHUFvIYUrvw/Xut/cyyGJLh5fVnb8UT+YqgHwcbuOcYI82GuZ4z
UIm1/kJMR3wawH/w/Nto53YSzYdzRzseGLZdf/UyDdYnRxhqWDWSTHb3UAqxtxL/6RvH
FmcnSGFXXWyl5HU7JkoNU3PFrNxp3sP1nPQqxLQA22lnUD8rlLFZ6tmV1Bp2oz03Co0M
Zta1jkiFJCipHFzKKMqwytdJ3PsBP9Zy4sKj92xPdvTPcDpJvLwVG8foMDnw9SRe5hTj
UanZbXeUl8DJre4jAhTA17miSsZmGAi6jIN2Ka0jiKKwkaB2M6Kp/RtiAB3dNgViTNLc
rn1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date;
bh=ycuOxX5Kz+KCq2BK9n5IAjHYw8MIBd9RpIDFWbCrn1U=;
fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=;
b=bThb6oXMZGU/sTanT2gcH01pKz3fQPn+sK4rnOgPe1WA4x1pX5yEhdVwWP6g+g1uGP
WOU0HK3uWayMrswlKbUZNbBXVta9n4N77TsceMRk+X6Pe0HooQgzI6J76cPU70BBwsIw
nMM6MLX03CZyDaPLxDG7RpFp5zdX2sMCk9idJvskBjMcf/O7iTyLe/HgLd73OPZv6pEV
svSr5SnDEht2jzKPBlsA3ZC4GjiMxDwTJg3zlgNWFbyAZNdBdX6ej8bMrTnOJlDXqP+U
l1cCaJktCXJdt2gkJlPBvJsD2E5rXjZZ95fuTVcZY+VI2XFSwiUGMHVtc0Z6uQD7k2+K
1Z5Q==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193])
by gmr-mx.google.com with ESMTPS id af79cd13be357-7a4ff0c86cfsi11517785a.5.2024.08.15.19.11.12
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 15 Aug 2024 19:11:12 -0700 (PDT)
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Received: from aj@azure.erisian.com.au
by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.94.2)
(envelope-from <aj@erisian.com.au>)
id 1semQj-0000ec-8T; Fri, 16 Aug 2024 12:11:07 +1000
Received: by email (sSMTP sendmail emulation); Fri, 16 Aug 2024 12:10:59 +1000
Date: Fri, 16 Aug 2024 12:10:59 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Mining pools, stratumv2 and oblivious shares
Message-ID: <Zr61M64kQlYIBuzO@erisian.com.au>
References: <Zp/GADXa8J146Qqn@erisian.com.au>
<26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com>
X-Spam_score: -0.0
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
permitted sender) smtp.mailfrom=aj@erisian.com.au
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
On Tue, Aug 13, 2024 at 09:57:06AM -0400, Matt Corallo wrote:
> Yes, block witholding attacks are easy to do. This has nothing to do with
> client work selection or not, its just...a fact of life with Bitcoin pooled
> mining.
>
> Doing block withholding by creating invalid templates I'd really call
> "shitty block withholding"
Hmm, I thought "BlueMatt" was referring to hair colour, not language
preference.
> cause at least the pool *can* detect it (with
> additional CPU power), vs traditional block withholding attacks they can
> only use statistical analysis.
>
> In fact, any statistical analysis you can do to detect traditional block
> withholding attacks also applies equally to any "shitty block withholding"
> attacks - the outcome (no valid blocks from a miner, but shares) is the
> same, so any relevant defenses apply equally.
The only way you can do statistical analyses is if miners (including
attackers) can be assigned a persistent identity with reasonable accuracy,
and you restrict your pool to accepting individual miners with a large
enough hashrate that they're expected to find a valid block relatively
frequently.
If individuals aren't required to have a large hashrate, an attacker can
just pretend to be multiple miners with small hashrate, all of whom are
unlucky, and your statistical result is just "my small hashrate miners
are in aggregate more unlucky than I expect", without providing a way to
distinguish the attacker's small hashrate identities from honest small
hashrate miners.
If "relatively frequently" is a year or less, that means only about 50k
companies/individuals globally can potentially be miners participating
in a pool, and far less if hashpower is not evenly distributed amongst
miners.
If you're relying on some combination of burdensome KYC, statistics and
restricting pool membership to large hashrate miners, then that's fine:
block withholding is fairly easily addressed. What I'm interested in is
a pool that doesn't do those things: for example, a world where 5% of
hashrate is from 60M BitAxe devices owned by 10M people, say. Solo-mining,
each person might expect to find a block once every 4000 years; with
pooled mining, they'd expect to be paid perhaps 80c per day. But in that
scenario, a pool with 30% hashrate running a block withholding attack
using 1% of hashrate increases their total reward (from 30% to 30.1%)
while cutting the honest bitaxe miners' rewards substantially (from 5%
to 4.2%, or 80c to 67c).
And in that scenario, it seems relatively easy for the attacker to
pretend to be 2M different users, *unless* you're doing real KYC on
every bitaxe miner at signup, in which case whoever you're outsourcing
KYC too becomes your centralising factor ("whoops, your social credit
score is too low to be allowed to be a bitcoin miner").
If the pool is not doing KYC, but does have some soft/hard-forked solution
like oblivious shares, and allows users to choose their block contents,
that's the point at which the invalid block appraoch comes in: you can
still perform effectively the exact same attack, simply by having your 1%
hashrate mining invalid shares rather than withholding the shares that
would be valid blocks. If the pool isn't validating every share, then
you'll only be detected when your share did turn out to be valid PoW, but
once you're detected you simply kill that identity and spin up a new one,
and because the pool isn't doing KYC, spinning up a new identity is easy.
As far as I can see that means your pool is either:
a) heavily KYCed
b) limited to high-hashrate miners
c) fully validating every share
d) vulnerable to block-withholding attacks, and hence not viable in
the long term in a competitive environment
Of those, "fully validating every share" seems the most appealing option
to me, but in practical terms, that seems incompatible with "any miner
can freely choose the txs they work on". In practice, of course, (a)
and (b) will presumably be the reality for the forseeable future for
all but a fairly trivial amount of hashrate.
> Adding more explicit "negotiation" to Stratum V2 work selection would defeat
> the purpose - if the pool is able to tell a miner not to work on some work
> it wants to, ...
A pool is always able to do that -- they can simply mark the share as
invalid after the fact and refuse to pay out on it, and perhaps make
a blog post explaining their policy. The over-the-wire protocol isn't
what provides that ability.
That's also precisely what they have to do if they detect a block
withholding attack by statistical methods: start refusing to pay out
for otherwise valid shares, based on non-consensus rules ("your account
has been banned", "your ip came from a range that seems suspicious",
"you don't have enough hashrate to be a member of this pool", ...).
> ... you might as well just have the pool pick the work.
> The only
> way any kind of centralized pooling with custom work selection adds any
> value to Bitcoin's decentralization is if the clients insist on mining the
> work they want to - whether on the pool or solo mining if the pool doesn't
> want it.
If you're really expecting miners are going to be constantly telling
their pool "do exactly what I want or I solo mine", I think you're pretty
likely to be disappointed by whatever the future holds... By its nature,
solo mining is something that can only be done profitably by relatively
few players at any given time; it's only potentially decentralised if the
total market for Bitcoin ownership/usage is itself very small.
Heck, we can observe right now that even *pools* aren't willing to insist
on the right to choose their own work when they can get smoother payouts
by letting someone else choose the work.
The only realistic way I see to improve mining decentralisation is
to make it easier to setup a viable competing pool when none of the
existing ones are being reasonable. If setting up a pool requires you
to do statistical analysis and setup KYC to avoid attacks from existing
players, that seems like a pretty big road-block.
Cheers,
aj
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zr61M64kQlYIBuzO%40erisian.com.au.
|
