3 ms·

Privacy and inflation in cryptocurrency are not technologically mutually exclusive, they’re mostly orthogonal. Eg, yes, technically you can have both. The pro

Privacy and inflation in cryptocurrency are not technologically mutually exclusive, they’re mostly orthogonal. Eg, yes, technically you can have both. The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate and ensure that some Byzantine miner/validator hasn’t found a way to hack the issuance algorithm and issue more currency (to themselves) than the system is designed to. For example, ZCash had a famous bug regarding this issue a few years ago, that they patched before disclosing it. That’s an ongoing technical challenge the industry is working on.

aspenmayer 6y ago
I’d like to know more about the bug mentioned in $ZEC, if you have a link?
- dlubarov 6y ago
  Not the parent, but I think he was referring to https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/ https://electriccoin.co/blog/zcash-counterfeiting-vulnerabil...
  - SkyMarshal 6y ago
    Yup that’s it.
    - aspenmayer 6y ago
      Even stranger are comments made in this link: https://electriccoin.co/blog/defense-against-counterfeiting-in-shielded-pools/ https://electriccoin.co/blog/defense-against-counterfeiting-... Especially this part: >Upon detecting this condition, the Zcash Company would begin its investigation into the possible source of the vulnerability as well as which pool, or pools, are affected. If we are able to identify that the bug affects only a single shielded pool, we might choose to effectively deactivate that pool by invalidating any of its outgoing transactions. A necessary consequence of this action is that any legitimate funds would also be lost forever in the affected pool. The mechanisms for this remote disabling are not mentioned in detail, and I don’t really mind, but this feature seems difficult to square with their desire for transparency. It’s an anti-feature perhaps serving a justifiable goal, but if this feature is possible to be abused, how would we even know if it had been?
      - abecedarius 6y ago
        I'm not sure what they mean there, but I'd guess they mean a hard fork. As with the Ethereum post-DAO fork, you don't have to accept it, but to the extent it seems legitimate, most of the value would go along.
        dlubarov 6y ago
        There's also this more recent post: https://electriccoin.co/blog/turnstile-enforcement-against-counterfeiting/ https://electriccoin.co/blog/turnstile-enforcement-against-c... It sounds like that plan has been codified in recent clients, so they should automatically reject transactions that would cause a pool's balance to go negative.
        aspenmayer 6y ago
        Entirely reasonable mitigation. Thanks for the link.
  - im3w1l 6y ago
    Ouch what a nightmare. At that point it seems like the best way may be to start over? Like have everyone who can prove they have old-money get new-money on a first-come-first serve basis. If too much money shows up you know you got owned. Otherwise you are fine. If too much money shows up years down the line, you just deny them new-money, which screws over people who bought-and-forgot but everyone else is ok.
im3w1l 6y ago
> The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate Satoshi could have made mining reward increase at 2% per year, but very deliberately decided on hard cap on how many will exist. This decision made early adopters literally and metaphorically invested in bitcoin's success. Are you saying that some detail of zk-Snark makes that not possible for cryptocurrencies based on this technology?
- SkyMarshal 6y ago
  No I’m saying the exact opposite. The inflation schedule can be any arbitrary algorithm. It can be a fixed amount like Bitcoin, or a continually increasing one like your 2% example. Zk-snarks don’t change that. It’s still a choice by the developers based on the economic objectives they’re trying to achieve, and snarks don’t prevent that. But problem is that in a fully-shielded, 100% private, snark-based blockchain, it’s difficult or impossible to verify that the actual coin supply is what the whitepaper says it should be. Since all the tx’s are hidden, you can’t inspect the blockchain data and just count all the coins in UTXOs or account holdings to see what the total money supply is at any given time and reconcile it with what the issuance algorithm says it should be.
  - tromp 6y ago
    Lack of transparent supply auditability is a feature not so much of zk-snarks but of Confidential Transactions, which use Pedersen commitments to obscure amounts. Knowing the discrete logarithm of just one particular point would completely break these commitments and all cryptocurrencies based on them, by allowing undetectable inflation. They thus require complete confidence in the computational hardness of the Elliptic Curve Discrete Log Problem.
    - SkyMarshal 6y ago
      Yup, fwiw I'm not actually aware of a fully shielded zk-snark cryptocurrency in production yet, was just using that as a hypothetical example, like a ZCash with only z-addresses.

aspenmayer 6y ago

I’d like to know more about the bug mentioned in $ZEC, if you have a link?

dlubarov 6y ago
Not the parent, but I think he was referring to https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/ https://electriccoin.co/blog/zcash-counterfeiting-vulnerabil...
- SkyMarshal 6y ago
  Yup that’s it.
  - aspenmayer 6y ago
    Even stranger are comments made in this link: https://electriccoin.co/blog/defense-against-counterfeiting-in-shielded-pools/ https://electriccoin.co/blog/defense-against-counterfeiting-... Especially this part: >Upon detecting this condition, the Zcash Company would begin its investigation into the possible source of the vulnerability as well as which pool, or pools, are affected. If we are able to identify that the bug affects only a single shielded pool, we might choose to effectively deactivate that pool by invalidating any of its outgoing transactions. A necessary consequence of this action is that any legitimate funds would also be lost forever in the affected pool. The mechanisms for this remote disabling are not mentioned in detail, and I don’t really mind, but this feature seems difficult to square with their desire for transparency. It’s an anti-feature perhaps serving a justifiable goal, but if this feature is possible to be abused, how would we even know if it had been?
    - abecedarius 6y ago
      I'm not sure what they mean there, but I'd guess they mean a hard fork. As with the Ethereum post-DAO fork, you don't have to accept it, but to the extent it seems legitimate, most of the value would go along.
      - dlubarov 6y ago
        There's also this more recent post: https://electriccoin.co/blog/turnstile-enforcement-against-counterfeiting/ https://electriccoin.co/blog/turnstile-enforcement-against-c... It sounds like that plan has been codified in recent clients, so they should automatically reject transactions that would cause a pool's balance to go negative.
        aspenmayer 6y ago
        Entirely reasonable mitigation. Thanks for the link.
- im3w1l 6y ago
  Ouch what a nightmare. At that point it seems like the best way may be to start over? Like have everyone who can prove they have old-money get new-money on a first-come-first serve basis. If too much money shows up you know you got owned. Otherwise you are fine. If too much money shows up years down the line, you just deny them new-money, which screws over people who bought-and-forgot but everyone else is ok.

im3w1l 6y ago

> The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate Satoshi could have made mining reward increase at 2% per year, but very deliberately decided on hard cap on how many will exist. This decision made early adopters literally and metaphorically invested in bitcoin's success. Are you saying that some detail of zk-Snark makes that not possible for cryptocurrencies based on this technology?

SkyMarshal 6y ago
No I’m saying the exact opposite. The inflation schedule can be any arbitrary algorithm. It can be a fixed amount like Bitcoin, or a continually increasing one like your 2% example. Zk-snarks don’t change that. It’s still a choice by the developers based on the economic objectives they’re trying to achieve, and snarks don’t prevent that. But problem is that in a fully-shielded, 100% private, snark-based blockchain, it’s difficult or impossible to verify that the actual coin supply is what the whitepaper says it should be. Since all the tx’s are hidden, you can’t inspect the blockchain data and just count all the coins in UTXOs or account holdings to see what the total money supply is at any given time and reconcile it with what the issuance algorithm says it should be.
- tromp 6y ago
  Lack of transparent supply auditability is a feature not so much of zk-snarks but of Confidential Transactions, which use Pedersen commitments to obscure amounts. Knowing the discrete logarithm of just one particular point would completely break these commitments and all cryptocurrencies based on them, by allowing undetectable inflation. They thus require complete confidence in the computational hardness of the Elliptic Curve Discrete Log Problem.
  - SkyMarshal 6y ago
    Yup, fwiw I'm not actually aware of a fully shielded zk-snark cryptocurrency in production yet, was just using that as a hypothetical example, like a ZCash with only z-addresses.