Cannot create low fee transaction via RPC #16304

Issue We're running bitcoind + lnd on a raspberry pi with several other pieces of software. Because we want bitcoind to be really light weight, we set the maxmempool to be 20 mb. We don't really care about having mempool data itself, but we do care about being able to create transactions and broadcast those transactions to the network.

The problem we've been running into is that when the mempool is constricted like this (20 mb limit), mempoolminfee seams to start out at 0.00000001 at boot time, but then gets larger the longer bitcoind is online. We typically create transactions at 1 sat_per_byte because we don't care about them being validated immediately. The problem is we're getting this [lncli] rpc error: code = Unknown desc = -26: mempool min fee not met, 143 < 2005 (code 66). This error is of course being propagated by bitcoind.

We set mintxfee to 0.00000001 and even minrelaytxfee to 0.00000001, but neither seem to stop mempoolminfee from increasing over time.

Is there anyway to guarantee these transactions always get inserted into the mempool and broadcasted? I did some research and it looks like the mempool operates like that to avoid dos attacks. But, shouldn't rpc calls bypass these ddos issues. It makes sense that rpc calls should always work.

Expected Behavior There are two appropriate ways I think this could be handled.

1. Creating a transaction via RPC should always be accepted by the local mempool and broadcasted to peers that will accept that feerate.
2. Creating a transaction via RPC should always be broadcasted to peers that will accept that feerate.

Actual Behavior The RPC call fails with an error message similar to this mempool min fee not met, 143 < 2005

Environment We compile our own docker containers. Important lines from the docker file are below. We are also using lnd 0.7.0.

FROM ubuntu:18.04

ARG VERSION=0.18.0
ENV BINARY_LINK https://bitcoin.org/bin/bitcoin-core-${VERSION}/bitcoin-${VERSION}-x86_64-linux-gnu.tar.gz

Machine Info This specifically is happening on a raspberry pi 3b+. But, I believe it is not machine based.

This is an intentional feature. If you broadcast transactions that have a feerate lower than the feefilter you send out, you are explicitly telling everyone that they most likely originated at your node. (See BIP 133 for details on feefilter). Also, in a network where most nodes are Bitcoin Core, and most Bitcoin Core nodes run with the default settings, it is hard to propagate a transaction that is rejected due to the mempool default limits.

I see that you manually set the mempool limit to a lower threshold. So, your transaction might propagate to peers, assuming that the feefilter your peers sent you indicate a lower feerate than the one your txs pay.

If you understand what you are doing, you can (before sending the tx to your mempool) mock the feerate of the tx with prioritisetransaction, then send the tx as usual.