This comes up every so often on HN, it's been in development for a while. I do see at least some technical work happening in Taler (https://taler.net/en/news/index.html) so it doesn't look like the project is dead, but I'm having a hard time finding a roadmap.
What is the overall state of Taler today? How close is this to being something tangible that I can hand to my parents where they can actually make real payments with it for an online product? Are there any businesses supporting it as a payment method yet?
I vaguely remember last time I checked that it was still trying to get buy-in from banks? But I could be remembering wrong.
There is no public roadmap on the business side as the commercial banks we are talking to are not yet willing to have their names disclosed to the public. They're rather conservative institutions (by nature), so they want things to be checked and double-checked and ready to go before going public. Plus it is not trivial (for them) to check all of the regulatory, technical and business checkboxes. I remain hopeful that we'll get through this mess "soon", but I've been too optimistic in the past.
What I can say is that we have presented GNU Taler to over a dozen central banks already. We're trying to convince them that they must give citizens privacy and that an account-based system would give them too much power.
So while the business side is not exactly transparent, what we do technically is all out there. And it's not necessarily a bad thing to have some extra time to reduce the list of known bugs before we go live. :-)
It's good to know that side of things hasn't been abandoned.
> I remain hopeful that we'll get through this mess "soon"
I know you can't give more definitive timetable or details about actual negotiations, but at a high level what does "get though this mess" here mean, what's the short-to-medium term goal that Taler is trying to achieve for how it initially enters the market? Is it possible I wake up one day X months/years from now and just see an announcement that a bank has now decided to use Taler and it'll go live next week, or is this something that's expected to be much more gradual in its rollout?
I don't feel like I have a great understanding of what the process for adoption for Taler looks like beyond the long-term goal that banks would start supporting it and then merchants would follow. I'm not sure if the plan is:
- a bunch of private negotiations happen, and then there's a breakthrough and suddenly within a year half of the banks are using it, or
- a bunch of smaller organizations take it up, and it starts out more niche and starts to grow, or
- somebody someday starts a Paypal equivalent that isn't even technically a bank, just a payment app.
I guess given that Taler is in talks with banks, the hope is that it gets adopted first with those banks; so is the goal that if talks are successful the rollout starts out at an almost national scale?
Could Taler be used in a smaller scope already? For example, could it be used as an "account system" inside an association (like a hackerspace), where members can charge their accounts with Talers and then use these to pay drinks from the fridge, etc?
Setups like this could be used to test the system in practice.
Even though I read the GNU Taler FAQ please excuse any lack of deeper knowledge about it.
When dealing with those commercial banks what is currently the biggest challenge? Is it more the political arguments or the technical arguments of such a payment system that you need to stress? And, I couldn't find no definite answer to that: Could GNU Taler ultimately replace Bitcoin?
GNU Taler is a nice software project. The problem with privacy-preserving centralized payment systems is that "writing software" remains the relatively easy part of the deployment puzzle: in practice you need to convince centralized banks and payment systems to deploy it for some application. Unfortunately, cryptographers have been trying to do this since the 1980s and DigiCash... with extremely limited success.
Decentralized payment systems have changed the equation and now we're seeing a great deal of progress in the area of privacy-preserving payments, some for better and some for worse. I wish Taler could find some applications over there, but the developers don't seem interested. Which is only fair.
(Disclosure: I've worked on decentralized private payment systems.)
Completely agree on where the difficulties lie in getting something like this used. Eventually it will happen though. To me it is a question of timing.
> As Merchants are not anonymous, they can be taxed, enabling income or sales taxes to be withheld by the state while providing anonymity for Customers.
Pulling this off in the United States sounds somewhere between very challenging and impossible.
Sales tax is not uniform. Rates vary not only by state but also at a local level. In some states, sales taxes can be imposed by the state, by counties, by cities, by school districts, by transit authorities, and by other entities like special purpose districts[1].
Which ones (plural) of these sales taxes (plural) apply to a transaction depends on the buyer's location.
In many cases, knowing the buyer's city, state, and zip code is not granular enough. For example, the boundaries of a school district may not correspond to zip code or city.
The typical approach today is to collect the buyer's full address. From that, there are databases that will tell you the list of jurisdictions and taxes that apply. Obviously, that's not very anonymous.
Maybe you could have the buyer determine all of the jurisdictions/taxes that apply to them and send only that info instead. That's less granular, but in some cases it might give away a lot of information. (Sort of like browser fingerprinting.)
But if you do that, I'm not sure what the implications would be for sellers. Sellers are required to collect the sales tax and remit it to the state. They can get in trouble for not doing it right. Governments don't like it when their taxes don't get collected, so they sometimes create laws that put the burden of compliance on the seller.
---
[1] Special purpose districts could allow a county or local government to, for example, pick an arbitrary area and impose a sales tax within it just to support libraries that serve that area. Or crime prevention, road improvement, emergency services, hospitals, parks, economic development, etc.
I'm talking about the "while providing anonymity for Customers" part.
Providing anonymity for customers AND collecting sales tax (in the US) are two goals that conflict with each other. Maybe there are ways to resolve the conflict, but that's far from obvious.
I'm not talking about whether it's automatic or whether GNU Taler makes it easier. I'm talking about whether making the seller info public is enough to comply with tax laws.
GNU Taler doesn't calculate or automatically pays the tax, it's just to prevent tax fraud so that authorities can check if the paid taxes correlate with the income.
The point is that SALES tax in the US doesn't correspond with "income" or even revenue. Sales tax isn't determined by the seller's characteristics - it depends on the buyer.
I don’t know if this is obvious to you or not, but this does not sound like a problem for merchants in most parts of the world. US sales tax is insane and not representative of most jurisdictions, globally speaking.
I’m not saying you couldn’t use Taler in the US - after all, sales taxes work for cash transactions which also anonymous for the buyer. I’m saying if you want to get automatic correct taxation of merchants, perhaps it’s a good idea to run your experiment outside the US.
I don't see why this would be an issue. Merchants deal with all of this today while accepting cash, which is an anonymous payment. None of this relies on tracking the individual customer.
The merchants accepting Taler payments would still be responsible for computing and including the applicable sales taxes in the final price charged to the customer. The customer then pays that, anonymously.
Another difficulty of the taxable feature is that for some retailers their sales tax changes all the time. A simple example is a food truck, sales tax rates can change daily depending on where the truck happens to be parked.
Overall its all very cool and this is in no way criticism on anybody that works on it. I am just point out to people that if you want to get involved or build on top of it what it is.
I would them to work together with some of those Peer-to-peer chat systems or something like that.
GNU Taler uses some libraries from GNUnet (and there is some overlap in core developers), but GNU Taler does not use the P2P (or GNS) functionality of GNUnet.
Seems like a lot of work to offer a less functional alternative to a VISA gift card purchased with cash.
The only real advantage I see is you don't need to stop by WalMart. Maybe the activation fees with Taler are less but I'm sure it's also less widely accepted.
VISA eGift cards are now available for purchase online with funds deposited to a digital wallet. These won't be totally anonymous but then as far as I can tell, neither is Taler --- to provide all the functionality they claim, they will need to maintain records of both purchaser and merchant.
In addition to the huge advantage of not needing to get cash from an ATM and physically carry it to the card vendor:
Transactions made on the same eGift card wallet are tied together. With Taler you have a wallet with coins you can spend separately, and which cannot be correlated, neither by your bank nor the merchant.
What makes you believe anyone (except maybe the purchaser themselves) needs to maintain records about the purchaser? As far as I understood it, their claim is that exactly this is not necessary.
What makes you believe anyone (except maybe the purchaser themselves) needs to maintain records about the purchaser?
Unless you buy your digital coins using cash, the exchanges have the identity of those who purchase and redeem coins/tokens.
From the documentation:
Taler is compatible with anti-money-laundering (AML) and know-your-customer (KYC) regulation, as well as data protection regulation (such as GDPR).
AML and KYC are all about removing anonymity. Merchants may not have the ability to correlate a purchase to you but the exchanges do; otherwise, they wouldn't be able to comply.
> Seems like a lot of work to offer a less functional alternative to a VISA gift card purchased with cash.
Not sure about Taler. But with Chaum's DigiCash from the 90s you could do micropayments and other fun stuff.
The blind signatures gave Alice a way to pull out some amount of her "Cipherbucks" or whatever from her bank. Then she could PGP them to Bob, who could "uncryptography" them and redeem them at OverTheBorder Bank(tm).
If I read correctly, Alice nests a unique number in her sealed thingy, and the the banks would keep an append-only record of these unique numbers. So it's something like this:
1. Alice's bank knows she made a request for $X cipherbucks
2. Bob's bank knows he made a deposit of $Z cipherbucks
3. Bob's bank knows the deposit is good because the unique ID isn't already in the database
As for your question below-- doesn't that satisfy the "Know your customer" rules? It's functionally equivalent to cash so I don't see how it wouldn't
Edit: I'm not sure of the properties of the transactions, so maybe $X and $Z have to be equal? No clue. Still, you get the idea...
I dunno, one of the problems with modern banking is that the same account number is used for both incoming and outgoing transfers. That combined with the general lack of security makes it impossible for me to enable someone to put money into my account without also granting them the ability to take money out. Having separate accounts for incoming and outgoing would fix that. Of course, authorizing transactions with digital signatures fixes that too, but having separate accounts makes me feel kinda warm and fuzzy.
But that is just an implementation detail of who is allowed to initiate outgoing transfers from your account. For me, I needed to send a signed letter to my bank to allow recurring debiting to my landlord (and since I stopped that, no entity except myself is allowed to initiate outbound transfers from my account).
That's not to say the Taler model can't work or anything, just that having one number for inbound and one for outbound transfers isn't really necessary for basic account security. The "everyone who knows my account number can draw money from my account" problem seems weird to have (and trivially solvable) .... in which country is this the default?
This is a really cool idea. I am interested in seeing other types of cryptographically secure payment or monetary systems come about, but decidedly not ones you'd call "crypto," much like Taler very carefully explains it is not.
For example, deflationary gold-like digital currencies just don't work. Fundamentally. It's a futile exercise to debate. But debt-based digital currencies run into some really hard problems.
How do you know if someone is good for their IOUs? If someone takes out a large amount of debt, what prevents them from dropping their wallet/identity and moving on to a new one and wiping themselves clear of their debts? Are all of these social issues? Does a new credit system built into such a currency serve as the basis for preventing someone from not paying their debts back to the network? Even if a credit system was built into the digital currency, someone can always create a new identity if there is no requirement for verification, but how do you design a system that does not require it?
Readit News
What is the overall state of Taler today? How close is this to being something tangible that I can hand to my parents where they can actually make real payments with it for an online product? Are there any businesses supporting it as a payment method yet?
I vaguely remember last time I checked that it was still trying to get buy-in from banks? But I could be remembering wrong.
What I can say is that we have presented GNU Taler to over a dozen central banks already. We're trying to convince them that they must give citizens privacy and that an account-based system would give them too much power.
So while the business side is not exactly transparent, what we do technically is all out there. And it's not necessarily a bad thing to have some extra time to reduce the list of known bugs before we go live. :-)
> I remain hopeful that we'll get through this mess "soon"
I know you can't give more definitive timetable or details about actual negotiations, but at a high level what does "get though this mess" here mean, what's the short-to-medium term goal that Taler is trying to achieve for how it initially enters the market? Is it possible I wake up one day X months/years from now and just see an announcement that a bank has now decided to use Taler and it'll go live next week, or is this something that's expected to be much more gradual in its rollout?
I don't feel like I have a great understanding of what the process for adoption for Taler looks like beyond the long-term goal that banks would start supporting it and then merchants would follow. I'm not sure if the plan is:
- a bunch of private negotiations happen, and then there's a breakthrough and suddenly within a year half of the banks are using it, or
- a bunch of smaller organizations take it up, and it starts out more niche and starts to grow, or
- somebody someday starts a Paypal equivalent that isn't even technically a bank, just a payment app.
I guess given that Taler is in talks with banks, the hope is that it gets adopted first with those banks; so is the goal that if talks are successful the rollout starts out at an almost national scale?
Setups like this could be used to test the system in practice.
When dealing with those commercial banks what is currently the biggest challenge? Is it more the political arguments or the technical arguments of such a payment system that you need to stress? And, I couldn't find no definite answer to that: Could GNU Taler ultimately replace Bitcoin?
Decentralized payment systems have changed the equation and now we're seeing a great deal of progress in the area of privacy-preserving payments, some for better and some for worse. I wish Taler could find some applications over there, but the developers don't seem interested. Which is only fair.
(Disclosure: I've worked on decentralized private payment systems.)
GNU Taler – Payment system for privacy-friendly, fast, easy online transactions - https://news.ycombinator.com/item?id=29850143 - Jan 2022 (48 comments)
GNU Taler 0.8 - https://news.ycombinator.com/item?id=28301172 - Aug 2021 (9 comments)
GNU Taler – A free software, privacy-friendly payment system - https://news.ycombinator.com/item?id=27302634 - May 2021 (1 comment)
GNU Taler – Payment system for privacy-friendly, fast, easy online transactions - https://news.ycombinator.com/item?id=26261314 - Feb 2021 (110 comments)
GNU Taler - https://news.ycombinator.com/item?id=15274110 - Sept 2017 (147 comments)
GNU Taler 0.0.0 released - https://news.ycombinator.com/item?id=11840453 - June 2016 (187 comments)
GNU Taler – Electronic payments for a liberal society - https://news.ycombinator.com/item?id=10258312 - Sept 2015 (183 comments)
Pulling this off in the United States sounds somewhere between very challenging and impossible.
Sales tax is not uniform. Rates vary not only by state but also at a local level. In some states, sales taxes can be imposed by the state, by counties, by cities, by school districts, by transit authorities, and by other entities like special purpose districts[1].
Which ones (plural) of these sales taxes (plural) apply to a transaction depends on the buyer's location.
In many cases, knowing the buyer's city, state, and zip code is not granular enough. For example, the boundaries of a school district may not correspond to zip code or city.
The typical approach today is to collect the buyer's full address. From that, there are databases that will tell you the list of jurisdictions and taxes that apply. Obviously, that's not very anonymous.
Maybe you could have the buyer determine all of the jurisdictions/taxes that apply to them and send only that info instead. That's less granular, but in some cases it might give away a lot of information. (Sort of like browser fingerprinting.)
But if you do that, I'm not sure what the implications would be for sellers. Sellers are required to collect the sales tax and remit it to the state. They can get in trouble for not doing it right. Governments don't like it when their taxes don't get collected, so they sometimes create laws that put the burden of compliance on the seller.
---
[1] Special purpose districts could allow a county or local government to, for example, pick an arbitrary area and impose a sales tax within it just to support libraries that serve that area. Or crime prevention, road improvement, emergency services, hospitals, parks, economic development, etc.
Providing anonymity for customers AND collecting sales tax (in the US) are two goals that conflict with each other. Maybe there are ways to resolve the conflict, but that's far from obvious.
I'm not talking about whether it's automatic or whether GNU Taler makes it easier. I'm talking about whether making the seller info public is enough to comply with tax laws.
I’m not saying you couldn’t use Taler in the US - after all, sales taxes work for cash transactions which also anonymous for the buyer. I’m saying if you want to get automatic correct taxation of merchants, perhaps it’s a good idea to run your experiment outside the US.
The merchants accepting Taler payments would still be responsible for computing and including the applicable sales taxes in the final price charged to the customer. The customer then pays that, anonymously.
The problem with all that GNUNet stuff its that its almost all research, no real active open source project built around them.
I really like re:claimID, basically OpenID Connect auth against your local device. But it would of course need much more work to be practical.
https://www.aisec.fraunhofer.de/de/fields-of-expertise/proje...
Overall its all very cool and this is in no way criticism on anybody that works on it. I am just point out to people that if you want to get involved or build on top of it what it is.
I would them to work together with some of those Peer-to-peer chat systems or something like that.
PS:
New GnuNet release: https://www.gnunet.org/en/news/2022-02-0.16.0.html
Seems like a lot of work to offer a less functional alternative to a VISA gift card purchased with cash.
The only real advantage I see is you don't need to stop by WalMart. Maybe the activation fees with Taler are less but I'm sure it's also less widely accepted.
VISA eGift cards are now available for purchase online with funds deposited to a digital wallet. These won't be totally anonymous but then as far as I can tell, neither is Taler --- to provide all the functionality they claim, they will need to maintain records of both purchaser and merchant.
Unless you buy your digital coins using cash, the exchanges have the identity of those who purchase and redeem coins/tokens.
From the documentation:
AML and KYC are all about removing anonymity. Merchants may not have the ability to correlate a purchase to you but the exchanges do; otherwise, they wouldn't be able to comply.Not sure about Taler. But with Chaum's DigiCash from the 90s you could do micropayments and other fun stuff.
The blind signatures gave Alice a way to pull out some amount of her "Cipherbucks" or whatever from her bank. Then she could PGP them to Bob, who could "uncryptography" them and redeem them at OverTheBorder Bank(tm).
If I read correctly, Alice nests a unique number in her sealed thingy, and the the banks would keep an append-only record of these unique numbers. So it's something like this:
1. Alice's bank knows she made a request for $X cipherbucks
2. Bob's bank knows he made a deposit of $Z cipherbucks
3. Bob's bank knows the deposit is good because the unique ID isn't already in the database
As for your question below-- doesn't that satisfy the "Know your customer" rules? It's functionally equivalent to cash so I don't see how it wouldn't
Edit: I'm not sure of the properties of the transactions, so maybe $X and $Z have to be equal? No clue. Still, you get the idea...
Cash is the ultimate form of anonymity. It neither requires nor provides any identification info. It does not conform to KYC.
In contrast to banking, where one has an account that works pretty much the same regardless of role of clients and nature of their transactions.
That's not to say the Taler model can't work or anything, just that having one number for inbound and one for outbound transfers isn't really necessary for basic account security. The "everyone who knows my account number can draw money from my account" problem seems weird to have (and trivially solvable) .... in which country is this the default?
https://taler.net/en/news/2020-09.html
Last thing I've learnt they were in touch with some Spanish bank institution to work on an implementation.
I guess a lot goes on behind closed doors.
For example, deflationary gold-like digital currencies just don't work. Fundamentally. It's a futile exercise to debate. But debt-based digital currencies run into some really hard problems.
How do you know if someone is good for their IOUs? If someone takes out a large amount of debt, what prevents them from dropping their wallet/identity and moving on to a new one and wiping themselves clear of their debts? Are all of these social issues? Does a new credit system built into such a currency serve as the basis for preventing someone from not paying their debts back to the network? Even if a credit system was built into the digital currency, someone can always create a new identity if there is no requirement for verification, but how do you design a system that does not require it?