Tag: Bitcoin privacy

  • Researchers Propose Zcash-Style Privacy for Bitcoin Without a Soft Fork

    Researchers Propose Zcash-Style Privacy for Bitcoin Without a Soft Fork

    Key Highlights

    • Researchers from Alloc Init proposed “Shielded Bitcoin,” a metaprotocol that hides BTC transfer amounts and counterparties using zero-knowledge proofs without altering Bitcoin’s consensus rules or requiring trusted bridges.
    • The design adapts Zcash’s encrypted-note model directly on Bitcoin’s base layer, allowing anyone to run indexers that verify proofs and track nullifiers to prevent double-spending.
    • Grayscale research head Zach Pandl recently warned that AI advances are making wallet-to-identity linking easier, suggesting shielded transaction tools may become essential for privacy-focused users.

    Alloc Init Researchers Unveil Shielded Bitcoin Privacy Metaprotocol

    A team of researchers behind Alloc Init has introduced “Shielded Bitcoin,” a novel metaprotocol designed to bring transaction privacy to Bitcoin’s base layer without modifying the network’s consensus rules or relying on trusted bridge operators. Presented by Clara Shikhelman, Mikhail Komarov, and Aleksei Moskvin, the proposal addresses a fundamental limitation of Bitcoin’s public ledger: amounts, transaction timing, and links between transactions remain visible and can often be associated with known wallets through blockchain analysis.

    How Encrypted Notes and Zero-Knowledge Proofs Enable Private Transfers

    The Shielded Bitcoin design borrows the encrypted-note approach pioneered by Zcash but implements it directly on Bitcoin’s existing infrastructure. When a user such as Alice pays Bob, her wallet publishes encrypted notes to the Bitcoin blockchain alongside a zero-knowledge proof. These notes contain the transfer amount and the recipient’s receiving information, while the cryptographic proof serves three critical functions: it confirms the notes being spent exist, verifies Alice’s authorization to spend them, and validates that input and output amounts balance — all without exposing any of these details publicly.

    Software components called indexers read these transfers, verify the zero-knowledge proofs, and track nullifiers — unique serial numbers that prevent the same note from being spent twice. According to the researchers, anyone can operate indexers, ensuring no single party controls the ledger state. The design also separates spending authority from viewing capabilities, allowing wallets to split into distinct keys: one for spending funds, a read-only key for detecting incoming transfers, and a third key for recovering a user’s own transaction history. This key hierarchy enables users to share limited transaction details with auditors or counterparties without surrendering spending control.

    Where Shielded Bitcoin Fits Among Existing Privacy Solutions

    Comparison With CoinJoin, Silent Payments, and Zcash

    Shielded Bitcoin enters a landscape of existing privacy-enhancing techniques for Bitcoin, each with distinct tradeoffs. Methods like CoinJoin, PayJoin, and Silent Payments operate within Bitcoin’s current transaction format and can obscure ownership trails, but transaction amounts and much of the transaction graph remain publicly visible. The researchers identified Zcash as the closest precedent due to its use of encrypted notes, nullifiers, and zero-knowledge proofs. However, Zcash operates on its own independent blockchain with separate consensus rules, whereas Shielded Bitcoin derives its state entirely from Bitcoin’s history.

    This architectural distinction carries implications: while Shielded Bitcoin avoids the need for a trusted intermediary or separate consensus mechanism, transaction patterns, distinctive wallet behaviors, and repeated publication fees could still allow observers to narrow down relationships over time through traffic analysis and heuristic clustering.

    Why This Matters

    The proposal arrives amid growing concern about the erosion of financial privacy on public blockchains. Grayscale’s research head, Zach Pandl, recently highlighted that advances in artificial intelligence are making it significantly easier to link wallet addresses to real-world identities. Pandl suggested that tools employing shielded transaction models — like those used by Zcash — could become “close to a necessity for privacy-minded users.” Shielded Bitcoin represents an attempt to bring similar cryptographic privacy guarantees to Bitcoin natively, without requiring users to move funds onto a separate chain or trust centralized mixing services. If adopted, it could shift the baseline for on-chain privacy on the world’s largest cryptocurrency network, though deployment would require wallet and indexer software development, as well as community consensus on the metaprotocol’s standards.

    Frequently Asked Questions

    Does Shielded Bitcoin require a soft fork or consensus change to Bitcoin?

    No. The researchers explicitly designed Shielded Bitcoin as a metaprotocol that operates on Bitcoin’s existing base layer without altering consensus rules. It uses cryptographic proofs published as transaction data rather than requiring protocol-level modifications.

    How does Shielded Bitcoin differ from using Zcash directly for private transactions?

    While both use encrypted notes, nullifiers, and zero-knowledge proofs, Zcash runs on its own independent blockchain with separate consensus rules. Shielded Bitcoin derives its state from Bitcoin’s history, meaning users stay on the Bitcoin network and do not need to bridge assets or trust a different validator set.

    Can observers still trace Shielded Bitcoin users through metadata analysis?

    Yes, the researchers acknowledge that transaction timing patterns, wallet behavior fingerprints, and fee publication rhythms could still allow sophisticated observers to correlate activity and narrow down relationships over time, even though amounts and counterparties are cryptographically hidden.

  • Researchers Propose Zcash-Style Private Bitcoin Transfers Without Soft Fork

    Researchers Propose Zcash-Style Private Bitcoin Transfers Without Soft Fork

    Key Highlights

    • Alloc Init researchers propose Shielded Bitcoin, a metaprotocol bringing Zcash-style private transfers to Bitcoin without a soft fork, using encrypted notes and zero-knowledge proofs.
    • The system relies on Bitcoin as a “neutral publication and ordering layer” while separate indexers verify ZK-proofs and prevent double-spending, avoiding base-layer consensus changes.
    • Critics highlight a small initial anonymity set and lack of quantum resistance; supporters including Eli Ben-Sasson see it advancing the original Zerocash vision of privacy on Bitcoin.

    Alloc Init Unveils Shielded Bitcoin: Privacy Metaprotocol Without Soft Fork

    Cryptography research firm Alloc Init has published a proposal for Shielded Bitcoin, a metaprotocol designed to bring Zcash-style shielded transactions to the Bitcoin network without requiring a soft fork or consensus changes to the base protocol. The paper, released Thursday by researchers Clara Shikhelman, Mikhail Komarov, and Aleksei Moskvin, outlines a system that would conceal transaction amounts, senders, receivers, and links to previously spent funds using encrypted notes and zero-knowledge proofs.

    Architecture: Bitcoin as Publication Layer, Indexers as Verifiers

    Unlike Zcash, which operates its own blockchain and consensus mechanism, Shielded Bitcoin would not launch a separate chain. Instead, the design explicitly uses Bitcoin as “a neutral publication and ordering layer,” the researchers wrote. Transaction data—encrypted notes, public nullifiers marking notes as spent, and zero-knowledge proofs attesting to validity—would be posted to Bitcoin blocks. Separate software components called indexers would then verify the zero-knowledge proofs, check that funds have not been double-spent, and reconstruct the state of the shielded system off-chain.

    This approach mirrors Zcash’s core cryptographic primitives—encrypted notes, nullifiers, and ZK-proofs—while offloading consensus and finality to Bitcoin’s existing proof-of-work chain. The researchers argue this offers a potential path to stronger privacy for Bitcoin users without the political and technical hurdles of a base-layer protocol upgrade.

    Developer Reactions: Anonymity Set Concerns and Quantum Resistance

    The proposal drew immediate and varied reactions from prominent cryptographers and developers. Vadim Zavodil, a developer, criticized the design on X, arguing that much of its privacy stack had already been implemented by Zcash and questioning the practical anonymity a newly launched system could provide.

    “Privacy is a function of the crowd. Zcash has a real shielded pool built over years,”

    — Vadim Zavodil

    “A brand new metaprotocol starts at zero, so your first private transfer hides in a crowd of one.”

    — Vadim Zavodil

    In a companion post, the Shielded Bitcoin researchers acknowledged a similar limitation, stating that large deposits do not automatically create a large anonymity set. They noted observers may still narrow down relationships between transfers if a small number of actors create most notes or if wallets exhibit distinctive behavior.

    Pierre-Luc Dallaire-Demers, founder of post-quantum cryptography firm Pauli Group, raised a separate concern, describing the construction as interesting but “not quantum resistant at all.” Dallaire-Demers later indicated he was exploring what a fully post-quantum version could look like, assuming Bitcoin eventually adopts a post-quantum signature scheme.

    Support from Zerocash Co-Author Eli Ben-Sasson

    Not all feedback was critical. Eli Ben-Sasson, co-author of the original Zerocash paper and CEO of StarkWare, offered a supportive perspective. In response to Alloc Init’s announcement, Ben-Sasson said the original intent behind the Zerocash paper—which preceded Zcash—was to bring privacy to Bitcoin. He added that he had not yet read the Shielded Bitcoin paper but would like to see the vision of privacy and scalability through zero-knowledge proofs materialize on Bitcoin’s base layer.

    Why This Matters

    Shielded Bitcoin represents a novel attempt to solve Bitcoin’s long-standing privacy limitations without the contentious governance process of a soft fork. By treating Bitcoin as a data-availability and ordering layer—similar to how rollups use Ethereum—the proposal sidesteps the need for miner or node operator consensus on privacy rules. However, the design inherits the bootstrapping challenge common to all new shielded pools: without a large, diverse set of participants, the anonymity set remains small, potentially undermining the very privacy it promises. The quantum-resistance critique also underscores a growing focus in the cryptography community on post-quantum readiness, especially for systems intended to operate for decades. If Bitcoin eventually activates a post-quantum signature scheme, metaprotocols like Shielded Bitcoin would need to migrate their cryptographic primitives accordingly. For now, the proposal adds a concrete, research-grade option to the expanding landscape of Bitcoin privacy tools, joining efforts such as Silent Payments, PayJoins, and second-layer solutions like Lightning Network with Taproot Assets.

    Frequently Asked Questions

    Does Shielded Bitcoin require a Bitcoin soft fork?
    No. The proposal explicitly avoids base-layer consensus changes. It uses Bitcoin only as a publication and ordering layer, with off-chain indexers handling verification of zero-knowledge proofs and double-spend prevention.
    How does Shielded Bitcoin differ from Zcash?
    While it adopts Zcash’s cryptographic architecture—encrypted notes, nullifiers, and ZK-proofs—Shielded Bitcoin does not operate its own blockchain or consensus mechanism. It relies entirely on Bitcoin for finality and data availability.
    What are the main criticisms of the proposal?
    Critics highlight two primary concerns: (1) a newly launched shielded pool starts with an anonymity set of near zero, limiting early privacy, and (2) the current construction is not quantum-resistant, posing long-term risk if large-scale quantum computers become viable.
  • Bitcoin’s Latest Mobile Privacy Feature Makes Incoming Transactions Invisible

    Bitcoin’s Latest Mobile Privacy Feature Makes Incoming Transactions Invisible

    Silent Payments Mobile Scanning Bandwidth Measured at 8 MB Daily, but Trust Risks Remain

    A new measurement project indicates that the bandwidth required for mobile wallets to scan for Silent Payments may be manageable, averaging roughly 8 MB per day near the current chain tip. However, the research highlights a more critical challenge: light wallets depend on indexers to deliver complete scanning data, and a single omitted entry can leave a real payment undiscovered.

    How Silent Payments Scanning Works

    Silent Payments, defined in BIP-352, enable a reusable Bitcoin address without exposing an obvious chain of payments. A sender uses the recipient’s public information to derive a fresh Taproot destination. The recipient’s wallet must then scan eligible transactions to find the output belonging to it. For a full node, this data is derived directly from the blockchain. For a light wallet, another source—an indexer—is required.

    Measurement Project Scope and Findings

    The independent project processed every Bitcoin block from height 709,656 through 965,089, an inclusive span of 255,434 blocks from shortly after Taproot activation to September 2026. Its per-block CSV contains the same number of rows with those exact height boundaries.

    Across that history, the complete BlindBit v2 scanning payload totaled 15,079,946,729 bytes, reported as 15.08 GB, averaging 59.0 KB per block. That full-history total describes a restore across the measured range. The daily figure answers a different question: using the average from heights 900,000 through 965,089 and an assumed 144 blocks per day, the project calculates about 8.0 MB for a wallet following the chain near the dataset’s upper end. This does not describe the initial historical download.

    The repository was produced by one independent operator. Its data and scripts are public, and the aggregate row count and payload totals can be checked from the CSV, but a second operator has yet to publish a full rerun. The result speaks to bandwidth volume; it does not measure phone battery use, processor load, storage behavior, or delivery latency.

    Filter-Based Alternative Modeled

    The project also estimates a lighter filter route: about 0.94 GB of modeled Taproot-only filters plus roughly 6.2 GB of raw tweaks yields a 7.14 GB subtotal. The 15.08 GB complete feed is about 2.1 times that subtotal. The filter route then adds a full-block download for every match, including false positives, so its realized traffic varies by wallet activity and match rate.

    The filter component is a model built from exact per-block item counts. Its sizing formula was checked against 21 real filter encodings and landed within about 0.5%, according to the project. A Taproot-only Silent Payments filter has yet to be deployed.

    How an Indexer Can Make a Payment Invisible

    For each eligible transaction, the wallet combines its private scan key with public data derived from the transaction’s inputs. It uses the result to generate candidate output keys and checks whether one appears in the transaction. One server-assisted model keeps matching on the phone and asks a server for public tweaks. This can avoid sharing the private scan key, but the server’s response still needs to be complete. If the one tweak needed for an incoming payment is absent, the wallet generates no matching destination and shows no receipt.

    A Cake Wallet issue opened in July 2025 analyzed how the miss could persist. The reporter wrote that a client may save a later local scan height after receiving incomplete data. If the wallet then treats the earlier range as finished, connecting to a different server would not automatically make it ask for the missing block again. The issue page does not show a maintainer confirmation of that architecture analysis, and it does not document intentional withholding by any server.

    The output itself remains valid on Bitcoin. The recipient’s keys still control it. Discovery can be recovered by rescanning from an earlier height against a complete, honest source or by using a full-node-backed scan. The user-facing danger is silence: the wallet may show a complete sync without signaling that historical data should be revisited.

    Proposed Mitigation: Chained Commitments

    The project proposes chained commitments to each block’s canonical tweak set. Two servers that publish commitments can be compared, and an externally anchored checkpoint can expose later rewriting or equivocation. This creates an audit trail. A first client relying on a single response can still receive an incomplete set before an independent comparison reveals the discrepancy.

    Wallet Implementations Diverge on Trust Models

    The standards picture has two layers. BIP-352’s status is Complete, covering the core Silent Payments protocol. Its light-client appendix still describes privacy-preserving phone support as open research. The new converged light-client document labels itself pre-draft v0.1, with adoption and interoperability work still ahead.

    Wallet developers have meanwhile shipped different server relationships. Sparrow Wallet 2.5.0, released in May 2026, added Silent Payments receiving and automatic selection of a public Frigate server. Frigate describes its design as a Remote Scanner, which performs the matching on server infrastructure with ephemeral client scan keys.

    The work-in-progress index specification maps Cake Esplora to Cake Wallet and lists Dana Wallet, BDK with Kyoto, and BlindBit Desktop as clients around BlindBit Oracle. Dana and Silentium describe their own mobile projects as experimental. Those implementation sources do not claim adoption of the September pre-draft.

    User Choice Extends Beyond Synchronization Speed

    For a user, these designs define more than synchronization speed. A remote scanner can learn which transactions belong to a wallet. A tweak server can keep the private matching work on the phone while leaving the wallet dependent on a complete feed. A personal full-node-backed service shifts both computation and trust onto infrastructure the user controls.

    The measurements make the bandwidth part of that choice look less forbidding. Wider adoption still depends on a second property: a wallet must be able to detect incomplete history before an incoming payment disappears from its view. Silent Payments can hide address reuse on-chain, but phone wallets need safeguards that keep privacy from becoming a new form of server trust.