3 ms·

Isn't this basically what's happening nowadays, except on the level of competing digital currencies instead of on the level of competing configurations? Bitcoi

by jpetso 6y ago

Isn't this basically what's happening nowadays, except on the level of competing digital currencies instead of on the level of competing configurations? Bitcoin, Z-Cash, Stellar, GNU Taler and many more, all of those offer different characteristics which societies can pick and choose from. Central Banks don't necessarily like the particular choices that have been made by existing systems and drill down a level further to design a system with exactly the combination of cryptographic blocks that provide the desired mix of characteristics. I don't think it's wrong that a particular solution like GNU Taler specializes in a particular set of combinations, it will do a better and more maintainable job at this (already pretty massive) project than trying to cover every arbitrary combination of characteristics. Same as libsodium provides a better crypto API than OpenSSL while not running into Heartbleed-scale bugs, because it actually dares to make opinionated choices. The flexible layer for e-cash should be on the level of crypto primitives, and the actual implementation is the configurable layer that you're asking for. Web browsers and operating systems are neat and general-purpose, but for a mission-critical currency it would be nice not to have to deal with the endless security fixes that an almighty everything-framework will unleash unto us.

matthewdgreen 6y ago
I'm a big fan of libsodium/NaCl for the use case of "encrypting things simply". However, I also recognize that it can't do certain things: for example, the original NaCl didn't support "public key encryption from an anonymous sender who doesn't have a static secret key", and libsodium had to add that feature via a new "crypto_box_seal" function. I've seen multiple people re-implement that feature from scratch into NaCl, before libsodium added it and became the standard. They did this because many protocols require a way to do this, and the original NaCl designers were aware of this but had a very opinionated design philosophy. So we get forks. This kind of thing is just barely tractable when you're talking about something as "simple" as a non-interactive encryption protocol. It becomes exponentially harder when you get into the world of interactive crypto protocols with ZK proofs and privacy guarantees (where a bug means losing millions of dollars.) It becomes even harder when specific anti-privacy features have been baked into the underlying protocols on purpose, because it requires so much expertise to remove them, and the consequences of a mistake are catastrophic to the whole system. You're often better off just starting from scratch, since the technology of centralized e-cash is reasonably well understood (and the Taler authors probably aren't going to support your fork, because they politically disagree with your choices.) I have been following Taler for several years and it's great that it exists. But I don't see a pathway to adoption for it, partly because it's so "politically" opinionated around a specific set of features that the authors think are the right ones, and partly because it's hard to launch a centralized private currency without buy-in from a lot of people who agree with your political decisions. Taler can only launch if it finds sponsors who agree with all its choices, and it has not found them yet. Whereas Zcash and Monero launched because, while they're also opinionated, they're decentralized currencies and don't face the same coordination problems.

by jpetso 6y ago

matthewdgreen 6y ago

I'm a big fan of libsodium/NaCl for the use case of "encrypting things simply". However, I also recognize that it can't do certain things: for example, the original NaCl didn't support "public key encryption from an anonymous sender who doesn't have a static secret key", and libsodium had to add that feature via a new "crypto_box_seal" function. I've seen multiple people re-implement that feature from scratch into NaCl, before libsodium added it and became the standard. They did this because many protocols require a way to do this, and the original NaCl designers were aware of this but had a very opinionated design philosophy. So we get forks. This kind of thing is just barely tractable when you're talking about something as "simple" as a non-interactive encryption protocol. It becomes exponentially harder when you get into the world of interactive crypto protocols with ZK proofs and privacy guarantees (where a bug means losing millions of dollars.) It becomes even harder when specific anti-privacy features have been baked into the underlying protocols on purpose, because it requires so much expertise to remove them, and the consequences of a mistake are catastrophic to the whole system. You're often better off just starting from scratch, since the technology of centralized e-cash is reasonably well understood (and the Taler authors probably aren't going to support your fork, because they politically disagree with your choices.) I have been following Taler for several years and it's great that it exists. But I don't see a pathway to adoption for it, partly because it's so "politically" opinionated around a specific set of features that the authors think are the right ones, and partly because it's hard to launch a centralized private currency without buy-in from a lot of people who agree with your political decisions. Taler can only launch if it finds sponsors who agree with all its choices, and it has not found them yet. Whereas Zcash and Monero launched because, while they're also opinionated, they're decentralized currencies and don't face the same coordination problems.