pull down to refresh
Is replacing tx_LS and tx_RBFr with tx_HS at step 7 really allowed?
Personally I consider it a design flaw of RBF. The whole point of the BIP 125 Rule #2 unconfirmed inputs rule is to avoid this type of situation where an unconfirmed input causes the replacement to be less valuable. As this example shows, the rule didn't go far enough - limiting unconfirmed inputs to coming from the same replaced transaction would fix this I believe.
RBF as it is currently implemented compares the feerates of transactions, not their mining scores, and the replacement does increase the feerate:
tx_HS has a higher feerate than tx_RBFr. The overall fees increased in the mempool, as well as the overall feerate in the mempool. While your expectation that the mining score (or effective feerate) of all transactions should increase, that’s not how it works at this time. It turns out that calculating a transaction’s mining score is a non-trivial amount of computational work that requires the entire cluster of the transaction as context. See e.g. the work Gloria Zhao and I did here last year: Implement Mini version of BlockAssembler to calculate mining scores. Also, you will probably really like the ClusterMempool project, since it will allow us to only accept replacements that strictly improve the mempool including in the manner that you describe.As far as I can tell,
tx_HS is a valid replacement of tx_RBFr and tx_LS as it:- Only includes unconfirmed inputs that were included by one of the directly conflicting transactions:
Yes,tx_HSonly uses the unconfirmed output oftx_LLthat was previously spent bytx_LS. - The replacement transaction pays an absolute fee of at least the sum of the replacements:
Yes, 105,000 sats ≥ 100 sats + 2000 s. - The additional fees (difference between absolute fee paid by replacement and originals) pays for the transaction’s bandwidth at or above incremental relay feerate:
Yes, 105,000 sats – (2000 sats + 100 sats) = 102,900 sats ≥ 5000 vB × 1 s/vB. - The number of original transactions does not exceed 100: Yes.
- The replacement transaction’s feerate is greater than the feerate of all directly conflicting transactions: Yes, 21 s/vB ≥ 20 s/vB ≥ 1 s/vB.
reply
RBF as it is currently implemented compares the feerates of transactions, not their mining scores, and the replacement does increase the feerate
That's not really true though. It's increasing the fee-rate of a transaction in isolation. But from the point of view of miners it is not increasing the fee-rate of the immediately mineable mempool, because you have to mine a low fee-rate transaction first to access the high fee-rate.
In my replace-by-fee-rate post, I called this kind of concept the highest minable fee-rate. The situation itself is similar to the argument as to why replace-by-fee-rate is miner incentive compatible in the first place: we'd almost always rather mine a high fee-rate transaction now, than have a higher total fee transaction that can't be mined any time soon.
As I mentioned on bitcoin-dev, IIUC Suhas identified this issue with RBF and has a draft pull-req intended to fix it. An even simpler fix could be to require that all unconfirmed inputs to a replacement come from the same transaction; currently they're allowed to come from different transactions. The whole point of the unconfirmed input rule was to avoid this type of situation in the first place; turns out we needed a stronger version of that rule.
reply
In my replace-by-fee-rate post, I called this kind of concept the highest minable fee-rate.
Yes, and the people that have been working on this topic in the past few years speak of "mining score" and "feerate diagram comparison" in this context.
It's increasing the fee-rate of a transaction in isolation. But from the point of view of miners it is not increasing the fee-rate of the immediately mineable mempool, because you have to mine a low fee-rate transaction first to access the high fee-rate.
While that might have been the intention, it is not how RBF is implemented today. I would expect you to know this, given your involvement in the original work and your recent advocacy for
mempoolfullrbf. If you have not read them yet, you may find Suhas’s overview of Cluster Mempool and Gloria’s numerous write-ups for RBF, package relay, v3 transactions, etc. interesting.
tx_LSandtx_RBFrwithtx_HSat step 7 really allowed? To me it's clear that it should not be allowed.tx_RBFrhas an effective fee rate of 20 s/vB, whiletx_HShas an effective fee rate of 1.95 s/vB. If current RBF code allows this, that is IMO obviously a bug that should be fixed regardless of RBFr.