Would appreciate if you named any specific advances off. I'm guessing bulletproofs, but not real sure, and the whole space is pretty murky to me still.

Bullet proofs is ancient zero knowledge tech. There was an insane amount of improvement with generalized zk proof systems, recursive proofs, reduced trust assumptions, more efficient circuit construction etc. Maybe the best outcome of the shitcoin era is the reallocation of capital from meme chasers to cryptographers.

Thanks! Generating the proof seems like a low price to pay. Especially if it’s (as you mentioned) just a couple of seconds. But transmitting and validating proofs would both increase the cost of operating a node. So perhaps you could say that with Bitcoin the risk is that an attacker can exploit the lack of privacy to make it unreasonably difficult for most people to adopt it as a currency. Whereas with privacy focused currencies the risk lies in the lack of decentralisation - too many users might put of convenience outsource their voting rights. Am I onto something? Also, would similar L2 solutions to those of Bitcoin work on top of privacy coins? Or might the inherent lack of information be a hurdle? Appreciate all your articles and thinking!

By now there are recursive proofs, and the blockchain could be a static size (couple KB) proof. So all you need for IBD is to download that tiny proof and run a quick validation, and that's equivalent to downloading and verifying the entire blockchain at the moment. So a smartly designed proof can be way smaller than raw transactions. Zcash doesn't have these recursive proofs, and thus it suffered a massive transaction spam attack that made mobile wallets unusable, and all these transactions cost like 10k$ in fees or something like that. It depends on the details of the base layer if it can support other layers. Monero for example can't support something like lightning network because it has no scripting. But darkfi is Turing complete, so that can do basically any second layer scheme.

Meh, that's mostly a mischaracterization I think. Bulletproofs as originally conceived was a valuable addition to the mix; it didn't have succinct verification so it couldn't *directly* compete with Groth16 and other pairing based schemes but it did have: no trusted setup and no assumptions outside of ECDLP. The other option was STARKs but the proof sizes were large. The verification scaling being bad was addressed in HALO and HALO2 with some rather clever tweaks, keeping the no-trusted-setup property while getting succinct verification. So nowadays it's a general class of algorithms see "folding schemes", "inner product arguments" and those can be flavours of zkSNARK; bulletproofs literally purely as originally written, yes, is rarely used, although perhaps occasionally still finds a use - an example is Curve Trees, which you mention. But it's also a paradigm which continues to be used in more sophisticated forms. Perhaps a confusion here is you were thinking about 'bulletproofs for confidential transactions via range proofs' (still used in Monero) as opposed to 'bulletproofs as a general ZKP system' (which was in the original paper).

As always a lot of great insight, Thanks!

Got to disagree here, it's one of the more profound questions in the space that @npub1t2pv...f3f7 is raising: "but how does ZKP usage affect auditability". See, there's a trite response: addition holding under a homomorphism still means addition holding (think like "well, the ZKP proves that new coins weren't minted, so just because you can't read the balance directly doesn't mean it isn't guaranteed to be fixed supply!"). But in a profound way this is not a good analysis: we don't only consider correctness, we consider recovery modes under incorrectness: *whatever* reason for random new bitcoin getting minted, we will see it in the utxo count (gettxoutsetinfo rpc); obviously it would be a bug, but we'd see it. in zcash it was warned in advance (by people like Peter Todd especially, but also I and others raised this alarm) that you don't have that counting function, so if *any part of the stack* fails, you will not know. That problem cross applies to *any* property you want a public blockchain to have, that if you cover it with ZK you need to be 100% sure there is no error, and you cannot be. None of this is some kind of checkmate atheists, never use ZKP, but it should be food for very serious thought. My way of putting this years ago is that "it's in the DNA of blockchains to be public". This is why I've always been focused on ZK for second layers.