path: root/78/e8be6cb786ea2880a307603a681ce6e50512fb

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]:&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--