Stop #318 - Verify Without Seeing

Imagine paying a supplier in bitcoin. You have agreed on an amount, received the invoice, and sent the payment. You would like the details of the transaction to remain between you, the supplier and, when necessary, the accountant.

On the timechain, however, amounts and links between transactions are public. Anyone who can associate an address with your business can begin reconstructing its movements by cross-referencing them with other information. The payment works, but commercial confidentiality requires some extra care.

Last September 24, Clara Shikhelman, Mikhail Komarov and Aleksei Moskvin, researchers at Alloc Init, published Shielded Bitcoin: a proposal for transferring bitcoin-denominated value while hiding amounts, recipients and links between payments, without changing consensus rules.

Alloc Init@allocinitxyz Shielded Bitcoin: Private Transfers on Bitcoin L1 2:06 PM · Sep 24, 2026 · 1.05M Views 288 Replies · 450 Reposts · 2.65K Likes The paper describes how private transfers work. The deposit and redemption of bitcoin are deferred to a later paper. It is worth keeping this distinction in mind as we explore what might be built.

The object that circulates within the system is called a note: it contains a value in satoshis and the data needed by the recipient to recognize and spend it. It appears on the blockchain in encrypted form. The model follows the architecture of Zcash, with one difference: Shielded Bitcoin reconstructs its state from Bitcoin's history, without introducing a separate blockchain. This is what the authors call a metaprotocol, a set of rules applied to data published on the network. Their explanation of how it works provides a good starting point.

Let us try a payment: Alice already owns two notes, one worth 60,000 and another worth 40,000 satoshis. She wants to send 70,000 to Bob. Her wallet prepares two new notes: 70,000 for him and 30,000 in change for her. The fees needed to publish the transaction on Bitcoin are funded separately.

To accept the payment, it must be verified that Alice controls existing notes, can spend them, and has preserved the total value. A zero-knowledge proof makes it possible to prove these properties while keeping private the data used to calculate it. In the example, a verifier can check that the numbers add up without knowing our four amounts.

The double-spending problem remains. For each consumed note, a nullifier is published, a marker cryptographically derived from that note and the secrets needed to spend it. Once the transfer has been accepted, every attempt to reuse the same marker is rejected. The observer sees the nullifier being used, but cannot directly link it to the previous note.

These checks are performed by indexers, programs that read data in the order established by Bitcoin, verify transactions, and update the state of the metaprotocol. Anyone applying the same rules correctly to the same history reaches the same result. Bob's wallet looks for notes it can decrypt and verifies that it has received the one intended for him.

The indexer performs verification work, without obtaining the key to spend users' notes. A wallet that relies on its data without checking it, however, assumes it is correct: a dishonest indexer could show it a false or incomplete state. Independent verification requires reconstructing the state from data published on Bitcoin, or verifying the response received against that data.

Bitcoin, meanwhile, has published and ordered the data. Inclusion in a block certifies that the transaction was published, while its shielded validity is verified separately. An invalid payload may be contained inside a valid Bitcoin transaction: metaprotocol software must ignore it.

This division of labor is what makes the construction possible without a soft fork. Interested users would need additional software; the rules enforced by all Bitcoin nodes would remain the existing ones.

For those making payments, the benefit would be reducing the information exposed with every transaction. CoinJoin, PayJoin and Silent Payments address different aspects of traceability in the ordinary transaction model. Amounts remain visible. Shielded Bitcoin's objective is to protect the contents of transfers as well and the link between spent and created notes, as clarified by the authors' comparison.

For the business in our example, it would mean being able to pay a supplier without making the amount immediately readable to every observer. For a professional, it would mean keeping their economic activity more private. Practical usefulness will also depend on the metadata left visible by the system, but the objective deserves attention.

The project also provides for separate keys for spending and viewing. Viewing keys have two distinct functions: recognizing incoming payments and recovering the history of outgoing ones. Access could be provided to an auditor without handing over spending authority. To document a single transaction, it would be preferable to show only the necessary details: a viewing key exposes the entire history it can read, including beyond the period we had in mind.

This would enable user-selected disclosure. One limitation remains: showing some transactions does not prove that all of them have been shown. A viewing key alone does not certify the balance, nor does it constitute complete proof of reserves. The disclosure model explicitly distinguishes these cases.

Publishing encrypted data on Bitcoin also serves recovery: the wallet should be able to reconstruct its activity from the seed and the available protocol history. Notes present in the initial state also require the data specified for bootstrapping the system.

Among the future developments are atomic swaps with ordinary bitcoin and optional KYC attestations. An interested recipient could verify certified requirements concerning the provenance of notes while keeping earlier steps private. Notes without these attestations would remain valid. These are extensions to be specified and assessed separately; potential acceptance by a bank would be an additional question.

Let us return to Alice. So far, we have assumed that she already held value within the private system. For those notes to represent usable bitcoin, there must be a mechanism linking their entry and exit to bitcoin on the blockchain.

Alloc Init intends to build it with PIPEs v2, described in a dedicated paper. The principle is witness encryption: encrypting a Bitcoin private key so that it can be recovered by presenting data proving that a condition has been satisfied. That data can be, for example, a zero-knowledge proof.

Once the key has been recovered, a regular Schnorr signature is produced and the corresponding UTXO is spent. Bitcoin verifies the signature. The more complex condition has been applied by the cryptographic construction controlling access to the key.

This could enable forms of programmable custody in which the right to spend depends on a verifiable condition, without asking an operator to authorize every withdrawal. It is a possibility that goes beyond privacy and also concerns recovery mechanisms or exits from other protocols. Each application, however, must define precisely what it authorizes.

The limitation of PIPEs v2 is explicit: after recovering the key, whoever holds it can sign arbitrary transactions. The primitive controls unlocking and leaves the holder free to choose the outputs of the transaction through which they spend those funds. Equating it with a general substitute for covenants, such as OP_CTV, would attribute a property to the construction that the paper rules out. Adam Gibson also discussed this point with Komarov.

For a system with many users, it therefore becomes crucial to know which UTXO each person can redeem, how partial amounts are managed, and how exercising the same right twice is prevented. We need to understand who can recover the key, what data they must retain, and what happens after a blockchain reorganization. These are questions concerning the complete exit protocol, which the description of transfers alone leaves open.

Then there is the setup. In the presentation of PIPEs on the Bitcoin-dev mailing list, key generation is distributed among multiple participants, and security requires at least one of them to behave honestly. This assumption should be distinguished from the ongoing custody of an operator, but it remains a trust assumption.

After the latest Fermate on self-custody, the criterion should be familiar: control over funds is also assessed by the conditions under which we can recover them. The authors state that they want to eliminate third-party custody both on entry and exit. To judge the result, we will need the vault protocol announced as next.

Hiding the contents of a payment still leaves useful information for observers. The proposal makes it recognizable that a shielded transfer took place, when it was published, and how many notes it consumed and created. The Bitcoin transaction carrying the data also retains its own inputs, outputs and fees. The authors list these exposures in the privacy section.

Think of a recognizable wallet that systematically pays publication fees. Anyone observing it could cluster those transactions even without being able to decrypt them. Or consider a deposit followed shortly afterward by an exit of a very similar amount: timing and quantities may suggest a link. Reducing these correlations requires further choices regarding wallets, publication, and entry and exit mechanisms.

The composition of the group also matters. If Alice is the only plausible party behind a transaction, cryptographically hiding some data leaves very little uncertainty about her identity. Many bitcoin deposited by a few recognizable entities do not provide the same privacy as activity distributed among users who are difficult to distinguish. It is an issue that the authors themselves acknowledge.

On costs, the profile described in the paper estimates 610 bytes of payload for a transfer with two input notes and two output notes. The complete OP_RETURN output occupies 625 bytes, to which the rest of the Bitcoin transaction must be added.

In an interview with Unchained, Komarov roughly estimates a cost in fees around four times higher than that of an ordinary payment. The ratio depends on the formats being compared; the actual fee also depends on the market for block space. Greater privacy would therefore carry an on-chain cost and would still require publication on Bitcoin.

This research direction is worth pursuing. Paying while keeping one's business private, being able to verify the rules, and choosing what to show a counterparty would be concrete advances. The possibility of building them on top of Bitcoin expands the range of solutions we can explore.

To trust my funds, however, I would want to be able to follow the entire path: from deposit to transfer, all the way to recovery on Bitcoin. That is where the proposal will have to demonstrate that it keeps its promise.

Privacy worth building must leave us in control of the exit as well.