MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
In-Reply-To: <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 14 Feb 2022 15:28:51 -0500
Message-ID: <CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000075e2bf05d80044ca"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

--00000000000075e2bf05d80044ca
Content-Type: text/plain; charset="UTF-8"

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.

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

<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<br>&g=
t; your peer topology might fluctuate between original send and<br>&gt; bro=
adcast 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<br>&g=
t; 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, since =
it also applies to CPFP: if you<br>tried to bump fees for transaction A wit=
h child txn B, if some mempool<br>hasn&#39;t seen parent A, it will reject =
B. <br><br>&gt; Have you heard about SIGHASH_GROUP [0] ? <br><br>I haven=
9;t - I&#39;ll spend some time reviewing this. Thanks.<br><div><br></div><d=
iv>&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 the<br=
>&gt; &quot;vaults&quot;/&quot;channels&quot; set of main keys and hosted o=
n replicated<br>&gt; infrastructure such as watchtowers.<br><br>This still =
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 that k=
ey<br>ends up being compromised. This isn&#39;t a matter of data availabili=
ty or<br>redundancy. <br><br>Note that this failure may be unique to vault =
use cases, when you&#39;re<br>pre-generating potentially large numbers of t=
ransactions or covenants<br>that cannot be altered after the fact. If you g=
enerate vault txns that<br>assume the use of some key for CPFP-based fee bu=
mping and that key<br>winds up being compromised, that puts you in a an unc=
omfortable<br>situation: you can no longer bump fees on unvaulting transact=
ions,<br>rendering the vaults possibly unretrievable depending on the fee m=
arket.<br><br>&gt; As a L2 transaction issuer you can&#39;t be sure the tra=
nsaction you wish<br>&gt; to point to is already in the mempool, or have no=
t been replaced by<br>&gt; your counterparty spending the same shared-utxo,=
 either competitively<br>&gt; or maliciously. So as a measure of caution, y=
ou should broadcast<br>&gt; sponsor + target transactions in the same packa=
ge, thus cancelling<br>&gt; the bandwidth saving (I think).<br><br>As I men=
tioned in the reply to Matt&#39;s message, I&#39;m not quite<br>understandi=
ng this idea of wanting to bump the fee for something<br><div>without knowi=
ng what it is; that doesn&#39;t make much sense to me. <br></div><div>The &=
quot;bump fee&quot; operation seems contingent on knowing<br></div><div>wha=
t you want to bump.<br></div><br>And if you&#39;re, say, trying to broadcas=
t a lightning channel close and<br>you know you need to bump the fee right =
away, before even broadcasting<br>it, either you&#39;re going to<br><br>- r=
eformulate 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><br>- =
you&#39;d have the same &quot;package relay&quot; problem with CPFP that yo=
u<br>=C2=A0 would with transaction sponsors.<br><br>So I don&#39;t understa=
nd the objection here.<br><br>Also, I didn&#39;t mean to discourage existin=
g work on package relay or<br>fixing RBF, which seem clearly important. May=
be I should have noted<br>that explicitly in the original message<br><br>&g=
t; 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 pinning<b=
r>&gt; attacks, as I think the bottleneck is replace-by-fee. Neither solve<=
br>&gt; the issues encumbered by the L2s by the dust limit.<br><br>I&#39;m =
not familiar with the L2 dust-limit issues, and I do think that<br>&quot;fi=
xing&quot; RBF behavior is *probably* worthwhile. Those issues aside, I<br>=
<div>think the transaction sponsors idea may be closer to a silver bullet <=
br></div><div>than you&#39;re giving it credit for, because designing speci=
fically 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>w=
hereas there is existing RBF policy that needs consideration. <br><br>But m=
aybe more importantly, transaction sponsors&#39; limited use case also<br>a=
llows for specifying much more targeted &quot;replacement&quot; policy sinc=
e<br>sponsors are special-purpose transactions that only exist to<br>dynami=
cally bump feerate. E.g. my SIGHASH_{NONE,SINGLE}|ANYONECANPAY<br>proposal =
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 mor=
e general transaction replacement. In other words, RBF&#39;s<br>general nat=
ure might make it a much harder problem to solve well.<br></div>

--00000000000075e2bf05d80044ca--