Two Ways to Hide a Payment
A normal Bitcoin payment leaves the amount, and enough structure to guess who paid whom, where anyone can read it. CoinJoin, Payjoin, and Silent Payments scramble the labels. The amounts stay on the chain. The designs below try to hide the payment itself, without a soft fork. None of them has a wallet release.
GLASS COINS
Hand the payment privately to the recipient, with a proof that it is valid. Bitcoin stores a short marker so the same coin cannot be spent twice. If you lose the proof, the chain does not have a copy.
SHIELDED BITCOIN
Post the encrypted payment on Bitcoin, with a proof that it was valid. Anyone can rebuild the books by replaying those posts in chain order. A seed can find your notes again because the ciphertext is on the chain.
THE LOCK
Those notes are not bitcoin until something locks real coins to the rules. A PIPE encrypts a Bitcoin private key so it can be decrypted only by someone who proves a statement. Miners still see an ordinary signature.
WHAT BITCOIN CHECKS
In all three, Bitcoin consensus does not learn a new opcode and does not verify the private payment. It orders bytes, or it sees a normal spend. The extra rules are checked by the users, or by software replaying the chain.
Glass Coins
Formerly Shielded CSV. Jonas Nick, Liam Eagen, and Robin Linus, ePrint 2025/068. Client-side validation: the recipient checks the coin. The chain is only there to catch a double spend.
64 BYTES
The paper puts a 64-byte nullifier on the chain per transaction. A user checks one Schnorr signature per nullifier. Everyone else can ignore the bytes. The proof travels with the coin, and the paper says its size and check cost do not grow with that coin's history.
100 PER SECOND
Their example is private Bitcoin payments at 100 per second, and only if there is an adequate bridge to the chain. They name BitVM-style bridges for that job. The 100 is their figure under that condition, not a measurement.
IF THE PROOF IS LOST
The protocol does not publish everything needed to rebuild the private state from Bitcoin. Shielded Bitcoin's related work, citing this paper, says a lost local proof is not generally recoverable from the chain alone.
THE RENAME
btc++ Insider, 31 Aug 2026: at the first developer call on 27 Aug, the three authors renamed the protocol Glass Coins and shared a high-level specification. The 24 Sep Shielded Bitcoin paper still describes Shielded CSV as a theoretical proposal, not a deployed system.
A PIPE Locks the Key
PIPEs v2 is ePrint 2026/186, from [alloc] init. Mikhail Komarov is an author of both PIPEs v2 and the Shielded Bitcoin paper. A proof gets control of a coin by encrypting the spending key, without a covenant opcode.
ENCRYPT, THEN DELETE
Make a fresh Bitcoin key. Encrypt the private key under a statement, and do not keep the plaintext key. Whoever can prove the statement decrypts it and produces a Schnorr signature. The statement can be "this shielded peg-out is valid."
NO CONSENSUS NET
Miners do not check the statement. They see a key-path spend like any other. If the encryption is broken, or the key leaks, the coins are not saved by a consensus rule. The guarantee is the cryptography.
WHERE SHIELDED BITCOIN USES IT
The 24 Sep paper says PIPEs enter at peg-in and peg-out, and sketches a PIPE fee vault so publication is not paid from the user's ordinary wallet. It does not specify either construction. It says the claim that users keep their own keys does not cover the peg.
NOT DEPLOYED
The concrete candidate in PIPEs v2 is AADP witness encryption, which that paper calls a research direction. It rests on assumptions much newer than Schnorr. There is no shipped way to lock a mainnet coin to a shielded-note proof with it.
Notes Posted on Bitcoin
Clara Shikhelman, Mikhail Komarov, and Aleksei Moskvin, 24 Sep 2026. Same note, nullifier, and proof shape as Zcash. No second chain. Bitcoin stores the bytes and their order. It does not interpret them.
A NOTE
Value inside the metaprotocol is an encrypted record: a satoshi amount and a way to reach the owner. The plaintext is not on the chain.
A TRANSFER
The sender publishes encrypted notes, one nullifier per note spent, and a proof that the notes exist, the spender is allowed to spend them, and the amounts balance. A nullifier can be accepted once.
REPLAY
Indexers rebuild the note tree and the nullifier set from accepted envelopes, in Bitcoin order. The paper says two correct implementations, on the same profile and the same chain, get the same state without coordinating. They do not receive a key that can spend.
ONE SEED
One seed derives a spending key, a viewing key for incoming notes, and a viewing key for the owner's own outgoing history. A viewing key cannot spend. Showing one transfer is narrower than handing over the viewing key, and a disclosure does not prove that nothing was withheld.
The Envelope Is Still Public
Hiding the note contents is separate from hiding that a transfer was published, and separate from how bitcoin enters and leaves.
STILL VISIBLE
An observer sees when the envelope was published, how many notes went in and out, the fee, and the Bitcoin transaction that carried it. Amounts, the shielded sender, the recipient, and which earlier note was spent stay inside the proof. A wallet that repeatedly pays the fee can still be clustered.
625 vB
Their 2-input, 2-output profile is a 610-byte envelope. In one
OP_RETURN output that is 625 vB. They also price a witness carrier at 438 vB across two transactions. Relay of the OP_RETURN assumes Bitcoin Core v30's default data-carrier size. An operator can set it back to 83 bytes. Consensus does not require miners to include it.THE DOOR
Peg-in and peg-out are not specified. The direction they name is a PIPE. They write that this paper does not claim entry or exit is trustless, private, unlinkable, or censorship-resistant. A distinctive peg amount, and its timing, can still be matched to later shielded activity.
GROTH16
The profile uses Groth16 proofs of about 192 bytes. Bitcoin does not verify them. Indexers do. The setup is per circuit, and one setup per arity they choose to support. Groth16's setup holds if at least one ceremony participant was honest. They list other proof systems as an open choice.
Where the Proof Lives
Glass Coins and Shielded Bitcoin put the payment data in opposite places. Both still need a bridge before the notes are bitcoin, and neither bridge is specified as a finished construction.
GLASS COINS
Small chain footprint. The owner must keep the proof. The paper's bridge is BitVM-style. A filtered service is not required to learn the payment, because the payment was never posted.
SHIELDED BITCOIN
Larger chain footprint, seed recovery, and a shared state anyone can replay. ZmnSCPxj's point on the thread: a phone that will not trust an indexer has to scan the chain, and a filtered service learns that you use the system even when it does not learn which notes are yours.
INDEXERS
A dishonest indexer can omit or delay envelopes and mislead a wallet that trusts it. It cannot spend. The user can switch indexers or replay the history. That is an availability dependency, not custody of the notes.
QUESTION
The transfer rules are the part that is written down. The peg, which is the part that touches real bitcoin, is a later PIPE paper. What is safe to treat as specified, and what is still a direction?