An opportunity to have fees subsidized in the moment of receipt is an even greater incentive. Someone else is willing to pay fees for you to transact, so consolidation or batching in that moment is cheaper than it would be without sender contribution.
Discussion
So, I remember when we thought about it "back in the day" we sort of concluded that "well, it doesn't technically reduce the fee costs for a merchant, if they pay for their inputs in the payjoin, but it can allow them to change when they pay fees" which could end up being better for them ... the point is really tricky.
Maybe you've thought about it recently in detail (I haven't!) so you may have a more exact perspective (btw please write it down somewhere if so!).
And then there's the scenario of a non-merchant receiver (which might apply here); it might not be relevant at all, there. Now with your new scheme, that becomes a more likely scenario than it was before.
There are two opportunities unique to payjoin to reduce fees beyond opportunistic consolidation (consolodating the incoming sats w/ existing sats can share the overhead of 1 tx)
1. transaction cut-through or forwarding: if you spend the incoming sats to someone else straight away in the same tx, you are never encumbered by fees to spend a utxo since you never take one
2. Overhead. Though indeed receivers do pay to add inputs to a payjoin, the marginal cost should be less than if they were to create their own tx to spend them since the sender is paying for the overhead of the tx header, making batching even more cost effective.
I have written the mechanics of how this could be coordinated here on substack. A few enterprise wallets have expressed interest especially since it hits their bottom line.
https://payjoin.substack.com/p/interactive-payment-batching-is-better
Very interesting article, thanks!
I hadn't considered (1) (cut-through) at all, at least I don't remember discussing it, but I totally agree that it's a very substantial possible angle of usage, and has economic incentive, at least if payjoin is a regular thing. A lot of it interacts with output substitution though, something we didn't discuss much until the end of the BIP78 discussion (and it was mostly motivated by address types iirc). I was and remain leery of it; as you already saw recently, it requires a very "hardened" security model, if anything is slightly off it introduces theft vectors. Still, if people get things right, for sure this kind of flexibility achieves something. It's just more dangerous.
As for (2) it feels very 'meh' to me. Even the concept that a receiver-merchant saves something is dubious because it's just kind of "cheating" the sender. And gains very little percentage wise anyway. Meanwhile you can save overhead, too, if you just accept 100 normal payments and then do a batch send of them later. (i.e. normal non-payjoin batching).
I understand how 2 could be relatively insignificant, but I definitely would not describe any aspect of it as cheating. The sender can specify their minfeerate and maximumadditionalfeecontribution to pay for 0 or more receiver inputs for privacy as well as their input + the overhead. A sender won’t sign any response that isn’t within sender-defined fee parameters.