path: root/a4/662ae5fa0e0d236daa02e218b65d0586f856cb

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3251FC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 00:43:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 28D4840909
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 00:43:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NKAdq2ZBa9VL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 00:43:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [IPv6:2607:f8b0:4864:20::b2e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7A89C40910
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 00:43:39 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id bt13so51381447ybb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Feb 2022 16:43:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=l8FjjHMaj5UvP/rZzLqEweCz9d2/rdQ0DHhiBa/WOFw=;
 b=D+Z2boRlRoN9e+swLo4JmyV6XSzqFU1eIFyLjbac+IJpW+ckD1t7ABvUmpBDNyMYjr
 sTdHSjDSZRdPRxRulXDJ/dtdWcKM5VtBHzDdChtv/r98FHlcFejGbKvSfnaYMt1lOZME
 q/FN+OGfOHpPUYewmu72Kt6OB+B3NMSlrjYfm7ud83ZnIEAxPnSt8Dx7XKx5TRmua30e
 swluVFcKq2dVhHU0h6LrJfcjR05Y0xYcv8AabUHZAsKe/nJ/PWQvy7R5Bb/nMg7WYgxV
 ZvRWej2+tJPotAY0kmnBhGDdHpaBSNHr8O+jWUYU3s3p6pBZQjitG0xs2k4kp+Nczsaq
 Pt6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=l8FjjHMaj5UvP/rZzLqEweCz9d2/rdQ0DHhiBa/WOFw=;
 b=oZU9QLujd9hSyIPvithlsXW8offeNdGxHX/rEfvnbThbFR0ZP+vicp2hQYsY/Ax/TT
 x0CcTanlTp9DQk9bo9bJI+LM/JBzjWkMpEAPa3OqKsncW2KNjuUNfXD+9LljAP04Gfag
 5AHC9GtoaBlCuPUzlaCLldz/4wsbMDiRdOMPZbBld6NH30CslfVWf9Jpgy6V4JY9rpyS
 f1om6Omn96jkpgM0nJy+FT5tmTId9YZTdGiYEq1kzpmaCbQt/IS5JiF0vZEWJ45fI2bc
 y0FiKG/FrmIxL2PIWN3c2FFYm2Z0I8iur9xQc2PW037Zgpi8D0Y6e+DB0A+BlJLvV5td
 0suw==
X-Gm-Message-State: AOAM533afsao721rrqGm3BumrYdNqMqRNJ37qnNX2jK57khdYBXqKAj8
 VnUhEHFBR0PxSPLxoowK8Cp7Js4UpR7r0EN3GEZBfJaBCEs=
X-Google-Smtp-Source: ABdhPJwpt9K2U5lygckOOgTP5DZY2pWMXjlBvjaM/3D/QrI6h46HG730UjpSMMBtGUZFighl9fl0jmsEudmDliaOb+U=
X-Received: by 2002:a81:b502:: with SMTP id t2mr1426679ywh.460.1644885818254; 
 Mon, 14 Feb 2022 16:43:38 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
 <CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
In-Reply-To: <CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 14 Feb 2022 19:43:26 -0500
Message-ID: <CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e4a84a05d803d203"
X-Mailman-Approved-At: Tue, 15 Feb 2022 01:09:36 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Feb 2022 00:43:41 -0000

--000000000000e4a84a05d803d203
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> In the context of fee bumping, I don't see how this is a criticism
> unique to transaction sponsors, since it also applies to CPFP: if you
> tried to bump fees for transaction A with child txn B, if some mempool
> hasn't seen parent A, it will reject B.

Agree, it's a comment raising the shenanigans of tx-diff-only propagation,
afaict affecting equally all fee-bumping primitives. It wasn't a criticism
specific to transaction sponsors, as at that point of your post, sponsors
are not introduced yet.

> This still doesn't address the issue I'm talking about, which is if you
> pre-commit to some "fee-bumping" key in your CPFP outputs and that key
> ends up being compromised. This isn't a matter of data availability or
> redundancy.

I'm not sure about the real safety risk of the compromise of the anchor
output key. Of course, if your anchor output key is compromised and the
bumped package is already public/known, an attacker can extend your package
with junk to neutralize your carve-out capability (I think). That said,
this issue sounds solved to me with package relay, as you can always
broadcast a new version of the package from the root UTXO, without
attention to the carve-out limitation.

(Side-note: I think we can slowly deprecate the carve-out once package
relay is deployed, as the fee-bumping flexibility of the latter is a
superset of the former).

> As I mentioned in the reply to Matt's message, I'm not quite
> understanding this idea of wanting to bump the fee for something
> without knowing what it is; that doesn't make much sense to me.
> The "bump fee" operation seems contingent on knowing
> what you want to bump.

From your post : "No rebroadcast (wasted bandwidth) is required for the
original txn data."

I'm objecting to that supposed benefit of a transaction sponsor. If you
have transaction X and transaction Y spending the same UTXO, both of them
can be defined as "the original txn data". If you wish to fee-bump
transaction X with sponsor, how can you be sure that transaction
Y isn't present in the majority of network nodes, and X has _not_ been
dropped since your last broadcast ? Otherwise iirc sponsor design, your
sponsor transaction is going to be rejected.

I think you can't, and thus preventively you should broadcast as a (new
type) of package the sponsoring/sponsored transaction.

That said, I'm not sure if that issue is equally affecting vaults than
payment channels. With vaults, the tree of transactions is  known ahead,
and there is no competition in the spends. Assuming the first broadcast has
been efficient (and it could be a reasonable assumption thanks to mempool
rebroadcast), the sponsor should propagate.

So I think here for the sake of sponsor efficiency analysis, we might have
to class between the protocol with once-for-all-transaction-negotiation
(vaults) and the ones with off-chain, dynamic re-negotiation (payment
channels, factories) ?

> I'm not familiar with the L2 dust-limit issues, and I do think that
> "fixing" RBF behavior is *probably* worthwhile.

Sadly, it sounds that "fixing" RBF behavior is a requirement to eradicate
the most advanced pinnings... That fix is independent of the fee-bumping
primitive considered.

>  Those issues aside, I
> think the transaction sponsors idea may be closer to a silver bullet
> than you're giving it credit for, because designing specifically for the
> fee-management use case has some big benefits.

I don't deny the scheme is interesting, though I would argue SIGHASH_GROUP
is more efficient, while offering more flexibility. In any case, I think we
should still pursue further the collections of problems and requirements
(batching, key management, ...) that new fee-bumping primitives should aim
to solve, before engaging more on the deployment of one of them [0].

[0] In that sense see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.htm=
l

Le lun. 14 f=C3=A9vr. 2022 =C3=A0 15:29, James O'Beirne <james.obeirne@gmai=
l.com> a
=C3=A9crit :

> Thanks for your thoughtful reply Antoine.
>
> > In a distributed system such as the Bitcoin p2p network, you might
> > have transaction A and transaction B  broadcast at the same time and
> > your peer topology might fluctuate between original send and
> > broadcast of the diff, you don't know who's seen what... You might
> > inefficiently announce diff A on top of B and diff B on top A. We
> > might leverage set reconciliation there a la Erlay, though likely
> > with increased round-trips.
>
> In the context of fee bumping, I don't see how this is a criticism
> unique to transaction sponsors, since it also applies to CPFP: if you
> tried to bump fees for transaction A with child txn B, if some mempool
> hasn't seen parent A, it will reject B.
>
> > Have you heard about SIGHASH_GROUP [0] ?
>
> I haven't - I'll spend some time reviewing this. Thanks.
>
> > > [me complaining CPFP requires lock-in to keys]
> >
> > It's true it requires to pre-specify the fee-bumping key. Though note
> > the fee-bumping key can be fully separated from the
> > "vaults"/"channels" set of main keys and hosted on replicated
> > infrastructure such as watchtowers.
>
> This still doesn't address the issue I'm talking about, which is if you
> pre-commit to some "fee-bumping" key in your CPFP outputs and that key
> ends up being compromised. This isn't a matter of data availability or
> redundancy.
>
> Note that this failure may be unique to vault use cases, when you're
> pre-generating potentially large numbers of transactions or covenants
> that cannot be altered after the fact. If you generate vault txns that
> assume the use of some key for CPFP-based fee bumping and that key
> winds up being compromised, that puts you in a an uncomfortable
> situation: you can no longer bump fees on unvaulting transactions,
> rendering the vaults possibly unretrievable depending on the fee market.
>
> > As a L2 transaction issuer you can't be sure the transaction you wish
> > to point to is already in the mempool, or have not been replaced by
> > your counterparty spending the same shared-utxo, either competitively
> > or maliciously. So as a measure of caution, you should broadcast
> > sponsor + target transactions in the same package, thus cancelling
> > the bandwidth saving (I think).
>
> As I mentioned in the reply to Matt's message, I'm not quite
> understanding this idea of wanting to bump the fee for something
> without knowing what it is; that doesn't make much sense to me.
> The "bump fee" operation seems contingent on knowing
> what you want to bump.
>
> And if you're, say, trying to broadcast a lightning channel close and
> you know you need to bump the fee right away, before even broadcasting
> it, either you're going to
>
> - reformulate the txn to bring up the fee rate (e.g. add inputs
>   with some yet-undeployed sighash) as you would have done with RBF, or
>
> - you'd have the same "package relay" problem with CPFP that you
>   would with transaction sponsors.
>
> So I don't understand the objection here.
>
> Also, I didn't mean to discourage existing work on package relay or
> fixing RBF, which seem clearly important. Maybe I should have noted
> that explicitly in the original message
>
> > I don't think a sponsor is a silver-bullet to solve all the
> > L2-related mempool issues. It won't solve the most concerning pinning
> > attacks, as I think the bottleneck is replace-by-fee. Neither solve
> > the issues encumbered by the L2s by the dust limit.
>
> I'm not familiar with the L2 dust-limit issues, and I do think that
> "fixing" RBF behavior is *probably* worthwhile. Those issues aside, I
> think the transaction sponsors idea may be closer to a silver bullet
> than you're giving it credit for, because designing specifically for the
> fee-management use case has some big benefits.
>
> For one, it makes migration easier. That is to say: there is none,
> whereas there is existing RBF policy that needs consideration.
>
> But maybe more importantly, transaction sponsors' limited use case also
> allows for specifying much more targeted "replacement" policy since
> sponsors are special-purpose transactions that only exist to
> dynamically bump feerate. E.g. my SIGHASH_{NONE,SINGLE}|ANYONECANPAY
> proposal might make complete sense for the sponsors/fee-management use
> case, and clarify the replacement problem, but obviously wouldn't work
> for more general transaction replacement. In other words, RBF's
> general nature might make it a much harder problem to solve well.
>

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

<div dir=3D"ltr">&gt; In the context of fee bumping, I don&#39;t see how th=
is is a criticism<br>&gt; unique to transaction sponsors, since it also app=
lies to CPFP: if you<br>&gt; tried to bump fees for transaction A with chil=
d txn B, if some mempool<br>&gt; hasn&#39;t seen parent A, it will reject B=
.<br><br>Agree, it&#39;s a comment raising the shenanigans of tx-diff-only =
propagation, afaict affecting equally all fee-bumping primitives. It wasn&#=
39;t a criticism specific to transaction sponsors, as at that point of your=
 post, sponsors are not introduced yet.<br><br>&gt; This still doesn&#39;t =
address the issue I&#39;m talking about, which is if you<br>&gt; pre-commit=
 to some &quot;fee-bumping&quot; key in your CPFP outputs and that key<br>&=
gt; ends up being compromised. This isn&#39;t a matter of data availability=
 or<br>&gt; redundancy.<br><br>I&#39;m not sure about the real safety risk =
of the compromise of the anchor output key. Of course, if your anchor outpu=
t key is compromised and the bumped package is already public/known, an att=
acker can extend your package with junk to neutralize your carve-out capabi=
lity (I think). That said, this issue sounds solved to me with package rela=
y, as you can always broadcast a new version of the package from the root U=
TXO, without attention to the carve-out limitation.<br><br>(Side-note: I th=
ink we can slowly deprecate the carve-out once package relay is deployed, a=
s the fee-bumping flexibility of the latter is a superset of the former).<b=
r><br>&gt; As I mentioned in the reply to Matt&#39;s message, I&#39;m not q=
uite<br>&gt; understanding this idea of wanting to bump the fee for somethi=
ng<br>&gt; without knowing what it is; that doesn&#39;t make much sense to =
me.<br>&gt; The &quot;bump fee&quot; operation seems contingent on knowing<=
br>&gt; what you want to bump.<br><br>From your post : &quot;No rebroadcast=
 (wasted bandwidth) is required for the original txn data.&quot; <br><br>I&=
#39;m objecting to that supposed benefit of a transaction sponsor. If you h=
ave transaction X and transaction Y spending the same UTXO, both of them ca=
n be defined as &quot;the original txn data&quot;. If you wish to fee-bump =
transaction X with sponsor, how can you be sure that transaction<br>Y isn&#=
39;t present in the majority of network nodes, and X has _not_ been dropped=
 since your last broadcast ? Otherwise iirc sponsor design, your sponsor tr=
ansaction is going to be rejected.<br><br>I think you can&#39;t, and thus p=
reventively you should broadcast as a (new type) of package the sponsoring/=
sponsored transaction.<br><br>That said, I&#39;m not sure if that issue is =
equally affecting vaults than payment channels. With vaults, the tree of tr=
ansactions is =C2=A0known ahead, and there is no competition in the spends.=
 Assuming the first broadcast has been efficient (and it could be a reasona=
ble assumption thanks to mempool<br>rebroadcast), the sponsor should propag=
ate.<br><br>So I think here for the sake of sponsor efficiency analysis, we=
 might have to class between the protocol with once-for-all-transaction-neg=
otiation (vaults) and the ones with off-chain, dynamic re-negotiation (paym=
ent channels, factories) ?<br><br>&gt; I&#39;m not familiar with the L2 dus=
t-limit issues, and I do think that<br>&gt; &quot;fixing&quot; RBF behavior=
 is *probably* worthwhile.<br><br>Sadly, it sounds that &quot;fixing&quot; =
RBF behavior is a requirement to eradicate the most advanced pinnings... Th=
at fix is independent of the fee-bumping primitive considered.<br><br>&gt; =
=C2=A0Those issues aside, I<br>&gt; think the transaction sponsors idea may=
 be closer to a silver bullet<br>&gt; than you&#39;re giving it credit for,=
 because designing specifically for the<br>&gt; fee-management use case has=
 some big benefits.<br><br>I don&#39;t deny the scheme is interesting, thou=
gh I would argue SIGHASH_GROUP is more efficient, while offering more flexi=
bility. In any case, I think we should still pursue further the collections=
 of problems and requirements (batching, key management, ...) that new fee-=
bumping primitives should aim to solve, before engaging more on the deploym=
ent of one of them [0].<br><br>[0] In that sense see <a href=3D"https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html</a><br=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>Le=C2=A0lun. 14 f=C3=A9vr. 2022 =C3=A0=C2=A015:29, James O&#39;Beirne &lt;=
<a href=3D"mailto:james.obeirne@gmail.com">james.obeirne@gmail.com</a>&gt; =
a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">Thanks for your thoughtful reply Antoine.<br><br>&gt; =
In a distributed system such as the Bitcoin p2p network, you might<br>&gt; =
have transaction A and transaction B =C2=A0broadcast at the same time and<b=
r>&gt; your peer topology might fluctuate between original send and<br>&gt;=
 broadcast of the diff, you don&#39;t know who&#39;s seen what... You might=
<br>&gt; inefficiently announce diff A on top of B and diff B on top A. We<=
br>&gt; might leverage set reconciliation there a la Erlay, though likely<b=
r>&gt; with increased round-trips.<br><br>In the context of fee bumping, I =
don&#39;t see how this is a criticism<br>unique to transaction sponsors, si=
nce it also applies to CPFP: if you<br>tried to bump fees for transaction A=
 with child txn B, if some mempool<br>hasn&#39;t seen parent A, it will rej=
ect B. <br><br>&gt; Have you heard about SIGHASH_GROUP [0] ? <br><br>I have=
n&#39;t - I&#39;ll spend some time reviewing this. Thanks.<br><div><br></di=
v><div>&gt; &gt; [me complaining CPFP requires lock-in to keys]</div><div>&=
gt;<br></div>&gt; It&#39;s true it requires to pre-specify the fee-bumping =
key. Though note<br>&gt; the fee-bumping key can be fully separated from th=
e<br>&gt; &quot;vaults&quot;/&quot;channels&quot; set of main keys and host=
ed on replicated<br>&gt; infrastructure such as watchtowers.<br><br>This st=
ill doesn&#39;t address the issue I&#39;m talking about, which is if you<br=
>pre-commit to some &quot;fee-bumping&quot; key in your CPFP outputs and th=
at key<br>ends up being compromised. This isn&#39;t a matter of data availa=
bility or<br>redundancy. <br><br>Note that this failure may be unique to va=
ult use cases, when you&#39;re<br>pre-generating potentially large numbers =
of transactions or covenants<br>that cannot be altered after the fact. If y=
ou generate vault txns that<br>assume the use of some key for CPFP-based fe=
e bumping and that key<br>winds up being compromised, that puts you in a an=
 uncomfortable<br>situation: you can no longer bump fees on unvaulting tran=
sactions,<br>rendering the vaults possibly unretrievable depending on the f=
ee market.<br><br>&gt; As a L2 transaction issuer you can&#39;t be sure the=
 transaction you wish<br>&gt; to point to is already in the mempool, or hav=
e not been replaced by<br>&gt; your counterparty spending the same shared-u=
txo, either competitively<br>&gt; or maliciously. So as a measure of cautio=
n, you should broadcast<br>&gt; sponsor + target transactions in the same p=
ackage, thus cancelling<br>&gt; the bandwidth saving (I think).<br><br>As I=
 mentioned in the reply to Matt&#39;s message, I&#39;m not quite<br>underst=
anding this idea of wanting to bump the fee for something<br><div>without k=
nowing what it is; that doesn&#39;t make much sense to me. <br></div><div>T=
he &quot;bump fee&quot; operation seems contingent on knowing<br></div><div=
>what you want to bump.<br></div><br>And if you&#39;re, say, trying to broa=
dcast a lightning channel close and<br>you know you need to bump the fee ri=
ght away, before even broadcasting<br>it, either you&#39;re going to<br><br=
>- reformulate the txn to bring up the fee rate (e.g. add inputs<br>=C2=A0 =
with some yet-undeployed sighash) as you would have done with RBF, or<br><b=
r>- you&#39;d have the same &quot;package relay&quot; problem with CPFP tha=
t you<br>=C2=A0 would with transaction sponsors.<br><br>So I don&#39;t unde=
rstand the objection here.<br><br>Also, I didn&#39;t mean to discourage exi=
sting work on package relay or<br>fixing RBF, which seem clearly important.=
 Maybe I should have noted<br>that explicitly in the original message<br><b=
r>&gt; I don&#39;t think a sponsor is a silver-bullet to solve all the<br>&=
gt; L2-related mempool issues. It won&#39;t solve the most concerning pinni=
ng<br>&gt; attacks, as I think the bottleneck is replace-by-fee. Neither so=
lve<br>&gt; the issues encumbered by the L2s by the dust limit.<br><br>I&#3=
9;m not familiar with the L2 dust-limit issues, and I do think that<br>&quo=
t;fixing&quot; RBF behavior is *probably* worthwhile. Those issues aside, I=
<br><div>think the transaction sponsors idea may be closer to a silver bull=
et <br></div><div>than you&#39;re giving it credit for, because designing s=
pecifically for the<br></div>fee-management use case has some big benefits.=
<br><br>For one, it makes migration easier. That is to say: there is none,<=
br>whereas there is existing RBF policy that needs consideration. <br><br>B=
ut maybe more importantly, transaction sponsors&#39; limited use case also<=
br>allows for specifying much more targeted &quot;replacement&quot; policy =
since<br>sponsors are special-purpose transactions that only exist to<br>dy=
namically bump feerate. E.g. my SIGHASH_{NONE,SINGLE}|ANYONECANPAY<br>propo=
sal might make complete sense for the sponsors/fee-management use<br>case, =
and clarify the replacement problem, but obviously wouldn&#39;t work<br>for=
 more general transaction replacement. In other words, RBF&#39;s<br>general=
 nature might make it a much harder problem to solve well.<br></div>
</blockquote></div>

--000000000000e4a84a05d803d203--