public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "James O'Beirne" <james.obeirne@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Date: Mon, 14 Feb 2022 14:51:26 -0500	[thread overview]
Message-ID: <CAPfvXfJX3sc_QKkWzPVRR=-P4eJb4SsfDNO4XjUxCgN1EK_Tpw@mail.gmail.com> (raw)
In-Reply-To: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2444 bytes --]

  reply	other threads:[~2022-02-14 19:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 19:40 [bitcoin-dev] Thoughts on fee bumping James O'Beirne
2022-02-10 23:09 ` Greg Sanders
2022-02-10 23:44 ` darosior
2022-02-10 23:51   ` James O'Beirne
2022-02-11  6:51     ` darosior
2022-02-12 19:44       ` Billy Tetrud
2022-02-11  0:12 ` Matt Corallo
2022-02-14 19:51   ` James O'Beirne [this message]
2022-02-17 14:32   ` Anthony Towns
2022-02-17 18:18     ` James O'Beirne
2022-02-18  9:01       ` darosior
2022-02-18  0:35     ` Antoine Riard
2022-02-11  5:26 ` Antoine Riard
2022-02-14 20:28   ` James O'Beirne
2022-02-15  0:43     ` Antoine Riard
2022-02-15 17:09       ` Billy Tetrud
2022-02-15 20:24         ` Russell O'Connor
2022-02-15 20:53           ` James O'Beirne
2022-02-15 21:37             ` Jeremy Rubin
2022-02-18 21:09               ` [bitcoin-dev] Sponsor transaction engineering, was " David A. Harding
2022-02-15 21:38           ` [bitcoin-dev] " Jeremy Rubin
2022-02-16  2:54             ` Billy Tetrud
2022-02-16 19:18               ` James O'Beirne
2022-02-16 20:36                 ` Billy Tetrud
2022-02-18  0:54 Prayank
2022-02-18  2:08 Prayank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPfvXfJX3sc_QKkWzPVRR=-P4eJb4SsfDNO4XjUxCgN1EK_Tpw@mail.gmail.com' \
    --to=james.obeirne@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox