payjoin
directory: limit V1 requests to 7168 bytes
This ensures that the OHTTP relay will not be able to distinguish v1 from v2 responses to the receiver.
Pull Request Checklist
Please confirm the following before requesting review:
- [x] I have disclosed my use of AI in the body of this PR.
- [x] I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.
Pull Request Test Coverage Report for Build 17336830025
Details
- 0 of 0 changed or added relevant lines in 0 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage remained the same at 85.916%
| Totals | |
|---|---|
| Change from base Build 17332008623: | 0.0% |
| Covered Lines: | 8168 |
| Relevant Lines: | 9507 |
💛 - Coveralls
I should have rewritten the commit message, it predates me verifying that the directory pads responses, details below (originally i was going to open another PR for that, realized i didn't need to but forgot to update this one).
If the sender is v1, and sends a too large request, the directory will truncate that when responding to the receiver's GET request:
https://github.com/payjoin/rust-payjoin/blob/fe9a5c68aa2018b5d659549bf83163bee8e0124f/payjoin-directory/src/lib.rs#L211
If it wasn't truncated then the receiver would still not be able to reply because the response will almost certainly be larger (if the sender's inputs have very large witness data, e.g. labitbus, then this might not be the case #fixthefilters)
Anyway, for this reason it's better to reject these requests earlier, giving an error to the sender, instead of giving the receiver a truncated request. This will generate a content length mismatch error in the receiver's state machine and that's not a replyable error.
As for the actual size, I chose that for simplicity and consistency with the requests. Technically it could be allowed to be up to BHTTP_REQ_BYTES - response overhead (status and empty headers?) and still be representable without truncation, but because the receiver needs to reply to it with a proposal request I don't think we can put a precise number on that due to the receiver adding its own inputs with arbitrary weight.
Setting it to BHTTP_REQ_BYTES - overhead seems less conservative as far as facilitating a payjoin, but i guess it ensures that the sender can at least receive the request in full and choose to broadcast the fallback if it fails to construct a response that fits.
~~hmm actually it might not even raise content length mismatch since that's set by the directory, so i think it's just silently truncated and psbt parsing might fail, and trailing query params may be silently omitted without error?~~
ah no i remembered correctly, first the full body is written and then the serialized bhttp response is possibly truncated: https://github.com/payjoin/rust-payjoin/blob/fe9a5c68aa2018b5d659549bf83163bee8e0124f/payjoin-directory/src/lib.rs#L209 so i think it will generate a content length mismatch