path: root/33/0d94674619e20f9cf6a2f5113ffbec38e94e84

Delivery-date: Tue, 19 Mar 2024 02:55:51 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDZPZFXW2IMRBHWC4WXQMGQECLPT6GQ@googlegroups.com>)
	id 1rmWCD-0001fd-PA
	for bitcoindev@gnusha.org; Tue, 19 Mar 2024 02:55:50 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-5a20d31ea8fsf5730198eaf.3
        for <bitcoindev@gnusha.org>; Tue, 19 Mar 2024 02:55:49 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1710842143; cv=pass;
        d=google.com; s=arc-20160816;
        b=LsJI+d/mPGdzmuQvUv+IzOBac0CEPzkHWw+tkMplCxvo779tQWNWv56/Yqrkp7Xo0v
         6DslJj0R4UDZzf2l+lToKrLhy+QSiFZ8JFAf3xlyBiq++jVXydOTCMDe5/hU/OMSGKuk
         A7Q0bOD9GpdyA2T/vQQ8OfkwZLvviXLmUxcMqib/zLkMR1LD8Q7THOMaCTqQNA/sBQIK
         ZjwjW6AdHEx3IPsmpapx/jwDF4nohWjWJ2WbH1p+tidrx0ARIUL6SCcvGte6ZdjuMwCm
         0Ng5eJOu1lk3W6XA1FrNiwvErBSEh9SnGWTxVYHNzAPxYYbYhss55PHS8Tt38jEd7gnx
         1HmA==
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:to:subject:message-id:date:from
         :mime-version:sender:dkim-signature:dkim-signature;
        bh=4DZfiMOT8b7bgvGnHJsObaPU9aytD/fETpmSM0OlTgY=;
        fh=M5f5xyRiPcM4bJGYj2JiNbVcg3aWTral3JmO9+Q+RL4=;
        b=LpIqOqlCBPL2GyZOtgYN8LBvaKXUBJ0jPkto7YnTwsv7mZx4n9ns9jbxW4J6JSWgRl
         juZK7wWhNJ/y+8eJkY+u2DB1N0DvkaQGpld3z6UcAM7GIcr9U26QNQaJFWvprnlTBa8v
         mMxrtvDlZ5GELM7F0iP1wo/fnb/+Z86mm8WPF/3ic+sMwcJR2G5oLFeDQR/MhrVJy8CO
         Js0vpumuLd/86MpC+VYwfJ23WrlWJZ4DO2P8S8npACrDyaOM6VgMRT3N37TSz+pv120R
         WXyg5Io2uK4wMbYE3jvGCvHrr053bJc2Omirb1QP8lfu8Zf3zhkTYu6GUVqlUB5/aZa3
         nCqw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kSsQH+aM;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1710842143; x=1711446943; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:subject:message-id:date:from:mime-version
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=4DZfiMOT8b7bgvGnHJsObaPU9aytD/fETpmSM0OlTgY=;
        b=ioeFFCpPBMg6MUAP3PFX1RAg60mXnPqy06s8qjKT5UtoUZH40SNgyXfR/glqUUXPvQ
         gpRvkHouBreI8MTQKcEGwReRc1tjxrKF6tMv7SXVnIMBB6SSlwovuJRbeoJbwauKszbh
         ot0yCUCRwgeIx9zghEu99d74vkjeXhCI6qVAbYWbIzWngoY0bbq/62f7QHRnNfCR3J4O
         vYhw5q5JpAJt/VuBhGya17ByyNSNAaRCdoyLHivCM5DDO4ZuCAZnieod2at9xNXqx//2
         6MKKFL9k/eEi8pkl7F9DaX82kE4SPWk04cTTmBRKrySCC0tuejc6n4drJSLzMACPgEPA
         Sb9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710842143; x=1711446943; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:subject:message-id:date:from:mime-version:from
         :to:cc:subject:date:message-id:reply-to;
        bh=4DZfiMOT8b7bgvGnHJsObaPU9aytD/fETpmSM0OlTgY=;
        b=UNShWXnBoQFd94Ds7Pi9sBc8De9w2aayVuYA2N4FpPmoEZngY4ZY2hKHCbWd9Gn93D
         5jsn49uZgso3Me45fKtvMXfCloHYBYTusV1sMuRsHrfsdYDMj0TdShdK8tgT82O95dYS
         MAEvU9RU8/t5NQSNtgV4sR9zLLGn/9mJyyzEfQHGPE7Y2C+BtheAjewotWsquhwSe4ui
         VrlWZtSS1nL7V7oAuVeFeslUmEieVpaOLmUEnx1ML7RWUguF6NE9kya5jNny5WhmKMRf
         hwg7y124B4b85O47MFa6xUypKYV0CV++exjFxKFN+j/B0CRmIW8922fCB98+i09kPRjF
         G+hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710842143; x=1711446943;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:subject:message-id:date:from:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4DZfiMOT8b7bgvGnHJsObaPU9aytD/fETpmSM0OlTgY=;
        b=rEfp1BQfFDfnM8zvBYBuu1X5xbT7fdZTuBOy3ltHcdLSzxSN1dGswHVnYfaudpNo4Z
         2ifspbBmtOth9mIYdugcs5pqfvt2hSUsxyNe38mEfBxC6ww653XvQxcqGZo6dRkufX8l
         SXiGqZMUFf3JBsHUG8v9Cka485n4/xcStbhnMW+NCnWUQqAj4aNO2v8wie9ZCVgqUs8G
         mB0cbjuBUx0354pdnWwIec+/w9Lm6yrQVjbHMGtoBBl6/rZSaSbQ1QviaS6HFwjIrygJ
         nkh7v/YtmgH/CFaRTHCcYBJTep37ZTVcZV3UT2n6YoCp2An5KTclYZk+C6HKGx+eh7Bc
         kY4g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXyEodhuKsWt4Ng3hRSg9n1B/du+gJsTGcQ3vKDZkC+abujIBuBAmeAchOItF/KYhqiOiNVomzujdPil5Iwfr6GaQ+ZPm0=
X-Gm-Message-State: AOJu0YwFbTEyFYz4HfmgH2INLWWaQC5ABC9E9114bcK2XgAw+PUrj+Fy
	YGlS5nL3N0jMrNlUoyFeDPUmk7X01riFm7krV6HGTJLRHj1/3lXB
X-Google-Smtp-Source: AGHT+IG0k0Uia6li7x2OrRiGc9OigMGy6AjPk86KKy9KwkXySDjAgFXW6RS4rg41AMUsI6GHdSXbMw==
X-Received: by 2002:a05:6820:2981:b0:5a4:b8fb:1ed8 with SMTP id dq1-20020a056820298100b005a4b8fb1ed8mr2460356oob.7.1710842143081;
        Tue, 19 Mar 2024 02:55:43 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:929c:0:b0:5a1:e060:cd29 with SMTP id i28-20020a4a929c000000b005a1e060cd29ls4449358ooh.2.-pod-prod-01-us;
 Tue, 19 Mar 2024 02:55:42 -0700 (PDT)
X-Received: by 2002:a05:6820:2229:b0:5a4:d45a:d0fb with SMTP id cj41-20020a056820222900b005a4d45ad0fbmr67377oob.1.1710842142056;
        Tue, 19 Mar 2024 02:55:42 -0700 (PDT)
Received: by 2002:a05:6808:2182:b0:3c1:e832:1745 with SMTP id 5614622812f47-3c25ed95b82msb6e;
        Tue, 19 Mar 2024 02:47:38 -0700 (PDT)
X-Received: by 2002:a05:6870:c092:b0:21e:df8b:5280 with SMTP id c18-20020a056870c09200b0021edf8b5280mr2008588oad.27.1710841657340;
        Tue, 19 Mar 2024 02:47:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1710841657; cv=none;
        d=google.com; s=arc-20160816;
        b=dR4IPjSfZ+uP2u9CN5oAUDoXWyJWZA99hqMGBfmA6e7P/+uh2PH88t7GrAHzscCjE+
         DawYADSEyv12I48TY+ONo3g6NP+4IZLn3Ur1w25r/Z1xHFhDIWz6oD96WnsdsD0K0DOr
         APoBbWvQl4/jACbQnMoTuRG7pEByjmLYSVXvBnbGhOQePWfoHP+z/W1jdhPUbiI1U4Ji
         8Y5eZsgBCoEmmsBAW/6eTInkH6LOUdRmJPbfYmdGT2InwWNhqXVqje7CdOQgw/FbnBJV
         OPBPTzDdbqzrqfaBVFlgiSjvz4pwsPKv2gP4rEgv5hbjf9gVfuM6oZmTAl+WVmT0/TNd
         zLCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=to:subject:message-id:date:from:mime-version:dkim-signature;
        bh=PT/Jp20w+fi177fyytpVye7Vb8AgEGzASg6i7ezOoyY=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=uv8k5OTHKBsTUV7GaZ0W+VhOBwGsbd4Rl1M1GHna8GxajxbfHO9diY41lMn3UWLboM
         4Oe9bV/Fag6cMGBmAsdTH/nq+z/v3G17vqLkOG1d6c74CAlWihAwifMoa2pgnhCLP2yK
         HGnWs7GrozEf4HstzJj/NOww35bZbGy/87qeSOHAnaEioX+GtlXeAm2jyJQPnLdosgL6
         2vCDAzItDccVjFx3vUZBhflE2qpW5ofWn0uL+cGSpbliZu9hFensbCCD32HocOpgSEnv
         ciAMfliR03Gu1e/GFcM2zstDiP54WWEhuyGGl2tnYw+elID4MvQSICnIVQYB7m+H6Byk
         JsUw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=kSsQH+aM;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com. [2607:f8b0:4864:20::e31])
        by gmr-mx.google.com with ESMTPS id td9-20020a056871878900b00221d905d771si2010873oab.2.2024.03.19.02.47.37
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 19 Mar 2024 02:47:37 -0700 (PDT)
Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) client-ip=2607:f8b0:4864:20::e31;
Received: by mail-vs1-xe31.google.com with SMTP id ada2fe7eead31-4767bf3e2a2so1171177137.2
        for <bitcoindev@googlegroups.com>; Tue, 19 Mar 2024 02:47:37 -0700 (PDT)
X-Received: by 2002:a05:6102:21bc:b0:476:53ff:e4a1 with SMTP id
 i28-20020a05610221bc00b0047653ffe4a1mr1465120vsb.3.1710841656438; Tue, 19 Mar
 2024 02:47:36 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Date: Tue, 19 Mar 2024 10:47:26 +0100
Message-ID: <CALkkCJZWBTmWX_K0+ERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw@mail.gmail.com>
Subject: [bitcoindev] Anyone can boost - a more efficient alternative to
 anchor outputs
To: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="00000000000032f5c10614005d6f"
X-Original-Sender: martin.habovstiak@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=kSsQH+aM;       spf=pass
 (google.com: domain of martin.habovstiak@gmail.com designates
 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.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: -0.5 (/)

--00000000000032f5c10614005d6f
Content-Type: text/plain; charset="UTF-8"

Hello everyone,

For a while I was thinking that anchor outputs/CPFP are wasteful and I
believe I have finally found a better way of doing them. I wrote up a
document describing the solution here:
https://gist.github.com/Kixunil/6ae6f787db36d0d5ed3220f5bcece7f7

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,
Firefish etc) face a problem with predicting fees of the presigned
transactions.
One possibility is to guess the future fee rate but that risks that 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 outputs".
The drawbacks of anchor outputs are increased transaction size and
potentially 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
issues 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
pools directly.
However this is detrimental to mining decentralization, not very accessible
to general public and the expected confirmation time is worse than in case
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
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 attacks,
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
independent 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
(presumably created by an attacker) and only include the high fee ones.

In other words, adding the boosting 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 boosted and boosting
transactions 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 transactions
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 the
boosts. Further it could RBF the boosts if some didn't confirm yet and new
orders arrived in the meantime.
Because of significant cost reduction use of such services would be highly
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 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 transaction could've been trivially boosted by
anyone.

Another interesting example is someone saying that figuring 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

### This requires a soft fork

Soft forks can be contentious and difficult to deploy.
This rule is also unusual because it causes interaction between transaction
within the same block.
However the code should be pretty simple: put all tx ids into a set and
then for each boosting transaction check that all of its txids are in the
set.
This allows loops but that shouldn't be a problem.
The loops can be also disabled by simply progressively iterating over
transactions 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
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 additional output is both more
efficient and more user-friendly.

### This requires having a special output

Unfortunately annex cannot be added to any signature but only to script
spend taproot signatures.
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 provide an
option.

Future witness versions could be designed with this in mind and enable
annex 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 to
boosting by using version 3 but that could decrease privacy and would
reintroduce potential for stuck transactions that cannot be boosted.

## Disclosure

I'm a contractor who wrote the core of Firefish smart contract, a protocol
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/msgid/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw%40mail.gmail.com.

--00000000000032f5c10614005d6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hello everyone,<div dir=3D"auto"><br></div><div dir=3D"au=
to">For a while I was thinking that anchor outputs/CPFP are wasteful and I =
believe I have finally found a better way of doing them. I wrote up a docum=
ent describing the solution here: <a href=3D"https://gist.github.com/Kixuni=
l/6ae6f787db36d0d5ed3220f5bcece7f7">https://gist.github.com/Kixunil/6ae6f78=
7db36d0d5ed3220f5bcece7f7</a></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Here&#39;s a copy of the proposal for your convenience:</div><div dir=
=3D"auto"><br></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">## Abstract</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bitco=
in protocols using presigned transactions (e.g. Lightning Network, Firefish=
 etc) face a problem with predicting fees of the presigned transactions.</d=
iv><div dir=3D"auto">One possibility is to guess the future fee rate but th=
at risks that the transaction will not be included in a block fast enough a=
nd it also risks wasting satoshis on fees.</div><div dir=3D"auto">Another p=
ossibility is to use CPFP which may require adding more outputs - so called=
 &quot;anchor outputs&quot;.</div><div dir=3D"auto">The drawbacks of anchor=
 outputs are increased transaction size and potentially decreased privacy s=
ince the anchor outputs usually use &quot;suspiciously low&quot; amounts.</=
div><div dir=3D"auto">Further, anchor outputs may pollute UTXO set if the p=
resigned transaction confirms anyway (because it also had high enough fee) =
but the outputs are uneconomical to spend.</div><div dir=3D"auto">This docu=
ment proposes a new solution that could not only solve these issues but bri=
ng even more efficiency gains in the future.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">## Solution</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">As stated in the abstract, anchor outputs increase the size and t=
hus the cost of transaction.</div><div dir=3D"auto">So starting from the id=
eal (no additional data in the boosted transaction), we would like to boost=
 any arbitrary transaction.</div><div dir=3D"auto">We observe that this is =
actually already possible by paying big mining pools directly.</div><div di=
r=3D"auto">However this is detrimental to mining decentralization, not very=
 accessible to general public and the expected confirmation time is worse t=
han in case of CPFP, when the whole network mines the transaction.</div><di=
v dir=3D"auto">A simple way to allow anyone boosting any transaction is to =
put the TXID of the boosted transaction into the boosting transaction&#39;s=
 annex and have a consensus rule that the boosting transaction is only vali=
d if the boosted tranation is in the same block.</div><div dir=3D"auto">Let=
&#39;s call this &quot;anyone can boost&quot;.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">At first sight this looks broken because of the pinn=
ing problem.</div><div dir=3D"auto">Today, if ANYONECANSPEND 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"auto">This is because of pol=
icy rules protecting the network against DoS attacks, so apparently the rul=
es cannot be relaxed.</div><div dir=3D"auto">The rules are designed specifi=
cally to impose cost on attackers.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">The reason why anyone can boost is not actually broken is that m=
ultiple independent transactions can boost the same transaction.</div><div =
dir=3D"auto">This brings another resource into the picture: new UTXOs.</div=
><div dir=3D"auto">Thus when a transaction is boosted and a new transaction=
 appears that is boosting it too, it can be considered by the anti-DoS rule=
s separately.</div><div dir=3D"auto">An attacker can&#39;t use this to DoS =
the network because it requires having multiple UTXOs which is already cost=
ly.</div><div dir=3D"auto">When a transaction is boosted by two transaction=
s the fees simply add up.</div><div dir=3D"auto">It&#39;s also possible for=
 a miner to ignore low-fee boosting transactions (presumably 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 boosting transaction to th=
e mempool is equivalent to adding any other transaction to the mempool prov=
ided it pays sufficient fee. It&#39;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 boosted and boo=
sting transactions are related because nobody would boost a transaction of =
someone else.</div><div dir=3D"auto">This heuritic can be trivially broken =
by having an external service that boosts arbitrary transactions and gets p=
aid via other means (LN).</div><div dir=3D"auto">But this can be further im=
proved by allowing boosting multiple transactions simply by putting more TX=
IDs into the boosting transaction.</div><div dir=3D"auto">If two people are=
 trying to boost two transactions at the same time they can almost halve th=
e cost of the boosting transaction.</div><div dir=3D"auto">An efficient boo=
sting service would presumably collect orders and batch the boosts. Further=
 it could RBF the boosts if some didn&#39;t confirm yet and new orders arri=
ved in the meantime.</div><div dir=3D"auto">Because of significant cost red=
uction use of such services would be highly incentivized undermining the he=
uristic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Notably, such b=
oosting service would *not* be trustless but non-delivery could be easily p=
roven using LN invoice and preimage.</div><div dir=3D"auto">Perhaps it is p=
ossible to make the service trustless but that&#39;s probably not worth the=
 effort given how low the amounts are.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">As an aside, there was recently a post in the local communit=
y that someone made a low-fee transaction without RBF enabled and the recei=
ver couldn&#39;t CPFP.</div><div dir=3D"auto">I assume such cases happen mo=
re than once.</div><div dir=3D"auto">If this service existed the transactio=
n could&#39;ve been trivially boosted by anyone.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Another interesting example is someone saying that=
 figuring 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 i=
n many cases since one would only have to copy-paste the txid, which probab=
ly 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">### T=
his requires a soft fork</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Soft forks can be contentious and difficult to deploy.</div><div dir=3D"au=
to">This rule is also unusual because it causes interaction between transac=
tion 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 tran=
saction check that all of its txids are in the set.</div><div dir=3D"auto">=
This allows loops but that shouldn&#39;t be a problem.</div><div dir=3D"aut=
o">The loops can be also disabled by simply progressively iterating over tr=
ansactions 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 r=
elax the RBF rules in some other way to enable external boosting for transa=
ctions that opt-into it. A vague idea was to allow replacing when each inpu=
t of a transaction has ANYONECANPAY flag but its interaction with other rul=
es is questionable. Perhaps this can be developed further but not needing a=
n additional output is both more efficient and more user-friendly.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">### This requires having a speci=
al output</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 sig=
natures.</div><div dir=3D"auto">Since this feature is most useful for presi=
gned transactions the entities performing them could simply prepare the out=
puts 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=
 provide an option.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Futu=
re witness versions could be designed with this in mind and enable annex re=
gardless of spend type which would make things simpler and save even more s=
pace (key spend is cheaper).</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">### This destroys fee betting</div><div dir=3D"auto"><br></div><div di=
r=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 i=
nto 2-of-2 multisig and then pre-sign two transactions with different fee r=
ates and lock times.</div><div dir=3D"auto">However this is already vulnera=
ble to miner collusion and to my knowledge nobody uses this.</div><div dir=
=3D"auto">It could be preserved by requiring that the boosted transactions =
opt-in to boosting by using version 3 but that could decrease privacy and w=
ould reintroduce potential for stuck transactions that cannot be boosted.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">## Disclosure</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">I&#39;m a contractor who wrote the =
core of Firefish smart contract, a protocol which would benefit from this f=
eature.</div><div dir=3D"auto">I was not paid to come up with this idea, I =
just believe this would be a generally useful feature.</div><div dir=3D"aut=
o"><br></div></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/CALkkCJZWBTmWX_K0%2BERTs2_r0w8nVK1uN44u-sz5Hbb-SbjVYw=
%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.go=
ogle.com/d/msgid/bitcoindev/CALkkCJZWBTmWX_K0%2BERTs2_r0w8nVK1uN44u-sz5Hbb-=
SbjVYw%40mail.gmail.com</a>.<br />

--00000000000032f5c10614005d6f--