3 ms·

> and a system has to choose! A system does not have to choose. The society that deploys it has to choose which systems they will use, how those systems will b

> and a system has to choose! A system does not have to choose. The society that deploys it has to choose which systems they will use, how those systems will be configured and so on. That society also needs to decide whether they will (or even can) ban alternative systems. The technology itself should not force the designers' favored technical balance onto society. An ideal technology should allow the broadest possible range of configurations, and let users and society make the remaining decisions wherever it's technically possible. (Many real-world systems are not ideal, and cannot technically admit the broadest possible range of solutions. But we know that centralized e-cash systems can make different choices than Taler.)

PeterisP 6y ago
My argument is that a broad range of constraints is inherently impossible to satisfy within a single fungible, fully interoperable money system - I agree that "ideal technology should allow the broadest possible range of configurations", however, even with such an ideal technology designed by $perfect_deity the "environments" with certain incompatible configurations need to be kept distinct and separate enough so they de facto form separate payment systems; and the users and society can choose to use system A for purpose X and system B (perhaps sharing all of the technology except a configuration flag) for purpose Y, but the society can't have a single system for both these purpuses, because if they are substantially different, then money can't be allowed to flow freely between the systems as that option would break one or the other use case. The society can freely choose between different systems and properties/configurations of systems; but certain emergent properties of a payment system that a society might want to choose require that some other options are closed off, that the configuration is set to ensure that no transactions in that system can use that option. For example, if some uses need an strictly anonymous system and others need an strictly unanonymous system, then these systems can interact only through some gateway that enforces breaking anonymity in the latter; if some uses need a reversible system and others need an irreversible system, then interaction needs to happen through some gateway that will reverse a transaction even if the other leg can't be reversed, taking on financial risk to cover the costs of such a scenario. And, crucially, it seems plausible that in many cases such gateways on the boundary between different configurations are socially impractical to operate as they would have to take on risks they can't protect from, and there would be financial motivation to target them to abuse that configuration difference. For example, we're seeing a bunch of barriers between physical cash USD and USD in bank accounts; and we're seeing a bunch of barriers between USD payments via cheques and USD Fedwire transfers. They are almost interchangeable, but the boundary between different "configurations" requires treating them as distinct and anyone offering a service for unrestricted exchange of one of those into the other is in for a world of hurt.
- matthewdgreen 6y ago
  We are having two different discussions here. I am having a technical discussion about how we should design privacy-preserving payment systems. I think we should design them to be as powerful as possible, since it is vastly harder to "strengthen" a weak system than it is to "selectively weaken" a powerful system if society decides to do that. Using this approach means that society gets the largest range of technology to choose from. You are having a discussion about what solutions society should adopt, and whether multiple systems should be allowed. I think that's interesting but a very different conversation. The only place where these two discussions interact is when technology developers proactively decide to make some kind of specific privacy/security compromise that they think is the right one. This means that societies who want privacy don't get it. It means that societies who want a different tradeoff don't get it. And the most likely outcome is nobody ever adopts the new system, and we get PayPal.
  - PeterisP 6y ago
    What I hear in your posts is an assertion that "technology developers proactively deciding to make some kind of specific privacy/security compromise that they think is the right one" is undesirable. My point is that "technology developers proactively deciding to make some kind of specific privacy/security compromise that they think is the right one" is unavoidable, since any attampts to "avoid" of that choice by leaving options open simply means proactively deciding to make a different compromise that also means that societies who want a different tradeoff (e.g. that the technology must ensure that those options are impossible) don't get the tradeoff they want. Opening one door closes others, in this space one does not simply "add options" without implicitly trading off others. IMHO the larger thread here is having a technical discussion about how we should design payment systems, of which privacy preservation is one factor that's not axiomatic. Your presumption that the systems must be privacy-preserving and as powerful (on the front of privacy-preservation) as possible seems exactly like a case of a technology developer proactively deciding to make some kind of specific privacy/security compromise that they think is the right one. And not really a compromise, but a point at one extreme on that tradeoff scale, which means that societies who want effective anti-fraud measures, anti-tax-evasion measures and ability to recover funds with legal means without the cooperation of wallet-holder don't get it; and IMHO it's quite clear that societies generally do want a tradeoff like that, as evidenced by all the laws societies have chosen to pass. The societies in general are not willing to trade off these factors to gain privacy preservation, and privacy-perserving payment systems get made only because developers proactively decide to make specific tradeoffs that they personally think are the right ones. Leaving aside differences in values and the "ought" part, I also fundamentally disagree with the factual points you make in the first paragraph. I disagree that it's vastly harder to turn a security-preserving system into a privacy-preserving one than to turn a privacy-preserving system into a security-preserving one. IMHO many decades and much, much, much more effort has gone into building security-preserving systems than privacy-preserving systems, and we still haven't succeeded at the former, as evidenced by all the loopholes in electronic transfers and cash controls that still leave enormous space for money laundering. Cash is probably the counterexample of a technology that's somewhat "powerful" w.r.t privacy preservation and has proven to be very, very hard to "selectively weaken" effectively. I'd say that to "selectively weaken" a powerful privacy-preserving system is definitely not easier, I'd say that it's pretty much impossible - since if a society would choose an ability to track specific transactions (e.g. money laundering or drug trades) then a selective weakening does not achieve that goal, and even 99% weakening does not achieve that goal. If there are multiple channels available, then achieving that requires that all channels are privacy-breakable, since otherwise the malicious transactions would all get funneled through the privacy preserving channel. The society can (and should!) apply privacy-breaking selectively, but if the technology can't ensure that these specific transactions are privacy-breakable despite some fraudster trying to preven tthat, then the society doesn't get the tradeoff it wants, that goal requires that 100% of the loopholes are closed - which IMHO is harder than ensuring that some transactions are privacy preserving; especially since you can have privacy preservation even if many transactions are non-private - as if you have multiple channels available, then you can choose to use only the privacy-preserving channels. The second disagreement is with the statement "Using this approach means that society gets the largest range of technology to choose from." My point is that societies may reasonably want choices which require that other choices are impossible - providing extra choices is not necessarily a net benefit, as the mere availability of option A denies the society some choices. For example, if a society chooses that a certain class of payments should be taboo (for whatever reason), then providing an extra choice of an uncensorable channel does not mean a larger variety of choices - it means denying the society one choice - the choice they wanted, to ensure that taboo-payments don't get made - just to provide another choice that they did not want as much. Perhaps that's the proper framing of this dichotomy? Maximum-choice-of-policy-outcomes is incompatible with maximum-choice-of-technology-options, there's a tradeoff.
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.
DavidPage 6y ago
All these systems impose a notion of society though, so your distinction holds little water. I've no idea if the "on-chain governance" crowd like Cosmos, Polkadot, etc. could politically introduce tools that supported taxation. Any "miner consensus" design like ZCash, Bitcoin, etc. could never introduce such politically contentious upgrades. ZCash's developers have thus de facto spoken definitively against taxation, by defining the voting set to oppose taxation. Taler exchanges do whatever governments permit/encurage banks to do. You might dislike our political system, but clearly Taler adopted a notion of society much closer to the conventional one. As I noted above, Taler could swap their crypto for balance hiding tool or with techniques that support balance hiding blockchains. ZCash cannot disentangle itself from its anti-tax roots.
- matthewdgreen 6y ago
  > ZCash cannot disentangle itself from its anti-tax roots. Sure it can. Anyone can fork the Zcash code, and with some changes can adapt it to a centralized ledger. Or you can use a Chaumian system. Once you do this, you will have a system that faces exactly the same adoption hurdles as Taler.

PeterisP 6y ago

My argument is that a broad range of constraints is inherently impossible to satisfy within a single fungible, fully interoperable money system - I agree that "ideal technology should allow the broadest possible range of configurations", however, even with such an ideal technology designed by $perfect_deity the "environments" with certain incompatible configurations need to be kept distinct and separate enough so they de facto form separate payment systems; and the users and society can choose to use system A for purpose X and system B (perhaps sharing all of the technology except a configuration flag) for purpose Y, but the society can't have a single system for both these purpuses, because if they are substantially different, then money can't be allowed to flow freely between the systems as that option would break one or the other use case. The society can freely choose between different systems and properties/configurations of systems; but certain emergent properties of a payment system that a society might want to choose require that some other options are closed off, that the configuration is set to ensure that no transactions in that system can use that option. For example, if some uses need an strictly anonymous system and others need an strictly unanonymous system, then these systems can interact only through some gateway that enforces breaking anonymity in the latter; if some uses need a reversible system and others need an irreversible system, then interaction needs to happen through some gateway that will reverse a transaction even if the other leg can't be reversed, taking on financial risk to cover the costs of such a scenario. And, crucially, it seems plausible that in many cases such gateways on the boundary between different configurations are socially impractical to operate as they would have to take on risks they can't protect from, and there would be financial motivation to target them to abuse that configuration difference. For example, we're seeing a bunch of barriers between physical cash USD and USD in bank accounts; and we're seeing a bunch of barriers between USD payments via cheques and USD Fedwire transfers. They are almost interchangeable, but the boundary between different "configurations" requires treating them as distinct and anyone offering a service for unrestricted exchange of one of those into the other is in for a world of hurt.

matthewdgreen 6y ago
We are having two different discussions here. I am having a technical discussion about how we should design privacy-preserving payment systems. I think we should design them to be as powerful as possible, since it is vastly harder to "strengthen" a weak system than it is to "selectively weaken" a powerful system if society decides to do that. Using this approach means that society gets the largest range of technology to choose from. You are having a discussion about what solutions society should adopt, and whether multiple systems should be allowed. I think that's interesting but a very different conversation. The only place where these two discussions interact is when technology developers proactively decide to make some kind of specific privacy/security compromise that they think is the right one. This means that societies who want privacy don't get it. It means that societies who want a different tradeoff don't get it. And the most likely outcome is nobody ever adopts the new system, and we get PayPal.
- PeterisP 6y ago
  What I hear in your posts is an assertion that "technology developers proactively deciding to make some kind of specific privacy/security compromise that they think is the right one" is undesirable. My point is that "technology developers proactively deciding to make some kind of specific privacy/security compromise that they think is the right one" is unavoidable, since any attampts to "avoid" of that choice by leaving options open simply means proactively deciding to make a different compromise that also means that societies who want a different tradeoff (e.g. that the technology must ensure that those options are impossible) don't get the tradeoff they want. Opening one door closes others, in this space one does not simply "add options" without implicitly trading off others. IMHO the larger thread here is having a technical discussion about how we should design payment systems, of which privacy preservation is one factor that's not axiomatic. Your presumption that the systems must be privacy-preserving and as powerful (on the front of privacy-preservation) as possible seems exactly like a case of a technology developer proactively deciding to make some kind of specific privacy/security compromise that they think is the right one. And not really a compromise, but a point at one extreme on that tradeoff scale, which means that societies who want effective anti-fraud measures, anti-tax-evasion measures and ability to recover funds with legal means without the cooperation of wallet-holder don't get it; and IMHO it's quite clear that societies generally do want a tradeoff like that, as evidenced by all the laws societies have chosen to pass. The societies in general are not willing to trade off these factors to gain privacy preservation, and privacy-perserving payment systems get made only because developers proactively decide to make specific tradeoffs that they personally think are the right ones. Leaving aside differences in values and the "ought" part, I also fundamentally disagree with the factual points you make in the first paragraph. I disagree that it's vastly harder to turn a security-preserving system into a privacy-preserving one than to turn a privacy-preserving system into a security-preserving one. IMHO many decades and much, much, much more effort has gone into building security-preserving systems than privacy-preserving systems, and we still haven't succeeded at the former, as evidenced by all the loopholes in electronic transfers and cash controls that still leave enormous space for money laundering. Cash is probably the counterexample of a technology that's somewhat "powerful" w.r.t privacy preservation and has proven to be very, very hard to "selectively weaken" effectively. I'd say that to "selectively weaken" a powerful privacy-preserving system is definitely not easier, I'd say that it's pretty much impossible - since if a society would choose an ability to track specific transactions (e.g. money laundering or drug trades) then a selective weakening does not achieve that goal, and even 99% weakening does not achieve that goal. If there are multiple channels available, then achieving that requires that all channels are privacy-breakable, since otherwise the malicious transactions would all get funneled through the privacy preserving channel. The society can (and should!) apply privacy-breaking selectively, but if the technology can't ensure that these specific transactions are privacy-breakable despite some fraudster trying to preven tthat, then the society doesn't get the tradeoff it wants, that goal requires that 100% of the loopholes are closed - which IMHO is harder than ensuring that some transactions are privacy preserving; especially since you can have privacy preservation even if many transactions are non-private - as if you have multiple channels available, then you can choose to use only the privacy-preserving channels. The second disagreement is with the statement "Using this approach means that society gets the largest range of technology to choose from." My point is that societies may reasonably want choices which require that other choices are impossible - providing extra choices is not necessarily a net benefit, as the mere availability of option A denies the society some choices. For example, if a society chooses that a certain class of payments should be taboo (for whatever reason), then providing an extra choice of an uncensorable channel does not mean a larger variety of choices - it means denying the society one choice - the choice they wanted, to ensure that taboo-payments don't get made - just to provide another choice that they did not want as much. Perhaps that's the proper framing of this dichotomy? Maximum-choice-of-policy-outcomes is incompatible with maximum-choice-of-technology-options, there's a tradeoff.

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.

DavidPage 6y ago

All these systems impose a notion of society though, so your distinction holds little water. I've no idea if the "on-chain governance" crowd like Cosmos, Polkadot, etc. could politically introduce tools that supported taxation. Any "miner consensus" design like ZCash, Bitcoin, etc. could never introduce such politically contentious upgrades. ZCash's developers have thus de facto spoken definitively against taxation, by defining the voting set to oppose taxation. Taler exchanges do whatever governments permit/encurage banks to do. You might dislike our political system, but clearly Taler adopted a notion of society much closer to the conventional one. As I noted above, Taler could swap their crypto for balance hiding tool or with techniques that support balance hiding blockchains. ZCash cannot disentangle itself from its anti-tax roots.

matthewdgreen 6y ago
> ZCash cannot disentangle itself from its anti-tax roots. Sure it can. Anyone can fork the Zcash code, and with some changes can adapt it to a centralized ledger. Or you can use a Chaumian system. Once you do this, you will have a system that faces exactly the same adoption hurdles as Taler.