spec: bip 77 doesn't say how v2 receiver should reply to v1 sender

[nothingmuch]

the spec and the code disagree on whether to use PUT vs. POST when a BIP 77 receiver responds to a BIP 78 sender

[SIDHARTH20K4]

Hey, I'm interested in working on this issue but want to make sure I understand it correctly.

From what I gather:

• BIP 77 spec says the receiver should respond with [PUT/POST]
• But the current implementation uses [POST/PUT] instead

Questions:

1. Which BIP endpoint specifically has the mismatch? (the initial request, the response, or the proposal submission?)
2. Should we fix the code to match the spec, or update the spec to match the code?
3. Are there deployed wallets using the current (wrong) method that we'd break by fixing this?

I can take a crack at the fix once I understand the backward compatibility considerations.

[nothingmuch]

From what I gather:

• BIP 77 spec says the receiver should respond with [PUT/POST]
• But the current implementation uses [POST/PUT] instead

Not exactly.

The BIP 77 spec more or less implies that when a v2 receiver replies to a v1 sender via the directory it should POST, but actually only describes the behavior for dealing with a v2 sender.

The code actually implements a PUT:

rust-payjoin/payjoin/src/core/receive/v2/mod.rs

Line 1182 in e3dec5b

method = "PUT";

1. Which BIP endpoint specifically has the mismatch? (the initial request, the response, or the proposal submission?)

The proposal submission

3. Should we fix the code to match the spec, or update the spec to match the code?

Probably fix the spec to match the code as it is more incorrect than I remembered, it also describes HPKE usage as unconditional, when v1 responses are sent in cleartext. distinguishing them with PUT instead of POST is not really a technical distinction but does help things clear and i don't see any good reason to change it

5. Are there deployed wallets using the current (wrong) method that we'd break by fixing this?

Yes, which is a good reason to claim the spec is wrong, not the code

i doubt this code path is actually used in the real world, as far as i know most of the v1 usage is by btcpay which we'd typically expect to be in the receiver role

[SIDHARTH20K4]

Thanks for the clarification!!
So the fix is in the BIP-77 spec, not the code...

specifically: (1) specify PUT instead of POST for the v1 receiver response,
and (2) clarify that HPKE only applies when a reply_key is present.

I can also fix the misleading doc comment on create_post_request in receive/v2/mod.rs which says "POST request" but actually uses PUT for the v1 path.

Worth doing in the same PR or separate?

[nothingmuch]

Thanks for the clarification!! So the fix is in the BIP-77 spec, not the code...

specifically: (1) specify PUT instead of POST for the v1 receiver response, and (2) clarify that HPKE only applies when a reply_key is present.

yes, but "when a reply_key is present" is just an implementation detail, having a reply key in the code is used as a stand-in for being a v2 request because that's required

I can also fix the misleading doc comment on create_post_request in receive/v2/mod.rs which says "POST request" but actually uses PUT for the v1 path.

sure

Worth doing in the same PR or separate?

A fix to the spec would be on the bips repository so they would have to be separate, if you want you can fork the repo and make a PR into the main branch of your fork instead of the upstream if you'd like us to review it first