spacebear

I believe all checklist items are now covered by our tests 💪 Closing this issue.

The receiver checklist from BIP78 is comparatively barebones: > - Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. * > - If the...

Thinking about the input contribution step more... The way input selection currently works: - Receiver selects one (and only one) input to contribute. It can be for ~any amount (UIH...

Also, it would be very helpful to have a list of concrete examples/test cases that cover realistic use cases for tx cut-through, e.g. opening lightning channels, utxo consolidation, forwarding payments...

Are we satisfied that the Session Event Log resolves this issue? If not, what else is missing?

Leaving in draft for now because some follow-up items need to be addressed: - process_response methods return inconsistent error types when POSTing vs. GETting, specifically: EncapsulationError vs. ResponseError for send...

The error audit I mentioned in my other comment can be addressed later in a follow-up, I'll make a new issue. > are there other from conversions that can be...

The latest push fixes `process_get_res` and replaces the `From` implementations with `map_err`.

ec4b67e7f39ee8e707c7a272b7459fb836ae0a50 only applies your suggestions re: `response.status()`.

Receiver side already enforced the size limit iiuc? > The v1 receiver enforces a reasonable limit on the request: > > https://github.com/payjoin/rust-payjoin/blob/34ee78d44e1527210a343f4e08128e41a82a67a1/payjoin/src/receive/v1.rs#L95-L97 It's here now: https://github.com/payjoin/rust-payjoin/blob/master/payjoin/src/receive/v1/exclusive/mod.rs#L60