38 ms·

Zcash had this which wasn't great: https://bitcoinist.com/zcash-inflation-bug-infinite-tokens/ https://bitcoinist.com/zcash-inflation-bug-infinite-tokens/ You

Zcash had this which wasn't great: https://bitcoinist.com/zcash-inflation-bug-infinite-tokens/ https://bitcoinist.com/zcash-inflation-bug-infinite-tokens/ You also only get privacy with transactions between two z-addresses, and those require a fair amount of resources to generate (I think HW wallets can't sign those transactions due to computational limitations). Most zcash transactions are between t-addresses which don't have any benefits over BTC (they're public). https://bitcoin.stackexchange.com/questions/49115/whats-the-difference-between-z-addr-and-t-addr-type-addresses https://bitcoin.stackexchange.com/questions/49115/whats-the-... As far as cardano, I'm skeptical of proof-of-stake compared to proof-of-work (though I might just not understand it fully). Proof-of-work seems like the main BTC innovation against abuse and a lot of the coins that use stake (stellar lumens, tezos) seem like they drop the defining characteristic of BTC decentralization in order to get faster transactions. Without proof of work you don't really get true decentralized protection from the system itself, you have to put trust somewhere. At least the tezos putting coins at risk approach is interesting. The cardano website also really sets off my bullshit alarms: https://cardano.org/ https://cardano.org/

dlubarov 6y ago
> You also only get privacy with transactions between two z-addresses, and those require a fair amount of resources to generate FWIW this is rapidly improving. The main thing we need to implement Zcash-style private payments is a Merkle proof in a zk-SNARK, so that we can prove ownership of an account in the Merkle tree without revealing the account. So the proving cost depends heavily on our choice of hash function. Since most SNARKs operate over large finite fields, traditional bit-oriented hashes are a poor fit, but the designers originally went with SHA-256 anyway to be on the safe side. More recent versions of the Zcash circuit use Pedersen hashes, which are much cheaper and still provably collision-resistant (assuming discrete log hardness). Future versions will probably use more specialized hashes designed to minimize field operations, like Rescue [1]. There's also the idea of using an embedded GKR protocol to verify gMIMC hashes with a very low incremental cost [2], although it might be overkill for Zcash-style circuits. [1] https://eprint.iacr.org/2019/426 https://eprint.iacr.org/2019/426 [2] https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI
- fossuser 6y ago
  Interesting - thanks for the context and additional links. I saw in your profile you work on Mir, are you also involved in Zcash?
  - dlubarov 6y ago
    I'm not really involved, just a fan of their work :) I think Mir and Zcash have some similar long-term goals, like using SNARKs to scale without affecting security. We just felt that starting over with a new blockchain seemed like the most practical way to get there.

dlubarov 6y ago

> You also only get privacy with transactions between two z-addresses, and those require a fair amount of resources to generate FWIW this is rapidly improving. The main thing we need to implement Zcash-style private payments is a Merkle proof in a zk-SNARK, so that we can prove ownership of an account in the Merkle tree without revealing the account. So the proving cost depends heavily on our choice of hash function. Since most SNARKs operate over large finite fields, traditional bit-oriented hashes are a poor fit, but the designers originally went with SHA-256 anyway to be on the safe side. More recent versions of the Zcash circuit use Pedersen hashes, which are much cheaper and still provably collision-resistant (assuming discrete log hardness). Future versions will probably use more specialized hashes designed to minimize field operations, like Rescue [1]. There's also the idea of using an embedded GKR protocol to verify gMIMC hashes with a very low incremental cost [2], although it might be overkill for Zcash-style circuits. [1] https://eprint.iacr.org/2019/426 https://eprint.iacr.org/2019/426 [2] https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI https://hackmd.io/@uCHu_NMSQ4mIUvA8i4qAyg/rkxBcmvcI

fossuser 6y ago
Interesting - thanks for the context and additional links. I saw in your profile you work on Mir, are you also involved in Zcash?
- dlubarov 6y ago
  I'm not really involved, just a fan of their work :) I think Mir and Zcash have some similar long-term goals, like using SNARKs to scale without affecting security. We just felt that starting over with a new blockchain seemed like the most practical way to get there.