Interesting summary, but I have a couple of criticisms.
1. "Monero relies on obfuscation not encryption". This is a wrong characterisation. I know where it's coming from: a ring sig over N parties still allows you to distinguish those N parties. But it's imo wrong to count that as "obfuscation only". But it's tricky to explain why, I'll try. A ring signature of this type can be (and is) information-theoretically hiding, i.e. perfectly hiding, as to the real signer ..
Meanwhile, there is some information still present on the blockchain - basically, the tx graph. So I think the best analogy would be a message where some is in plaintext, and some info is blanked out (but can only be one of N possible texts). My point is that which of the N is cryptographically indistinguishable, so "obfuscation not encryption" is imo wrong.
A good example of obfuscation in this area would be a coinjoin with unequal sizes but a 1000 inputs and outputs, so that it's hard ...
computationally, but not impossible, to disentangle.
Meanwhile say zcash can be seen as better, because it "blanks out" the entire message (the whole tx graph), but that's not an encryption vs obfuscation difference, really, and ofc it's biggest weakness today is very low anonymity set (while Monero is hardly huge!).
Hence 2/ Disagree with his final conclusion that zcash is best option, today it fairly clearly isn't.
Oh and on the "obfuscation" question, I forgot to mention: in this context coinjoin is much like ring signatures - except there's no actual cryptography involved if you use equal sized amounts, then the N "things" (outputs/utxos/identities) are just intrinsically indistinguishable.
But I suppose the exact defn of "obfuscation" is debatable.
To me obfuscation is something that *can* be unwound, I guess that's my main point.
Small follow-up: Greg Maxwell just corrected me on a point I made in this thread: Monero's ring sig is not information theoretically hiding.
The ring sig itself is, but the whole algorithm is a ring sig PLUS a commitment to your key, to prevent double spending. The commitment is perfectly binding (it's x *hash-to-point(P), P is your pubkey, x is your private key) and, (as I explained in 2.3.2 here: https://github.com/AdamISZ/from0k2bp/blob/master/from0k2bp.pdf) you can't have perfect hiding and binding. It's interesting to think ...
... about why that commitment to your public key, the thing that prevents double spending, called the "key image", can't be perfectly hiding *instead* of perfectly binding, which is what you get for the bog-standard Pedersen commitment (like xG + aH or similar).
@waxwing This is really good. Thanks for posting. I'm glad to see this paper.
Just to note (it's on the README but I didn't link to that) that github's embedded reader doesn't display the equations properly, so download the pdf if you want to read it :)
@waxwing already did :)
@waxwing Zcash also has the initial lambda "trusted" setup issue.
btw, have you dug into the latest on the mimblewimble implementations, grin and beam?
Yeah the trusted setup is an issue, of course it was ameliorated somewhat in the recent updated with distributed generation, also there's zkstarks in future with different tradeoffs, etc. More fundamental potential issue around unscalability of blockchains without the ability to prune a txo set (by definition, if you don't know when a txo is spent). XMR has same problem there.
I know a bit, not much, about MW, wrote a CT explainer doc too btw.
Very complex and difficult area.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!