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
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
|
Delivery-date: Tue, 19 Mar 2024 07:14:56 -0700
Received: from mail-oi1-f183.google.com ([209.85.167.183])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBAABBWF342XQMGQEOYOZK3Q@googlegroups.com>)
id 1rmaEx-0006Hb-5T
for bitcoindev@gnusha.org; Tue, 19 Mar 2024 07:14:56 -0700
Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-3c37b995ed6sf3804834b6e.3
for <bitcoindev@gnusha.org>; Tue, 19 Mar 2024 07:14:54 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1710857689; cv=pass;
d=google.com; s=arc-20160816;
b=eDrofKDhBzAmwhacLbY6E60KouJDFHWIBLuKQuOLzsrwmatahKs6y7ZwQ16jJe3u+/
IpUXZgCko5CNyvf5XSH3oQ1H6ezda/4906pj0rmY8e4cYwKGFMhro5xVvqqiOkfT/TzX
hxo95tTyIEf0jG96YFdheMxZ5xmvgx8r0Ur8mo8Y2M/M/YjNYrXELVm39xMDfddBynef
l7oNkb0yku6BPuiQiN9rh+hnOqiXPIupZx8ZTf/RaR9TpKDF9D9e0KmFCi60lYl/qIu6
/YDvGnIFsOblDEZdsjOiX5g69Bi4kJAoxGVIjt2eqqCd3ZdK7XfiO9ooLXTdmawACNIz
ooiQ==
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:reply-to:mime-version:feedback-id
:references:in-reply-to:message-id:subject:cc:from:to:date
:dkim-signature;
bh=QaOygfK0R7Cr+DcBdrWf0ntG3hrBGKyvQnaCyN0dwWA=;
fh=GVB+1P1O2B+vZfcRUYlm65Gl0yMDxmkEx6K6wwB7DlQ=;
b=P6wirvDdWVz20igLH6n+m2+9ra0r//A6YAyeqKbfeHhr4Nulue81Vo9d98VrWchJfx
ieokXBdVjoceCaUDoSShBpfVGUfN/xn/5N//lSj8OuHe+4dvxaeNfuTossH0a/qYWysy
XB8a7lTsmBUjgJnzVxmThNJmocXDpgSrTpMRYT1ckQIb9OaFeIQrHT+aU+dSF+xkSQPk
crl7D3o3sGjlYWpEu3t2/mJ8Nwvqj/DpsgiqZ/8bfnALJrCmlq6TPfD/JrPJjiAUEexF
W58XIgVjIXcHWb/IHlH7/2l808/nGfHU/3f08NurhHb2In35hSPM/3sJusVGMB9evS2w
v5IQ==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GwQrjFJA;
spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=fjahr@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1710857689; x=1711462489; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:reply-to
:x-original-authentication-results:x-original-sender:mime-version
:feedback-id:references:in-reply-to:message-id:subject:cc:from:to
:date:from:to:cc:subject:date:message-id:reply-to;
bh=QaOygfK0R7Cr+DcBdrWf0ntG3hrBGKyvQnaCyN0dwWA=;
b=ItmxgVgy3OGbkC5UqKYxYpKwNhELweC4/EpITy2bIbNBLVz9K1JucPaUocb5kW9O/J
m5r6WK4r9GBp76ZVT7LLtDoIA3N5esdHQQ9Y/uSiFIZhvdtMkKcmm3IImvs8R76Vfa+/
7thg/hxVuCreq/dH9drBO9e+vSwmaYUQmic+nmQE63TNtFmJFtlO5rrHzYGEoolX/xLb
Dg93iBDnvWrGD+yDqo3R2+59n6ym/h1eWFurB03tVqbZJjuydM3I70YWxYA3g4ywK1gK
pWD0uMibLYQgogSxCQeQBGm9AFJgxRvHZqXzYEBn6qKYebVRw4LVfIL/cV1NTgQQqErF
YU/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1710857689; x=1711462489;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:reply-to
:x-original-authentication-results:x-original-sender:mime-version
:feedback-id:references:in-reply-to:message-id:subject:cc:from:to
:date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=QaOygfK0R7Cr+DcBdrWf0ntG3hrBGKyvQnaCyN0dwWA=;
b=Uvg56DwafiLc3WSdt3t4tj7jshFnrJ5KWArS4uhJHRmvsVWtYdrM667HvN804elFlS
gw6IsX3FoV+1MPxGG1OyWivbq2M8ha4CiH3QPam3krUSzsWYVr836aHdxmS+cbO+zw+E
REYoan39EQ6NaZ/HTA2gn8zjKsRfg1DdMBPVGR8FBQhOWXcZ2RqTwh81C6mbUCoyH/yR
W8Ggoz3XHxtlOnymaPmOIUoBYChoemZLrxpImpUGggUKAS/lyq2d7Lji/IV0MUJN82pq
sGB9xOPG4XB2lHNzmv+KWF9q0RfsUgRT/Ii8vwWd59MmrAn+LfEqwZW0ldZ5uafFAvwr
UFUw==
X-Forwarded-Encrypted: i=2; AJvYcCXJ/3y4VQaX2sW0ohDDj3sf0833xHV9OP3E0dpTy/MrmWkCd8SBE7vkySaOZhJrk79y/7w42PlIgo7uIFoYG/7TQqZBeVo=
X-Gm-Message-State: AOJu0YyX6TSZ7VGGYARZV5bXYumE8iENdI5+cu2NjCp/c05I8B4NFa8G
0g5WOVxp6VfxdUUMg8+AyrJO5le4W0CNFmbvfNjIgTeRlttGj2Vl
X-Google-Smtp-Source: AGHT+IGI4kAJ/OS44HqFTxBENFSnsGH6rZx0gnWtN7qLttTdHHSJmjPwxD3mPVax4v2CLbU6qpXYpg==
X-Received: by 2002:a05:6808:3207:b0:3c2:3e23:f7b7 with SMTP id cb7-20020a056808320700b003c23e23f7b7mr18601640oib.38.1710857688958;
Tue, 19 Mar 2024 07:14:48 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:5d3:b0:430:d00d:93c5 with SMTP id
d19-20020a05622a05d300b00430d00d93c5ls2351661qtb.2.-pod-prod-03-us; Tue, 19
Mar 2024 07:14:48 -0700 (PDT)
X-Received: by 2002:a05:620a:6746:b0:789:d965:2714 with SMTP id rq6-20020a05620a674600b00789d9652714mr80567qkn.6.1710857688171;
Tue, 19 Mar 2024 07:14:48 -0700 (PDT)
Received: by 2002:a05:620a:4012:b0:789:cb27:7cb6 with SMTP id af79cd13be357-78a100011afms85a;
Tue, 19 Mar 2024 07:11:15 -0700 (PDT)
X-Received: by 2002:a5d:42cf:0:b0:33e:7133:ee31 with SMTP id t15-20020a5d42cf000000b0033e7133ee31mr10192933wrr.40.1710857473338;
Tue, 19 Mar 2024 07:11:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1710857473; cv=none;
d=google.com; s=arc-20160816;
b=LkmHecXDZZrezJjjtnqyhRAePL4AvBL+0YNpYqLaZgv5kcOpOkxyDzQya/2SgUQtUu
oJm/dCcdxOmvr48GQ22Z728/kf29l1l+CPvqaeZQQTWYUX5qICbq2CfkwbbGg5y+GvJS
9OZmUK8pNqq1ZP8vXXIFwdRy+kvyDhOrkuviMBY/6nXeJCozLEMhHSUs3pnlTfHYz0pa
Udncm2QJfeix0mbvKKTQj05+wUekvgureGmUaXRrKJ5lLJ6TlskfTK7uT1TRQeeaE+1s
mtCqpHPF6zjmVu9HBp+3hA8++3mtRo9s2xEX7FIu7Vf0UkHALBw66d84RwhJ3mBgWMoo
9iJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=mime-version:feedback-id:references:in-reply-to:message-id:subject
:cc:from:to:date:dkim-signature;
bh=OXscnoH8zYom53MR5WJxwELwVUD3kSLFnrjFizpfS3E=;
fh=l8Hj30ukzhYsUs+eNv/HBPfAp3+6h8f6Tbw0NJE11gg=;
b=uA01CdeOx7QzHnTgkKYlr0ZUWU0zmQkc/r4vwxxUQBA1x09dQStCBppDK/5WhNCH3g
e/rbqyf90jYPHBqmb07u4dmW7Orfl1/mI6kAipSKDdgIARw9jVRA2WGAjxCtwfWSwsSm
nvWDKqsDCLG4sxSpI6WfYOa3xUe0rQMZ7HWZz1J8RlzXog0xAxSdeuFwDs88XxL+nIN1
5QV9hefrD2RMeg85ZvJYsbPeKptauprYTpSkNbY0GvPRe47TnItRcGnBYXbGS9Iie5+W
Hu9QkMld1M87RWwjbsiT27Kb8uaMMld7kBijp4sCCo0/ZOow3oh5b5NB89VQyF08nEu1
CCpA==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=GwQrjFJA;
spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=fjahr@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch. [185.70.40.131])
by gmr-mx.google.com with ESMTPS id h8-20020a5d4fc8000000b0033da656f9edsi569689wrw.0.2024.03.19.07.11.13
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 19 Mar 2024 07:11:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.131 as permitted sender) client-ip=185.70.40.131;
Date: Tue, 19 Mar 2024 14:10:43 +0000
To: =?utf-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Anyone can boost - a more efficient alternative to
anchor outputs
Message-ID: <45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzSIP98QvIOjtcnIdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4=@protonmail.com>
In-Reply-To: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
References: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
Feedback-ID: 5067558:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_B1pYHnWdCoxv9mkXTkJgoWsCbvIbprqlkdUIocjo4"
X-Original-Sender: fjahr@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@protonmail.com header.s=protonmail3 header.b=GwQrjFJA;
spf=pass (google.com: domain of fjahr@protonmail.com designates
185.70.40.131 as permitted sender) smtp.mailfrom=fjahr@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Fabian <fjahr@protonmail.com>
Reply-To: Fabian <fjahr@protonmail.com>
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: -1.0 (-)
This is a multi-part message in MIME format.
--b1_B1pYHnWdCoxv9mkXTkJgoWsCbvIbprqlkdUIocjo4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Martin,
at first glance your idea sounds fairly similar to Jeremy Rubin's transacti=
ons sponsoring from 2020, though he proposed a different structure for refe=
rencing the sponsored transaction and not the annex [0]. The concept was di=
scussed further discussed in a long mailing list thread in 2022 [1].
Whether your idea is indeed similar or if there are substantial differences=
that I have missed, I think it would be interesting if you could reference=
the prior suggestions and contrast them to your solution, i.e. explicitly =
tell us what makes your proposal a better idea. Thanks a lot!
Best,
Fabian
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September=
/018168.html
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/=
019879.html
On Tuesday, March 19th, 2024 at 10:47 AM, Martin Habov=C5=A1tiak <martin.ha=
bovstiak@gmail.com> wrote:
> Hello everyone,
>
> For a while I was thinking that anchor outputs/CPFP are wasteful and I be=
lieve I have finally found a better way of doing them. I wrote up a documen=
t describing the solution here: https://gist.github.com/Kixunil/6ae6f787db3=
6d0d5ed3220f5bcece7f7
>
> Here's a copy of the proposal for your convenience:
>
> # Anyone can boost - a more efficient alternative to anchor outputs
>
> ## Abstract
>
> Bitcoin protocols using presigned transactions (e.g. Lightning Network, F=
irefish etc) face a problem with predicting fees of the presigned transacti=
ons.
> One possibility is to guess the future fee rate but that risks that the t=
ransaction will not be included in a block fast enough and it also risks wa=
sting satoshis on fees.
> Another possibility is to use CPFP which may require adding more outputs =
- so called "anchor outputs".
> The drawbacks of anchor outputs are increased transaction size and potent=
ially decreased privacy since the anchor outputs usually use "suspiciously =
low" amounts.
> Further, anchor outputs may pollute UTXO set if the presigned transaction=
confirms anyway (because it also had high enough fee) but the outputs are =
uneconomical to spend.
> This document proposes a new solution that could not only solve these iss=
ues but bring even more efficiency gains in the future.
>
> ## Solution
>
> As stated in the abstract, anchor outputs increase the size and thus the =
cost of transaction.
> So starting from the ideal (no additional data in the boosted transaction=
), we would like to boost any arbitrary transaction.
> We observe that this is actually already possible by paying big mining po=
ols directly.
> However this is detrimental to mining decentralization, not very accessib=
le to general public and the expected confirmation time is worse than in ca=
se of CPFP, when the whole network mines the transaction.
> A simple way to allow anyone boosting any transaction is to put the TXID =
of the boosted transaction into the boosting transaction's annex and have a=
consensus rule that the boosting transaction is only valid if the boosted =
tranation is in the same block.
> Let's call this "anyone can boost".
>
> At first sight this looks broken because of the pinning problem.
> Today, if ANYONECANSPEND output is used an attacker could boost a transac=
tion of someone else in a way that would make it stuck in the mempool.
> This is because of policy rules protecting the network against DoS attack=
s, so apparently the rules cannot be relaxed.
> The rules are designed specifically to impose cost on attackers.
>
> The reason why anyone can boost is not actually broken is that multiple i=
ndependent transactions can boost the same transaction.
> This brings another resource into the picture: new UTXOs.
> Thus when a transaction is boosted and a new transaction appears that is =
boosting it too, it can be considered by the anti-DoS rules separately.
> An attacker can't use this to DoS the network because it requires having =
multiple UTXOs which is already costly.
> When a transaction is boosted by two transactions the fees simply add up.
> It's also possible for a miner to ignore low-fee boosting transactions (p=
resumably created by an attacker) and only include the high fee ones.
>
> In other words, adding the boosting transaction to the mempool is equival=
ent to adding any other transaction to the mempool provided it pays suffici=
ent fee. It's just a bit larger and its fee rate is computed differently.
>
> ## Efficient fee boosting service
>
> A simplistic chain analysis would assume that the boosted and boosting tr=
ansactions are related because nobody would boost a transaction of someone =
else.
> This heuritic can be trivially broken by having an external service that =
boosts arbitrary transactions and gets paid via other means (LN).
> But this can be further improved by allowing boosting multiple transactio=
ns simply by putting more TXIDs into the boosting transaction.
> If two people are trying to boost two transactions at the same time they =
can almost halve the cost of the boosting transaction.
> An efficient boosting service would presumably collect orders and batch t=
he boosts. Further it could RBF the boosts if some didn't confirm yet and n=
ew orders arrived in the meantime.
> Because of significant cost reduction use of such services would be highl=
y incentivized undermining the heuristic.
>
> Notably, such boosting service would *not* be trustless but non-delivery =
could be easily proven using LN invoice and preimage.
> Perhaps it is possible to make the service trustless but that's probably =
not worth the effort given how low the amounts are.
>
> As an aside, there was recently a post in the local community that someon=
e made a low-fee transaction without RBF enabled and the receiver couldn't =
CPFP.
> I assume such cases happen more than once.
> If this service existed the transaction could've been trivially boosted b=
y anyone.
>
> Another interesting example is someone saying that figuring out how to bo=
ost a transaction took him a while. (IIRC it was an LN channel open.) Havin=
g such service could greatly simplify fee boosting in many cases since one =
would only have to copy-paste the txid, which probably all wallets provide.
>
> ## Known downsides
>
> ### This requires a soft fork
>
> Soft forks can be contentious and difficult to deploy.
> This rule is also unusual because it causes interaction between transacti=
on within the same block.
> However the code should be pretty simple: put all tx ids into a set and t=
hen for each boosting transaction check that all of its txids are in the se=
t.
> This allows loops but that shouldn't be a problem.
> The loops can be also disabled by simply progressively iterating over tra=
nsactions and adding the txid to the set *after* its annexes were checked.
>
> It may be possible to relax the RBF rules in some other way to enable ext=
ernal boosting for transactions that opt-into it. A vague idea was to allow=
replacing when each input of a transaction has ANYONECANPAY flag but its i=
nteraction with other rules is questionable. Perhaps this can be developed =
further but not needing an additional output is both more efficient and mor=
e user-friendly.
>
> ### This requires having a special output
>
> Unfortunately annex cannot be added to any signature but only to script s=
pend taproot signatures.
> Since this feature is most useful for presigned transactions the entities=
performing them could simply prepare the outputs beforehand. (e.g. LN impl=
ementations could make it built-in)
> And for those who did not prepare the boosting services would provide an =
option.
>
> Future witness versions could be designed with this in mind and enable an=
nex regardless of spend type which would make things simpler and save even =
more space (key spend is cheaper).
>
> ### This destroys fee betting
>
> Currently it is possible for two people to bet on the height of the fees =
in the future: they make a transaction that moves their satoshis into 2-of-=
2 multisig and then pre-sign two transactions with different fee rates and =
lock times.
> However this is already vulnerable to miner collusion and to my knowledge=
nobody uses this.
> It could be preserved by requiring that the boosted transactions opt-in t=
o boosting by using version 3 but that could decrease privacy and would rei=
ntroduce potential for stuck transactions that cannot be boosted.
>
> ## Disclosure
>
> I'm a contractor who wrote the core of Firefish smart contract, a protoco=
l which would benefit from this feature.
> I was not paid to come up with this idea, I just believe this would be a =
generally useful feature.
>
> --
> 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/msgi=
d/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw%40mail.g=
mail.com.
--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzSIP98QvIOjtc=
nIdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4%3D%40protonmail.com.
--b1_B1pYHnWdCoxv9mkXTkJgoWsCbvIbprqlkdUIocjo4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hello Marti=
n,</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br=
></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">at f=
irst glance your idea sounds fairly similar to Jeremy Rubin's transactions =
sponsoring from 2020, though he proposed a different structure for referenc=
ing the sponsored transaction and not the annex [0]. The concept was discus=
sed further discussed in a long mailing list thread in 2022 [1].</div><div =
style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><div s=
tyle=3D"font-family: Arial, sans-serif; font-size: 14px;">Whether your idea=
is indeed similar or if there are substantial differences that I have miss=
ed, I think it would be interesting if you could reference the prior sugges=
tions and contrast them to your solution, i.e. explicitly tell us what make=
s your proposal a better idea. Thanks a lot!</div><div style=3D"font-family=
: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family:=
Arial, sans-serif; font-size: 14px;">Best,</div><div style=3D"font-family:=
Arial, sans-serif; font-size: 14px;">Fabian</div><div style=3D"font-family=
: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family:=
Arial, sans-serif; font-size: 14px;">[0]: <span><a target=3D"_blank" =
rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2020-September/018168.html">https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2020-September/018168.html</a></span></d=
iv><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">[1]:&nbs=
p;<span><a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879=
.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Februar=
y/019879.html</a></span></div><div class=3D"protonmail_quote">
On Tuesday, March 19th, 2024 at 10:47 AM, Martin Habov=C5=A1tiak &l=
t;martin.habovstiak@gmail.com> wrote:<br>
<blockquote class=3D"protonmail_quote" type=3D"cite">
<div dir=3D"auto">Hello everyone,<div dir=3D"auto"><br></div><d=
iv dir=3D"auto">For a while I was thinking that anchor outputs/CPFP are was=
teful and I believe I have finally found a better way of doing them. I wrot=
e up a document describing the solution here: <a href=3D"https://gist.githu=
b.com/Kixunil/6ae6f787db36d0d5ed3220f5bcece7f7" rel=3D"noreferrer nofollow =
noopener" target=3D"_blank">https://gist.github.com/Kixunil/6ae6f787db36d0d=
5ed3220f5bcece7f7</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">He=
re's a copy of the proposal for your convenience:</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"># Anyone can boost - a more efficient alternative=
to anchor outputs</div><div dir=3D"auto"><br></div><div dir=3D"auto">## Ab=
stract</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bitcoin protocols=
using presigned transactions (e.g. Lightning Network, Firefish etc) face a=
problem with predicting fees of the presigned transactions.</div><div dir=
=3D"auto">One possibility is to guess the future fee rate but that risks th=
at the transaction will not be included in a block fast enough and it also =
risks wasting satoshis on fees.</div><div dir=3D"auto">Another possibility =
is to use CPFP which may require adding more outputs - so called "anchor ou=
tputs".</div><div dir=3D"auto">The drawbacks of anchor outputs are increase=
d transaction size and potentially decreased privacy since the anchor outpu=
ts usually use "suspiciously low" amounts.</div><div dir=3D"auto">Further, =
anchor outputs may pollute UTXO set if the presigned transaction confirms a=
nyway (because it also had high enough fee) but the outputs are uneconomica=
l to spend.</div><div dir=3D"auto">This document proposes a new solution th=
at could not only solve these issues but bring even more efficiency gains i=
n the future.</div><div dir=3D"auto"><br></div><div dir=3D"auto">## Solutio=
n</div><div dir=3D"auto"><br></div><div dir=3D"auto">As stated in the abstr=
act, anchor outputs increase the size and thus the cost of transaction.</di=
v><div dir=3D"auto">So starting from the ideal (no additional data in the b=
oosted transaction), we would like to boost any arbitrary transaction.</div=
><div dir=3D"auto">We observe that this is actually already possible by pay=
ing big mining pools directly.</div><div dir=3D"auto">However this is detri=
mental to mining decentralization, not very accessible to general public an=
d the expected confirmation time is worse than in case of CPFP, when the wh=
ole network mines the transaction.</div><div dir=3D"auto">A simple way to a=
llow anyone boosting any transaction is to put the TXID of the boosted tran=
saction into the boosting transaction's annex and have a consensus rule tha=
t the boosting transaction is only valid if the boosted tranation is in the=
same block.</div><div dir=3D"auto">Let's call this "anyone can boost".</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">At first sight this looks b=
roken because of the pinning problem.</div><div dir=3D"auto">Today, if ANYO=
NECANSPEND output is used an attacker could boost a transaction of someone =
else in a way that would make it stuck in the mempool.</div><div dir=3D"aut=
o">This is because of policy rules protecting the network against DoS attac=
ks, so apparently the rules cannot be relaxed.</div><div dir=3D"auto">The r=
ules are designed specifically to impose cost on attackers.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">The reason why anyone can boost is no=
t actually broken is that multiple independent transactions can boost the s=
ame transaction.</div><div dir=3D"auto">This brings another resource into t=
he picture: new UTXOs.</div><div dir=3D"auto">Thus when a transaction is bo=
osted and a new transaction appears that is boosting it too, it can be cons=
idered by the anti-DoS rules separately.</div><div dir=3D"auto">An attacker=
can't use this to DoS the network because it requires having multiple UTXO=
s which is already costly.</div><div dir=3D"auto">When a transaction is boo=
sted by two transactions the fees simply add up.</div><div dir=3D"auto">It'=
s also possible for a miner to ignore low-fee boosting transactions (presum=
ably created by an attacker) and only include the high fee ones.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">In other words, adding the boostin=
g transaction to the mempool is equivalent to adding any other transaction =
to the mempool provided it pays sufficient fee. It's just a bit larger and =
its fee rate is computed differently.</div><div dir=3D"auto"><br></div><div=
dir=3D"auto">## Efficient fee boosting service</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">A simplistic chain analysis would assume that the b=
oosted and boosting transactions are related because nobody would boost a t=
ransaction of someone else.</div><div dir=3D"auto">This heuritic can be tri=
vially broken by having an external service that boosts arbitrary transacti=
ons and gets paid via other means (LN).</div><div dir=3D"auto">But this can=
be further improved by allowing boosting multiple transactions simply by p=
utting more TXIDs into the boosting transaction.</div><div dir=3D"auto">If =
two people are trying to boost two transactions at the same time they can a=
lmost halve the cost of the boosting transaction.</div><div dir=3D"auto">An=
efficient boosting service would presumably collect orders and batch the b=
oosts. Further it could RBF the boosts if some didn't confirm yet and new o=
rders arrived in the meantime.</div><div dir=3D"auto">Because of significan=
t cost reduction use of such services would be highly incentivized undermin=
ing the heuristic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Notab=
ly, such boosting service would *not* be trustless but non-delivery could b=
e easily proven using LN invoice and preimage.</div><div dir=3D"auto">Perha=
ps it is possible to make the service trustless but that's probably not wor=
th the effort given how low the amounts are.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">As an aside, there was recently a post in the local co=
mmunity that someone made a low-fee transaction without RBF enabled and the=
receiver couldn't CPFP.</div><div dir=3D"auto">I assume such cases happen =
more than once.</div><div dir=3D"auto">If this service existed the transact=
ion could've been trivially boosted by anyone.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Another interesting example is someone saying that f=
iguring out how to boost a transaction took him a while. (IIRC it was an LN=
channel open.) Having such service could greatly simplify fee boosting in =
many cases since one would only have to copy-paste the txid, which probably=
all wallets provide.</div><div dir=3D"auto"><br></div><div dir=3D"auto">##=
Known downsides</div><div dir=3D"auto"><br></div><div dir=3D"auto">### Thi=
s requires a soft fork</div><div dir=3D"auto"><br></div><div dir=3D"auto">S=
oft forks can be contentious and difficult to deploy.</div><div dir=3D"auto=
">This rule is also unusual because it causes interaction between transacti=
on within the same block.</div><div dir=3D"auto">However the code should be=
pretty simple: put all tx ids into a set and then for each boosting transa=
ction check that all of its txids are in the set.</div><div dir=3D"auto">Th=
is allows loops but that shouldn't be a problem.</div><div dir=3D"auto">The=
loops can be also disabled by simply progressively iterating over transact=
ions and adding the txid to the set *after* its annexes were checked.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">It may be possible to relax t=
he RBF rules in some other way to enable external boosting for transactions=
that opt-into it. A vague idea was to allow replacing when each input of a=
transaction has ANYONECANPAY flag but its interaction with other rules is =
questionable. Perhaps this can be developed further but not needing an addi=
tional output is both more efficient and more user-friendly.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">### This requires having a special ou=
tput</div><div dir=3D"auto"><br></div><div dir=3D"auto">Unfortunately annex=
cannot be added to any signature but only to script spend taproot signatur=
es.</div><div dir=3D"auto">Since this feature is most useful for presigned =
transactions the entities performing them could simply prepare the outputs =
beforehand. (e.g. LN implementations could make it built-in)</div><div dir=
=3D"auto">And for those who did not prepare the boosting services would pro=
vide an option.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Future w=
itness versions could be designed with this in mind and enable annex regard=
less of spend type which would make things simpler and save even more space=
(key spend is cheaper).</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>### This destroys fee betting</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Currently it is possible for two people to bet on the height of the =
fees in the future: they make a transaction that moves their satoshis into =
2-of-2 multisig and then pre-sign two transactions with different fee rates=
and lock times.</div><div dir=3D"auto">However this is already vulnerable =
to miner collusion and to my knowledge nobody uses this.</div><div dir=3D"a=
uto">It could be preserved by requiring that the boosted transactions opt-i=
n to boosting by using version 3 but that could decrease privacy and would =
reintroduce potential for stuck transactions that cannot be boosted.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">## Disclosure</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">I'm a contractor who wrote the core of F=
irefish smart contract, a protocol which would benefit from this feature.</=
div><div dir=3D"auto">I was not paid to come up with this idea, I just beli=
eve this would be a generally useful feature.</div><div dir=3D"auto"><br></=
div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw=
%40mail.gmail.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">h=
ttps://groups.google.com/d/msgid/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8n=
VK1uN44u-sz5Hbb-SbjVYw%40mail.gmail.com</a>.<br>
</blockquote><br>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzS=
IP98QvIOjtcnIdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzSIP98QvIOjtcn=
IdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4%3D%40protonmail.com</a>.<br />
--b1_B1pYHnWdCoxv9mkXTkJgoWsCbvIbprqlkdUIocjo4--
|