7 ms·
Chaumian digital cash is fine, but that isn't what taler actually implements. Instead, it requires the recipient to identify themselves and the amounts for eve
by nullc 6y ago
Chaumian digital cash is fine, but that isn't what taler actually implements.
Instead, it requires the recipient to identify themselves and the amounts for every payments. This is a continuous realtime surveillance which does not exist for cash.
Used perfectly it might be potentially more private than paypal, but no one is under any illusion that paypal is particularly private.
On a scale of ethical behavior providing strong privacy is superior to providing limited privacy but both are vastly superior to falsely claiming something has strong privacy when it is limited.
Taler takes matters a step further a falsely claim that its continuous realtime mass surveillance is required to facilitate lawful taxation. This claim is false-- an outright lie in fact. Not only is it technically not required, it's not legally required either and taxation has existed for countless generations when this kind of electronic surveillance was unimaginable.
- helen___keller 6y ago> falsely claiming something has strong privacy when it is limited Taler provides strong privacy for buyers, not for merchants. It's important to note that Taler is not a peer-to-peer system for transferring money (there are claims for interest in implementing such a system in the future, but it does not exist), so the receiver is always a merchant Personally I don't mind that businesses are surveilled when I purchase at them, because businesses are not people and do not have the right to avoid surveillance. I would be very concerned if such surveillance could extend to me, but as discussed Taler provides buyers privacy and blindly signed tokens cannot be traced to me.
- hdevalence 6y agoAt the end of the day, balance sheets always balance, every transaction has two sides, and privacy for only one side of every transaction is impossible.
- igorkraw 6y agoYes it is. You just write down "got 5 bucks from customer" and submit it to the tax office. Now one side is anonymous (customers) and the other not (merchant)
- Ar-Curunir 6y agoAnd before that the customer writes down “received 5 bucks”. Then you match up the two and can track the customer’s spending habits
- littlestymaar 6y agoWell, If all you have is “A spent $5” and “B received $5” you are still missing a lot of info to identify that A and B are part of the same transaction (there are thousands of $5 trades every day) But that's not even how Taler works: you withdraw an arbitrary amount of Taler (say $50), this is what is recorded on the consumer side, but then you have anonymous tokens (exactly like coins and bills) that you can spend without connecting to anything: only the supplier need to have a connection to a certification entity (which ensure no double spending).
- runeks 6y agoWhat is the denomination of these tokens? Do I hand over 500 one-cent tokens to pay $5?
- littlestymaar 6y agoThat's the coolest thing about Taler: there is a thing called “the refresh protocol”[1] which allows you to obtain change after a transaction: that is, for instance you pay with a $7 token for your $5 transaction, and you get a $2 change token! [1]: section “4.7.4. Refreshing and Linking” in this paper https://ged.univ-rennes1.fr/nuxeo/site/esupversions/41aac1ac-3074-4b0e-9087-cee5f58ce0b2?inline https://ged.univ-rennes1.fr/nuxeo/site/esupversions/41aac1ac...
- runeks 6y agoThat is pretty cool! So, basically, if a merchant requests payment of $5 and the buyer only has a $4 and a $3 token then the buyer exchanges her $3 token for three $1 tokens with the exchange (without involvement of the merchant) and then pay the merchant with a $4 and a $1 token?
- helen___keller 6y agoIn that case, please enlighten me how to pierce the veil. For the sake of argument, you can play the role of an exchange arbiter - you have full visibility into every transaction. On a given day you're signing a few billion in IOUs into existence from users, while paying out a few billion in IOUs from merchants. Since you are providing blind signatures, you essentially have two ledgers: one is transactions of the form (user, token_value, signed_at) and a second is transactions of the form (merchant, token_value, redeemed_at). How do you suggest the exchange matches user to merchant from this data?
- zaphirplane 6y agoNot the person u are replying to Can a hash not be calculated for the iou, does it have an identifier ? The exchange can log those
- littlestymaar 6y agoIt cannot, the anonymity guarantees are exposed in the Taler paper[1]: https://ged.univ-rennes1.fr/nuxeo/site/esupversions/41aac1ac-3074-4b0e-9087-cee5f58ce0b2?inline https://ged.univ-rennes1.fr/nuxeo/site/esupversions/41aac1ac...
- monoideism 6y agoI've never looked into Taler before this, but they could be matched by token value and approximate time, no?
- helen___keller 6y agoToken value perhaps, under very low volume (think single digit users). But imagine millions or billions of dollars a day in transaction volume, looking at a $5 payment at a cafe and then trying to figure out which of the people whose been assigned a $5 token to in the past month might have shopped there - it would be absolutely futile. Taler wallets just sit there until you use them, much like cash. Realistically, there would be too many degrees of freedom to create a matching from merchant to user, even if we additionally assumed a ton of metadata about user/merchant location and such.
- littlestymaar 6y agoSo Zcash developers feel threatened enough about Taler to spread FUD about it. Sounds like a positive signal to me ;).
- waynesonfire 6y agoHahah, nice.
- tffg 6y agoLmao
- matthewdgreen 6y agoI 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 agoThe 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.