Shielded Bitcoin was announced by [[alloc] Init] (they really need to get a handle on all the brackets in their name) a few days ago. #1580989 #1427029 #1583163

It's exciting to see new privacy ideas like this and Babilonia #1565564 and Glass Coins #1556346 but I've also found it fairly difficult to wrap my head around the differences in each of these proposals.

So, I found really helpful this approach that Insider Edition has taken here with Clara Shikhelman (one of the people who has worked on Shielded Bitcoin), organizing her explanation of Shielded Bitcoin by addressing various criticisms people have raised in response to its publication.

Insider Edition's newsletter on the topic is excellent and filled with lots of great details, but it is also quite long. I've taken the liberty of summarizing it a bit and re-arranging the numbered list of criticisms they address. (That's why numbers are out of order below).

12: Does Bitcoin need a soft fork for any of this?

No. Shielded Bitcoin applies its own metaprotocol rules to data published and ordered by Bitcoin. No new opcodes, consensus changes, or soft forks are required.

2: What is Shielded Bitcoin if it’s not L1, an L2, or a sidechain?

As far as a Bitcoin node is concerned, Shielded Bitcoin doesn't exist as any more than ordinals exist. Bitcoin still just sees transactions with inputs and outputs in blocks.

Shielded Bitcoin is not part of Bitcoin consensus: Bitcoin nodes validate the underlying Bitcoin transactions, not Shielded Bitcoin’s private transfer rules.

Shikhelman describes it as a Bitcoin metaprotocol. While she don't make the comparison, other metaprotocols that I can think of are Ordinals, RGB, and UTEXO.

Protocol data is published to and canonically ordered by Bitcoin, while a separate indexer/explorer parses that data to derive the protocol state deterministically.

Unlike ordinals though, Shielded Bitcoin relies on cryptography embedded in witness data to enforce the protocol, so, I believe, your ownership of your BTC in Shielded Bitcoin is enforceable by you and math, rather than by everyone else agreeing to some indexer's version of where everything is at.

4: Isn’t it a trusted bridge? Who controls it?

I've seen a number of people asking this question, or saying something like this:

source

Insider Edition answers the question of whether there is a trusted bridge or not like this:

This objection tends to conflate two very different concepts: trusted setup and trusted operation. PIPEs does have trusted setup assumptions. Constructing a PIPE ciphertext involves a one-time 1-of-n multiparty computation (MPC) ceremony, and the ZK proof system may introduce its own setup assumptions. But those participants do not become custodians or operators. They aren’t required to remain online, process transactions, approve withdrawals, or exercise ongoing control over users’ funds.

And in reply to the tweet above, one of the alloc-int founders clarified:

source

Cryptography replaces the role that a trusted operator, committee, or multi-sig would otherwise play. Once the setup is complete, no setup participant is supposed to control the funds or participate in the user flow.

It seems to me that this is a case where the jury is out. I'm certainly not cryptographically savvy enough to evaluate the math, so we will probably need to wait and see what sort of community opinion gets formed about this.

Also, they have not yet published details about the vault (I believe this means the script for the actual utxo in which your bitcoin sits). Here's their reasons for publishing this separately:

This separation is deliberate because the vault architecture is a substantial protocol design contribution in its own right, with applications beyond Shielded Bitcoin. We believe it warrants dedicated treatment as a separate contribution to Bitcoin research

9: Don’t PIPEs require 338 TB? How could this possibly be practical?

In question #4 above, a ciphertext is mentioned. This is a large file -- used to be as much as 338 TB, now only 10TB, but I believe the user needs access to this file in an unhappy exit from the system.

Moving and managing Bitcoin inside a shielded system does not require decrypting a PIPE at all; decryption is primarily needed to exercise the unilateral L1 vault exit mechanism.

Shikhelman suggests that the storage burden of this ciphertext could be solved like this:

The ciphertext also does not need to be stored by each user. Because it can be public, storage can be outsourced or distributed across inexpensive, high-latency storage infrastructure without introducing an additional trust assumption.

5: Don’t users still have to trust an indexer or maintain client-side state?

Putting aside the question of a bridge, does Shielded Bitcoin require users to rely on a third-party indexer, and if so, what can that indexer do?

A malicious indexer can omit data, return stale information, or refuse service, but its responses can be independently verified against Bitcoin history...It never has access to a user’s private keys, cannot spend their notes, and has no authority over protocol state.

"can be independently verified" may be doing a lot of work here. I wonder how difficult it is to run your own indexer.

3: Even if the transfers are private, isn’t privacy compromised by transaction metadata and fees?

This seems like a pretty important concern. Similar to joining a coinjoin, you still have to pay a lot of attention to what you do before and especially after leaving Shielded Bitcoin.

Peg-ins, peg-outs, carrier transactions, timing, network activity, and fee payments can expose metadata if handled naively.

The important distinction is between privacy within the shielded system, which is enforced cryptographically, and privacy at its boundaries, which depends on how users enter, exit, and interact with Bitcoin.

The following points are ones that I thought were less interesting. The points above give a pretty quick digest on Shielded Bitcoin, and what follows are questions you may not find as relevant.

6: Without its own consensus, how can Shielded Bitcoin prevent double-spends or handle reorgs?

These are Shielded Bitcoin validity rules, not Bitcoin consensus rules. Bitcoin does not determine whether a shielded transfer is valid; it determines the canonical history over which Shielded Bitcoin’s rules are applied.

7: Isn’t Witness Encryption novel and therefore risky?

Witness Encryption has been studied in cryptography since 2013, but unlike ZKPs, it has not yet crossed the gap from theoretical research to practical, production-grade cryptography. PIPEs should therefore not be treated as though it were a mature primitive with decades of battle testing behind it.

8: Isn’t the AADP Witness Encryption scheme broken?

Yes, and they fixed it. Shikehlman points out that

Finding and fixing attacks is a normal and valuable part of cryptographic research (e.g., MuSig2, Signal’s PQXDH), particularly at this stage of a new construction.

10: Can’t a circuit bug secretly inflate the supply?

This is pretty much what happened in the Zcash hack over the summer #1502689. If you have a bunch of shielded transactions occurring inside a pool or metaprotocol, the rules of Bitcoin can still prevent inflation of actual BTC, but they cannot prevent the metaprotocol from inflating itself -- which would result in their not being enough BTC for everyone to peg-out.

The relevant risk is whether an implementation bug could create unbacked shielded claims against the BTC held in the system’s Bitcoin vaults.

I think their answer here is yes, this is a concern and they take it seriously.

11: Can Shielded Bitcoin and PIPEs become quantum-safe?

It's not currently designed to use quantum-resistant cryptography, but it could be.

For signatures, the key encrypted within PIPEs could move from Schnorr to a post-quantum signature scheme such as SHRINCS. For ZK proofs, the underlying proof system could similarly be replaced with one based on post-quantum-friendly assumptions, including hash-based constructions

1: Isn’t this just Zcash bolted onto Bitcoin?

I don't really understand why this is a valid criticism.

The shielded transfer rules do not become part of Bitcoin consensus, but there is no separate blockchain, consensus mechanism, or token either.