I don’t have ground-truth “same bitcoind” labels in the current dataset, so I can’t directly answer that yet. What I can say is that same operator clearly does not imply the same header clock: for example, keff.org is consistently on the same initial-hash side across four forks, while some of its endpoints differ by ~9 s and others by ~191 s. So the 30 s–5 min band I observed between arbitrary Electrum endpoints shouldn’t be interpreted as an upper bound for servers sharing one Bitcoin node.
Where I have a stronger same-host/backend signal, the differences are much smaller: grey.pw 32 ms, GCP IP↔PTR 221 ms, and tool.sh↔18.195.224.155 446 ms (N=4, always on the same side). That makes my current hypothesis that two sessions ultimately fed by the same backend should usually be much closer — perhaps sub-second — but I don’t have enough ground truth yet to claim that.
On tool.sh: yes, I agree that since it resolves to 18.195.224.155, you’d expect nearly identical timestamps. I have not yet opened multiple connections to the exact same host:port. What I currently have are two independent SSL sessions: one to the hostname and one directly to the IP, created independently by the collector. So it is effectively a dual-connect under two labels. My suspicion is that the 446 ms difference is connection/scheduling noise rather than evidence of a different backend, but your proposed experiment is exactly the right way to establish that floor.
My next step is therefore a controlled version of this: run several Electrum servers all against the same Bitcoin Core node, subscribe to headers from all of them, and measure pairwise first-seen deltas for new blocks (and, ideally, fork events). In parallel, I can open N independent connections to the exact same Electrum host:port. That should give me two useful baselines:
- same Electrum endpoint, different sessions;
- different Electrum servers, same
bitcoind.
Then we can compare the ~446 ms observation against those distributions rather than guessing from the public-server dataset.