Is it just me or are more and more stories which look like fluff pieces for ZCash coming up on the HN frontpage? If they were a startup, I'd guess they were prepping for an IPO/acquisition. Most of them have titles with rhetorical questions, and come across as marketing pieces more than anything else.
I actually found it interesting to read Zooko's opinions about the market opportunity (namely, replacing fiat currencies in countries where they are unstable) and why governments might not hate Zcash (namely, because transactions can contain identifying information as they are encrypted). I don't actually agree with him, and I question if he truly believes those answers, but I was interested to read his public opinions.
For the record, someone who gives an interview to a journalist almost never gets a say over what headline it gets published under. Did you read the article? I really liked the way it came out!
Also for the record, we didn't ask Assange or Snowden to start accepting donations in Zcash or anything. Or at least, I didn't. It's quite possible some other members of the Zcash community did without my knowledge.
[New account because I can't remember my password and when I ask it to the reset the password on zooko-zcash it says "sorry there is no valid email address associated with that account". Maybe it thinks "zooko@z.cash" is not a valid email address.]
The unfortunate thing to me about Zcash is that privacy is opt-in. It would be like if Signal was default no privacy, but then you could enable it per message if you wanted to send something secret. Governments could just ban you from turning the privacy on and we've already seen this happen with TOR. Opting into privacy "raises suspicion", and we need services where privacy is enabled by default. Monero does this.
you can interpret this as a problem and as a solution too. Yes, ztransactions will could dye your money so no exchange will accept it because you are a terrorist and the US can ban the usage of ztransactions.
In my opinion it's better like this, since the overall goal is to not rely on exchanges and regulatory thirdparties. In a P2P economy (which is this technology is meant to lead us) fungibility problems are not a thing beacuse there is no relative central party to make a standard.
> In a P2P economy (which is this technology is meant to lead us) fungibility problems are not a thing beacuse there is no relative central party to make a standard.
wat?
fungibility is not about a standard. fungibility applies at every level.
"Hrmmm yes while you are looking at this car here I'm just going to scan your blockchain activity and hrmmmmm it seems that you are in about the top 30% of income in this country so yessss the price of this car is X"
boom. That car salesman just defacto made your tracecoin less valuable than some poor shmuck in the lower 50%.
If collusion was suggested by one or more of the people present in the setup it would be quite likely that another one would have come out and said something about it. This would have made zcash and the person itself very untrustworthy. This makes it likely that it wasn't worth the risk to the person thinking of collusion in the first place.
Erm, #1 is not that far from being achieved. IIRC, that's just 6 people, guarding hundreds of millions of dollars.
There lies the inherent problem with "trusted setup", why leave there a possibility of 6 people not colluding? That just isn't scientific or exhuastive. Just drop the IFs, go with Monero's method of RingCT.
Beside, Monero's privacy is a working feature today, with no pre-mines, unlike ZCash.
It is not down to 6 people forever not colluding. It's down to 6 people not having colluded at one point in time in the past, each having been scrutinized during the procedure, with post-hoc inspection of the software and hardware. If those 6 people decided at any point after the procedure that they wanted to collude, then it would be too late for them to do so.
Essentially they each produced a private key, and if each of them revealed their private key to the same party then that party could derive a master private key that would allow them to (among other things) mint Zcash for free (privacy wouldn't be broken). Assuming that any one of the 6 did in fact destroy/corrupt his private key without revealing it, then the collusion opportunity is forever lost.
I'd suggest you read my "Cypherpunk Desert Bus" article a little more closely, notably section 1.2 where I say:
"Until the software and deterministic builds are audited, the entire ceremony is a bunch of crypto hocus pocus that means nothing."
The trusted setup is really dubious and highly vulnerable; so far my efforts were wasted due to the fundamental problems that everyone in the multi-party-computation ran the exact same unaudited software.
The trusted setup is not necessarily an issue in practice, but it's something that Bitcoin was explicitly created to avoid and that makes it rather absurd to describe Zcash as "Satoshi's vision". Arguably it has as much or more in common with the older pre-Bitcoin cryptocurrencies than with Bitcoin.
Honest question: what about the potential of someone kidnapping two or more of these people and forcing them to give up their keys? What would the consequence of that be?
My understanding is that you would have to believe that they were kidnapped or otherwise under duress at the time that they did the trusted setup, which was on video.
The trusted information (supposedly) can't be given up now because nobody has it: it was ceremonially destroyed in interesting ways.
Mimblewimble doesn't provide very strong privacy protections. Indeed, to a first approximation all it hides is transaction value. The aggregatable transactions only provide privacy if you assume they are generated, fully formed from nothing. Which isn't true. If they are passed around the network and things are aggregated in, than anyone observing the networking will see exactly what went in and what didn't. IF you pass them to a trusted party, well then you have a centralized party you trust for privacy.
You have a choice: use a trusted party (obviously bad) or pass around partial aggregates and have someone add on to them ( this is the standard proposal). Problem is, you can trivially attach to almost every full node and observe those transactions as they get broadcast around. Its not NSA level attacks, I know at least 2 blockchain analysis companies that do this in Bitcoin today.
So, against that attacker, which already exists and is live today, mimblewimble seeming provides almost no privacy.
Everything in a MimbleWimble chain, and even at the transaction broadcast level, look like sorted sets of uniformly random curve points. There are no amounts as you point out, but there are no addresses either.
If Alice gives you a coin and then you spend it to Bob, what stops Alice and Bob from identifying that they delt with the same person? This isn't an issue of addresses or values, but the transaction graph. The only thing that hides that in mimblewimble is aggregate transactions. But again, they don't hide it if you see them assembled. To such an attacker , the transaction graph is entirely intact.
The transaction graph (apart from private aggregation) is intact to an attacker who has seen all transactions being broadcast, but can then only relate outputs that they themselves have been involved in (like Alice and Bob in your example) to real world identities. This is the great advantage of having no addresses.
This is a cool project. Thanks for sharing the link. I'll totally buy/mine some GRIN when it comes out.
Things I like so far:
1) Solves privacy and scaling in a single elegant stroke.
2) Inventors seem to be anonymous. I didn't try too hard to identify them but Tom Elvis Jedusor is the French name of Lord Voldemort. This is an important feature for privacy focused coins and for cryptocurrency as a political statement (not just as a technology).
3) The website, by eschewing flashy web2.0 design and and buzzwords, clearly sets itself apart from the typical "lets get rich quick" coin. Although I am disappointed the white paper isn't done in LaTeX.
Reasons I'm skeptical (perhaps you can address these):
1) Missed the boat on first mover advantage. Monero seems to solve the privacy problem good enough. Perhaps it is unreasonable to expect people to completely swap over to a new coin whenever there's an advance in tech. Especially when word of the new coin has to spread through grass roots instead of a centralized mechanism.
2) Elliptic curve crypto is vulnerable to quantum computers. IMO this is a ticking time bomb.
3) Expanding on point 2, bitcoin intentionally made a habit of layering "proven" crypto methods on top of each other. Eg both SHA256 and RIPEMD160 hash functions are used so that if a weakness is found in one hash the other is still ok. So far as I can tell mimblewimble has a single point of failure (elliptic curve cryptography).
> Reasons I'm skeptical (perhaps you can address these):
1) Monero may have first mover advantage in the privacy realm, but at the cost of prunability. Grin not only avoids that cost but further improves prunability beyond bitcoin. To me the first mover advantage will always belong to bitcoin, which will likely adopt privacy improving features in the long term.
2+3) Indeed; when evidence appears of quantum computers becoming feasible at breaking EC crypto, current blockchains will need to adopt post-quantum crypto methods of signing transactions, and migrate existing balances. Since EC crypto is more heavily ingrained into Grin, it may have a much harder time than the more modular bitcoin design, or even find it impossible to do so. I'm not aware of any post-quantum equivalent to Pedersen commitments.
My hope is that quantum computer development runs into insurmountable barriers...
>current blockchains will need to adopt post-quantum crypto methods of signing transactions, and migrate existing balances.
That's sort of true. Bitcoin is mostly quantum safe. The only vulnerability is that a quantum computer could deduce a private key and change a transaction during the brief (~1 hour) window when the transaction is pending. Quantum computers would have get to ~660*10^6 quantum gates per second before this becomes feasible (roughly a clock cycle of 660 MHz in classical terms). The first quantum computers will likely be slower than this.
The bitcoin ledger itself is quantum safe because addresses are hashes of public keys rather than just naked public keys. QC won't significantly speed up hash inversion thus a QC won't be able to steal funds out of an arbitrary address.
This is what I mean by bitcoin "layering the crypto" so as not to have a single point of failure. Sure bitcoin could have just used public keys as addresses. Instead it choose to use hash's of keys seemingly for no reason. Some of the facets of Satoshi's design are so genius that we only learn their purpose years later.
>My hope is that quantum computer development runs into insurmountable barriers...
ehhh maybe the GRIN devs should think about this now rather than later.
> The bitcoin ledger itself is quantum safe because addresses are hashes of public keys rather than just naked public keys.
This is true of later addresses, but in early times, addresses were naked public keys, and tons of bitcoins are thus vulnerable to slow quantum computers.
I could have sworn that hashing the pub key was all the way back in the whitepaper. In any case are any "naked pub key" coins still left unspent? I'd reckon that if they are actively owned by someone than that person can forward to a secure address when QC becomes practical and if they are "lost" then who cares if someone with a QC comes and claims them?
I really don't like the reliance on the Ceremony to prevent counterfeiting, but it is the only way science has yet discovered for how to enable full-strength (encryption-based) privacy. Fortunately, science continues to advance and I hope we'll be able to upgrade to a trapdoor-free cryptographic proof system someday.
The other issue with zcash is an ever growing double-spend list. Monero also suffers this flaw, unfortunately. If either one scaled up to just bitcoin's level of activity, there'd be severe problems.
Mimblewimble is far more likely to be a lasting privacy gain since the technology it is built upon, Blockstream's confidential transactions, has properties more like Bitcoin's in this regard, and perhaps even better as you can sync from a partially-pruned history.
Yes, I'm pretty sure that neither Zcash or Monero allow double-spends. Wondering what the context of that statement could possibly be. Any successful cryptocurrency must solve the double-spend problem or there's no value in the ledger at all.
TL;DR Monero requires every transaction input to include a "key image" (an elliptic curve point, looks like a public key). The key image is deterministically constructed from the actual coin being spent, without actually revealing which one it is. So making sure the chain never contains a repeated key image is sufficient to make sure that no coin is ever spent more than once, without actually knowing whether any one specific coin is spent. This is how Monero achieves its inflation/non-cloning guarantee.
(There was a famous double-spending bug in CryptoNote protocols you might have heard about that resulted in limitless inflation. This was because the Ed25519 signature scheme used has a co-factor of 8, a stupid performance "enhancement" that DJB should really re-think. As a result, a given key-image had a 1-in-8 chance of being malleable by adding a point of order 8. It's fixed by checking that the key image is actually contained in the group. These sorts of unexpected consequences are why serious cryptographers don't use co-factors other than 1, or other fiddly tricks that get you small constant implementation gains with risky not well studied trade-offs. This is also why the current push to standardize on DJB designed crypto solutions is borderline insanity. But I digress.)
The mathematics of what zerocash does is wildly different, but it serves essentially the same purpose. Each private/anonymous spend in zerocash has some bits associated with it that are generated in a non-linking way from the input being spent. As long as there are never two transactions in the entire block chain history with the same value for this field, there are no double-spends.
-----
The problem is that these can never go away. In bitcoin if a coin is spent, you can prune knowledge of that coin from your local history. This is what the "-prune" option does in recent versions of Bitcoin Core. You still need to receive and process the transaction once when you sync the chain, but you can then throw it away if you are space constrained. Mimblewimble potentially improves the situation even better by boiling down each transaction to just a single EC point, the script kernel, such that a client needs only the current UTXO set and the full history of all these kernels to do initial sync. The rest of the data can well and truly be forgotten. But although those kernels are needed for initial sync, pruning nodes can throw them away afterwards. They are not needed for the validation of future blocks in any way.
TL;DR: The amount of data a verifier needs to keep around to validate a new block in bitcoin depends only on the number of unspent outputs. The full block chain is only needed for initial sync. This is asymptotically O(current size of bitcoin ecosystem). The amount of data needed by Monero or Zerocash, on the other hand, is (a constant factor of) the entire block chain used by these systems. This is asymptotically O(every transaction ever). Monero and ZCash are chugging along now, but every single block found increases the amount of data a verifier needs to keep around. That doesn't scale....
Very good summary of the issue. This is actually a solveable problem. You use a tree of spent serial numbers and non-membership proofs. This basically eliminates the over head to the network of managing serial numbers and checking for double spends. However, it requires they be stored somewhere because some of that data is needed to make non-membership proofs and update the tree. To further reduce it, keep separate serial number data structures per some long epoch and reveal which epoch a coin was create in on spending. Now the burden epochs is only one people with coins in that epoch. For most reasonable scales, epochs can be very very long. Like 10 years.
As an aside, the fact that mimbelwimble does not have this issue should make you wonder just how much privacy it provides.
That doesn’t solve the issue. It just pushes the responsibility of holding all this data onto the signer instead of the validator, which is a free choice. But signers are usually more space constrained than validators.
And there is no connection between privacy guarantees and this issue. I’m not sure what you’re getting at there.
It not holding all the data though. Anyone with old coins has to hold at most 2kb of data. They do have to occasionally (think every 1 to 5 years) scan all spends from that epoch to update that data or get someone to do that on their behalf. But it really does reduce the work.
As to mimblewimble: yes, there is a connection. You are trying to prune provably spent things. But to do that, you must know what was spent. Which means, if I spend a coin with you in Mimblewimble, the set of possible coins it could be is orders of magnitude smaller than the set of coins it could be in zcash or even Monero. Because these don't prune.
How do you "scan all spends from that epoch" with having those spends ("the data")?
You essentialy just said: "It's not holding all the data though, you just have to have all the data." ...?
As I pointed out elsewhere in this thread (see cousin comments) relying an an external 3rd party archival service doesn't solve the issue because either (a) you want the system decentralized so it needs to be within the signer's capability to run such a service, or (b) you don't do that and now you've introduced central points of failure and then what's the point?
So the model is as follows: This network holds the last n blocks (where n is something on the order of months or years.). Spending coins within that time period is unchanged. For every coin outside of those n blocks, the user must hold about 2kb of data per coin. Every n blocks, they must scan the last n blocks before those blocks are discarded to update their state OR rely on a third party archiving service. So if n = 1 year, then oncee a year you must connect to the network and either download the years worth serial numbers from coins outside the current epoch (note that this is much smaller than the years blockchain) or just have a node scan on your behalf given your data.. If you wait longer than a year, then you are out of luck unless you find a copy.
So users must scan the entire block chain to maintain their balance. Note that this is a stronger requirement than bitcoin has! A similar amount of data needs to be synced for on bitcoin to see if the inputs were spent, but not to make a transaction. That's the key difference. There are many applications where it makes sense to have a wallet make spends while checking block data only when it is expecting a confirmation, e.g. because its keys are HSM protected. Vending machines, for example.
Bitcoin has about 2-4k inputs per block. Let's say 3k inputs every 600 seconds. A key image size depends on the crypto being used. A super conservative lower bound on size is 256 bits per key image -- smaller than either Monero or Zcash, I believe -- as general information theory says anything less than that cannot provide 128 bits of security. That's 4GB/yr or 330MB/mo. And again, that's a minimum -- Zcash for example is 9x this number as a theoretical minimum, larger when you add protocol and serialization overhead.
That's a lot of data to suck down a pay-as-you-use-it IoT 3G connection. And that's just at bitcoin's pre-segwit average usage, not even what segwit can do or levels people think bitcoin should eventually be scaled up to. However much bitcoin capacity limits are raised in the future will directly scale up these numbers.
> rely on a third party archiving service
This is not a solution. If you allow scaling to such a degree that third party archiving services are required, then you've centralized the network. Why even use a block chain at that point?
The assumption isn't that the entire blockchain is stored forever, its that users who keep year old coins can 1) receive blocks (either as they are created, or in some batched process where the batch size could be as large as you like up to e.g. 1 year) and 2) store 2k of state per coin. This is weaker assumption than that of a full node in Bitcoin (which stores the entire blockchain)but obviously stronger than an SPV client which doesn't receive blocks.
And remember, this only happens for really old coins. The data from looking at Monero's anonymous Tx's (recall there was a bug that leaked spending history) is that coins are typically spent with in a week. Not just does this mean few users will pay this cost, but the cost will actually be smaller. You don't need the entire block to update the non-memership proof for a given epoch, you only need all the serial numbers from that epoch that were in that block. Thats likely a small fraction of transactions. Zcash serial numbers are 256 bits by the way.
Yes, its a cost. But it is the price you pay for strong privacy. If you can prune transactions, its because you know their outputs have been spent. Which means those outputs don't contribute to your anonymity set.
Doesn't it scale? Isn't it the case that the Merkle tree holding all the shielded coins can be pruned just as easily as the Merkle tree storing Bitcoin transactions? Pruning either tree eliminates the information needed to verify the claimed owner of a coin in a pruned branch, correct?
You can’t get rid of the requirement that this data be kept around. Either you implicitly have the validators keep it, which is what I assumed for simplicity, or you have the spender provide a Merkle proof, the generation of which requires access to that data set that scaled linearly with the entire block chain history. On the face of it this is a bad trade off because signers often need to be low power mobile or tamper resistant devices with limited bandwidth, whereas full validation nodes have access to high powered servers on low latency networks. A middle ground is to have a third party archivist maintain these records and provide proofs for a fee. That’s fine until running one of these becomes beyond the reach of individuals or scrappy organizations, as them you’ve introduced de facto centralized gateways.
This Merkle tree commitment approach is basically what zerocoin and zcash do — except with fancy zero knowledge proofs to achieve full cryptographic anonymity. But to make those proofs you still need the data...
Thank you very, very much for that long and thorough answer. I need to read it through more thoroughly when I return from work. But sounds like I may need to re-think my holdings of Monero :)
Mimblewimble used properly gets nearly the same benefits that you have in Monero (essentially non interactive coinjoin) but with scaling guarantees better than bitcoin. If it was possible to ring signatures like Monero has without the scaling difficulties, I guarantee you bitcoin developers would be working on it. Friends don’t let friends invest alt coins.
Thanks a lot once more! I need to read that Mimblewimble white paper.
Haha yeah the last sentence came a bit late as I have lost some money on Monero. I may just hold them until they perhaps gets even and then sell. Just liked the philosophy and idea behind. But thanks anyway :)
I think the fact that there is no Satoshi means that 1. his/her/their vision is up for grabs and 2. whoever did create Bitcoin didn't want people continuously asking him/her/them what their vision for this is. It hasn't even been 10 years, why are we already arguing over catechism?
My guess is that Satoshi's vision wasn't that Bitcoin would start a frenzy of "blockchain technology" endeavors that feature the movement of capital to promoters and investors, and between speculators.
There's evidence the vision didn't include investors and speculators. The "generate coins" button in the old GUI depends on their absence. Even GPU mining made that button obsolete.
No. Absolutely no. Satoshi didn't envision a corporation pulling strings behind the scenes just in case some bad guys might use it some day down the line.
Not that I have experience in the matter, but I have heard that spending bolivar in Venezuela means waiting in long lines for goods with artificial prices, whereas you can buy whatever you want in USD.
I suspect that the bolivar/BTC trade is just a feel-good story, and the reality is that Bitcoin is not available to ordinary Venezuelans.
Correct. 20% of block rewards before the first halving (roughly the first 4 years, accounting for half of the eventual Zcash supply) goes to the "Founders Fund" for investors and developers.
Really weird.