From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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?= From: "'Fabian' via Bitcoin Development Mailing List" 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: References: 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 Reply-To: Fabian Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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
Hello Marti= n,
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].

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!

Best,
Fabian

[0]: https://lists.linuxfo= undation.org/pipermail/bitcoin-dev/2020-September/018168.html
On Tuesday, March 19th, 2024 at 10:47 AM, Martin Habov=C5=A1tiak &l= t;martin.habovstiak@gmail.com> wrote:
Hello everyone,

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: https://gist.github.com/Kixunil/6ae6f787db36d0d= 5ed3220f5bcece7f7

He= re's a copy of the proposal for your convenience:
# Anyone can boost - a more efficient alternative= to anchor outputs

## Ab= stract

Bitcoin protocols= using presigned transactions (e.g. Lightning Network, Firefish etc) face a= problem with predicting fees of the presigned transactions.
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.
Another possibility = is to use CPFP which may require adding more outputs - so called "anchor ou= tputs".
The drawbacks of anchor outputs are increase= d transaction size and potentially decreased privacy since the anchor outpu= ts usually use "suspiciously low" amounts.
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.
This document proposes a new solution th= at could not only solve these issues but bring even more efficiency gains i= n the future.

## Solutio= n

As stated in the abstr= act, anchor outputs increase the size and thus the cost of transaction.
So starting from the ideal (no additional data in the b= oosted transaction), we would like to boost any arbitrary transaction.
We observe that this is actually already possible by pay= ing big mining pools directly.
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.
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.
Let's call this "anyone can boost".

At first sight this looks b= roken because of the pinning problem.
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.
This is because of policy rules protecting the network against DoS attac= ks, so apparently the rules cannot be relaxed.
The r= ules are designed specifically to impose cost on attackers.

The reason why anyone can boost is no= t actually broken is that multiple independent transactions can boost the s= ame transaction.
This brings another resource into t= he picture: new UTXOs.
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.
An attacker= can't use this to DoS the network because it requires having multiple UTXO= s which is already costly.
When a transaction is boo= sted by two transactions the fees simply add up.
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.

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.

## Efficient fee boosting service

=
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.
This heuritic can be tri= vially broken by having an external service that boosts arbitrary transacti= ons and gets paid via other means (LN).
But this can= be further improved by allowing boosting multiple transactions simply by p= utting more TXIDs into the boosting transaction.
If = two people are trying to boost two transactions at the same time they can a= lmost halve the cost of the boosting transaction.
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.
Because of significan= t cost reduction use of such services would be highly incentivized undermin= ing the heuristic.

Notab= ly, such boosting service would *not* be trustless but non-delivery could b= e easily proven using LN invoice and preimage.
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.

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.
I assume such cases happen = more than once.
If this service existed the transact= ion could've been trivially boosted by anyone.

<= /div>
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.

##= Known downsides

### Thi= s requires a soft fork

S= oft 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 then for each boosting transa= ction check that all of its txids are in the set.
Th= is allows loops but that shouldn't be a problem.
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.
=

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.

### This requires having a special ou= tput

Unfortunately annex= cannot be added to any signature but only to script spend taproot signatur= es.
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)
And for those who did not prepare the boosting services would pro= vide an option.

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).

### 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-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 dir=3D"auto">
## Disclosure

I'm a contractor who wrote the core of F= irefish smart contract, a protocol which would benefit from this feature.
I was not paid to come up with this idea, I just beli= eve 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 e= mail to bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion on the web visit h= ttps://groups.google.com/d/msgid/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8n= VK1uN44u-sz5Hbb-SbjVYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/b= itcoindev/45ghFIBR0JCc4INUWdZcZV6ibkcoofy4MoQP_rQnjcA4YYaznwtzSIP98QvIOjtcn= IdRQRt3jCTB419zFa7ZNnorT8Xz--CH4ccFCDv9tv4%3D%40protonmail.com.
--b1_B1pYHnWdCoxv9mkXTkJgoWsCbvIbprqlkdUIocjo4--