Failure to contribute inputs should result in reciverer fallingback

[arminsabouri]

This check if fine as the internal error is opaque and this is checked in the input selection logic https://github.com/payjoin/rust-payjoin/blob/3f057e130d45c423a22c5e41007529cc0ee6894f/payjoin/src/core/receive/common/mod.rs#L273C51-L273C87

But ideally the receiver should fallback here instead. And we propogate the internally error somehow so we don't have a duplicate check

Originally posted by @arminsabouri in #1071 (comment)

[arminsabouri]

Related to #1164

[mehmetefeumit]

Any thoughts on whether the fallback would be handled by the receiver or the sender?

Alternative 1: Receiver Broadcasts the Fallback

1. Receiver broadcasts the fallback transaction.
2. Receiver sends an indication of the fallback to the sender.
3. Receiver marks the session complete.
4. Sender receives the update, handles it, and marks the session as complete in the persister.

Alternative 2: Receiver Indicates Payjoin Failure to Sender; Sender Broadcasts Fallback

1. Receiver sends an indication of the fallback to the sender; this can be the fallback transaction AS the "proposal," or a different payload which specifically indicates the fallback.
2. Receiver directly moves to the Receiver<Monitor> state, which will handle fallback transaction monitoring.
3. Sender broadcasts the transaction and marks the session complete.
4. Receiver detects that the fallback transaction has been broadcast, and marks the session complete.

---

I'm thinking which one makes sense from a motivation perspective. The sender wants the privacy, but in Alternative 1, the receiver can broadcast the transaction without the approval of the sender. Note sure if an additional flag indicating if the sender is willing to not use the fallback transaction would be ideal, unnecessary, or if there are better alternatives... IMO, sender broadcasting seems like the better alternative.

[arminsabouri]

Thanks for laying out some options

The receiver can broadcast the transaction without the approval of the sender

The receiver does not need the approval of the sender. Nor is there a coordination between them to figure out when or who is going to broadcast the fallback. Either party can broadcast depending on the application and user preferences.

Note sure if an additional flag indicating if the sender is willing to not use the fallback transaction would be ideal,

By virtue of using a bip77 Pj client the sender is opt'ing into using the fallback.

Re: alternative two. IIRC this is exactly what our error to monitoring state machine does today. We reply with an error and then monitor. If the error is requires the receiver to fallback perhaps that warrants another typestate which exposes the fallback and then progresses to monitoring. In this case I dont see why the receiver should wait for the sender to fallback. If the reciever is expecting more inputs they can wait, otherwise they should just fallback. Another point, the sender doesnt need an error reply to know the fallback is broadcasted. Assuming most applications are monitoring for incoming/outgoing txs. Maybe that assumption is too weak and we need some monitoring on the sender side. This decision will be informed by doing more integrations.

Also related work: #1164