Defense for the "Inflation Bug" Argument?

Technology
1

The topic of Layer 1 privacy came up on today’s episode of Anthony Sassano’s “Daily Gwei Refuel” (Ronin bridge hacked, Polygon ID revealed and more - The Daily Gwei Refuel #344 - Ethereum Updates - YouTube).

Sassano (a well-respected Ethereum educator) argued that “even if we could implement privacy-by-default on layer 1 ethereum, we wouldn’t want to because of the possibility of an inflation bug…” In other words, he’s calling out the “limited means to immediately detect a bug in a zk-SNARK circuit that allows an attacker to counterfeit coins” articulated in the ECC’s “Defense Against Counterfeiting in Shielded Pools” post (Defense Against Counterfeiting in Shielded Pools - Electric Coin Company)

Now, I know Zcash implements a “turnstile defense” (Turnstile Enforcement Against Counterfeiting - Electric Coin Company) to prevent inflation in practice, but it seems this solution still leaves innocent people vulnerable to having their funds invalidated. What if they have shielded ZEC on the wrong side of the turnstile after an attacker mints counterfeit shielded ZEC and withdraws the max possible value into the transparent pool?

I strongly believe in privacy-by-default on Layer 1 to prevent panopticon surveillance, but I don’t have a good rebuttal to the common “inflation bug” argument that Sassano (and others previously) have employed.

Is the possibility for an inflation bug fundamental to any network that implements privacy? If so, is there a better defense than a turnstile that leaves innocent late-movers vulnerable?

6 Likes
2

This collection of Twitter threads on this topic is well worth a read:

3

Pretty much if the projects txs reveal the same or less as Zcash shielded txs which is only the tx fee, a user sending to themselves isn’t discernable from 2 users sending/recieving or the amounts. It happened here once though the bug was so discrete that the likelihood of it being exploited is considered to be almost zero, it was found by a dev at the ECC (then nicknamed Zcash co.) doing a last minute review before a conference after it had passed multiple audits prior. Quite the year that one must have been for those who knew! The idea for the turnstile existed before the bug however and is somewhat fail-safe (tells if it happened but thats it) so thats what goes on currently and at least one migration tool exists to automate the process for ease. The same thing comes up when we talk about killing sprout altogether e.g. what about the users who still have funds there and so on. In the end we’re trusting the developers. I advocated for continued funding for the ECC to work on Zcash because if they’re not the very best for it then they’re certainly better than most all. Maybe Ethereum doesn’t trust themselves fully to implement it correctly given the possible consequences or their current roadmap (idk anything about that) and maybe that’s not unwise, I certainly don’t mess zero knowledge snark proofs! (Well, I do but I’m not a cryptographer, I just encrypt a lot! And I am noding again btw, yes)

2 Likes
4

thanks for the thoughtful replies. here’s the counterargument (as I understand it):

there are actually two types of inflation bugs:

  1. consensus inflation bugs
  2. zero-knowledge-proof inflation bugs

re: consensus inflation bugs - a consensus inflation bug is actually less likely on zcash because (re: @zooko’s tweet below) zcash requires a zk-proof that asserts the validity of the transaction on top of the consensus protocol that secures account transaction ledger.

re: zero-knowledge-proof inflation bugs - the ECC (then ZCash Co.) patched the 2018 inflation bug in the zk-proof that validated transactions in a deprecated shielded pool (Sprout0. We are several iterations past Sprout’s zk-proof, and the Halo zk-proof will be our “best defense yet” against attacks on zcash’s shielded pool by eliminating the trusted setup.

the bottom line: we can’t guarantee the absence of undetected flaws in a zk-proof (by nature of their being “undetected”). however, this is not a risk specific to L1 protocols that implement privacy; it will affect any L2 protocol that implements zk-proofs (e.g., Aztec, zkSync, Polygon Miden, etc.). in either case, we have to “trust the devs.”

am I getting that right?

5

I can’t speak to the nature of the sprout bug or this question really but your conclusion sounds overly presumptuous given how much emphasis there is on continued development round these parts.

6

presumptuous on which front(s)?

7

No cryptography is guaranteed, even longstanding protocols. That’s why they talk about attack vectors with computation times on the order of universal lifetimes and memory cards the size of the moon, it can be ever approaching but always a non-zero-sum risk. Zkp’s are cutting edge, Zcash is the first practical implementation of them ever. Continued development coincides with audits and reviews and overtly implies people smart enough to do it (:heart: all) . Perhaps Im being nitpicky over word usage because whatever “guarantee” you’re referring to must surely stem from that.

1 Like
8

yes - guarantee may have been a poor choice of word.

rephrasing the intent of my thread w slightly better vocabulary: what are the attack vectors that are unique to zcash vs other crypto assets that deploy zkproofs? (eg the commonly misunderstood “inflation bug”).

to the extent that anyone can comment on this (or the counter arguments i may have mangled), i am grateful.

1 Like
9

I don’t think there is much clarification here. Saying “nothing” is guaranteed is a rather unfortunate way of evading the question being asked.

Risk comes in multiple ways (if you have someone watching you create your keys and passwords–that’s a risk too). In cryptography there is no method that can be proven impossible to crack, but there is a usable concept that one can use to “prove” theoretical security, and that is “infeasibility.” So cryptographic protocols are proven theoretically to a level of “infeasibility.”

Standard cryptographic protocols have that level of security. The problem that Sassano is trying to avoid, counterfitting, does not have that kind of security, nor any known way to reach it either–for now.

It is very reasonable to stay away from risks that could be rather catastrophic to blockchain users.

Z-cash allows blockchain users to prioritize their needs. It might be the case that it is more important to keep some value private, than suffer a catastophic loss due to a counterfit bug/injection. Remember, Z-cash can be used like a regular cryptocurrency as well, so one does not have to have all their currency in a shielded pool. Ethereum doesn’t have that capability in their layer1.

zk-proofs are used to preserve privacy, and they do that well. But the added property, that they also preserve integrity, is not guaranteed, or accurately expressible, in the terms we would like.

That said, there is a way to help yourself assess the risk in a general way, that can alleviate the “blindness” in the choice you face to use or not use a shielded pool.

Some of the best zk researchers are in the cryptocurrency space. Obvious exploits among these experts in pool level integrity–even at the theory level–haven’t been discovered. So what is the likelihood a devious exploiter has more knowledge than they do? High or low? How long would you need to store currency in a shielded pool? Then there’s the question of whether or not a theoretical exploit is feasible in the actual implementation of a zk-protocol. Many security vulnerabilities discovered in cryptographic methods are often very difficult to exploit in practice. Even so, they are often patched, or the protocol retired, before anyone can come up with one. It’s possible that this is also true for zk-protocols. None of this can be used as a security blanket, but it might help you assess, and correctly use the shielded pools for your needs.

1 Like
10

Like I said the turnstile goes on “currently”, the main devs aren’t fans of it and the topic of a privacy-preserving auditing function (unblinded in terms we would like) has been raised but has not been built out yet. Furthermore you’ll have to ask the devs about attack feasibility of the protocol and underlying crypto, I don’t know about that.

“Z-cash allows blockchain users to prioritize their needs. It might be the case that it is more important to keep some value private, than suffer a catastophic loss due to a counterfit bug/injection.”
I don’t understand this.

(“Remember, Z-cash can be used like a regular cryptocurrency as well” Slight edit
“Remember, Z-cash can be used like a regular currency as well” There ya go!)

“Some of the best zk researchers are in the cryptocurrency space.”
No argument there

“So what is the likelihood a devious exploiter has more knowledge than they do? High or low?”
Hard to say, probably still low, maybe even exceedingly so but zkp’s are becoming better understood everyday which again precludes people (deviously) smart enough to feasibly do it, idk. And you’re right, not a security blanket but it goes back to the audits and continued development, it’s really the only practical defense.

1 Like
11

It’s strange that every coin is pumping except Zcash…

Very strange.

Almost makes you wonder…

1 Like
12

all pools with trusted setup should be removed and transferred to transparent pool and again to trust-less pool with turnstile method

3 Likes
13

Do you have a theory as to why? I would like to understand and I simply do not understand.