From: Anthony Towns <aj@erisian•com.au>
To: Bastien TEINTURIER <bastien@acinq•fr>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
Date: Wed, 2 Feb 2022 20:21:16 +1000 [thread overview]
Message-ID: <20220202102116.GB5140@erisian.com.au> (raw)
In-Reply-To: <CACdvm3O4sQ_kF+y9R73c1wiDiTos9Zs7jJQZEQrc8Uz5SsSx1g@mail.gmail.com>
On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev wrote:
> But do you agree that descendants only matter for DoS resistance then,
> not for miner incentives?
There's an edge case where you're replacing tx A with tx X, and X's fee
rate is higher than A's, but you'd be obsoleting descendent txs (B, C,
D...) and thus replacing them with unrelated txs (L, M, N...), and the
total feerate/fees of A+B+C+D... is nevertheless higher than X+L+M+N...
But I think that's probably unusual (transactions D and L are adjacent
in the mempool, that's why L is chosen for the block; but somehow
there's a big drop off in value somewhere between B/C/D and L/M/N),
and at least today, I don't think miners consider it essential to eke
out every possible sat in fee income.
(If, as per your example, you're actually replacing {A,B,C,D} with
{X,Y,Z,W} where X pays higher fees than A and the package in total pays
either the same or higher fees, that's certainly incentive compatible.
The tricky question is what happens when X arrives on its own and it
might be that no one ever sends a replacement for B,C,D)
> The two policies I proposed address miner incentives. I think they're
> insufficient to address DoS issues. But adding a 3rd policy to address
> DoS issues may be a good solution?
>>> 1. The transaction's ancestor absolute fees must be X% higher than the
>>> previous transaction's ancestor fees
>>> 2. The transaction's ancestor feerate must be Y% higher than the
>>> previous transaction's ancestor feerate
Absolute fees only matter if your backlog's feerate drops off. If you've
got 100MB of txs offering 5sat/vb, then exchanging 50kB at 5sat/vb for
1kB at 6sat/vb is still a win: your block gains 1000 sats in fees even
though your mempool loses 245,000 sats in fees.
But if your backlog's feerate does drop off, *and* that matters, then
I don't think you can ignore the impact of the descendent transactions
that you might not get a replacement for.
I think "Y% higher" rather than just "higher" is only useful for
rate-limiting, not incentive compatibility. (Though maybe it helps
stabilise a greedy algorithm in some cases?)
Cheers,
aj
next prev parent reply other threads:[~2022-02-02 10:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 2:47 Prayank
2022-02-01 9:30 ` Bastien TEINTURIER
2022-02-02 10:21 ` Anthony Towns [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-02-09 17:57 lisa neigut
[not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` [bitcoin-dev] Improving RBF policy Bram Cohen
2022-02-01 0:08 ` Eric Voskuil
2022-02-01 8:32 ` Bram Cohen
2022-02-01 19:44 ` Eric Voskuil
2022-02-01 0:42 ` Antoine Riard
2022-01-27 13:42 [bitcoin-dev] Improving RBF Policy Gloria Zhao
2022-01-28 1:35 ` Jeremy
2022-01-30 22:53 ` Antoine Riard
2022-01-31 15:57 ` Bastien TEINTURIER
2022-02-01 1:56 ` Anthony Towns
2022-02-05 13:21 ` Michael Folkson
2022-02-07 10:22 ` Bastien TEINTURIER
2022-02-07 11:16 ` Gloria Zhao
2022-02-08 4:58 ` Anthony Towns
2022-03-09 15:09 ` Gloria Zhao
2022-03-11 16:22 ` Billy Tetrud
2022-03-12 8:18 ` Billy Tetrud
2022-03-14 10:29 ` Gloria Zhao
2022-03-15 1:43 ` Billy Tetrud
2022-03-17 2:02 ` Antoine Riard
2022-03-17 15:59 ` Billy Tetrud
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=20220202102116.GB5140@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bastien@acinq$(echo .)fr \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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