5 ms·

You are completely right, I hadn't considered that. This is what Zcash has to say about it: Since the value sent between shielded addresses is private, how can

by josu 10y ago

You are completely right, I hadn't considered that. This is what Zcash has to say about it: Since the value sent between shielded addresses is private, how can we determine the number ZEC in circulation? Currently, we know that every miner validates every transaction, and each transaction comes with a zero-knowledge proof that it doesn't violate conservation-of-money (i.e. a proof that the money coming out of the transaction is ≤ the money going into the transaction). This reasoning depends on the soundness of the zero-knowledge proofs. If someone could get the miners to accept a transaction that created new money — if you could somehow forge a zero-knowledge proof or defeat the zero-knowledge-proof-verifier software in the miners — then you could counterfeit money. We are investigating options for the future which would enable accounting for all ZEC in existance(sic). Stay tuned to our blog for any proposals on this matter. https://z.cash/support/faq.html https://z.cash/support/faq.html

jackgavigan 10y ago
This type of challenge is implicit in any cryptocurrency with strong confidentiality (i.e. which conceals the amount being transferred from public view) unless you trust the "inputs-equal-outputs" proving mechanism (which, in Zcash's case, is the zk-SNARK that accompanies a shielded transaction). One potential solution is to periodically require that all coins be unshielded (i.e. sent to a t-address) and passed through a turnstile mechanism (thus allowing them to be counted). After a reasonable amount of time, a new consensus rule kicks in that prevents coins from being spent unless/until they've been put through the turnstile. That would effectively allow for a full audit of the monetary base without compromising privacy.
- kobeya 10y ago
  What? This is totally incorrect. It is perfectly possible to build systems that verify total issuance while concealing amounts. Blockstream's Confidential Transactions does this, for example.
  - jackgavigan 10y ago
    So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?
    - tromp 10y ago
      As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes. For which bitcoin has some billion dollar in bounties:-)
      - daira 10y ago
        The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)
        kobeya 10y ago
        The CRYPTO relies only on ECDLP. That word, as it is usually used as a term of art, indicates the underlying mathematical assumptions. to say "it does not only rely on ECDLP" is to indicate that there are other trusted mathematical security assumptions, such as harness of EC pairing or the knapsack problem. This is not the case with confidential transactions, whose Pedersen commitments and Back-Maxwell rangeproofs rely on the exact same cryptographic assumptions as any bitcoin signature. It even uses the same library to create and check these commitments, with a minimal amount of new code. Is there scope for new implementation errors? Yes, but only in the fully generic sense of it involving _some_ new code. Anything that is different involves changes, and any change brings the possibility of an implementation error. However Blockstream has tried to keep confidential transactions as close to the underlying bitcoin code base as possible to minimize that error, and unlike other solutions CT has been subject to academic review and external security audit.
        daira 10y ago

by josu 10y ago

jackgavigan 10y ago

This type of challenge is implicit in any cryptocurrency with strong confidentiality (i.e. which conceals the amount being transferred from public view) unless you trust the "inputs-equal-outputs" proving mechanism (which, in Zcash's case, is the zk-SNARK that accompanies a shielded transaction). One potential solution is to periodically require that all coins be unshielded (i.e. sent to a t-address) and passed through a turnstile mechanism (thus allowing them to be counted). After a reasonable amount of time, a new consensus rule kicks in that prevents coins from being spent unless/until they've been put through the turnstile. That would effectively allow for a full audit of the monetary base without compromising privacy.

kobeya 10y ago
What? This is totally incorrect. It is perfectly possible to build systems that verify total issuance while concealing amounts. Blockstream's Confidential Transactions does this, for example.
- jackgavigan 10y ago
  So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?
  - tromp 10y ago
    As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes. For which bitcoin has some billion dollar in bounties:-)
    - daira 10y ago
      The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)
      - kobeya 10y ago
        The CRYPTO relies only on ECDLP. That word, as it is usually used as a term of art, indicates the underlying mathematical assumptions. to say "it does not only rely on ECDLP" is to indicate that there are other trusted mathematical security assumptions, such as harness of EC pairing or the knapsack problem. This is not the case with confidential transactions, whose Pedersen commitments and Back-Maxwell rangeproofs rely on the exact same cryptographic assumptions as any bitcoin signature. It even uses the same library to create and check these commitments, with a minimal amount of new code. Is there scope for new implementation errors? Yes, but only in the fully generic sense of it involving _some_ new code. Anything that is different involves changes, and any change brings the possibility of an implementation error. However Blockstream has tried to keep confidential transactions as close to the underlying bitcoin code base as possible to minimize that error, and unlike other solutions CT has been subject to academic review and external security audit.
        daira 10y ago