4 ms·

I would take this even a step further. To state the obvious, the hard part of building a private currency system is building the private currency system. Once y

I would take this even a step further. To state the obvious, the hard part of building a private currency system is building the private currency system. Once you've done that, it's relatively easy to deliberately relax the privacy guarantees of the system in straightforward ways if that is something you want to do. (Whether this is advisable is totally orthogonal. I'm speaking strictly at a technical level.) Think about this like having a perfect invisibility device. Once you have such a technology, it's relatively easy to make yourself deliberately more visible: e.g., throw a can of paint over your invisible body.* But Taler doesn't start out by building what I consider to be a very strong privacy base and then allowing for optional relaxations. Instead it makes a series of design decisions that begin with the idea that privacy will be limited in certain ways, and then bakes those design choices all the way down to the foundations of the protocol. This means the designers have chosen the deployment parameters, rather than the people and democracies who might actually want to make the decisions. This rubs me the wrong way. * This has in the past been interpreted by people as me saying "I think backdoors are great", which is funny and also not true.

PeterisP 6y ago
The main problem is that certain guarantees about behavior are fundamentally incompatible with certain attributes of transactions; you can have meaningful assertions that hold only if all transactions meet some criteria and there is no optionality, because the intentional abuse will simply choose the set of options that circumvent whatever conditions you want to enforce. Using your own example, if your "world" supports a perfect invisibility device, then your world can't provide any guarantees that under certain conditions specific things will be seen - you can't have your cake and eat it too, if you want or need such guarantees, then you need to design a world where a perfect invisibility device is impossible. Stability of any financial system needs an ability to protect against malicious, resourceful actors. Just as a proof-of-work coin needs to protect against double-spending and miner collusion, a Taler-like system needs to protect against malicious exchanges (so, the requirements foor auditability) and against malicious fraudulent merchants (so, the requirements to ensure that there's no option that a malicious merchant might use to cash out anonymously after receiving a payment). Perhaps there is some way to satisfy all needs, but I personally doubt that, there are too many fundamentally opposite requirements (anonymity vs AML; circumventing gov't control vs ability to take legal action; irreversibility vs reversibility of fraud, etc) - and a system has to choose! If 99% of your transactions use a reversible mode and 1% are irreversible and untraceable, well, you can't have fraud protection for hacked wallets since those will use the irreversible and untraceable option; if you want feature A, you have to ensure that feature B is impossible.
- matthewdgreen 6y ago
  > 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.
DavidPage 6y ago
Yes, there exist harder technical challenge in designing systems with more privacy, and ECC has an incredible engineering team doing SNARK work, but.. You're drawing a false equivalence between actual deployment potential in real systems, and the pure technological potential of ECC's code. At a technical level, both ZCash and Taler operate upon two databases, one for UTXOs and one for nullifers, and either could change their cryptography. If you compare design decisions more carefully then you'll find ZCash baked their politics much more deeply than Taler. Taler provides inexpensive anonymous payments for small everyday purchases. This is not controversial. ZCash employs non-scalable blockchain designs that cannot realistically support many small purchases, and even requires merchants track the chain, making it primarily an investment instrument. It's true one ECC dev has contributed to the scaling discussion, and ECC's code base spawned zexe and arkworks, which advanced zk rollups, but.. ZCash does not fund obviously much scalability work. In short, Taler appears focused upon real privacy needs of everyday people, while ZCash appears focused upon investors' privacy desires, including for for tax evasion. ZCash could engineer some taxation support system, although not sure about the complexity. Taler could trivially simplify their refresh protocol, which then makes all transactions become plausibly refreshes, and makes taxation hard. ZCash expressly supports hiding large balances, presumably from taxation. Taler could adopt a system that hides balances with range proofs, if they valued hiding large balances. ZCash like Bitcoin was designed to combat flawed government monetary policy, which weds them tightly to this goal. If desired, Taler could operate upon finality proofs produced by blockchains, thus giving supporting the same anti-governmental monetary political goals as ZCash, etc. Again, if we compare the political positions based into the designs of Taler and ZCash, then we find ZCash's positions to be more extreme, and to be baked more deeply into the design.
- matthewdgreen 6y ago
  This shouldn't be viewed as a Zcash decision vs. Taler. I think this should be more viewed as full centralized Chaumian e-cash (with more flexible privacy choices) vs. Taler. If you're telling me that Taler's "value transparency" decisions are driven by technological scaling limitations that can't addressed any other way, then that's an interesting discussion to have. But it's not a discussion about Zcash.

PeterisP 6y ago

The main problem is that certain guarantees about behavior are fundamentally incompatible with certain attributes of transactions; you can have meaningful assertions that hold only if all transactions meet some criteria and there is no optionality, because the intentional abuse will simply choose the set of options that circumvent whatever conditions you want to enforce. Using your own example, if your "world" supports a perfect invisibility device, then your world can't provide any guarantees that under certain conditions specific things will be seen - you can't have your cake and eat it too, if you want or need such guarantees, then you need to design a world where a perfect invisibility device is impossible. Stability of any financial system needs an ability to protect against malicious, resourceful actors. Just as a proof-of-work coin needs to protect against double-spending and miner collusion, a Taler-like system needs to protect against malicious exchanges (so, the requirements foor auditability) and against malicious fraudulent merchants (so, the requirements to ensure that there's no option that a malicious merchant might use to cash out anonymously after receiving a payment). Perhaps there is some way to satisfy all needs, but I personally doubt that, there are too many fundamentally opposite requirements (anonymity vs AML; circumventing gov't control vs ability to take legal action; irreversibility vs reversibility of fraud, etc) - and a system has to choose! If 99% of your transactions use a reversible mode and 1% are irreversible and untraceable, well, you can't have fraud protection for hacked wallets since those will use the irreversible and untraceable option; if you want feature A, you have to ensure that feature B is impossible.

matthewdgreen 6y ago
> 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.

DavidPage 6y ago

Yes, there exist harder technical challenge in designing systems with more privacy, and ECC has an incredible engineering team doing SNARK work, but.. You're drawing a false equivalence between actual deployment potential in real systems, and the pure technological potential of ECC's code. At a technical level, both ZCash and Taler operate upon two databases, one for UTXOs and one for nullifers, and either could change their cryptography. If you compare design decisions more carefully then you'll find ZCash baked their politics much more deeply than Taler. Taler provides inexpensive anonymous payments for small everyday purchases. This is not controversial. ZCash employs non-scalable blockchain designs that cannot realistically support many small purchases, and even requires merchants track the chain, making it primarily an investment instrument. It's true one ECC dev has contributed to the scaling discussion, and ECC's code base spawned zexe and arkworks, which advanced zk rollups, but.. ZCash does not fund obviously much scalability work. In short, Taler appears focused upon real privacy needs of everyday people, while ZCash appears focused upon investors' privacy desires, including for for tax evasion. ZCash could engineer some taxation support system, although not sure about the complexity. Taler could trivially simplify their refresh protocol, which then makes all transactions become plausibly refreshes, and makes taxation hard. ZCash expressly supports hiding large balances, presumably from taxation. Taler could adopt a system that hides balances with range proofs, if they valued hiding large balances. ZCash like Bitcoin was designed to combat flawed government monetary policy, which weds them tightly to this goal. If desired, Taler could operate upon finality proofs produced by blockchains, thus giving supporting the same anti-governmental monetary political goals as ZCash, etc. Again, if we compare the political positions based into the designs of Taler and ZCash, then we find ZCash's positions to be more extreme, and to be baked more deeply into the design.

matthewdgreen 6y ago
This shouldn't be viewed as a Zcash decision vs. Taler. I think this should be more viewed as full centralized Chaumian e-cash (with more flexible privacy choices) vs. Taler. If you're telling me that Taler's "value transparency" decisions are driven by technological scaling limitations that can't addressed any other way, then that's an interesting discussion to have. But it's not a discussion about Zcash.