Ohttp-relay selection should still be randomized even when ohttp-keys is hard coded in the config.

[benalleng]

This code skips ohttp_relay selection when ohttp_keys are hard coded and default chooses the 0 index relay of the possible relays.

rust-payjoin/payjoin-cli/src/app/v2/ohttp.rs

Lines 30 to 47 in 762fbaf

	pub(crate) async fn unwrap_ohttp_keys_or_else_fetch(
	config: &Config,
	directory: Option<url::Url>,
	relay_manager: Arc<Mutex<RelayManager>>,
	) -> Result<ValidatedOhttpKeys> {
	if let Some(ohttp_keys) = config.v2()?.ohttp_keys.clone() {
	println!("Using OHTTP Keys from config");
	return Ok(ValidatedOhttpKeys {
	ohttp_keys,
	relay_url: config.v2()?.ohttp_relays[0].clone(),
	});
	} else {
	println!("Bootstrapping private network transport over Oblivious HTTP");
	let fetched_keys = fetch_ohttp_keys(config, directory, relay_manager).await?;
	Ok(fetched_keys)
	}
	}

While skipping reaching out to the relay when you already have an ohttp-key may make sense, and even be desirable for initial key grab, as it has already been set, whether through a cache or otherwise. We should still utilize a randomized relay selection for followup connections to update the state of a payjoin.

[DanGould]

@arminsabouri This is the kind of timing / clustering analysis that's separate from utxo based to do in simulation. I think this kind of thing is probably easier to simulate and draw conclusions about than UTXO things because the problem space seems to be better understood already.

---

skipping reaching out to the relay when you already have an ohttp-key may make sense,

Not sure I understand this one. Aren't your connetions going through a relay no matter what? ohttp-key comes from the directory.

We should still utilize a randomized relay selection for followup connections to update the state of a payjoin.

It seems like you'd want connections to the directory to be somewhat randomized either per Payjoin Session or even per connection. Using the same relay all the time may make it easier to identify specific IPs that are likely to have payjoin traffic in a given timeframe.

[bc1cindy]

i see that the point is unwrap_ohttp_keys_or_else_fetch is responsible for key fetching and relay selection. The relay is always needed, regardless of whether the keys are fetched or hardcoded, so that's why randomization shouldn't depend on keys being absent. separating them would fix this

[benalleng]

Not sure I understand this one. Aren't your connections going through a relay no matter what? ohttp-key comes from the directory.

Maybe i am just having a hang-up on why we use the key fetch as the relay health check as @bc1cindy pointed out "unwrap_ohttp_keys_or_else_fetch is responsible for key fetching and relay selection.",
if we already have some keys hard coded, or implicitly cached in the case of a prod wallet why are we continually fetching them every time we establish a connection, could there be a better way to do this with something that just responds with 200 OK to use as a relay selection at least for followup connections especially if we are leaning towards a new relay connection per_request.

It seems like you'd want connections to the directory to be somewhat randomized either per Payjoin Session or even per connection. Using the same relay all the time may make it easier to identify specific IPs that are likely to have payjoin traffic in a given timeframe.

I think we can think about that in #1385

[bc1cindy]

Maybe i am just having a hang-up on why we use the key fetch as the relay health check as @bc1cindy pointed out "unwrap_ohttp_keys_or_else_fetch is responsible for key fetching and relay selection.", if we already have some keys hard coded, or implicitly cached in the case of a prod wallet why are we continually fetching them every time we establish a connection, could there be a better way to do this with something that just responds with 200 OK to use as a relay selection at least for followup connections especially if we are leaning towards a new relay connection [per_request]

I guess the key fetch is not only to get the keys, because it acts like an integration test, by communicating with the directory and validating the full relay directory path e2e, which e.g. a simple HEAD to health check relays would be far less accurate

[benalleng]

I think I'm satisfied with that, I gave it some more though today and ultimately the GET request is probably fine for the health check even if we already have keys cached or saved.