A Private Room With a Public Door

SEPTEMBER 25, 2026

Someone sent me a link today, and on first read I didn't really understand it. In crypto that usually means it's either a scam or a research paper. This one is a research paper. The page, from a site called Bitsaga, makes a claim that would have been a punchline a few years ago: private Bitcoin transfers, with the amount and the recipient encrypted, running on Bitcoin as it exists today. "Nothing in Bitcoin's rules changes. No soft fork, no vote, no new coin." And there's a receipt: a real transaction, confirmed in block 968,533 at 09:40 UTC on September 25, carrying a shielded transfer that only its recipient can read.

Both halves of that are true. The same page also calls its own demo "proof of concept, insecure by design, not usable today", and that's true too. So here is the whole thing, from the top, in the order it finally made sense to me.

Two Different Groups, One Idea

It helps to know there are two parties here, because the headlines blur them. On September 24, three researchers at a New York cryptography firm called [alloc] init (Clara Shikhelman, Mikhail Komarov and Aleksei Moskvin) published a 56-page paper called Shielded Bitcoin. It's a design and a security analysis. Bitsaga, a separate outfit, built the transfer half of that design as a public test program, rehearsed it on a test network, and on September 25 ran it on mainnet with test-sized amounts. The paper is the blueprint. Bitsaga put up a shed from it to show the blueprint isn't fiction.

The Problem It's Solving

Bitcoin is a glass ledger. Every payment ever made is public forever: which address paid which address, and exactly how much. Addresses don't carry names, but once anyone ties one address to you (an exchange withdrawal, an invoice, a donation page), they can often follow the money for years.

There are partial fixes today, and the paper lists them honestly. CoinJoin mixes many people's payments into one transaction so it's harder to say whose coin went where. PayJoin breaks some common tracing assumptions. Silent Payments let you publish one reusable address without every payment to it being linked. All three make tracing harder. None of them hides the amount, and none of them gives you what Zcash has had since 2016: a shielded pool where the sender, the recipient and the value are simply not on the public record.

Until now, the Bitcoin-native ways to get there all ran through a soft fork, usually new opcodes like OP_CAT, which means years of argument and possibly never. The point of this paper is to skip that argument entirely.

How It Works, in Plain English

Picture a vault with one public door in and one public door out, and a private room in between.

1. The door in. You send ordinary bitcoin to a vault address. That payment is a normal Bitcoin transaction, so everyone sees it.
2. Your coins become notes. Inside, your balance exists as encrypted "notes." Each note is a sealed amount addressed to its owner. Nobody else can read one.
3. Paying someone means mailing an envelope. To send, your wallet builds a sealed envelope (669 bytes in Bitsaga's test) and posts it inside a perfectly normal Bitcoin transaction, in the OP_RETURN field Bitcoin already allows for attaching data. The envelope holds the new notes, encrypted so only the recipient can open theirs, plus a small mathematical proof.
4. The proof does the trusting. That proof, 192 bytes, is a zero-knowledge proof. In Bitsaga's words it says the sender "spent notes she owns and created exactly the value she consumed, without saying which notes or what value." It proves you didn't counterfeit anything while revealing nothing about what you actually did.
5. Spent notes get punched, like a coat-check ticket. Each spend publishes a "nullifier," a code that marks some note as spent without saying which one. If anyone tries to spend the same note twice, the second nullifier matches the first and the transfer is thrown out.
6. The door out. When you want real bitcoin back, the vault pays you to an ordinary address. Also public.

The recipient opens their note with a viewing key. That key has a nice side effect: if an accountant needs to see your income, you hand them a viewing key that shows what you received, not a list of addresses that shows everything.

The Clever Part: Bitcoin as a Bulletin Board

Here's the move that makes it work without a fork. Bitcoin itself never checks the proofs. To a Bitcoin node, the envelope is just data it carries and ignores. The checking happens in software called an indexer, which reads every envelope in block order, verifies each proof (about 2.5 milliseconds apiece in the test) and keeps the private ledger up to date. If an envelope's proof fails, the transaction still gets mined, and the indexer simply doesn't count it.

That sounds fragile until you see the guarantee the paper rests on: the rules are fixed and the input is the Bitcoin blockchain, so any two honest indexers replaying the same blocks end up with the same private ledger, without talking to each other. Bitcoin supplies the ordering and the permanence. The math supplies the validity. It's the same basic trick Ordinals and Runes use: meaning is read into data Bitcoin carries but doesn't interpret. The difference is that here the thing being tracked is money, and the tracking is encrypted.

That is also why the design leans on the paper's Zcash lineage so openly. It's Zcash's shielded-note architecture (notes, nullifiers, a zero-knowledge proof per transfer), minus Zcash's own blockchain. For Zcash that was the whole pitch against Bitcoin: "Bitcoin, plus privacy." This is an attempt to make the "plus" available without leaving.

What the Demo Proved, and What It Didn't

It proved the private room works on real Bitcoin, today, with no one's permission. It also came with three problems, which Bitsaga lists itself rather than leaving you to find them:

• The vault is one company holding one key. "Coins enter by paying a vault we control... That is a custodian, not a bridge." The shielded ledger may be trustless, but the actual bitcoin is sitting in someone's wallet, and getting it back out means that someone pays you.
• The lock's combination is public. This kind of proof system (Groth16, the same one Zcash used for years) needs a one-time setup that produces a secret, which must then be destroyed. In the test, that secret is generated from a published seed, so "anyone could forge a proof and empty the vault." That's deliberate for a demo, and the fix is known: a proper setup ceremony, or a newer proof system that needs no secret at all, which is the road Zcash itself took in 2022.
• Proving is slow. About two seconds per proof on a sixteen-thread server, nine on a single thread. Fine for a server, rough for a phone.

And it's heavy. A plain Bitcoin payment is about 140 virtual bytes. The shielded transfer was 793, most of it the envelope, for a 2,382-satoshi fee at a quiet three sats per byte. On a busy fee day, every private payment costs five-and-a-half times a normal one. The envelope also only relays because Bitcoin Core raised its default OP_RETURN size limit in version 30, the change that had Bitcoin developers at each other's throats last year. The paper itself flags the risk that relay or mining policy tightens again around large data outputs.

Privacy Is the Size of the Crowd

This is the part that matters more than any of the cryptography, and both documents say it plainly. Bitsaga: "with two depositors the link is obvious." If Alice puts in 0.37 BTC on Tuesday and Bob takes out 0.37 BTC on Wednesday, the encryption in between is decoration. The paper goes further: in the worst case the set of people you could be "may collapse to a singleton."

Encrypted notes don't make you anonymous. Other people's notes make you anonymous. Zcash learned this the hard way. A 2018 study, "An Empirical Analysis of Anonymity in Zcash", found that most of what flowed through its shielded pool could be linked anyway, because so few people used the pool and the ones who did moved money in and out in recognizable patterns. And even a full pool can't hide what the paper lists as public: when you transacted, how many notes went in and out, and which wallet paid the fee.

Could a Decentralized Escrow Replace the One Key?

This was my first instinct too: keep the private room, but hand the door to a group instead of one company, so no single party can run off with the coins. It's a good instinct, and the paper already lists it as a possible design: "Federated or multisignature custody, BitVM-style bridges, and future covenant- or vault-based constructions remain useful comparison points, but the intended architecture is PIPE-based." Here's how the options compare.

The federation is the one you could build this year, and it would be a real improvement: one rogue signer can't steal anything. Something very close already exists. Fedimint is a federation of "guardians" holding bitcoin in multisig and issuing private ecash against it. The difference is where the ledger lives. In Fedimint the federation runs the private ledger itself. In Shielded Bitcoin the ledger lives on Bitcoin and anyone can rebuild it, and the federation would only guard the door.

But a federation has two problems, and I've already watched the first one happen. On September 6, roughly four thousand bitcoin walked out of Liquid's federation reserve in one afternoon. The leading theory when I wrote about it, from developers who know that codebase, was a bug in the math that checks Liquid's hidden amounts, and the eleven-of-fifteen signers approved the withdrawal because it looked perfectly normal. A federation can only refuse what it can see, and a door-keeper for a shielded pool sees even less, because hiding amounts is the entire point. If a proof can be forged (and in the demo, remember, the setup secret is public), the signers will cheerfully approve a withdrawal that looks flawless. Decentralizing the keyholders doesn't help if the thing they're all checking is broken.

The second problem isn't technical at all. It's legal. The prosecutions that hit Bitcoin privacy tools in the last two years turned on the charge of running an unlicensed money-transmitting business. Samourai Wallet's developers pleaded guilty to it, and one was sentenced to five years last November. Tornado Cash's Roman Storm was convicted on that count in August 2025. The line those cases keep drawing is custody. A federation holding the bitcoin behind a shielded pool is a named group of people holding a mixer's money, and that's exactly the shape those cases were about. It doesn't matter how decentralized the signing is if every signer can be subpoenaed.

So a decentralized escrow makes this safer but not viable, in the sense of something a normal person should put savings into. That's why the authors are betting on PIPEs v2. The idea: lock the vault's key inside a kind of encryption that only opens for someone holding a valid proof, so the coins move when the math says so and nobody ever holds them. If it works, there's no custodian to charge. It's elegant, it would give Bitcoin covenant-like powers with no soft fork, and as of today it's a research paper that no one has built.

Would I Build This, or Just Keep Building on Lightning?

What I actually find exciting here isn't the demo. It's that someone spelled out, in 56 pages of honest analysis, how much of Zcash's privacy Bitcoin can get without changing a single rule. The answer turns out to be all of the private room. The door is the part nobody has figured out yet.

Where I Could Be Wrong

• I read the paper and Bitsaga's write-up; I didn't run the code. The size, fee and speed figures are Bitsaga's own from one test transfer, and the transaction itself checks out on the public chain (793 virtual bytes, 2,382 satoshis, one data output). One test isn't a benchmark.
• PIPEs v2 could arrive faster than I'm implying. Witness encryption has gone from "theoretical" to "has a concrete candidate scheme" quickly, and the v2 paper alone has ten authors. Press coverage has quoted storage requirements in the hundreds of terabytes for the current version against a target of around 100 gigabytes. I haven't checked those figures myself, and a gap like that can close suddenly or not at all.
• The legal picture is moving. US prosecutors have signaled since 2025 that writing genuinely non-custodial software isn't by itself the target, and the Tornado Cash case still has post-trial and appeal steps that could change what it stands for. How any of that applies to a federation holding a shielded pool's bitcoin hasn't been tested, and I'm not a lawyer. Treat my custody point as a reading of the pattern, not legal advice.
• I'm describing Lightning's privacy in broad strokes. How private a given Lightning payment is depends heavily on the wallet, the service provider and the invoice format, and some popular wallets are simply custodial accounts with a Lightning front end.
• I hold bitcoin, so I'd like it to get more private. That's a bias worth naming. None of this is investment advice. It's one person's reading of a new paper and a day-old demo.