Delivery-date: Tue, 19 Mar 2024 07:14:56 -0700
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"
Reply-To: Fabian <fjahr@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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]:&nbsp;<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&gt; 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&quot; 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--