Indistinguishable Bloom Filter (IBF)

• Indistinguishable Bloom Filter (IBF) is a randomized data structure designed for dynamic sets, supporting efficient insertion, deletion, and recoverable extraction below a critical load threshold.
• It leverages multiple hash functions and per-cell fields such as count, idSum, and hashSum to enable iterative peeling for both full and partial element recovery.
• IBFs are applied in set reconciliation, network telemetry, and privacy-aware data outsourcing, balancing space efficiency with communication overhead.

An Indistinguishable Bloom Filter (IBF), more widely known as an Invertible Bloom Filter, is a randomized data structure designed to represent dynamic sets (or multisets) compactly, supporting efficient insertion, deletion, and, with high probability, recovery (“extraction”) of the encoded set elements. IBFs extend classical Bloom filters’ approximate membership property with invertibility: they can enumerate their contents if the structural load—determined by the number of stored elements relative to the number of cells—remains below a critical threshold. These properties underpin applications in set reconciliation protocols, straggler identification, network telemetry, and privacy-aware data outsourcing. The efficiency and reliability of IBFs rest on the interplay between their hash-based indexing mechanisms and the random hypergraph models that characterize their behavior under extraction, both for full and partial listing of stored items (Goodrich et al., 2011, Kubjas et al., 2020, Houen et al., 2022).

1. Data Structure, Fields, and Hashing Mechanisms

An IBF is an array $F[1..m]$ of $m$ cells. Each cell maintains three fields:

• Count (integer): net tally of insertions minus deletions hashed to this cell
• idSum (universe element, typically XOR-sum of bit-string keys): aggregate of inserted values
• hashSum (checksum, modulo a small range $C$): sum of a short hash $B(x)$ of each inserted key $x$

The IBF uses $k$ independent hash functions $H_1, ..., H_k$ mapping the key universe $X$ into coordinates $[m]$. In practice, hash function outputs are distributed to ensure near-uniform load balancing.

Parameter definitions:

• $n$: number of elements to be stored
• $m$0: number of IBF cells
• $m$1 ($m$2 in some works): number of hash functions
• $m$3: storage overhead ratio

The design selects $m$4 and $m$5 to trade off between space and extraction success. The critical threshold $m$6, arising from the random $m$7-hypergraph induced by the hash assignments, demarcates the region where extraction succeeds with high probability (Goodrich et al., 2011, Kubjas et al., 2020). For example, $m$8, $m$9, $C$0 for $C$1.

2. Algorithms: Insertion, Deletion, and Extraction

Insertion and Deletion

For a key $C$2:

• Insert($C$3): For $C$4, update $C$5 by incrementing count, XOR-ing $C$6 to idSum, and adding $C$7 to hashSum.
• Remove($C$8): Same locations are updated in reverse (decrement, XOR, subtract).

Extraction

Extraction proceeds through iterative “peeling.” For each cell:

1. Detect singleton cells: those with $C$9 and whose hashSum matches the idSum ($B(x)$0).
2. Recover the corresponding element, remove it (reverse Insert), and continue.
3. Repeat until no singletons remain.

This process is mathematically equivalent to peeling vertices of degree one in a random $B(x)$1-uniform hypergraph. Extraction succeeds if no stopping set (non-empty $B(x)$2-core) remains (Goodrich et al., 2011, Kubjas et al., 2020).

3. Failure Probabilities and Threshold Analysis

Full Extraction

The fundamental threshold for successful extraction is set by the random hypergraph core phenomenon:

• If $B(x)$3, with probability $B(x)$4, all $B(x)$5 elements are extracted: the random hypergraph is peelable.
• If $B(x)$6, extraction fails with high probability due to stopping sets (Goodrich et al., 2011).

The value $B(x)$7 is defined as the infimum of all $B(x)$8 for which the following has no fixed point $B(x)$9:

$x$0

For $x$1, $x$2; for $x$3, $x$4; for $x$5, $x$6.

The failure probability for $x$7 decays polynomially: $x$8 (Kubjas et al., 2020). For strict finite-size bounds, exact counting of extractable configurations can yield precise lower and upper failure bounds (Kubjas et al., 2020):

$x$9

where $k$0 counts the number of matrices from which at least $k$1 elements are extractable, and $k$2.

Partial Extraction and Under-Provisioning

When $k$3, partial extraction becomes relevant. Even at $k$4, partial extraction succeeds for a substantial fraction—merely $k$5 recovery may be feasible for $k$6 (Kubjas et al., 2020). This motivates multi-round or iterative reconciliation protocols.

4. Iterative Set Reconciliation Protocols

IBFs support efficient iterative reconciliation when storage overhead is insufficient for full extraction. In such protocols:

1. Party A encodes its set as an IBF and transmits to B.
2. B constructs an IBF of its own set, subtracts, and extracts elements from the difference.
3. Only a fraction of the symmetric difference is recovered each round (dictated by partial extraction bounds).
4. Unrecovered elements remain for subsequent rounds, with freshly initialized IBFs.

Each iteration acts as a Markov chain step: the remaining set difference shrinks by a random variable with distribution determined by $k$7 from the extraction analysis. Standard hitting-time arguments and explicit upper bounds demonstrate that only $k$8 rounds are typically required to fully reconcile even when $k$9 (Kubjas et al., 2020).

5. Comparisons and Variants: Lookup Tables and Minimal IBF Designs

The Invertible Bloom Lookup Table (IBLT) is a generalization supporting key–value pairs, with extended fault-tolerance against extraneous deletes, duplicate keys, and keys with multiple values (Goodrich et al., 2011). Each cell in the IBLT may include additional hash-based checksums (e.g., keyHashSum and valueHashSum) to guard against “poisoning” or false singleton detection. The listing threshold and analytic core behavior are governed by the same hypergraph principles as the basic IBF.

The Simple Set Sketch is a minimalistic IBF variant, using a single XOR field per bucket and implicit "quotienting" via bucket index for singleton detection, eschewing explicit counts and per-cell checksums. The load threshold for successful full recovery drops: at $H_1, ..., H_k$0, the peelable threshold is $H_1, ..., H_k$1 (thus, $H_1, ..., H_k$2) (Houen et al., 2022). This approach yields superior space efficiency at the cost of slightly increased risk of anomalous, but easily correctable, decoding mistakes.

Structure Version	Overhead Threshold ($H_1, ..., H_k$3)	Per-Cell Fields
Standard IBF	$H_1, ..., H_k$4	Count, idSum, hashSum
IBLT	$H_1, ..., H_k$5	Count, keySum, valueSum, keyHashSum, valueHashSum
Simple Set Sketch	$H_1, ..., H_k$6	XOR aggregate only

6. Applications and Empirical Performance

IBFs and IBLTs are fundamental in set reconciliation: minimizing communication for database or file synchronization by transmitting only a sketch of the symmetric difference (Goodrich et al., 2011, Kubjas et al., 2020). Specific use cases include:

• Distributed deduplication
• Network flow tracking, where insertions/deletions correspond to flow start/stop events (Goodrich et al., 2011)
• Oblivious selection and retrieval in privacy-preserving outsourced data settings (Goodrich et al., 2011)

Numerical and simulation results confirm the sharpness of the $H_1, ..., H_k$7 listing threshold: empirical failure rates agree with leading-order theoretical analysis. For IBLT, with $H_1, ..., H_k$8, $H_1, ..., H_k$9 marks the transition to near-certain successful listing (Goodrich et al., 2011). In the presence of extraneous deletes and duplicates, or a nontrivial poisoned key fraction ($X$0), the robust checksum scheme continues to enable extraction of almost all valid items, contingent on $X$1 and $X$2 (Goodrich et al., 2011).

7. Storage-Communication Trade-offs and Design Recommendations

When full extraction in a single round is nonessential, setting $X$3, $X$4 allows for recovery of $X$5 of the items with negligible risk, drastically reducing communication overhead compared to provisioning for full extraction in one shot (Kubjas et al., 2020). Iterative peeling rounds, each operating on a newly constructed IBF, complete the reconciliation at low cost. For one-way or client-server synchronization, this yields a fast initial round and completion within two to three passes. For channels with tight constraints, repeated partial extractions optimize total data transferred versus latency.

A rule of thumb: $X$6 is optimal for one-round overheads in the $X$7 range, $X$8 for $X$9, and for high-probability full extraction, $[m]$0 should be chosen above $[m]$1 (Kubjas et al., 2020).

---

Indistinguishable Bloom Filters thus combine the theoretical efficiency of random graph-based coding with practical, robust algorithms for dynamic set representation, supporting both retrieval and difference reconciliation under rigorous probabilistic guarantees (Goodrich et al., 2011, Kubjas et al., 2020, Houen et al., 2022).