Add "effective fee rate" in rpc's mempool entries #10389

For both getrawmempool true and getmempoolentry it should probably have a field effectivefeerate.

Where as "effective fee rate" is defined as what miners sort transactions by (when taking into consideration the whole CPFP stuff).

I need this field for when trying to create my own CPFP transactions, but it's quite difficult to calculate myself (especially as the mempool entries don't have a "dependants" field, so you need to dump the whole mempool, which currently takes me about ~26 seconds alone).

--

This is useful for when trying to do something like CPFP as you want to know the pre-existing fee rate. The term I use in my code that deals with this is "transaction cluster" which might make a decent term. It could expose a "clusterSize" and "clusterFee" so you can calculate the feerate (as well as know the total size of the cluster)

You can divide ancestorfees divided by ancestorsize to get the feerate in sat/byte for a transaction including all its dependencies.

@sipa That's wouldn't take into consideration CPFP

Assume all transactions are very small, and we have 4 unconf transactions (A, B, C and D):

A = 10 satoshis of fees B = 100 satoshis of fees (and depends on A) C = 1 satoshi of fees (and depends on B) D = 1000 satoshis of fees (and depends on B)

If we're querying B, what we care about is size/fee of the (A, B, D) set. This is all the ancestors and some (but not all) of the descendants (when they boost the effective fee rate)

@rhavar I think you may be interested in the getmempoolancestors and getmempooldescendants rpc calls (introduced in #7292).

Assume all transactions are very small, and we have 4 unconf transactions (A, B, C and D):

A = 10 satoshis of fees B = 100 satoshis of fees (and depends on A) C = 1 satoshi of fees (and depends on B) D = 1000 satoshis of fees (and depends on B)

Keep in mind that it's a bit tricky to exactly calculate the "effective" feerate of transaction B. Imagine if A had some other descendant, E, which has a much higher feerate than D. Then A's effective feerate is actually determined by E, and B's effective feerate is determined only by B and D (since B no longer has to pay for A).

If you're interested in transaction B and willing to ignore the effect of descendants of B's ancestors on the effective feerate of B, then I think you could just look at all the descendants of B, and look at the max ancestor feerate of B and each of B's descendants. Does that seem like it'd be good enough for your use cases?

@RHavar I think you may be interested in the getmempoolancestors and getmempooldescendants rpc calls (introduced in #7292).

Yeah, that's neat. It'll make my code a little simpler, I won't need to dump the whole mempool. It's not ideal though, because I still need to:

getmempoolancestors on the transaction, and then loop over all the results with getmempooldescendants to compile enough information.

Keep in mind that it's a bit tricky to exactly calculate the "effective" feerate of transaction B.

Yeah, it's annoying. That's why it should be provided by bitcoin :P

Does that seem like it'd be good enough for your use cases?

Nope :( I really need to know exactly in order to do CPFP myself properly.

Seems related to #15553 and #9645. Currently working on this.

Ping @murchandamus, does this work with MiniMiner now?

Ping @murchandamus, does this work with MiniMiner now?

It does, can probably implement this for getmempoolentry. Just need to handle GatherClusters potentially running up against the mempool limit.

Should become easy to do with cluster mempool as well.