proposed BIP 77 edits for the poll-timing change, implemented in #1658, part of #440, #1586
authors: @DanGould @nothingmuch
Client/Directory interactions
current:
GET requests on an empty mailbox should block until a message is posted or a timeout occurs. The timeout should be 30 seconds because that will not exceed the default timeout for most HTTP clients.
proposed:
A directory should respond to v2 poll GET requests immediately rather than blocking. The 30-second blocking timeout still applies to the synchronous BIP 78 fallback. Clients should poll on a Poisson schedule with a uniform 5-second mean gap, scheduling each poll independently of when the previous response arrives, so the directory cannot infer a client's relay round-trip latency from poll timing (see Request timing). A client that polls without its own schedule against a non-blocking directory will poll excessively until updated, bounded by the directory's denial-of-service protections.
Attack vectors - add a new entry after Network privacy
Request timing
A fixed poll cadence makes the directory-observed interval approximately the cadence plus the client's round-trip latency to its relay, which can distinguish sender from receiver and correlate a session's requests. Clients poll on an independent Poisson schedule decoupled from responses, so the observed process reveals only the rate. The rate must be uniform across clients, since a per-client rate is itself a fingerprint. A single directory is not a mix network, so this is partial: directory-side delay and cover traffic are future work.
- Rationale - add a new entry after
HTTP
Poll Interval
The 5-second mean balances latency against directory load: a payjoin completes in roughly two poll gaps, while a shorter interval would multiply requests and bandwidth, a concern for mobile clients. The directory learns the rate, so uniformity matters.
- follow-up timing mitigations (POST re-clock, directory mixing delay, cover traffic) will be proposed as separate edits.
does this wording work? open to alternatives on the unconditional non-blocking and the 5s default.
proposed BIP 77 edits for the poll-timing change, implemented in #1658, part of #440, #1586
authors: @DanGould @nothingmuch
Client/Directory interactionscurrent:GET requests on an empty mailbox should block until a message is posted or a timeout occurs. The timeout should be 30 seconds because that will not exceed the default timeout for most HTTP clients.
proposed:A directory should respond to v2 poll GET requests immediately rather than blocking. The 30-second blocking timeout still applies to the synchronous BIP 78 fallback. Clients should poll on a Poisson schedule with a uniform 5-second mean gap, scheduling each poll independently of when the previous response arrives, so the directory cannot infer a client's relay round-trip latency from poll timing (see Request timing). A client that polls without its own schedule against a non-blocking directory will poll excessively until updated, bounded by the directory's denial-of-service protections.
Attack vectors- add a new entry afterNetwork privacyRequest timingA fixed poll cadence makes the directory-observed interval approximately the cadence plus the client's round-trip latency to its relay, which can distinguish sender from receiver and correlate a session's requests. Clients poll on an independent Poisson schedule decoupled from responses, so the observed process reveals only the rate. The rate must be uniform across clients, since a per-client rate is itself a fingerprint. A single directory is not a mix network, so this is partial: directory-side delay and cover traffic are future work.
HTTPPoll IntervalThe 5-second mean balances latency against directory load: a payjoin completes in roughly two poll gaps, while a shorter interval would multiply requests and bandwidth, a concern for mobile clients. The directory learns the rate, so uniformity matters.
does this wording work? open to alternatives on the unconditional non-blocking and the 5s default.