BitcoinPIR
Contents 14 How we know the database matches Bitcoin The authenticity chain

The authenticity chain

Privacy and authenticity answer different questions. The privacy proof asks what the server can learn from a wallet query. Database authenticity asks whether the database root the wallet trusts is tied to Bitcoin history.

BitcoinPIR's authenticity story is a chain of small commitments. A PIR answer is checked against database Merkle roots; those roots are bound to an attested database build anchor; the anchor names a Bitcoin height, block hash, and Core-style MuHash; and a separate blockhash-to-MuHash proof ties that same tuple to a SEV-SNP-attested computation.

1 PIR answer UTXO bytes or verified absence 2 Database Merkle proof bucket/onion path to a super-root 3 Attested database build roots bound to build evidence 4 Snapshot anchor height + block_hash + MuHash 5 BHTM leaf proof same tuple under the chunk tree 6 BHTM tree root append-only MuHash commitment 7 SEV-SNP quote measured proof runner + report data 8 Bitcoin-linked stream headers + txid Merkle commitments
The database claim is not one magic proof. It is a path from a wallet answer to Merkle roots, then to a snapshot anchor, then to a MuHash tree root bound by attestation.

What this adds

Section 09 already showed how a wallet verifies returned bins against published Merkle roots. This section adds the next question: where did those published roots come from, and why should a verifier believe they correspond to a Bitcoin snapshot?

Database proof

Binds bucket and onion database super-roots to a snapshot anchor: height, block_hash, and Core-display MuHash.

BHTM proof

Shows that the same anchor appears as a leaf under an append-only blockhash-to-MuHash chunk tree.

SEV-SNP quote

Binds the BHTM chunk tree root to a measured reusable proof-runner image and checked report signature.