Blindsats: Blind your Bitcoin

01 What Bitcoin verifies

Bitcoin provides the transaction history, ordering and confirmation of the carrier transactions. It does not execute the BLIND proof verifier or enforce BLIND balances. Those checks belong to BLIND clients and indexers using the authenticated protocol profiles, verification resources and replay rules.

Reading an OP_RETURN payload is therefore only the beginning of verification. A reader must also recognize the carrier version, verify its authorization and any required proof, apply the state transition in canonical chain order, reject conflicts and handle reorganizations. A successful Bitcoin payment alone does not establish a valid BLIND claim or transfer.

BLIND is not a claim on a redeemable BTC reserve. The current note system does not implement a BTC peg, a blind BTC vault, or a statechain. References to those ideas below are historical research context.

02 Transaction families in use

These are proof byte counts, not complete transaction sizes. Envelopes, encrypted outputs, routing receipts and Bitcoin inputs and outputs add bytes and fees. A larger proof is not evidence of greater security: security depends on the statement proved, its implementation, the proof system and its assumptions.

v16 adds a compact transparent-claim format alongside v13 and v14. It does not replace their private proof system or reinterpret old notes. Earlier profiles and upgrade records remain part of the authenticated history and must be validated under their original rules. A version number is not a security rating.

The implementation pins proof encodings, verification keys, circuit and runtime hashes, activation heights and predecessor digests. The private profiles use a universal CRS; v16 uses a universal Powers of Tau setup. Older profiles also include single-party setup history. The existence of these pins is not evidence that BLINDSATS completed an independent setup ceremony or a security audit.

03 Initial mint eligibility

The initial mint allocation is a sealed record with a pinned digest. The eligibility commitment and subsequent proofs bind claims to that allocation. An account holder signs a read authorization to obtain their own original allocation and eligibility evidence; the full payer and allocation record is not exposed by a public endpoint.

This is an important verification boundary. A commitment or a valid membership proof demonstrates consistency with the committed record. It does not, by itself, prove that every original payment, price and allocation was correctly included. Bitcoin data and the public archive alone are not sufficient to independently reconstruct the complete initial eligibility calculation. Full auditing of that calculation requires the underlying mint records and the rules used to seal them.

Original allocation and remaining claimable amount are different values. Remaining rights require verified replay of claims and spends. Where only the original allocation can be read, the interface must not present it as an unspent balance.

Claims use an immutable eligibility-owner binding and amount-independent claim/right nullifiers. Partial claims consume the previous right and preserve a typed remainder. Changing an amount, opening another browser or producing another proof does not create a second allocation. Conflicting spends are resolved by the asset replay rules; a payment preview is not a completed claim.

04 Notes, signatures and recovery

A private note carries an encrypted opening and a commitment. Spending proves the required ownership and value relation and publishes nullifiers that prevent reuse. The current private envelope contains two nullifiers and two encrypted output slots. Their membership in the same envelope remains public, even when their values and owners are hidden.

Current receiving addresses use the bln1 format. The older mint-era blnd1 description is not the current note-address encoding. A BLIND receiving address is not a Bitcoin payment address.

The wallet derives privacy keys from a fixed, domain-separated wallet-signature message. Its exact message bytes, including the original origin, are part of key recovery and must remain unchanged when the website's routes or wording change. A wallet that returns different valid signatures for the same derivation request can produce different keys. The current flow rejects unstable derivation; it does not silently switch to a new random identity.

The verification and recovery page provides encrypted backup controls and downloadable recovery tools. A backup can contain privacy keys, initial eligibility evidence and available sender receipts. Keep it with its password. A missing initial eligibility witness cannot be recreated merely by scanning encrypted notes, and a sender's original recipient address may be unavailable without its saved receipt.

The independent recovery tool recovers account information from a backup and independently verified history up to the saved block height. It is a read-only recovery tool, not an independent replacement for every step needed to authorize and broadcast a new claim or transfer.

05 Routing and availability

The deployed carrier flow uses an operator-issued route ticket. Its signature binds an operation, profile, expiry and allocated marker script to a pinned routing key. The carrier includes the ticket and a Bitcoin marker output; clients and indexers reject an unauthorized ticket.

The routing signer does not replace the asset proof or the user's Bitcoin signature. However, new operations depend on obtaining the required ticket. If that service refuses a request or becomes unavailable, a user cannot bypass it simply by publishing an otherwise valid proof. Independent verification of existing history is a different capability from independent continuation of this issuance and routing service.

Eligibility reads, immutable account binding, preparation, transaction admission and synchronized state also use project-operated services in the website flow. Services can observe requests and their timing. The protocol must not be described as eliminating every trusted party or every opportunity for metadata correlation.

Current v13/v14 private and v16 transparent-claim proofs are generated by the browser runtime. Proof generation, Bitcoin transaction signing and route admission are separate steps. New remote-proof requests through the older public-claim compatibility routes are disabled; an older client must upgrade. Verification of historical v9 proofs and recovery of already prepared payments remain supported. When previously enabled under explicit consent, remote proving received the claim witness, including a nullifier key and eligibility or remainder evidence. Closing that endpoint does not erase information already disclosed, and that historical path does not describe the disclosure boundary of the current browser-proved paths.

06 Independent verification and checkpoints

The downloadable indexer and recovery resources make it possible to examine the published rules and validate supported transaction history without relying only on the website's displayed balance. Verification requires the appropriate profiles, historical verifier resources, authenticated starting state and Bitcoin data. Downloading a file is not the same as verifying it.

A checkpoint records a state at a specific Bitcoin height and hash. Incremental recovery must validate its integrity and context, resume from its declared boundary and reject a mismatched chain or a conflicting continuation. A checkpoint accelerates replay; it cannot prove an omitted genesis history or supply unpublished mint-allocation evidence. Distinguish replay from an authenticated checkpoint from a full reconstruction of the initial allocation.

Archiving the data and verification resources improves recoverability if the website disappears. It does not remove the route-ticket dependency for new operations or guarantee that all private recovery material can be derived from Bitcoin. Keep copies of recovery material and verify archive contents before relying on them.

07 What privacy does and does not cover

The deployed protocol does not merge all operations in a block into one anonymous batch. Outputs remain grouped by transaction envelope. Earlier claims that the input/output grouping was never written were incorrect for this implementation.

Especially early in the protocol, a small set of eligible notes or active participants can make timing and transaction patterns revealing. Reusing Bitcoin funding addresses, closely timed claims and transfers, and transparent entry or exit amounts can further reduce ambiguity. Zero knowledge does not guarantee unlinkability against these observations, and there is no fixed anonymity-set size or numerical probability of untraceability promised here.

The slogan “Anyone can verify. No one can see.” describes a design aim, not a claim that every field is hidden or that the complete issuance history can be reconstructed from public data alone.

08 Review status

According to the project team, external independent reviews are in progress. The reported organizations and scope are listed in the project-reported audit status. No completed audit report is published; this is not a claim of certification or institutional endorsement.

Automated regression tests, proof verification fixtures and source hashes are useful implementation checks. They do not replace an independent review of the circuits, setup assumptions, initial allocation, key derivation, state transitions and operational dependencies. The deployed metadata retains independentAuditComplete: false.

09 Historical design and future work

The September paper described a proposed 610-byte envelope with a 192-byte Groth16 proof, public reconstruction of all issuance, per-block mixing, a separate full-allocation registration step, and possible BTC vaults and swaps. Those descriptions must not be read as the specification of the current v13/v14/v16 paths. Some earlier implemented profiles also used other proof encodings; their historical verifier rules remain relevant to historical data.

Per-block mixing, a BTC peg or vault, statechain transfers and the proposed swap systems are not implemented by the current BLIND note protocol. Research citations express intellectual background, not deployed functionality, audits or endorsements. Any future protocol change needs explicit rules, compatibility analysis, new verification evidence and a clear activation boundary.

Verify the rules. Understand the boundary.