BitcoinPIR
Contents 12 What the server learns On the wire

What the server learns — honest trade-offs

PIR is not magic. It hides specific things and leaves other things visible; pretending otherwise would be worse than not using PIR at all. This page covers what an honest-but-curious server can and cannot infer from the wire traffic of a BitcoinPIR query.

Server CANNOT learn

  • Which scripthash you queried
  • Which specific PBC groups contain your real query (padding hides this)
  • Which bin inside a group you cared about (DPF / FHE / PRP keys are opaque)
  • Whether the address was found. Every query — found, not-found, whale — emits the same number of CHUNK and MERKLE rounds, with the same per-level item count.
  • Whether a returned bin was tampered with (Merkle root binds the data)

Server CAN observe

  • Which database you're querying. The base snapshot vs a particular delta epoch is part of the protocol's public API.
  • Your position in a HarmonyPIR session. The session_query_index sizes the hint-refresh schedule; it's a function of session length and is already public.
  • Timing patterns and bandwidth. Same client connection, repeatable cadence. Wire bytes are constant across queries, but the timing isn't.
  • Approximate per-query UTXO count. The removed M=16 CHUNK padding means the server can infer how many CHUNK Merkle items each query contributes (the chunk_max leakage axis). This was traded off as mild because ~99% of addresses are single-chunk.
  • That you're a wallet talking to a PIR server. PIR doesn't hide network presence.

Everything above is about a single honest-but-curious server (or a pair of servers for DPF). There are adversaries PIR doesn't address on its own — network observers, colluding servers, compromised client state. The next page covers those.