Tx with feeRate = 1100sat/vB doesn't pass -minrelaytxfee of 1100sat/vB #18475

So I was fiddling with feerates today. I bumped into #13283, but this seemed different.

I have the following setup:

• -regtest and -minrelaytxfee=0.00001100
• one node makes a block every some seconds
• other node has -mintxfee=0.00001100 as well and connects to that node and creates a tx with createraw+fundraw+signraw+sendraw

On fundraw, I use "{\"feeRate\": 0.00001100}".

Result: the txs of the second node don't get relayed to the first node and don't get mined.

So my main reason for this research was to observe fee estimation. After a while, estimatesmartfee 3 gives a feerate of 0.00001097, which is just below the feeRate supposedly set in every txs in the blockchain & mempool (which seems weird on itself), but is also lower than the minRelayTxFee for that node.

Is this a bug report about fundraw, or about tx relay (feefilter), or about estimatesmart?

Can you reproduce the issue?

Yeah I found this while fiddling with things in Elements and reproduced this using Bitcoin Core 0.19.1. I can't say for sure which one of the parts is behaving wrongly.

This is a stat of one of the txs:

  "size": 418,
  "vsize": 256,
  "weight": 1024,

and

  "fee": -0.00000281,

So that would be 1097.65625 sat/kvB. Which seems to be undershooting the feerate I'm setting in fundraw. So I'd think it's a fundraw bug.

Actually that's more interesting because it's not 1099, which could be a rounding problem. In Elements I was getting 99 instead of 100, which I attributed to rounding. But here it seems like the difference is 2.5 sats, which is more significant. It seems it's significant enough to not be allowed in the peer's mempool. (In my Elements testing, the txs did get relayed despite calculating to 1 sat/vkB short.)

If you can reproduce, steps to reproduce or even a functional test would be useful to debug this. Or a debug log might even help

My OP kind-of explains the way to reproduce this. I noticed this in Elements and reproduced it in Core using the steps I gave in the OP.

Also, proving/testing the fee estimation aspect of this is also hard to do in a functional test because it's time-consuming.

@stevenroose have you continued to see this with subsequent releases or have further insight into the issue since your last comment?

Likely related to https://github.com/bitcoin/bitcoin/issues/11800

I guess there are two bugs?

• fee estimation returning something lower than the min fee, which was fixed in #22722
• The wallet somehow creating a tx with fee lower than the min fee

To debug the wallet issue, it would be good to double check in the debug log. The wallet should print a fee estimation debug info:

wallet.WalletLogPrintf("Fee Calculation: Fee:%d Bytes:%u Tgt:%d (requested %d) Reason: ...

I wrote a basic test to exercise a few of the possible cases here, although I am unsure whether OP was using full blocks, or just mining regularly...

1. Create a rawtx with the feeRate with the setting specified in OP, sign it and send it, which seems to work every time without undercutting the fees and so failing -minrelaytxfee checks.
2. Create a rawtx with a feeRate deliberately lower than the node's -mintxfee setting (which it seems is permitted by the override_min_fee bool in FundTransaction), sign it and send it. This transaction will enter senders mempool but is not accepted by the receiver who has -minrelaytxfee set to a value which excludes the transaction due to policy.

Closing for now, the rpc issue should be fixed, but the wallet one needs more infos to debug.