From: Matt Corallo <lf-lists@mattcorallo•com>
To: James O'Beirne <james.obeirne@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Date: Thu, 10 Feb 2022 19:12:16 -0500 [thread overview]
Message-ID: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com> (raw)
In-Reply-To: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity,
its not some software engineering failure or imagination failure that leads to the complexity.
On 2/10/22 14:40, James O'Beirne via bitcoin-dev wrote:
-snip-
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
This is where *all* the complexity comes from. If our goal is to "ensure a bump increases a miner's
overall revenue" (thus not wasting relay for everyone else), then we precisely *do* need
> Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency
Whether a transaction increases a miner's revenue depends precisely on whether the transaction
(package) being replaced is in the next block - if it is, you care about the absolute fee of the
package and its replacement. If it is not in the next block (or, really, not near a block boundary
or further down in the mempool where you assume other transactions will appear around it over time),
then you care about the fee *rate*, not the fee difference.
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
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. We cannot simply ignore network-wide costs like total relay
bandwidth (or implementation runtime DoS issues).
> # Special transaction structure should not be required to bump fees
>
> 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.
> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].
How does this not also fail your above criteria of not wasting block space?
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.
Matt
next prev parent reply other threads:[~2022-02-11 0:12 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 [this message]
2022-02-14 19:51 ` James O'Beirne
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=8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=james.obeirne@gmail$(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