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
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
|
Return-Path: <alicexbt@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 73D77C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2023 06:26:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 3BFA940377
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2023 06:26:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3BFA940377
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=kpFig7FP
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2bTT2Gm-gVc4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2023 06:26:55 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
[188.165.51.139])
by smtp2.osuosl.org (Postfix) with ESMTPS id ED6FF4010C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Dec 2023 06:26:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ED6FF4010C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1702880806; x=1703140006;
bh=2IoC6AMjTn/CNJXs8pqIM7FHC0bg6aaZVv1IY7Zypdc=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=kpFig7FPhVNN8eSd0w+DXJzUrPGtVBFPB2aNNqOTiBgBVxj0QWNgjTn1N0YN8XlIP
nwBw8la6+ZiLVcWKzn366NXEOtl+2DCpW1d1ainGNN1CnVoNOzBCv2pqnlyWmcou0U
EysSX3US1/u/On20d/Cdrz+I+59YLycbE9vkXoKFtw5g1DdIjrH/ZUc0tPXbrOX5H5
KS68mE2gcWn79QmAsCBPkNAV1CjeIRH8EGUw3xRByGlJ/inOX5lmQpKM5+gLveC+TL
Dwt2NWAPw7i4G882GZFktkVDKQciYNW5PUZyDiLB85qA+xzgJ9Wv7KrpKMNiMRhWnC
caQtpbJmKYkOg==
Date: Mon, 18 Dec 2023 06:26:28 +0000
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <XwBIMrHjY7N3DkEDVgxTHI3W3BRhijP7d4Lr7jUiR6E_fPxxPF0YyeKXwwsFiKBNjvM9NVSHrCwXwZhLr69hsYxVDkT_NUXzyN6NvQjM6FE=@protonmail.com>
In-Reply-To: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
References: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 18 Dec 2023 09:19:13 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Addressing the possibility of profitable fee
manipulation attacks
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: Mon, 18 Dec 2023 06:26:58 -0000
Hi ArmchairCryptologist,
Bitcoin is working as expected and I don't see any 'manipulation' attacks i=
n the bidding for block space. Maybe we aren't used to such demand for bloc=
kspace on bitcoin. Additionally, fingerprinting based on fee rates and timi=
ng to attribute transactions to a single person is inaccurate. Various serv=
ices, such as unisat, are used for deploying and minting BRC20 tokens based=
on region, community etc. Consequently, a service broadcasting Bitcoin tra=
nsactions might appear as a single individual.
With regards to UTXO set, IBD for machines with enough RAM seems to be unaf=
fected, however I have not done benchmarking to compare IBD before and afte=
r inscriptions with less dbcache. Also the number of full nodes have increa=
sed in last one year.
> However, in practice, the attack appears to rely on exploiting the inhere=
nt decay used by fee estimation algorithms that are based on historical fee=
data. This causes many wallets to create transactions that overpay the nec=
essarily next-block fee by a significant amount - for example, the morning =
after the 700 sat/vB flood on December 16th, Bitcoin Core was still giving =
a six-block estimate of 529 sat/vB even though <250 sat/vB transactions wer=
e being mined.=20
Bitcoin Core fee estimation has known issues since years, and I would not r=
ecommended it for actual use, except for testing purposes.
Related discussion: https://github.com/bitcoin/bitcoin/issues/27995
> My proposed solution to this would be to add partial transaction fee burn=
ing.=20
NACK
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
On Sunday, December 17th, 2023 at 11:11 AM, ArmchairCryptologist via bitcoi=
n-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> ** Motivation **
> As everyone already knows, over the last seven months or so, the size of =
the mempool as well as transaction fees of on the bitcoin network have both=
been abnormally high. This tend has generally been ascribed to the introdu=
ction of ordinals, and while this may be both technically and actually true=
, disregarding the debate of whether ordinals is a "valid use" or the block=
chain or not, the specific patterns we are seeing for some of these transac=
tions have been making me somewhat suspicious that there could be other und=
erlying motivations for this trend.
>=20
> Crucially, as other people have noted, the dust UTXOs these ordinals tran=
sactions leave behind combined with the fact that consolidation transaction=
s are being priced out due to persistent high fees is also causing the size=
of the UTXO set to blow up. As you can see on the chart below, on April 30=
2023 there were roughly 90M UTXOs, while as of this writing roughly 7 mont=
hs later, there are more than 140M. Practically, this means that over the c=
ourse of the last year, the chainstate as stored by Bitcoin Core has increa=
sed from ~5GB to ~9GB.
>=20
> See https://www.blockchain.com/explorer/charts/utxo-count - the 3Y chart =
makes the sudden change in the rate of increase very obvious. More than twi=
ce the number of UTXOs has been added in the last six months than in the pr=
eceding two and a half years.
>=20
> While it is certainly not constant, if you watch the fee rates and timing=
of when transactions are broadcast using a live view of the mempool like m=
empool.space, you can see that especially during periods of low mempool inf=
lux like early mornings on weekends, there tends to be large bursts (often =
several hundred kvB worth) of tiny ordinals/BRC-20 transactions with a sing=
le dust UTXO broadcast right after each block is found, with a fee set mode=
rately higher than the current average of the top of the mempool, which mak=
es it highly likely that this is done by a single actor. There may of cours=
e be legitimate explanations for these patterns, like that they are simply =
taking advantage of the lower fees, but the impression they leave me is tha=
t they seem deliberately timed and priced to pad blocks during such periods=
to prevent the mempool from draining, under the guise of "minting" BRC-20 =
tokens.
>=20
> For example, in the two-minute span between blocks #820562 and #820563 fr=
om Sunday December 10th, over a thousand of these transactions were broadca=
st:
>=20
> https://mempool.space/block/000000000000000000015d5065ea2ade8bfd0bb948383=
5c907e34dd969854345
> https://mempool.space/block/000000000000000000001ae267367ade834627df7b119=
a2710091b3f5d8c1a88
>=20
> Most of these transactions have been in the 30-60 sat/vB range, with occa=
sional periods of increasingly higher-fee transactions going higher. The mo=
rning of Saturday December 16th is a good example of the latter, where ther=
e was an ~8 hour flood where the fees were pushed all the way up to 700 sat=
/vB. These are particularly suspicious, seeing as it would not make much se=
nse to "take advantage of lower fees" by flooding transactions with fees in=
creasingly and systematically set this much higher than the best next-block=
fee at this time of the week. There are many blocks during this period wit=
h noticeable large clusters of these high-fee BRC-20 transactions - for exa=
mple, see #821428 and #821485:
>=20
> https://mempool.space/block/000000000000000000011dd74372ff2d5fdec5e743134=
0a160b0304f3f145e82
> https://mempool.space/block/00000000000000000000653a2389a42549943c859e414=
f451f86944ac60b411b
>=20
> You would think that if someone were in fact making a large volume of tra=
nsactions specifically to inflate the transaction fees, they would eventual=
ly run out of funds to do so. In other words, considering how long this tre=
nd has been going on, they would either need to have exceptionally deep poc=
kets, or directly profit from the transaction fees being high. This line of=
thought lead me to consider the possibility that such patterns could be in=
dicative of ongoing fee manipulation by either a large miner or a consortiu=
m of miners, and whether such manipulation could be practically profitable,=
even with a minority hashrate. While miners have always had the ability to=
pad their own blocks with junk transactions, it seems to be generally assu=
med that at the very least there would be an opportunity cost of doing so, =
and that it would therefore would be unprofitable. The general ability to p=
ad all blocks with junk transactions would of course both be much more seve=
re and much less obvious. So if this were the case, I believe it would brea=
k a fundamental assumption to the design of Bitcoin - seeing as transaction=
fees are central to prevent DoS attacks on the blockchain, if such an atta=
ck could be done in a way where both the base costs and opportunity costs a=
re fully (or more than) recouped, we have a problem.
>=20
> Just to be clear - I'm not saying with any certainty that such an attack =
is currently ongoing, has taken place in the past, or will take place in th=
e future. Providing hard evidence of such would be difficult or impossible,=
so this should be considered pure conjecture based on circumstantial evide=
nce. As such, seeing as conspiracy theories are generally unhelpful, I will=
ultimately only consider whether an attack such as this could be theoretic=
ally profitable. All the transactions observed may very well be "legit" in =
the sense that they have nothing to do with fee manipulation, but for the s=
ake of argument we will run some numbers under the hypothesis that this is =
the ultimate goal, even if it is in fact coincidental.
>=20
>=20
> ** A short analysis, of the napkin kind **
>=20
> Simply put, and trivially, such an attack would be profitable if the net =
fees the participating miners spend on fee-stuffing transactions is less th=
an the increase in fees the participating miners can collect from "real" tr=
ansactions.
>=20
> The cost for carrying out the attack primarily has three factors: the rat=
io of participating miners, the ratio of fee-stuffing transactions required=
to maintain full blocks with a high fee level, and the per-transaction fee=
s required for these.
>=20
> The ratio of participating miners is important since it determines how mu=
ch of the spent fees are lost to miners that do not participate in the atta=
ck. If 20% of the hashrate participates, on average 20% of blocks will be m=
ined by these miners, recouping these fees. Which means the net amount of f=
ees spent on the attack in this case is 80% of the gross fees spent on the =
creating these transactions - the remaining fraction of the fees would be c=
ollected by the honest miners instead.
>=20
> Critically, this means that the higher the ratio of the hashrate is parti=
cipating, the lower the cost of the attack. If 100% of miners participate w=
ith a ratio of transactions equal to their hashrate, the cost of the attack=
is zero, since every participating miner will get back on average 100% of =
the fees they contributed, and 0% of the fees will be lost to honest miners=
(of which there are none).
>=20
> The ratio of fee-stuffing transactions required to maintain full blocks w=
ith a high fee level and their required fees would vary over time - weekend=
s have fewer transactions, for example, and consistently high fees would li=
kely reduce the number of people attempting to use the blockchain at all. N=
ote however that in the degenerate case where all miners are participating,=
these two factors would be much less important, since all spent fees are r=
ecouped anyway, so it would only affect the absolute number of fees spent f=
or real transactions.
>=20
>=20
> If all real transactions were fee-optimal, using low-balled fees based on=
the current mempool only and actively using fee bumping to barely squeak i=
nto a block, the total cost of the attack per block could be easily approxi=
mated as: (ratio of fee-stuffing transactions lost to honest miners) * (rat=
io of fee-stuffing transactions to real transactions) * (total block transa=
ction fees)
>=20
> However, in practice, the attack appears to rely on exploiting the inhere=
nt decay used by fee estimation algorithms that are based on historical fee=
data. This causes many wallets to create transactions that overpay the nec=
essarily next-block fee by a significant amount - for example, the morning =
after the 700 sat/vB flood on December 16th, Bitcoin Core was still giving =
a six-block estimate of 529 sat/vB even though <250 sat/vB transactions wer=
e being mined. This means that the actual cost would likely be much lower. =
Seeing as this would be difficult to model, we would need to estimate the a=
bsolute cost to maintain a 100% block fillrate with high fees over time bas=
ed on observations and some guesswork. Looking at the bursts of transaction=
s we have seeing over the last few months during low-influx periods, most o=
f them are in the 40-60 sat/vB range, so it seems reasonable to conclude th=
at you can maintain this high fee level with transactions averaging ~50 sat=
/vB.
>=20
> The increase in fees that can be collected from real transactions is also=
difficult to model. There is an opportunity cost for participating miners =
from mining their own fee-stuffing transactions instead of legitimate trans=
actions, and it would depend greatly both on how many transactions are will=
ing to outbid the fee-stuffing transactions at a particular fee level, the =
decay rate used by fee-estimation algorithms, as well as the cascading fee-=
related effects of blocks being full 100% of the time, leading to low-fee t=
ransactions never being mined. Due to the non-homogeneous nature of the eco=
system, estimating these factors individually would require a lot of (weak)=
assumptions, but we can make some higher-level estimates based on real-wor=
ld data by comparing the fees collected from mined transactions today compa=
red to fees collected a year ago.
>=20
> See https://www.blockchain.com/explorer/charts/transaction-fees - if we u=
se the 30D average, we were at around 20 BTC/day a year ago compared to aro=
und 150 BTC/day when this was written. With 144 blocks per day, this is app=
roximately 0.14 BTC/block a year ago, and 1.05 BTC/block right now.
>=20
> The gross profit for the attack would then simply be: ( (total average bl=
ock transaction fees with attack) - (total average block transaction fees w=
ithout attack) ) * (ratio of blocks mined by participating miners)
>=20
> Using these numbers, the cost of a hypothetical attack would have to be o=
n average less than 0.9 BTC per block mined by participating miners to be p=
rofitable.
>=20
> So let's plug in some hypothetical numbers, using these assumptions toget=
her with the current real-world data under the hypothesis that such an atta=
ck is currently taking place, and that the current fee spike can be explain=
ed by it.
>=20
> If we assume that 20% of miners participate in the attack and they need t=
o fill on average 20% of each block (200 kvB) with an average transaction f=
ee of 50 sat/vB to effectively maintain high fees:
>=20
> The average cost per block would be 50 sat/vB * 200000 vB =3D 0.1 BTC
>=20
> The gross profit would be 0.9 BTC * 0.2 =3D 0.18 BTC averaged per block
>=20
> This gives a net profit of 0.18 BTC - 0.1 BTC =3D 0.08 BTC averaged per b=
lock
>=20
> Which would result in an average daily net profit shared among the partic=
ipating miners of 144 * 0.08 =3D 11.52 BTC, or around US$ 500K at today's p=
rice. (Non-participating miners would of course profit as well.)
>=20
> Just to emphasize - the profits are averaged over all blocks mined on the=
network, not just the ones mined by participating miners, since the cost i=
s incurred on every block regardless of who mines it. With these numbers, t=
hese participating miners would have a loss of 0.1 BTC per block they did n=
ot mine, and a gain of 0.8 BTC for every block they did mine, with 20% of t=
he hashrate obviously averaging 1 in every 5 blocks - or somewhat restated,=
4 * -0.1 + 0.8 =3D 5 * 0.08 =3D 0.4 BTC per 5 blocks.
>=20
> If you keep the other hypothetical factors constant, the break-even numbe=
rs in this example would be an average fee-stuffing transaction fee of 90 s=
at/B, 11.1% participating miners, or 36% required fill rate.
> Observe also that miners would not have to actively coordinate or share f=
unds in any way to participate. If a miner with 10% of the participating ha=
shrate contributes 10% of the fee-stuffing transactions, they would also ge=
t back on average 10% of the total fees paid by transactions that are inclu=
ded in blocks mined by participating miners, giving them 10% of the profits=
. As such, each participating miner would simply have to watch the mempool =
to verify that the other participating miners are still broadcasting their =
agreed rate/ratio of transactions, the rest should average out over time.
>=20
> In short, I believe this is a real problem. The premise of this analysis =
is based on conjecture and casual observation which is vulnerable to confir=
mation bias, and obviously cannot be considered proof that anything fishy i=
s going on at present. However, regardless of the intent of these transacti=
ons, their existence and effect on the fee is obvious for everyone to see, =
so I feel relatively safe to conclude that under certain conditions where b=
locks are mostly full most of the time, a small-ish minority hashrate could=
potentially manipulate the network fees for a significant profit with no a=
ctive coordination. As we are seeing, this would cause both unnecessarily h=
igh fees for people wanting to use the blockchain, and long-term issues wit=
h a bloated UTXO set that affects both fully archiving and pruning Bitcoin =
Core nodes as well as all other software that needs to keep a record of uns=
pent transactions. In my opinion, it is necessary to address this.
>=20
>=20
> ** A possible solution, with some caveats **
>=20
> My proposed solution to this would be to add partial transaction fee burn=
ing. If 50% or more of transaction fees were burned, this should effectivel=
y curtail any incentive miners have for padding blocks with junk transactio=
ns in general, as it would both significantly reduce the amount of spent fe=
es they would be able to recoup, and also reduce the amount of benefit they=
gain from the transaction fees being high. The burn rate would however nec=
essarily have to be less than 100%, otherwise miners would not be incentivi=
zed to include any transactions at all, and might as well be mining empty b=
locks.
>=20
> While this change by itself could be implemented with a soft fork, miners=
would be (highly) unlikely to accept such a change, since it would directl=
y reduce the profits even for honest miners. However, this solution could e=
ffectively complement arguments made by Peter Todd and others regarding the=
future of block subsidy, which in short go along the lines that block subs=
idy halvings should be stopped at some point with a hard fork, leaving a pe=
rpetual fixed subsidy per block. By itself this would arguably make Bitcoin=
into an inflationary currency, which many people object to, but if you com=
bine it with partial fee burning, it could very well become deflationary in=
stead depending on how the fee market develops, while still providing a gua=
ranteed minimum reward per block. This would effectively alleviate the dang=
er of a deficient fee market compromising the security of the blockchain du=
e to low miner rewards at some point in the future, while only adding an "a=
bout" to the statement "there will only ever be 21 million coins".
>=20
> For example, if the collected fees in the year prior to such a hard fork =
being implemented were on average 1 BTC per block, and it was decided to bu=
rn 50% of the fees, the subsidy could be increased by a fixed 0.5 BTC which=
would not be affected by halvings. In other words, when the current subsid=
y starts approaching zero, we would be left with a perpetual static subsidy=
of 0.5 BTC and change per block, without drastically affecting the total c=
oin supply. Worst case, if fees collapsed entirely we would have an inflati=
on of ~0.1% per year=C2=A0(0.5 BTC/block * 144 blocks/day * 365 days/year =
=3D 26280 BTC/year) not taking permanently lost coins into account, while o=
n the other hand, if fees went higher still then the deflation would not ha=
ve a fixed limit, unless an absolute limit for burned fees per block was ad=
ded.
>=20
>=20
> I did briefly consider the possibility of doing this with a soft fork ins=
tead, where the "burned" fees were instead transferred into a special "subs=
idy fund address" that would be drawn from by miners to effectively increas=
e the block subsidy, but seeing as this would not remove the correlation be=
tween intentionally inflating fees and increasing miner rewards, I don't be=
lieve this would actually address this attack. For the same reason, adding =
a dynamic subsidy based on historic fee rates would have the same problem, =
so it would necessarily have to be a fixed additional subsidy.
>=20
> It is important to emphasize that if the goal is to fully address this ty=
pe of miner attack in general, increasing the blocksize would NOT be a viab=
le solution by itself. If the blocksize increase is large enough and the fr=
action of participating miners is low enough, then yes, it would probably t=
hwart it, but if the majority (or all) miners participated, it would have l=
ittle (or no) effect unless the blocksize was unbounded, which does not see=
m like a good idea. While the absolute amount of fees the miners would need=
to spend for fee stuffing would of course increase, the fraction of spent =
fees miners would recoup would not change, so if 100% of miners participate=
d, 100% of fees used in the attack would still be recouped regardless of th=
e absolute number of transactions it would take to fill a block. Furthermor=
e, the absolute number of transactions willing to outbid them would not cha=
nge, so the extra fees gathered from the attack would remain the same as we=
ll.
>=20
> Additionally, if the attack continued, the rate of increase of the size o=
f the UTXO set would likely increase by a similar factor as the blocksize i=
ncrease. As such, any blocksize increase at all would in my opinion necessa=
rily have to be combined with partial fee burning - possibly dynamic, based=
on the size of each block - to prevent exacerbating potential attacks that=
excessively and unnecessarily bloat the size of the UTXO set. It would how=
ever be natural add a modest and scaling increase as part of the same fork,=
seeing as the fee burning change would resolve the main argument against i=
t, since adding data to the blockchain would now always have a guaranteed c=
ost even for miners.
>=20
> Changing fee estimation algorithms across the board to not take historica=
l fee data into account, eliminating the long-term decaying fee effects obs=
erved after short-term flooding of high-fee transactions, would of course s=
ignificantly help prevent such attacks from being profitable in the first p=
lace without requiring any sort of fork. As such, I believe this should als=
o be done as a short-term makeshift solution. A less exploitable estimate c=
ould be made by limiting the algorithms to only use the current mempool sta=
te and influx rate, as well as possibly the estimated current blockrate and=
the arrival times of recent blocks. Additionally, wallets could pre-sign a=
number of replacement transactions spending the same UTXO(s) with graduall=
y increasing fees up to a maximum specified by the user, and automatically =
broadcast them in order as the state of the mempool changed. And I'm sure t=
here are additional strategies that could be used here as well to make the =
ecosystem more fee-optimal in general.
>=20
>=20
>=20
> Unfortunately, as long as some parties still use historic fee data for th=
eir fee estimation, the attack could still be effective up to a point. Paym=
ent providers like BitPay for example currently specify that you need to us=
e a historically high fee for the initial transaction for it to be accepted=
, and does not recognize replacement transactions that bump the fee.
>=20
>=20
> If you made it this far, thanks for reading my wall. Please let me know i=
f you find any serious mistakes in my assumptions and/or math that invalida=
te the whole premise, so I can stop thinking about it.
>=20
> --
> Sincerely,
> ArmchairCryptologist
|