MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
In-Reply-To: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 14 Feb 2022 14:51:26 -0500
Message-ID: <CAPfvXfJX3sc_QKkWzPVRR=-P4eJb4SsfDNO4XjUxCgN1EK_Tpw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="0000000000009958d205d7ffbe7b"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

--0000000000009958d205d7ffbe7b
Content-Type: text/plain; charset="UTF-8"

> This entirely misses the network cost. Yes, sure, we can send
> "diffs", but if you send enough diffs eventually you send a lot of data.

The whole point of that section of the email was to consider the
network cost. There are many cases for which transmitting a
supplementary 1-in-1-out transaction (i.e. a sponsorship txn) is going
to be more efficient from a bandwidth standpoint than rebroadcasting a
potentially large txn during RBF.

> > In an ideal design, special structural foresight would not be
> > needed in order for a txn's feerate to be improved after broadcast.
> >
> > Anchor outputs specified solely for CPFP, which amount to many
> > bytes of wasted chainspace, are a hack. > It's probably
> > uncontroversial at this
>
> This has nothing to do with fee bumping, though, this is only solved
> with covenants or something in that direction, not different relay
> policy.

My post isn't only about relay policy; it's that txn
sponsors allows for fee-bumping in cases where RBF isn't possible and
CPFP would be wasteful, e.g. for a tree of precomputed vault
transactions or - maybe more generally - certain kinds of
covenants.

> How does this not also fail your above criteria of not wasting block
> space?

In certain cases (e.g. vault structures), using sponsorship txns to
bump fees as-needed is more blockspace-efficient than including
mostly-unused CPFP "anchor" outputs that pay to fee-management wallets.
I'm betting there are other similar cases where CPFP anchors are
included but not necessarily used, and amount to wasted blockspace.

> Further, this doesn't solve pinning attacks at all. In lightning we
> want to be able to *replace* something in the mempool (or see it
> confirm soon, but that assumes we know exactly what transaction is in
> "the" mempool). Just being able to sponsor something doesn't help if
> you don't know what that thing is.

When would you be trying to bump the fee on a transaction without
knowing what it is? Seeing a specific transaction "stuck" in the
mempool seems to be a prerequisite to bumping fees. I'm not sure what
you're getting at here.

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

<div dir=3D"ltr">&gt; This entirely misses the network cost. Yes, sure, we =
can send<br>&gt; &quot;diffs&quot;, but if you send enough diffs eventually=
 you send a lot of data.<br><br>The whole point of that section of the emai=
l was to consider the<br>network cost. There are many cases for which trans=
mitting a<br>supplementary 1-in-1-out transaction (i.e. a sponsorship txn) =
is going<br>to be more efficient from a bandwidth standpoint than rebroadca=
sting a<br>potentially large txn during RBF. <br><br>&gt; &gt; In an ideal =
design, special structural foresight would not be<br>&gt; &gt; needed in or=
der for a txn&#39;s feerate to be improved after broadcast.<br>&gt; &gt; <b=
r>&gt; &gt; Anchor outputs specified solely for CPFP, which amount to many<=
br>&gt; &gt; bytes of wasted chainspace, are a hack. &gt; It&#39;s probably=
<br>&gt; &gt; uncontroversial at this<br>&gt;<br>&gt; This has nothing to d=
o with fee bumping, though, this is only solved<br>&gt; with covenants or s=
omething in that direction, not different relay<br>&gt; policy.<br><br>My p=
ost isn&#39;t only about relay policy; it&#39;s that txn<br>sponsors allows=
 for fee-bumping in cases where RBF isn&#39;t possible and<br>CPFP would be=
 wasteful, e.g. for a tree of precomputed vault<br><div>transactions or - m=
aybe more generally - certain kinds of</div><div>covenants.</div><br>&gt; H=
ow does this not also fail your above criteria of not wasting block<br>&gt;=
 space?<br><br>In certain cases (e.g. vault structures), using sponsorship =
txns to<br>bump fees as-needed is more blockspace-efficient than including<=
br>mostly-unused CPFP &quot;anchor&quot; outputs that pay to fee-management=
 wallets.<br>I&#39;m betting there are other similar cases where CPFP ancho=
rs are<br>included but not necessarily used, and amount to wasted blockspac=
e.<br><br>&gt; Further, this doesn&#39;t solve pinning attacks at all. In l=
ightning we<br>&gt; want to be able to *replace* something in the mempool (=
or see it<br>&gt; confirm soon, but that assumes we know exactly what trans=
action is in<br>&gt; &quot;the&quot; mempool). Just being able to sponsor s=
omething doesn&#39;t help if<br>&gt; you don&#39;t know what that thing is.=
<br><br>When would you be trying to bump the fee on a transaction without<b=
r>knowing what it is? Seeing a specific transaction &quot;stuck&quot; in th=
e<br>mempool seems to be a prerequisite to bumping fees. I&#39;m not sure w=
hat<br>you&#39;re getting at here.<br></div>

--0000000000009958d205d7ffbe7b--