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 --]
next prev parent 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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