Should default `min_feerate` be 0?

[arminsabouri]

This is more of an open question than a bug report so if I am wrong please answer and close the issue.
If a sender does not provide a sane minfeerate the default value of 0 or FeeRate::MIN. Could this mean that after the reciver adds inputs/outputs the pj tx total fee rate drops below the default mempool policy min relay fee rate? Of course the tx is brodcastable but will be rejected due to mempool policy. Instead the default value for minfeerate should just be the min relay fee rate.

[DanGould]

I don't think payjoin has a strict dependency on mempool, only consensus rules. It seems to me that clients may impose a dependency on mempool, but our crate does not have to.

[DanGould]

That said, maybe it's more appropriate to use FeeRate::BROADCAST_MIN as default and allow FeeRate::ZERO by explicit configuration

[nothingmuch]

somewhat relatedly, max_fee_rate (which, for clarity, constrains the receiver's effective feerate, not the overall feerate for the payjoin transaction) also defaults to 0, but that might not be economically rational for receivers.

as a base case, suppose Alice sends a payjoin with amount $x$ to Bob, who has $k$ UTXOs worth $y$ in total, and that the original PSBT has a feerate of exactly 1 sat/vbyte.

if bob's max_fee_rate is 0, he will reject this proposal, and end up with $k+1$ UTXOs, all of which have to be spent eventually, i.e. his effective balance at min relay fee is $(x+y) -(k+1)\epsilon$. on the other hand if his max_fee_rate is 1 sat/vbyte, his effective balance will be $((x - \epsilon) + y) - k \epsilon$ which is exactly the same as $(x+y) - (k+1) \epsilon$

however, if Bob expects to need to pay a higher fee to spend these UTXOs at a later point in time expressed as $\epsilon_0 < \epsilon_1$, which is basically true by definition, then he should prefer to accept, because $((x - \epsilon_0) + y) - k \epsilon_1 < (x + y) - (k+1)\epsilon_1$.

in other words therefore it's strictly more rational for Bob to prefer accepting such a transaction at min feerate regardless of what value min relay fee is since the lowest it could ever go is 0.

this also suggest users should specify max_fee_rate in line with core's waste metric's long term feerate, which we should probably document.

[DanGould]

I'm now convinced defaulting to FeeRate::BROADCAST_MIN makes sense for receiver's max_fee_rate setting (is this an appropriate name, given that it represents effective feerate for spending only its own contributions / consolidations in isolation?

If this is taken as default, it is must be applied at ProvisionalProposal::apply_fee as a default rather than leaving it up to implementers to do correctly.

AND that we must document that max_fee_rate ought to be set to core's waste metric long-term feerate (Or whatever this idea represents) for purely economizing consolidators, and that we should somehow build this into coin selection to optimistically consolidate under low-fee payjoin-available conditions.

[spacebear21]

if bob's max_fee_rate is 0, he will reject this proposal

I don't think this is strictly true: BIP78 recommends for the sender to set an allowance to pay for one receiver input by setting maxadditionalfeecontribution (see the Fee Output section). The payjoin-cli sender follows this recommendation by calling build_recommended.

Bob could still reject the proposal if e.g. he is trying to add multiple inputs, or one input of greater weight than what Alice is willing to pay for, but that's not the base case.

[nothingmuch]

Bob could still reject the proposal if e.g. he is trying to add multiple inputs, or one input of greater weight than what Alice is willing to pay for, but that's not the base case.

This is correct, but what I meant by base case wasn't that it's the default/typical behavior, rather the in the sense of a strong induction argument, even in this most pessimal case the inequality still holds unless Bob's expectation is strictly that he will never pay more than min relay fee, and even then $\leq$ holds, implying he should still weakly prefer a higher default value (presumably he values payjoin privacy greater than 0, but less than 1 sat, or he would not signal willingness to accept payjoins).

In general, this additional contribution is not guaranteed in rust-payjoin (c.f. fee_available branch), and different sender implementation might ignore this recommendation altogether.

In what we hope is the typical case, which is better than this base case, the inequality still holds and with a larger separation, so I think that doesn't change the conclusion that a default of min relay fee is more rational?