This probably deserve a test. Also, it doesn't seem like putting to 0 is ever a good idea, you just open yourself to DoS. It seems like the problem is more not being able to go lower than 1sat/kb than not being able to go to zero, or is it ?

Test you referring to is part of D554 as this change was.

Going to move the test over here too.

Prev to this change you can set minrelaytxfee to 1 satoshi per KB (10E-3 sat per byte). It's different from zero but not much in terms of opening the door to DoS attacks.

What I wanted to say is that letting minrelaytxfee being 0 or 1 satoshi per KB does not change much.

Another thing to take into account is that once you start to run out of mempool space (current default 300MB) incrementalrelayfee kicks in, current default for the latter is 1000 satoshi/KB. That means that the open door to the DoS attack will be closed again.

To recap I'm going to add a functional test here to verify that we are going to relay non-high-prio zero fee txns in case minrelaytxfee is set to 0.

Same test file will be expanded further in D554 adding test to cover other scenarios.

Lastly WRT having sub-satoshi per KB fee: I have to look at the code. But I think that we could reach this aim changing the default rate unit switching from sat/KB to sat/MB, so that we could ideally achieve 0.1 satoshi per KB, hence 10E-4 per byte.

Current default is 1 satoshi per byte (minrelayfee = 1000 Sat/KB) I think that lowering the default by a order of magnitude (i.e. minrelayfee = 100 Sat/KB) would be already a great thing to have and wouldn't require match changes if not at all a part from changing some defaults and adding some unit/functional tests.

On second thought I think I will setup a new unit test to see if minrelayfee could be set to 0 and leave the more complete functional test on D554.

This doesn't seem like it should be independent of D554