Should ohttp-relay selection be done on a per session basis in the cli

[benalleng]

Currently when running a command like payjoin-cli resume the relay manager selects a good relay and then uses that for all current sessions instead of randomly selecting a relay for each session. This can release some heuristics through our connection metadata and instead we should probably be selecting a new randomized relay for each session individually.

[bc1cindy]

BB mobile and Cake Wallet are the wallets that use BIP-77 (v2) for now, and both do ohttp-relay selection per-request, not per-session

BB Mobile

fixed deterministic order, same relay for per-request:

// constants.dart:50
static const List<String> ohttpRelayUrls = [
  'https://ohttp.achow101.com', // always first
  'https://pj.bobspacebkk.com',
  'https://ohttp.cakewallet.com',
];

bullbitcoin-mobile % rg ohttpRelayUrls
lib/core/utils/constants.dart
50:  static const List<String> ohttpRelayUrls = [

lib/core/payjoin/data/datasources/pdk_payjoin_datasource.dart
58:    for (final ohttpRelayUrl in PayjoinConstants.ohttpRelayUrls) {
562:      for (final ohttpRelay in PayjoinConstants.ohttpRelayUrls) {
616:    for (final ohttpRelayUrl in PayjoinConstants.ohttpRelayUrls) {
650:    for (final ohttpProxyUrl in PayjoinConstants.ohttpRelayUrls) {
703:      for (final ohttpRelay in PayjoinConstants.ohttpRelayUrls) {

randomness it's being fixed in SatoshiPortal/bullbitcoin-mobile#1907

Cake wallet does ohttp-relay selection per-request using Random.secure()

// payjoin_send_worker.dart:74
ohttpProxyUrl: await pj_uri.Url.fromStr(PayjoinManager.randomOhttpRelayUrl()),

// payjoin_send_worker.dart:87 
ohttpRelay: await PayjoinManager.randomOhttpRelayUrl(),

// payjoin_receive_worker.dart:107
ohttpRelay: await PayjoinManager.randomOhttpRelayUrl(),

// payjoin_receive_worker.dart:124
ohttpRelay: await PayjoinManager.randomOhttpRelayUrl(),

see more in #1328

all implementations bellow only use BIP-78 (v1)

BTCPayServer

using BTCPayServer.BIP78.Sender;

Blue Wallet

"payjoin-client": "1.0.1",

Sparrow Wallet

grep "postString" src/main/java/com/sparrowwallet/sparrow/payjoin/Payjoin.java
            String response = httpClientService.postString(finalUri.toString(), null, "text/plain", base64Psbt);

Join Market

joinmarket-clientserver % grep -i "bip" src/jmclient/payjoin.py
                      process_shutdown, BIP78ClientProtocolFactory)
    https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki

Wasabi Wallet

WalletWasabi % grep "HttpClient\|PaymentUrl" WalletWasabi/WebClients/PayJoin/PayjoinClient.cs | head -5
        public PayjoinClient(Uri paymentUrl, HttpClient httpClient)
                PaymentUrl = paymentUrl;
        public Uri PaymentUrl { get; }
        private readonly HttpClient _httpClient;
                var endpoint = ApplyOptionalParameters(PaymentUrl, optionalParameters);

BitMask

bitmask-core % grep "payjoin" Cargo.toml
payjoin = { version = "0.8.0", features = ["send"] }

as raised in #1380

rotating relays across requests within the same session is safe,
but would be an unusual pattern that could itself become a fingerprint

the current per-process payjoin-cli behavior is an intentional design decision, selected_relay being stored in RelayManager state, and shared across all sessions via Arc<Mutex<RelayManager>> in resume_payjoins so the first session randomly selects a relay and writes it to selected_relay, and every subsequent session finds Some(relay) and skips the random entirely, but resume with multiple sessions always ends up using the same relay for all of them, which comes back to the fingerprinting concern

let selected_relay = relay_manager.get_selected_relay();
match selected_relay {
    Some(relay) => relay, // sessions 2, 3... never randomize
    None => // only the first session reaches here
}

so, removing selected_relay from the RelayManager state and adding pick_relay, each call will have ohttp-relay selection independently random, without saving state, called directly within each function that makes a request, and this would change the behavior from per-process to per-request and would match BBmobile and cake wallet

to perform per-session, I see that would be necessary to randomly select the relay once at the beginning of process_sender_session and process_receiver_session and pass it as a parameter to all internal calls, and this would require to change the functions are assigned, and also update cake wallet and BBmobile to follow the per-session reference.

per-request

• No single relay sees the complete session, each request goes to a different relay
• Simple implementation, no state, no parameter passing
• Resilience requires explicit implementation, add_failed_relay and pick_relay could be centralized in post_request_with_relay_fallback to pick a new relay and continue the session
• But the ISP sees connections to multiple relays during the same session
• And it is an unusual pattern that could itself become a behavioral fingerprint

per-session

• One relay per session, more natural and predictable
• ISP sees only one relay per session
• But a single relay sees the complete session, greater exposure per relay
• Requires passing the relay as a parameter to all internal calls
• Resilience requires explicit implementation, add_failed_relay and pick_relay could be centralized in post_request_with_relay_fallback to pick a new relay and continue the session

privacy against the relay favors per-request
privacy against the ISP favors per-session
these are different threat models and the choice depends on which is more relevant for payjoin.

I couldn't find research specifically addressing per-request vs per-session relay rotation in OHTTP or payjoin contexts, but the closest that I found was:

RFC 9458
Oblivious HTTP

Each active Client configuration partitions the Client anonymity set. In practice, it is infeasible to reduce the number of active configurations to one. Enabling diversity in choice of Oblivious Relay Resource naturally increases the number of active configurations. More than one configuration might need to be active to allow for key rotation and server maintenance.

Client privacy depends on having each configuration used by many other Clients. It is critical to prevent the use of unique Client configurations, which might be used to track individual Clients, but it is also important to avoid creating small groupings of Clients that might weaken privacy protections.

https://www.ietf.org/rfc/rfc9458.html

per-request creates more active configurations throughout the session and per-session maintains one configuration per session.

RFC 9458 notes that client privacy depends on each configuration being used by many other clients. It's unclear whether the relay configurations used in payjoin have anonymity sets large enough for this distinction to matter in practice. is this something worth considering when choosing between the approaches?

[benalleng]

I Am leaning towards per-request While a larger entity can see that you are connecting to multiple relays and by doings so may be able to track the progress of your session based on the number of times you hop between relays. I think there is ultimately greater obfuscation

[bc1cindy]

I Am leaning towards per-request While a larger entity can see that you are connecting to multiple relays and by doings so may be able to track the progress of your session based on the number of times you hop between relays. I think there is ultimately greater obfuscation

I agree that per-request it's better to move on, it's also simpler and safer against state bugs

[bc1cindy]

if per-request is the way we're following, @DanGould commented:

Struct which isn't doing randomization (though as you'll find in my second point perhaps it should) #1380 (comment)

I thought about refactor to add to RelayManager:

pick_relay - randomizes excluding failed

else

select_relay reads the relay list from config and calls pick_relay on every request, replacing unwrap_relay_or_else_fetch
fetch_ohttp_keys use pick_relay

removed: selected_relay, set/get_selected_relay, get_failed_relays, relay_url

all three fixes shared the same root cause: relay selection was cached in shared state, bypassing randomization. This suggestion eliminates that state entirely. pick_relay runs independently on every request, fixing session sharing #1391 , #1399 , the hardcoded ohttp_relays[0] when ohttp_keys #1390 is config, and randomization being in the wrong place

and result is per-request, since select_relay would be called on every request without saving state, each call independently randomizes via pick_relay and no relay is persisted between calls, except failed_relays, which accumulate for the lifetime of the session

would be needed to update #1035 and docs in #1380

what would still be open is the issue of ohttp_keys in the cli config #1390 . do we keep it or can be removed? #1390 (review) ?

what do you guys think about this, does this sound like a good path?

[bc1cindy]

lightningdevkit/ldk-node#746 relay_order returns all relays in random order without state. The caller retries by iterating through the list, but without recording which ones are selected or failed, and in the next call all relays become eligible again, which is also what Cake Wallet and BBmobile do

[spacebear21]

IMO randomized per-request with fallback in randomized order seems like the right choice. I like the way this is implemented in https://github.com/lightningdevkit/ldk-node/pull/746/changes#diff-85d210513b3a481863cdc4a6bf4131351eafb9988ba49367f96892d5c8606dd8R247 with the relay order shuffled first and using the first one from the randomized order that succeeds.

[nothingmuch]

sort of related: #919

[benalleng]

Should a new relay be chosen even between polling loops at the same state, i.e. after each timeout before polling the directory again?