Is this FUD or legit? On "the untrusted setup" and "fungibility"

[kxra]

http://weuse.cash/2016/10/28/the-untrusted-setup/

http://weuse.cash/2016/06/09/btc-xmr-zcash/

Is the “Sybil zk-proof attack” a real threat?

Are cryptographic ring signatures superior to Zcash’s method?

There is lots of discussion on reddit as well:

r/btc - The Untrusted Setup – Why you shouldn’t trust ZCash

r/btc - On Fungibility, Bitcoin, Monero and why ZCash is a bad idea.

[kek]

if you’re reading a negative piece about zcash, and monero’s positively mentioned - can pretty-much guarantee you it’s FUD.

[zooko]

@kxra

Is the “Sybil zk-proof attack” a real threat?

What is a “Sybil zk-proof attack”?

[kxra]

@GPU_Mining

It is like saying, “what if Apple is evil and all iPhones spy on us?” Or not using busses, because the driver could be a psychopath.

I don’t trust Apple or proprietary software generally, though not exactly for tinfoil-hat paranoia about being personally targeted by surveillance, but also do you really want to claim that Zcash is only as trustworthy as a corporate giant founded by a (brilliant or otherwise) narcissistic megalomaniac? As far as the busdriver goes, this analogy would be more accurate if the bus was also a bank and the driver hid in a box where everyone’s money was stored. I think Zcash aims and claims (and hopefully succeeds) to be much better than that.

@GPU_Mining

I trust @zooko and the guys from Zcash with my time and money. I believe they are good guys and they have their hearts and minds at the right place.

I absolutely do as well, and have appreciated it since as far back as Tahoe-LAFS! I’m not concerned about the intention of the developers, so much as the technical points brought up by these naysayers.

@kek

if you’re reading a negative piece about zcash, and monero’s positively mentioned - can pretty-much guarantee you it’s FUD.

That’s definitely the impression that I’ve gotten, and the look of the website and style of writing would seem to support that. All I have seen though are statements such as the yours, as opposed to any engagement with the particularities of their arguments. It’s entirely possible that their claims have been debunked (and i hope they have) but are just hard to find because the monero shilling brigade has managed to bury them. Links to those things would be great!

As an aside, I vaguely remember hearing something about some coin that made a lot of lofty claims, had a mysterious and shady development team, and ended up being traced back to the monero devs. Does this sound familiar? I’d love to find that.

@zooko

What is a “Sybil zk-proof attack”?

From the link: «Imagine an attacker counterfeiting a lot of fake zk-proofs. This could create the illusion of a liquid mixer. A lot of usage means that suddenly one can hide his transaction in this mixer with a lower (perceived) risk of being tracked. Timestamp analysis attacks become increasingly harder. But the attacker, who knows all the fake zk-proofs, can ignore his own counterfeited liquidity. He is still able to do the timestamp analysys based on the real (low) liquidity inside the zk-mixer. This leads to a very dangerous situation in which the user thinks he is transacting anonymously, but in which an attacker will still be able to track all transactions.»

It all seems to come down to their insistence on ring signatures and stealth addresses:

• «A ring signature is a type of group signature that makes use of your account keys and a number of public keys (also known as outputs) pulled from the blockchain using a triangular distribution method. Over the course of time, past outputs could be used multiple times to form possible signer participants. In a “ring” of possible signers, all ring members are equal and valid. There is no way an outside observer can tell which of the possible signers in a signature group belongs to your account. So, ring signatures ensure that transaction outputs are untraceable. Moreover, there are no fungibility issues with Monero given that every transaction output has plausible deniability (e.g. the network can not tell which outputs are spent or unspent).»
• «They allow and require the sender to create random one-time addresses for every transaction on behalf of the recipient. The recipient can publish just one address, yet have all of his/her incoming payments go to unique addresses on the blockchain, where they cannot be linked back to either the recipient’s published address or any other transactions’ addresses. By using stealth addresses, only the sender and receiver can determine where a payment was sent.»

Their specific concerns with Zcash are:

• They seem to feel the biggest problem is regarding SNARK parameters: «the “trusted setup”, the so called cryptographic “toxic waste” problem.» but Peter Todd’s writeup (which also mentions problems with Equihash Proof-of-Work and Scalability) is much more detailed and sensible, «I’ve had some experts tell me they thought the security level was 2^80 operations (very weak), while others (including Zooko himself) thought it was more like 2^96. I’m not sure which figure is right, but the fact that there’s disagreement is a bad sign.»
• «The fact that transparent transactions are still possible, also makes your OpSec dependant on others: even if you try to anonymize your coins as much as possible, you can still be deanonymized if the people you transact with aren’t using the same standards. It’s even possible you’ll be forced to use transparent transactions if you want to use some kind of (regulated) service. This will result in the same issues as described on a transparent blockchain. Identities will be attached to addresses and this can eventually lead to blacklisting or even miner censorship. The fact that mixing isn’t enforced on ZCash is bad for fungibility and anonymity.»
• «The ZCash extended paper also mentions a theoretical “poison pill attack” (section 6.4). This attack makes it possible to target a single user with the goal of deanonymizing him. It seems this attack is easier to perform when the targeted user uses an anonymous network like Tor.»

[kxra]

@GPU_Mining

@kxra I give you massive points for a truly well written post!

Hahah, thank you. I hoped it would be clear that my intentions are supportive and only seeking knowledge to better inform others as well as hopefully be beneficial to the future of zcash and cryptocoins. If I, having a lot of respect since Tahoe-LAFS, couldn’t find satisfying responses to monero shills, that probably means many more people never took the steps to even look.

@GPU_Mining

I feel skeptical about Monero’s ring signatures. I understand what they are doing, and I do agree that it all seems to be giving a lot of anonymity and security.

I wonder, could ring signatures and stealth addresses be implemented in a future version of Zcash, or would that require a new blockchain?

@GPU_Mining

However,I feel mixing just makes it harder to find out who sent the money.

Do you mean the sender is protected but not the receiver? How?

@GPU_Mining

I often feel that the lack of official tools to support a proper Zcash ecosystem is a sign that for the company this still is sort of a soft launch. I believe once the technology is perfected further, the Zcash company will focus more on wallets and similar tools. And it will be then, I believe, when we will see a true increase in the Zcash value.

Some cool projects looking to implement Zcash:

• OpenBazaar Client (needs to be refiled against Client v2, “Desktop” & Go (Server v2)
• Voluntary.net’s BitMarkets
• I’ve also contacted Uphold and CoinsBank to consider adding their support, Uphold appreciated it but Coinsbank has yet to reply <<>rant> and also unresponsive on problems verifying my because their website requires a last name which is not a legal requirement so some people like myself don’t legally have one <<>/rant>

@GPU_Mining

You wrote you had concerns regarding the mix of t and z addresses. @zooko wrote an interesting post during the last AMA session regarding this topic. Have you read the AMAs?

I haven’t, but would love to.

@GPU_Mining

Going back to the addresses, the plan is to retire t addresses and make the entire Zcash world encrypted. I believe this will happen once the technology is perfected and processing costs has been reduced.

Awesome, would this include private multisig?

Now i’m wondering, which things can/should be improved as Zcash evolves, and which would require a fresh start?

• combining ring signatures with existing methods (a lá monero shills)
• combining stealth addresses with existing methods (again)
• equihash pow problems (peter todd)
• scalability (peter todd)
• SNARK parameters, aka trusted setup’s “toxic waste” (peter todd and monero shills)
• mix of t and z addresses (already planned to drop transparent ones! awesome)
• poison pill attack?

[anon]

@kxra You make some highly valid pros and cons for both currencies.
IMO monero has had more time to mature, along with receiving hat tips by some of the well respected pioneers in the cryptosphere covering its unique valued features (todd, maxwell, lee), has gone through the process of purging toxic parties from development early on, is focusing on pure darknet integration with i2p which has a larger anonymity pool than that of tor as all users of the network are routers and team X are genuinely sincere and up front about their intentions; you’re warned against investing, focus on code > pr.
On the other hand, zcash is the first significant application with zero knowledge proofs and only a few have a complete understanding as to how they work in theory; I trust team Z, but would prefer if comprehension was universal and more outside audits were present.
Its still early considering we haven’t even hit the 1 yr mark since 1.0.0, the ratio of t to z addresses is still no where near where it ought to be and mem resources for making shielded TX is still too large to process on the latest mobile platforms.

With the above outlined doesn’t mean long xmr/short zec, quite the contrary.
Instead I’m holding out and believe that once those kinks have been worked out, zcash and its cousin zclassic could be serious contenders when it comes to fungibility.

In the meantime, for the cautious ones, btc → taddr (ss) → zaddr → xmr (ss) → xmr → btc (xt) shall suffice.

ss = shapeshift
xt = xmrto

[zooko]

If you — as fast as possible — move 1.23456789 BTC through any other systems and back to yourself, then an attacker (e.g. a thief who is cyber-stalking you in order to rob you) will probably be able to easily deduce what you just did, just by looking at the amount of BTC and the timings of the transactions on the Bitcoin blockchain. This is regardless of how good the other systems are at breaking linkability.

[anon]

I should have explained the process a little further, thanks for bringing up this scenario.
The bitcoin is bought via an exchange, lbtc, with gift cards.
Each part of the order process is given a delay pulled from a pool of shuffled floats with a set range of 3 to 24 hours; this is more than enough to obfuscate who transferred what at said given time - bonus points for generating a randomized fee array for each asset and assigning to each transaction for further mitigation efforts!
Interactions are done directly with the shapeshift, xmr.to and exchange (optional) APIs.
The user can either choose to stay in xmr and make their transfers over either of those channels, or they can transfer their entire stake over to bitcoin.
They can also repeat the first and second process, hold in zec and use ss
Transferring their entire stake to bitcoin should be warned against, seeing as each given transaction sent (depending on amount held and whether the addresses are one time/constant) would help our good eve and friends when it comes to analyzing the transparent blockchain and profiling alice.

[zooko]

@kxra

As an aside, I vaguely remember hearing something about some coin that made a lot of lofty claims, had a mysterious and shady development team, and ended up being traced back to the monero devs. Does this sound familiar? I’d love to find that.

Nope, never heard of that.

@kxra

Imagine an attacker counterfeiting a lot of fake zk-proofs. This could create the illusion of a liquid mixer.

Erm. I’m not sure that would even be a problem. The ZK approach really has different privacy consequences than “Chaumian mix”-style approaches, and this might be one of those cases where your intuitions about such things, informed by traditional Chaumian mixes, just don’t apply to ZK privacy.

@kxra

I’ve had some experts tell me they thought the security level was 2^80 operations (very weak), while others (including Zooko himself) thought it was more like 2^96.

Now I think it is 2^128, except that a brand new science result just came out yesterday that throws it into question again. [Corrected by @daira.]

@kxra

The fact that mixing isn’t enforced on ZCash is bad for fungibility and anonymity.

Basically agree.

@kxra

• combining ring signatures with existing methods (a lá monero shills)

Don’t understand the point. AFAIK ZK privacy is great and can’t be improved by adding ring sigs.

(BTW let’s practice Benefit of the Doubt / Principle of Charity and instead of attributing this to “shills”, attribute it to well-meaning Monero fans who have sincere and well-justified concerns.)

@kxra

• combining stealth addresses with existing methods (again)

We basically already have stealth addresses — all shielded addresses (z-addrs) work like that.

@kxra

• equihash pow problems (peter todd)

I don’t see the problem.

@kxra

• scalability (peter todd)

Yes! I have a lot of thoughts about scalability. Fortunately there is a lot of active research going on into this topic that we can draw from.

@kxra

• SNARK parameters, aka trusted setup’s “toxic waste” (peter todd and monero shills)

I consider this a problem. I am not satisfied with the current assurance (even though, as a first-hand observer/participant, I can have a level of assurance that most other people can’t that the precursors were well and truly destroyed before they ever had a chance to form the toxic waste).

@kxra

• mix of t and z addresses (already planned to drop transparent ones! awesome)

Yeah!

@kxra

• poison pill attack?

I don’t remember or never learned this.

[indolering]

@zooko

Now I think it is 2^128, except that a brand new science result just came out yesterday that throws it into question again.

Odd that you didn’t choose a 196 curve given the newness of the crypto, was the performance hit severe?

@zooko

@kxra

combining ring signatures with existing methods (a lá monero shills)

Don’t understand the point. AFAIK ZK privacy is great and can’t be improved by adding ring sigs.

I think @kxra is suggesting obfuscation of the “transparent” chain.

[Voluntary]

@zooko

(BTW let’s practice Benefit of the Doubt / Principle of Charity and instead of attributing this to “shills”, attribute it to well-meaning Monero fans who have sincere and well-justified concerns.)

With a side of tongue-in-cheek.

[zooko]

@indolering

Odd that you didn’t choose a 196 curve given the newness of the crypto, was the performance hit severe?

The curve was chosen by the authors of the Zerocash paper. According to the Zerocash paper they used BCTV-2014, which says they got it from PGHR-2013, which says they chose a 256-bit BN curve (from BN-2006) in order to achieve 128-bit security.

FWIW I probably would have done likewise. The performance hit is a significant issue here, because of the performance problem with generating proofs, and so far (11 years on) nobody has actually shown that BN-128 is weaker than 128-bits as far as I understand (which isn’t far). In any case, even if the alleged attacks can crack BN-128 as cheaply as they claim, then what they are claiming is 100 bits, which is still safe enough in my opinion.

(Safe enough, that is, considering that we are already working on upgrading to better crypto that includes a stronger curve.)

@indolering

I think @kxra is suggesting obfuscation of the “transparent” chain.

Oh, well that’s an interesting idea that I hadn’t previously considered. It seems like we should focus our finite engineering researches on upgrading everyone to all-Z-addresses-all-the-time.

[indolering]

@zooko

FWIW I probably would have done likewise. The performance hit is a significant issue here, because of the performance problem with generating proofs, and so far (11 years on) nobody has actually shown that BN-128 is weaker than 128-bits as far as I understand (which isn’t far). In any case, even if the alleged attacks can crack BN-128 as cheaply as they claim, then what they are claiming is 100 bits, which is still safe enough in my opinion.

(Safe enough, that is, considering that we are already working on upgrading to better crypto that includes a stronger curve.)

Yeah, the magical “128 bits” gives engineers plenty of margin. It’s just a stylistic choice really, I like starting with a 2x safety margin and then optimizing for efficiency later on.

@zooko

Oh, well that’s an interesting idea that I hadn’t previously considered. It seems like we should focus our finite engineering researches on upgrading everyone to all-Z-addresses-all-the-time.

There are always trade-offs, but if there are obfuscation mechanisms that can easily be ported over… Hiding the total value of transactions, for example, would make it significantly harder to correlate inputs and outputs between the shielded and unshielded transaction sets. Of course, I don’t think that could work with zk-SNARKS so ¯_(ツ)_/¯.

Edit: I don’t know how you could exchange z-coins for t-coins without revealing the value.