clarify relayfee method and add blockchain.mempoolminfee method

[f321x]

The description of blockchain.relayfee() promises the user that
transactions paying the relayfee will get accepted into the servers
mempool. This however seems incorrect as the relayfee is just a
fixed value in the core backend (either configured or a hardcoded default value)
and doesn't change with a growing mempool.
See definition:
https://github.com/bitcoin/bitcoin/blob/d387b8ec15e553db9b9c370314ee359e981fb374/src/main.cpp#L55-L56
and usage for the API:
https://github.com/bitcoin/bitcoin/blob/d387b8ec15e553db9b9c370314ee359e981fb374/src/rpcmisc.cpp#L86-L87

To get the minimal feerate to be paid for mempool acceptance one has to
use getmempoolinfo['mempoolminfee'] being added here as blockchain.mempoolminfee()
This can be useful for things like lightning anchor commitment tx fees as discussed here:
spesmilo/electrum#9826

[SomberNight]

Using bitcoin core 28.1, getmempoolinfo returns a structure as below:

$ bitcoin-cli getmempoolinfo
{
  "loaded": true,
  "size": 9444,
  "bytes": 4434640,
  "usage": 23474240,
  "total_fee": 0.08848368,
  "maxmempool": 1500000000,
  "mempoolminfee": 0.00001000,           // what you propose to also expose
  "minrelaytxfee": 0.00001000,           // already exposed as blockchain.relayfee
  "incrementalrelayfee": 0.00001000,
  "unbroadcastcount": 0,
  "fullrbf": true
}

What else might we want to expose from this data structure?
I guess at least incrementalrelayfee could be nice. Maybe maxmempool.
These seem easily cacheable.

Note that we might not want to expose size/bytes/usage/total_fee, as that would make servers fingerprintable. Imagine if two servers are backed by the same bitcoind. Comparing these values between them would trivially link them together. (is this a real concern though?)

Would it be better to add a single RPC that exposes whatever subset we want, or separate methods for each?
If it's a single method, we could mandate some fields, and say that besides those it could contain anything (if it's a dict).

[f321x]

yeah we could easily make more values available if they are useful, spesmilo/electrumx@e5bae4d already caches the whole getmempoolinfo response anyways.

I think these values could be interesting for clients in some way:

  "mempoolminfee" : n,          (numeric) Minimum fee rate in BTC/kvB for tx to be accepted. Is the maximum of minrelaytxfee and minimum mempool fee
  "minrelaytxfee" : n,          (numeric) Current minimum relay fee for transactions
  "incrementalrelayfee" : n,    (numeric) minimum fee rate increment for mempool limiting or replacement in BTC/kvB

not sure if the others could be useful in any way for clients?
If we accept the privacy downside you mentioned, maybe:

  "unbroadcastcount" : n,       (numeric) Current number of transactions that haven't passed initial broadcast yet

could also be useful for a client to see if this server is a good choice to broadcast a transaction to, or if another one with lower unbroadcastcount might be better.
I expect it is not too difficult to detect if two servers use the same daemon e.g. by timing notifications?

We could expose these three values in a single call to blockchain.mempoolinfo and maybe mark blockchain.relayfee for deprecation at the same time as is already included here?