Bitcoin Light Client Block Filter Research

Introduction

Code and dataset: github.com/purszki/bitcoin_research_01

The problem: private Bitcoin wallets are too slow on mobile

Bitcoin promises self-sovereignty — your money, held by you, not a bank or exchange. To deliver on that promise, a user must be able to check their balance on a phone without leaking addresses to a third-party server. Today that means downloading compact block filters (BIP 158) and scanning them locally. The privacy is excellent, but the cost is real: BIP 158 filters use Golomb-Rice coding, which requires a full sequential decode for every query. On a mobile phone this translates to minutes of heavy CPU work just to scan recent blocks — the phone heats up, the battery drains, and the user waits.

What we achieved

We built a reproducible benchmark framework on top of Bitcoin Core and used it to evaluate Binary Fuse filters as an alternative to Golomb-Rice coded sets. Across 50,000 real mainnet blocks and 10 wallet scenarios (from 24 to 480 scripts), benchmarked on both desktop x86-64 and a Raspberry Pi 5 (ARM Cortex-A76), the current results support two concrete conclusions:

• Fuse16 is a strong candidate for a new compact block filter type alongside BIP 158 basic filters. In the 50k-block benchmark, Fuse16 preserves zero false negatives, reduces client-side query CPU by 9x to 81x on desktop and 6x to 46x on ARM across the wallet set, and produces slightly smaller filter data than GCS (955.9 MB vs 972.1 MB). When matched-block downloads are included, total bandwidth stays very close to GCS, rising by only about 0.2% to 2.9% in the current measurements.
• Hierarchical Fuse filters are a promising bandwidth-oriented research direction. We also benchmarked two-stage Fuse designs that try to reduce total bandwidth further without giving up the speed advantage completely. Some variants improve the bandwidth tradeoff, and some achieve zero false positives in the current 50k run. But this work is still experimental: it needs more optimization, clearer protocol design, and dedicated privacy analysis because a two-stage retrieval scheme may leak wallet interest unless the request pattern is carefully hidden.

The speedup comes from a fundamental algorithmic difference: GCS requires O(N) sequential decoding per query, while flat Fuse16 answers each query with exactly 3 random memory lookups — O(1) regardless of filter size. The hierarchical variants build on the same idea, but add an extra protocol layer that is not yet deployment-ready.

Where we can go with more work

These results are a proof of concept, not a finished protocol. The current evidence makes Fuse16 the clearest deployment candidate, while the hierarchical variants remain exploratory. ARM benchmarking on a Raspberry Pi 5 confirms the desktop results: Fuse16 delivers significant speedups even on a low-power ARM processor. The path forward includes: writing a native C++ implementation suitable for Bitcoin Core (replacing the current C library wrapper); specifying a deterministic construction and wire format; designing privacy-preserving retrieval if a hierarchical scheme is pursued; and ultimately drafting a BIP proposal. Fuse filters could make private, self-sovereign wallet sync practical on everyday phones.

Binary Fuse Filters

Binary fuse filters are a family of probabilistic data structures for approximate set membership, introduced by Thomas Mueller Graf and Daniel Lemire in "Binary Fuse Filters: Fast and Smaller Than Xor Filters" (Journal of Experimental Algorithmics, Vol. 27, 2022; arXiv:2201.01174).

A binary fuse filter answers one question: is a given value a member of a set? If the answer is "yes", the value might be in the set (a false positive is possible). If the answer is "no", the value is definitely not in the set — there are no false negatives. This is the same guarantee as GCS filters used in BIP 158, but binary fuse filters answer the question with only 3 memory lookups, regardless of how large the set is.

A binary fuse filter is built from a fingerprint function and an array of fingerprints. The algorithm is described in detail in the reference paper. Using a simple lookup method that XORs three fingerprints, the algorithm gives O(1) query time with exactly three memory accesses, regardless of set size.

The probability of a false positive depends on the fingerprint width: a k-bit fingerprint gives FPR = 1/2^k. Common configurations are:

A bandwidth optimization - Hierarchical Fuse Filters

We propose an original contribution on top of Binary Fuse Filters: a hierarchical two-stage design that aims to reduce bandwidth without giving up the core speed advantage. To our knowledge, this two-stage outer/inner filter architecture has not been explored in the context of Bitcoin light client block filtering before.

A hierarchical filter splits the decision into two stages. The client still downloads one small outer filter for every block and queries it locally. If that outer filter reports a possible match, the client fetches a second, more selective inner filter for that block. Only if the inner filter also reports a match does the client download the full block.

The naming convention follows that two-stage structure: F12+16 means a Fuse12 outer filter plus a Fuse16 inner filter. Likewise, F10+10 uses Fuse10 in both stages.

HIERARCHICAL FILTER FLOW

download outer filter for every block
           |
        no match -> stop
           |
        match
           v
   fetch and query inner filter
           |
        no match -> stop
           |
        match
           v
   download full block

The benchmarked bandwidth numbers in this document assume exactly that on-demand inner-filter retrieval model: outer filters for all blocks, inner filters only for outer matches, and full blocks only for final matches. That is also why hierarchical filters raise a privacy issue. Under BIP 158, the peer sees only that the client downloads one filter per block. In a hierarchical scheme, the peer can also observe which specific blocks triggered second-stage inner-filter requests unless the protocol adds a privacy defense.

Proof of Concept Implementation

We use the xor_singleheader C library as a reference implementation of Binary Fuse and XOR filters: https://github.com/FastFilter/xor_singleheader

It is good for benchmarking, but not yet protocol-ready. Main limitations:

• It uses malloc/free internally.
• Error handling is too weak for critical production code.

To integrate it cleanly, we wrapped it in Bitcoin Core-style C++ classes with the same API shape as BlockFilter. See src/fuse16filter.h/.cpp for Fuse16, src/fuse8filter.h/.cpp for Fuse8, and src/xor8filter.h/.cpp for Xor8. We use PIMPL (pointer-to-implementation) so the large C header does not leak into the rest of the codebase. After a native C++ rewrite, neither malloc nor PIMPL should be needed.

Alongside that wrapper layer, we also started an experimental C++ refactor of the original library in src/bench/xor_singleheader/binaryfusefilter.hpp. It uses templates to support variable-width filters (for example Fuse12, Fuse18, and Fuse20), and it moves serialization toward an explicit platform-independent little-endian format. This is promising for overcoming some limitations of the original C code, but it is still research code rather than a production-ready implementation.

Construction must be deterministic. We derive the seed from the block hash. If construction fails (the probabilistic peeling process does not converge), we currently throw an exception. For benchmarking this is acceptable: in practice failure is very rare, and a deterministic retry strategy can handle it. A protocol-grade implementation must define that retry behavior explicitly.

Core question: can Binary Fuse filters (and related XOR filters) replace or complement the current GCS-based compact block filters from BIP 158? We evaluate:

1. Deterministic construction. Fuse construction is probabilistic, so it may fail and retry with a different seed. Can we define this so every full node still produces exactly the same filter for the same block?
2. Client-side query speed. On the client, are Fuse filters faster than GCS (Golomb-Rice decode plus per-element hashing)?
3. Network bandwidth. Is total filter size, and therefore download bandwidth, comparable to BIP 158?
4. False positives. BIP 158 has a very low false-positive rate (1/784,931). Each false positive is expensive: the client downloads the full block (~1.5 MB) and checks it manually. How do Fuse filters compare?

Source Files

All research-specific C++ code lives under src/bench/light_client_research/ and src/bench/xor_singleheader/, separate from the Bitcoin Core codebase.

Data Extraction for Profiling and Validation

For benchmarking on real mainnet data, we export block and transaction data from a fully synced Bitcoin Core node into compact binary (.bin) blobs. Each blob stores 250 blocks, including all output scriptPubKeys and spent prevout scripts, which are exactly the elements used by BIP 158 filter construction.

This extraction step is needed for three reasons:

• We must build each filter from scratch (not from a pre-built index), so construction time can be measured fairly across filter types.
• The binary format lets us stream blocks one by one, without keeping the full dataset in memory. This is important for large runs (50k+ blocks).
• Ground-truth validation needs the original scripts, to prove we never miss a real match (zero false negatives).

For exact, step-by-step dataset reproduction from a Bitcoin Core node, see REPRODUCE.md.

Simulating Wallet Behaviour

To measure real-world filter performance, we simulate how a light client wallet queries block filters. A wallet holds a set of scriptPubKeys and scans every block filter to find blocks that may contain relevant transactions.

The number of scripts, and the script-type mix, directly affects query time and false-positive rate.

We generate 10 wallet use cases, from a simple mobile wallet (24 scripts) up to a large exchange hot wallet (480 scripts). Each use case has a realistic address-type mix (P2WPKH, P2TR, P2WSH, P2SH, P2PKH) and includes ground-truth data: which blocks in the 50k-block dataset actually contain matching transactions. We use this ground truth to verify zero false negatives and to count false positives exactly.

The True Hits column shows how many of the 50,000 blocks contain at least one matching transaction for that wallet. A simple user wallet matches about 2% of blocks, while an exchange hot wallet matches about 55%. For most wallets, non-matching blocks are still the majority. This is exactly where filter query speed matters most, because the client checks every block filter, match or not.

The wallet scenario files are generated deterministically from block data using benchmark_tools/generate_wallet_use_cases.py. See REPRODUCE.md for details.

Disk space required for the 50k-block dataset used in our benchmarks:

Ground-Truth Validation

Any new filter type must satisfy one hard requirement: zero false negatives. If a block contains a transaction matching the wallet, the filter must report a match. A single false negative means the wallet misses a payment — this is unacceptable. False positives (the filter says "maybe" but the block has no matching transaction) are tolerated; they only cost an extra block download.

We validate correctness and count false positives in two layers:

Layer 1: Computing ground truth (Python, offline). During wallet scenario generation, the script generate_wallet_use_cases.py scans every block in the dataset and records which blocks contain at least one scriptPubKey that belongs to the wallet. This is an exact, brute-force check against the raw transaction data — no filter is involved. The result is a list of block indices stored in the wallet scenario JSON under ground_truth.matched_blocks.

Layer 2: Streaming validation (C++, dedicated benchmark). A dedicated benchmark called StreamingGroundTruthValidation reads blocks one at a time from the binary chunks, constructs a filter for each block using all four filter types (GCS, Fuse16, Fuse8, Xor8), and queries each filter with the wallet's scripts. For each filter type it checks:

• False negatives: For every block index in the ground-truth list, did the filter report a match? If any ground-truth block is missed, the validation throws an exception and stops.
• False positives: The count is computed as:

  false_positives = candidate_matches - true_hits_in_range

where candidate_matches is the number of blocks the filter flagged, and true_hits_in_range is the number of ground-truth blocks within the scanned range.

The streaming approach processes one block at a time and discards its elements immediately, so memory usage stays low even for 50k+ blocks.

./light_client_research/benchmark_tools/false_positive_check.sh 50000

# Single wallet:
BIN_SCAN_MAX_BLOCKS=50000 ./build-release/bin/bench_bitcoin \
    -filter='StreamingGroundTruthValidation' -min-time=100

# Specific wallet:
BIN_SCAN_MAX_BLOCKS=50000 \
BIN_WALLET_SCENARIO=light_client_research/mainnet_datasets/wallet_use_cases/wallet_use_case_exchange_hot_wallet.json \
    ./build-release/bin/bench_bitcoin \
    -filter='StreamingGroundTruthValidation' -min-time=100

FUSE16_GROUND_TRUTH scenario=... scanned_blocks=50000 skipped_small=55
    construction_failures=0 true_hits_in_range=... candidate_matches=...
    false_negatives=0 false_positives=...

Benchmarking Methodology and Results

What we measure

The benchmarks simulate what a light client does when it receives block filters over the network: deserialize the filter from bytes, then query it with the wallet's scripts. This is the client-side hot path that runs for every block in the chain.

For each filter type, the benchmark:

1. Setup (not timed): Reads blocks from the binary dataset, constructs filters, and serializes them to byte arrays. This simulates the full node building filters; the client never does this.
2. Timed loop (nanobench): For each pre-built filter, deserializes from bytes and calls MatchAny(wallet_scripts). This is repeated many times by nanobench to get stable timing.

For GCS (BIP 158), deserialization reconstructs the Golomb-Rice encoded bitstream and the query performs a full O(N) sequential decode. For Fuse16, deserialization reconstructs the fingerprint array and the query performs 3 array lookups per wallet script — O(1) per element regardless of filter size.

The benchmarks also report:

• Total filter size in bytes (sum of all serialized filters)
• Average filter size per block
• Match count (number of blocks where the filter reports a hit)
• Block download volume for all matched blocks (true positives + false positives)
• Total bandwidth = filter data + downloaded blocks for all matches

Bandwidth is counted from the client point of view. If a filter reports a match, the client must download the full block before it can tell whether the match was real or just a false positive.

TOTAL BANDWIDTH
    = filter_data
    + downloaded_blocks_for_all_matches

    = filter_data
    + block_downloads(true_positives)
    + block_downloads(false_positives)

    match reported by filter
           |
           v
      download full block
           |
           v
    later classify as TP or FP

So the download cost is paid for every reported match, not only for true hits.

For hierarchical schemes, "filter_data" includes both the outer filters and any
inner filters fetched on demand.

# Build (release mode, required for meaningful timings):
cmake -B build-release -DCMAKE_BUILD_TYPE=Release -DBUILD_BENCH=ON
cmake --build build-release --target bench_bitcoin -j $(nproc)

# GCS baseline — 50k blocks, simple_user wallet:
BIN_SCAN_MAX_BLOCKS=50000 ./build-release/bin/bench_bitcoin \
    -filter='ResearchBasicClientSideQuery' -min-time=1000

# Fuse16 — 50k blocks, simple_user wallet:
BIN_SCAN_MAX_BLOCKS=50000 ./build-release/bin/bench_bitcoin \
    -filter='ResearchFuse16ClientSideQuery' -min-time=1000

# Specific wallet:
BIN_SCAN_MAX_BLOCKS=50000 \
BIN_WALLET_SCENARIO=light_client_research/mainnet_datasets/wallet_use_cases/wallet_use_case_exchange_hot_wallet.json \
    ./build-release/bin/bench_bitcoin \
    -filter='ResearchFuse16ClientSideQuery' -min-time=1000

# All wallets, flat and hierarchical filter matrix:
./light_client_research/benchmark_tools/wallet_benchmark.sh 50000

./light_client_research/benchmark_tools/bench_all.sh 50000

Profiling Results: Fuse8 and Xor8 (20k blocks)

This early 20k-block run compared all four filter types to decide which ones to carry forward. The results led us to drop Fuse8 and Xor8; the 50k benchmarks below focus on the viable candidates. Benchmarked on a Lenovo ThinkPad P51 (Intel Core i7-7820HQ @ 2.90 GHz, 4 cores / 8 threads).

Taking into account the FP rate and the speedup, Fuse16 seems to be a viable alternative to GCS.

8-bit filters are ~50% smaller and ~100x faster, but their FPR (1/256) causes thousands of unnecessary full block downloads (~2.6 GB for Fuse8 at 20k blocks). The bandwidth cost far exceeds the size savings.

Profiling Results: Flat Fuse Variants vs GCS (50k mainnet blocks)

The flat-filter comparison covers GCS, Fuse16, Fuse18, and Fuse20 across both platforms. Desktop results use wallet_benchmark_results_50000.txt; Raspberry Pi 5 results use arm_fixed_wallet_benchmark_results_50000.txt. Filter sizes and match counts are identical across platforms; only timing differs.

CPU speed — Raspberry Pi 5 (ARM Cortex-A76, deserialize + MatchAny, lower is better):

Key observations:

• Fuse16 remains the CPU winner in every wallet on both platforms. On desktop x86-64 it ranges from 9x to 81x faster than GCS. On the Raspberry Pi 5 (ARM Cortex-A76) it ranges from 6x to 46x faster.
• F18 and F20 reduce false-positive-driven block downloads relative to Fuse16, but their larger filters more than offset that gain. In this flat-filter comparison, both variants are slower than Fuse16 and still worse than GCS on total bandwidth.
• GCS keeps the lowest total bandwidth among these flat filters, but it pays for that result with much higher client-side CPU cost.

Profiling Results: Experimental Hierarchical Fuse Variants vs GCS (50k mainnet blocks)

The experimental hierarchical comparison covers F16+20, F10+10, F12+12, F12+16, F12+18, and three Fuse+GCS hybrids: F8+GCS, F12+GCS, and F16+GCS. Desktop results use wallet_benchmark_results_50000.txt; Raspberry Pi 5 results use arm_fixed_wallet_benchmark_results_50000.txt. In the Fuse+GCS hybrids the outer layer is a fast Fuse filter and the inner layer is the existing BIP 158 GCS filter, which full nodes already compute and serve. These schemes trade protocol simplicity for a different speed/bandwidth frontier.

CPU speed — Raspberry Pi 5 (ARM Cortex-A76, hierarchical; lower is better):

Key observations:

• The hierarchical variants remain much faster than GCS on both platforms, but none of them beats flat Fuse16 on CPU time. On desktop, F16+20 is the fastest hierarchical option for small wallets (6 of 10), while on ARM F12+16 wins in the majority of wallets (7 of 10) because its smaller outer filter stresses the ARM cache less. F10+10 is typically the slowest on both platforms.
• F10+10 is the strongest bandwidth result in the current experimental set. It beats GCS on total bandwidth in 8 of 10 wallets, but it does so with only modest speedups and a non-zero false-positive rate.
• F12+16 is the cleanest zero-false-positive hierarchical result. In the current 50k run it keeps zero false positives across all wallets, remains materially faster than GCS, and lands near the middle of the experimental bandwidth tradeoff curve.
• F16+20 proves that a zero-false-positive two-stage design is possible, but not yet economical. In the current measurements it is worse than GCS on total bandwidth in all 10 wallets because the extra inner-filter traffic outweighs the saved block downloads.
• The Fuse+GCS hybrids (F8+GCS, F12+GCS, F16+GCS) achieve zero false positives across all wallets by using the existing BIP 158 GCS filter as the inner verification layer. Their main advantage is deployment simplicity: the inner GCS filter is already computed and served by full nodes, so only the new Fuse outer filter needs to be added. F8+GCS offers the best bandwidth for low-match wallets (15% less total bandwidth than GCS for Simple User) but degrades to GCS-level CPU at high script counts because its 1/256 FPR triggers too many expensive O(N) GCS verifications. F16+GCS is 30–36x faster than GCS for small wallets while keeping bandwidth near-neutral. F12+GCS is the most balanced: 5–16x faster with 0–12% bandwidth savings for wallets with less than 20% match rates.

Limitations and future profiling improvements

The benchmarks now cover both desktop x86-64 and ARM (Raspberry Pi 5). The ARM results confirm the algorithmic advantage holds on low-power hardware, though with reduced speedup ratios. Important remaining gaps:

1. Mobile SoC profiling. The Raspberry Pi 5 (Cortex-A76) provides our first ARM data point, confirming 6x-46x Fuse16 speedup over GCS. Mobile phones (Snapdragon, Apple A-series) have different cache hierarchies and thermal constraints. Profiling on actual phone hardware would complete the picture.
2. Measuring actual network cost beyond byte totals. The current bandwidth tables already count actual serialized filter bytes, actual on-demand inner-filter bytes, and actual full-block bytes for every reported match in the 50,000-block dataset. What they still do not model is transport behavior: request batching, round-trip latency, peer behavior, retries, parallel downloads, and the CPU cost of parsing blocks after receipt. For hierarchical schemes there is an additional unresolved question: whether inner-filter retrieval can preserve wallet privacy without giving up the measured bandwidth gains.
3. Skipped blocks with fewer than 2 elements. Both the Fuse filter wrappers and the GCS benchmark path require at least 2 unique script elements to construct a filter. Blocks with 0 or 1 elements (typically empty blocks or blocks with only a coinbase) are skipped during benchmarking. In the 50,000-block dataset, 55 blocks fall into this category. Skipping them has almost no impact on match counts, false positive rates or profiling results. A production implementation would need to handle these blocks (e.g., by padding or using a trivial filter).
4. End-to-end wall-clock measurement. The current benchmarks measure filter query time in isolation. A production-relevant benchmark would measure the full wallet sync flow: receive filter bytes over a (simulated) network, deserialize, query, and on match download and process the block. This would capture the true user-facing latency including I/O and memory allocation overhead.

Path to Protocol-Ready

The proof-of-concept results are promising (6–81x speedup across desktop and ARM, comparable filter size, acceptable FP overhead). Below is what remains to go from research prototype to a deployable protocol change.

1. Evaluate Cuckoo filters

Cuckoo filters are another commonly suggested alternative to GCS. They offer O(1) lookup (similar to Fuse), support deletion (which Fuse does not), and have well-studied implementations. Before committing to Fuse as the proposal, we should build a proof-of-concept Cuckoo filter implementation using the same benchmark framework and compare. Our guess is that Fuse will be faster, but the evaluation must happen.

2. Research on hierarchical filters

The hierarchical filter approach raises a serious protocol question: it breaks the main privacy property that makes BIP 158 attractive. Under BIP 158, the client downloads one compact filter per block and performs all wallet queries locally, so the peer cannot tell which blocks are interesting to the wallet. In a hierarchical design, the client first checks an outer filter and then requests inner filters only for the candidate blocks. That second-stage request pattern can leak wallet interest directly.

The research question is whether there is a way to preserve most of the bandwidth savings without giving up that privacy model. Possible directions include:

• Noise injection. Download random extra inner filters so the true candidate set is hidden inside a larger request set.
• Temporal defenses. Decouple inner-filter requests from outer-filter matches by batching, delaying, or shuffling them over time so the correlation is weaker.
• Private Information Retrieval. Investigate PIR-style techniques that let the client fetch inner-filter data without revealing which blocks it is actually interested in.

Any such workaround must be evaluated as a full protocol tradeoff: privacy leakage, extra bandwidth from cover traffic, latency, implementation complexity, and whether the hierarchical scheme still beats a flat filter once those protections are added.

3. Native C++ implementation of a Binary Fuse Filter

The original implementation wrapped the xor_singleheader C library via PIMPL. During the research we partially addressed the most critical issues:

• C++ template implementation: We wrote binaryfusefilter.hpp, a template-based C++ reimplementation that supports variable-width filters (Fuse10, Fuse12, Fuse18, Fuse20, Fuse32) and moves serialization toward an explicit little-endian format. The Fuse8 and Fuse16 wrappers still use the original C library.
• Exception-safe construction: All filter wrappers now throw on failure and clean up via RAII destructors, replacing the C library's silent error-return pattern.
• Ground-truth validated: All filter types pass streaming ground-truth validation across 50,000 mainnet blocks and 10 wallet scenarios with zero false negatives — we are confident in correctness.

Remaining issues that a production implementation must address:

• Memory management: The Fuse8/Fuse16 wrappers and the C library still use malloc/free internally. Bitcoin Core expects RAII-based allocation with no raw malloc in consensus-adjacent code.
• PIMPL overhead: All wrappers still use unique_ptr<Impl> to hide the C/C++ headers. A production implementation should eliminate this indirection.
• Endianness: The C++-template filters use explicit little-endian serialization, but the C-library wrappers (Fuse8, Fuse16) still use native endianness. A wire protocol must use a consistent fixed byte order.
• No formal test suite: Correctness is validated through benchmark ground-truth checks, not through unit tests or fuzz tests. A production codebase needs both.

The algorithm itself is straightforward (the paper is clear and the C code is ~400 lines). A clean, unified C++ rewrite following Bitcoin Core coding conventions — replacing both the C library and the current template prototype — would be moderate effort.

4. Deterministic construction specification

Full nodes must produce identical filters for the same block. The current approach derives a deterministic seed from the block hash via SipHash, but throws an exception if the probabilistic peeling process does not converge.

A production specification must define:

• Exact seed derivation formula (e.g., SipHash-2-4(block_hash, domain_tag)).
• Deterministic retry: if construction fails with seed S, the next seed is S' = f(S) for a specified function f. The spec must guarantee that all implementations arrive at the same seed and the same filter bytes.
• Maximum retry count and behavior on exhaustion (in practice, failure is extraordinarily rare — zero failures observed in 50k mainnet blocks).

5. Wire format specification

Define the exact byte layout for Fuse filters on the network:

• Fixed-size header: seed (8 bytes), element count (4 bytes), segment parameters (12 bytes), array length (4 bytes) = 28 bytes.
• Fingerprint array: array_length × 2 bytes, little-endian uint16 values.
• Total: 28 + 2N bytes where N is the array length (~1.125 × element count).

The format must be specified precisely enough that any implementation can deserialize and query filters from any other implementation, bit-for-bit.

6. Handling edge cases

• Blocks with 0–1 unique scripts: Fuse filters require at least 2 elements. The spec must define how to handle empty blocks and single-element blocks (e.g., encode as a trivial filter with a special marker, or fall back to a direct element list).
• Coinbase-only blocks: Some blocks contain only a coinbase transaction with a single output. The filter for such blocks needs defined behavior.

7. Mobile SoC profiling

The Raspberry Pi 5 results confirm the ARM speedup (6x-46x). Profiling on actual phone SoCs (Snapdragon, Apple A-series) under thermal and battery constraints would complete the picture, but the algorithmic advantage is established.

8. End-to-end integration test

Build a prototype light client that performs the full sync flow:

• Download filter headers and verify the header chain
• Download filters from peers
• Query filters against the wallet
• On match, download the full block and scan transactions
• Measure total sync time, bandwidth, and FP handling cost

This validates the real-world performance including network latency, I/O, and the actual cost of false positives beyond the current byte-counting benchmark tables.

9. Security audit

Before any protocol deployment, the following need independent review:

• Filter construction: Can an attacker craft block content that causes filter construction to fail or produce a malicious filter?
• Deserialization: Buffer validation, integer overflow checks, and rejection of malformed filters. The current C library does minimal validation.
• Fingerprint collisions: Verify that the SipHash-based fingerprinting provides sufficient collision resistance against adversarial inputs.
• DoS resistance: Ensure that pathological filters cannot cause excessive CPU or memory usage on the client.

10. Server-side benchmarking

The current benchmarks focus on the client side (filter query). Full nodes must also construct and serve filters. Before proposing a protocol change, we need to measure the server-side cost:

• Construction time: How long does it take to build a Fuse filter per block vs GCS? This runs during block validation on full nodes.
• Index build time: Time to build the full filter index for the entire chain (~895k blocks). GCS index currently takes several hours.
• Storage: Disk space for the complete filter index.
• Serving throughput: How many filter requests per second can a node handle? Fuse filters are slightly smaller than GCS, which may improve I/O.

11. BIP proposal

Once the above items are resolved, a formal BIP proposal would specify:

• Filter type identifier (new type alongside basic = 0x00)
• Construction algorithm with deterministic seed derivation
• Wire format and serialization rules
• P2P protocol messages (extending BIP 157's getcfilters/cfilters)
• Filter header chain construction (extending BIP 157's getcfheaders)
• Test vectors: known block → expected filter bytes

12. Backward compatibility and deployment

• Fuse filters would be a new filter type, not a replacement for existing BIP 158 basic filters. Nodes can serve both types simultaneously.
• Light clients negotiate the filter type during the P2P handshake.
• Deployment can be gradual: nodes opt in to building and serving Fuse filters, clients opt in to requesting them.

Conclusion

This research set out to answer a simple question: can we make private Bitcoin wallet sync fast enough for mobile phones? The answer, based on 50,000 mainnet blocks, 10 wallet scenarios, and benchmarks on both desktop x86-64 and ARM hardware, is a clear yes — with the right data structure.

The strongest current result is that flat Binary Fuse16 filters are a strong candidate for a new compact block filter type alongside BIP 158 basic filters. In the 50,000-block benchmark they deliver 9x to 81x faster queries on desktop and 6x to 46x on ARM, slightly smaller filter data, and zero false negatives, while keeping total bandwidth very close to GCS.

The core insight is algorithmic: GCS forces O(N) sequential decoding for every query, while Fuse16 answers with exactly 3 memory lookups — O(1) regardless of how many elements the filter contains. This is not an optimization of the existing approach; it is a fundamentally different tradeoff. The ARM benchmarks confirm that the advantage holds on low-power hardware, though the speedup ratio narrows because Fuse's random access pattern is more sensitive to cache latency than GCS's sequential decode.

A second result is that hierarchical Fuse filters may open a better bandwidth frontier, but that line of work is still experimental. It needs more optimization and explicit privacy-preserving protocol design, because on-demand inner-filter retrieval could leak wallet interest if handled naively. Beyond that, the path to deployment requires a native C++ implementation, mobile SoC profiling, deterministic construction and wire-format specs, and a BIP proposal. The filter would deploy as an optional new type — no consensus change, no breaking change, gradual adoption.