Date: Wed, 2 Feb 2022 20:21:16 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bastien TEINTURIER <bastien@acinq.fr>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220202102116.GB5140@erisian.com.au>
References: <MunATIf--3-2@tutanota.de>
 <CACdvm3O4sQ_kF+y9R73c1wiDiTos9Zs7jJQZEQrc8Uz5SsSx1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACdvm3O4sQ_kF+y9R73c1wiDiTos9Zs7jJQZEQrc8Uz5SsSx1g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Improving RBF Policy
Precedence: list

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