Just a random thought, not sure if it's baseless.

What if we remove this requirement and just allow the payjoin endpoint to redirect the outputs of the proposed transaction?

It would allow settling payments scheduled by the receiver by using the sender's funds and not require any UTXOs at hand, and still poison heuristics even more. A 1 input tx could even be used to pay the receiver, and the receiver uses the same tx to pay scheduled payments. It is technically not a payjoin, but it is one in the world of meta as you've redirected funds from User A to Merchant A to MerchantSupplier A and MerchantSupplier B, with only 1 transaction.

This is a great idea.

I see this too late. The idea sounds good but the sender should reject it because it gains no privacy.

@lontivero it does. The receiver can make the change harder to detect.

The sender should not trust the receiver is honest.

What if the receiver replaces the change outputs' scriptPubKey by another already known address of the sender, forcing the sender to reuse addresses and damaging his privacy? Or Give it back some dust change even when the sender decided to spend the whole coin (to the same utxo scriptPubKey) or things like that.

Receiver could decide to split the change output in some way that only makes the sender to pay more fee.

The sender should not be forced to accept whatever the receiver proposes.

What if the receiver replaces the change outputs' scriptPubKey by another already known address of the sender, forcing the sender to reuse addresses and damaging his privacy? Or Give it back some dust change even when the sender decided to spend the whole coin (to the same utxo scriptPubKey) or things like that.

We should tighten this. Indeed, the sender may want to do a batch payment for example.
However it is important that the receiver can change his payment output. For example, if the receiver has 2 wallets and the payer is using P2SH for paying a P2WPKH, then the receiver should be able to switch the payment output to P2SH for improved privacy.

Receiver could decide to split the change output in some way that only makes the sender to pay more fee.

I enumerated the checks that the sender need to do to make sure he does not pay too much fee. (It is capped to twice the fee)
Moreover, it is important for the receiver to also be able to batch his own payments.

What if the receiver replaces the change outputs' scriptPubKey by another already known address of the sender, forcing the sender to reuse addresses and damaging his privacy? Or Give it back some dust change even when the sender decided to spend the whole coin (to the same utxo scriptPubKey) or things like that.

Is there perhaps a misunderstanding here @lontivero ? I took this does NOT check section to mean only that the sender does not check the type or number of the receiver's outputs - the sender certainly does check his own output, insisting on an unchanged scriptPubKey, and of course checking that the output amounts follow the other rules described.

But, the language should be clearer. It is the receiver's outputs that don't need to be checked.

Is 50bda8e better?

Probably I misunderstood this @AdamISZ, what you say makes sense to me.
@NicolasDorier 50bda8e is more clear. I am not sure my point is really important because the sender can always reject a proposal from the receiver.

This limit sounds reasonable now but in January 2018 some people paid upto 30 us dollars for a transaction and if that situation repeats it could mean 60us dollars instead of 30. This should be a recommendation and not be hard parameter because the implementers can decide to change this anyway.

I had the same thought. Why not require the receiver to bump any extra fees required from their own funds?

IMO, if the sender has already chosen a suitable fee rate and is expecting a certain amount of change, the receiver should not be changing this.

If the receiver wants to add inputs/outputs that's fine but they should cover all fees required and ensure they maintain an equivalent fee rate.

Allowing the receiver to change these values can lead to all sorts of strange UX issues that are problematic to solve on the wallet end.

What would be more reasonable here to state in terms of being cautious of fee increases?

I think change:

• Check that the sent amount in the payjoin proposal is less or equal to the sent amount of the original transaction.

If the sent amount in the payjoin proposal is above the amount sent in the original PSBT

• Check that the additional paid amount has been paid to fee.
• Check that the additional paid amount is not more than twice the original fee
• Check that the additional paid amount has only been used to pay the receiver's additional inputs.

to just:

• Check that the sent amount in the payjoin proposal is equal to the sent amount of the original transaction.

Many wallets ask a user to confirm the details of a transaction before sending it. This normally includes fee rate and spending amount. It's pretty confusing if a user confirms this, does a PayJoin, and ends up broadcasting a TX that actually spends a different amount with a different fee rate.

Yes, the wallet could notify the user of these changes and prompt them for confirmation but that leads to other UX issues and weird edge cases.

If the wallet prompts the sender if they want to accept a different fee rate / change amount, the original non-payjoin TX could already be broadcast by the receiver before the sender confirms. This would be very confusing.

If we don't prompt the sender, they could lose unfair amounts of money or the TX could take an unreasonable length of time to confirm.

Maybe the sender wanted a specific fee rate, because they want the change UTXOs in a reasonable amount of time.
Maybe the sender wanted a specific amount of change.

The receiver doesn't know the sender's reasoning for choosing those values so IMO they shouldn't be changing them.

The receiver can add whatever inputs/outputs they want, and the sender shouldn't care, as long as their change/fee rate values aren't changed.

but with an additional check of percentage change as well.

This is the Check that the additional paid amount is not more than twice the original fee part. Basically it allows a 100% percent change max. This is not fool proof either as high fee can make it unacceptable.

Maybe we should just remove the percent change max, and let sender the freedom to deal as they want with it? If the fee is almost the same, the sender should not care about validating the payjoin. However, if the fee is very different, the sender's UI might want to show a proper confirmation step to the user.

Given how pain in the ass it is to implement, I guess a good temporary way for senders would be to enforce in software this max limit.

Another thing we can do is also to add an optional parameter that the sender can specify to the receiver "maxfeecontribution". For example "maxfeecontribution=1000" would tell to the receiver that the sender wants to pay up to 1000 satoshi of fee. Above this, the receiver could still pay from his own pocket.

I think this can be a good solution as it remove the need for sender wallet to ask one more question to the user. What do you think @lukechilds?
It could be a wallet setting: Don't accept more than 1USD of additional fee for payjoin or something like that.

Another thing we can do is also to add an optional parameter that the sender can specify to the receiver "maxfeecontribution". For example "maxfeecontribution=1000" would tell to the receiver that the sender wants to pay up to 1000 satoshi of fee. Above this, the receiver could still pay from his own pocket.

Yeah, I think this is a reasonable solution.

It could just be a global setting in the wallet that defaults to some sane value. Then users can set a custom value if desired or override on a per payment basis.

It solves the UX issue of requiring a second user confirmation as you said. It also allows a wallet to show the max possible potential fee in the initial confirmation dialog to the user too.

This is the Check that the additional paid amount is not more than twice the original fee part. Basically it allows a 100% percent change max. This is not fool proof either as high fee can make it unacceptable.

Sorry if it wasn't clear. I meant percentage of the payment amount, not percentage of the existing fee. And this would be separate to what I am counting as a non-percentage "absolute" measure - the existing fee in satoshis (100% of fee as a number of sats).

I wrote 38cfb3f @AdamISZ @lukechilds this would allow the sender to decide by himself what he considers reasonable. Does it solve all the issues?

This also let the receiver to adapt the size of his contributions based on the sender's preference. This also let the receiver eventually pay for the inputs if he wishes to.

I think that's good.

Maybe reword to:

• maxfeebumpcontribution=, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. To be ignored if set to less than zero. (default: -1)

In case the receiver does not add any inputs then the sender could use the original transaction instead of the proposed by the receiver because it is hard to believe the sender can improve his privacy in this way and there is a risk of the receiver is sending to an exchange, betting site or something like that.

Sender can increase privacy even if inputs are not added, for example, if the receiver switched his output from P2SH to P2WSH to match the type of inputs.

Should the receiver accept payjoin request with nLockTime in the future? It could be easy to scan the receiver utxo by sending transactions that can only be mined in 100 years.

It can't because the receiver and the sender are broadcasting the original PSBT after 2 minutes whatever happen.

@NicolasDorier you have answer this same question twice to me but I still don't get it. Do you say the receiver can broadcast a transaction that cannot be mined?

Sorry I misunderstood. I thought you were talking about an invalid payjoin tx (in which case, this is not a problem as the original transaction will be broadcasted).

In BTCPay Server, we verify that the transaction is broadcastable before doing payjoin.
For Wasabi wallet, the sender will not be able to automatically retry a payjoin transaction so he would only learn about a single utxo.