5 ms·

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 o

by kobeya 9y ago

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.

q-base 9y ago
Could you elaborate on this flaw, or perhaps point to a link - especially with regards to Monero?
- dangero 9y ago
  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.
- kobeya 9y ago
  Here's a stack exchange question: https://monero.stackexchange.com/questions/2158/what-is-moneros-mechanism-for-defending-against-a-double-spend-attack https://monero.stackexchange.com/questions/2158/what-is-mone... 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....
  - q-base 9y ago
    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 :)
    - kobeya 9y ago
      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.
      - q-base 9y ago
        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 :)
  - sowithit 9y ago
    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?
    - kobeya 9y ago
      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...

by kobeya 9y ago

q-base 9y ago

Could you elaborate on this flaw, or perhaps point to a link - especially with regards to Monero?

dangero 9y ago
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.
kobeya 9y ago
Here's a stack exchange question: https://monero.stackexchange.com/questions/2158/what-is-moneros-mechanism-for-defending-against-a-double-spend-attack https://monero.stackexchange.com/questions/2158/what-is-mone... 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....
- q-base 9y ago
  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 :)
  - kobeya 9y ago
    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.
    - q-base 9y ago
      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 :)
- sowithit 9y ago
  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?
  - kobeya 9y ago
    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...