@Gruez there's no bug here

local transactions are treated exactly the same way that outside transactions are treated to avoid fingerprinting attacks

I believe that contradicts the intention for the whitelistforcerelay flag. Here's the relevant comment for it.

                // Always relay transactions received from whitelisted peers, even
                // if they were already in the mempool or rejected from it due
                // to policy, allowing the node to function as a gateway for
                // nodes hidden behind it.

My interpretation of this is that the transaction should be relayed, even if it was rejected for not meeting the min mempool fee. I checked for when the check for mempool min happens, and it's after the check for whitelistforcerelay, which means the same transaction will also not be relayed, even if it was from a whitelisted node, which appears to contradict what was intended according to the comment.

There should probably be a flag for sendrawtransaction to act as if whitelisted, default to off.

Maybe it would be simpler to just have a "force" flag for sendrawtransaction that will override everything except consensus rules.

@pstratem @jameshilliard See #7533

I ran into this other day, and an easy work around is to first call prioritisetransaction on the transaction setting it a high virtual fee, then sending it

Relaying a transaction you wouldn't accept yourself is generally a waste of time-- not just fingerprinting avoidance-- after all, if your own node wouldn't relay it because the fee is too low, then none of your peers likely will either.

The whitelist relay stuff is mostly intended to handle rebroadcasts for transactions which weren't correctly relayed the first time because you had few/no peers up at the time.

Priortizing it is a pretty good general workaround, -- though it still won't make peers handle the transaction. :)

Not sure this is a bug. Also, a "workaround" exists.