7 ms·

In more recent times, we had to think about this problem in Indian market context. I saw this problem as online vs offline payments problem. If both parties ar

In more recent times, we had to think about this problem in Indian market context. I saw this problem as online vs offline payments problem. If both parties are offline, can you still make a secure transfer of stored value? Yes, with a trusted execution environment and cryptography, you can do it. So, yeah, smart card works; a smartphone works, a feature phone with NFC smart card works etc. For each, the risk profile is different which affects the answer to the next question. Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario. In India, right now, we have NETC stored value cards for closed loop systems like metro. For open systems like UPI we have recently introduced offline payments capability with very small stored value stored as tokens on the mobile phone and used for very small transactions. As the banks learn the real-world operational risks, the wallet limits and transaction limits will be increased.

bertman 3y ago
>For open systems like UPI we have recently introduced offline payments capability with very small stored value stored as tokens on the mobile phone and used for very small transactions. Sounds interesting! I read about India's UPI for the first time a couple of months ago in an Economist article: https://archive.ph/WoqQp https://archive.ph/WoqQp
londons_explore 3y ago
The real solution is to let the receiver of the money have a "verify" button which will, if connected to the internet, contact a central server and check that no double-spends etc. have happened. Up until verification is done, the money shows as "provisional" in your account - but you can still spend it. Only one person in the chain needs to verify for the whole chain to become permanent. Then the users and merchants can decide if they wait to click the verify button. And the default for anyone with data connectivity should probably be auto-verification. There is an incentive to verify, because if any double-spending has happened, the first to verify is the one who gets the money. Double-spends will happen in any system that allows offline transactions, because a user has to be allowed to log into a new device (if they lose their old one), and there is no way to know if the money spent from their old device was synced to the server yet.
- vinay_ys 3y ago
  > because a user has to be allowed to log into a new device (if they lose their old one) You can solve for that by having short validity of the offline tokens on device and having that equal the cool-off period for reclaiming those funds when new device is provisioned. If I had ₹100 unspent tokens in my offline capable device that I lost, and got a new device provisioned the same day, then that ₹100 will show up in my account and be available to load on my device only after, say 7 days, of cooling-off period. In those 7 days, if someone who found your device could spend it and if so you lose it. If you know you are likely to be offline only sporadically for few hours and not for days, you can reduce the validity (and hence cooling-off period) significantly to just 12 or 24 hours.
  - londons_explore 3y ago
    I think this system has to be designed for some users who will never be online. Think of villages where there is no internet access yet (only 8% of Eritrea has access to the internet for example!). Hence there can't be a 'if you don't log in for 7 days you lose your money' mode.
    - vinay_ys 3y ago
      Let me clarify: if you have you device with you (didn't lose the device) and you didn't make contact with another online device for more than cool-off period, your device tokens won't be refreshed and they will expire and become unspendable. You don't lose that money – it is still in your account and will be available for you spend as soon as you go online. The "lose your money" scenario is only if you lose your device and someone finds your device and spends the money on the device within the cool-off period. It is equivalent to losing your cash wallet and someone else spending your cash. Except in case of cash, that stolen/found cash is lost forever and is valid to be spent by the thief/finder forever whereas in this case there is a small time-window after which you automatically don't actually lose your money!
- lxgr 3y ago
  > Up until verification is done, the money shows as "provisional" in your account - but you can still spend it. Who would accept "provisional money" though, if there is a realistic risk of it being double spent and therefore effectively worthless? > Double-spends will happen in any system that allows offline transactions Only if you assume untrusted devices. That's why in most past and existing stored-value systems, smartcards are being used – these have different security properties.
endgame 3y ago
If both parties are offline, exchanging cash trivially solves this problem.
- vinay_ys 3y ago
  :-) that assumes cash is trivial. It is not for so many reasons. Cash is bulky and discrete. Cash is visible and easily snatched/coerced from you. Apart from classical robbery held at knifepoint or gunpoint and taken to an atm and being robbed or being blackmailed to actually do instant money transfer online which do happen, there are other lower threshold but more frequently occurring and more painful cash "thefts". One eye-opening story I learnt a while ago was this: the women daily wage workers (or the household help that comes to my home) who are typically the breadwinners for the family are coerced by their drunk husbands to give their hard earned cash which they will waste on more alcohol or gambling. This was the situation for decades. Now, with zero-balance, zero-cost bank accounts being made available at scale in India, these women can now keep their money safe and provide care for their children by refusing to give money to their husbands (usually it involves telling them they don't have the money to give when in fact they do in their banks). Such is the social reality for so many.
  - jameson71 3y ago
    That doesn’t sound a lot different than “hiding” the cash. If she is working, the husband knows she is getting money. I do not think the loss of privacy is worth the convenience when talking about replacing cash in a society.
    - lxgr 3y ago
      I fully agree, but in fact stored-value cards offer a plausible path forward for private electronic money: Most existing stored-value systems use "shadow accounts" for reconciliation (in case one of the card-level private keys gets compromised and makes it possible to "double-spend" electronic cash), but that's not really a required part of the system. If it's secure enough, it's possible to just leave these out! It's probably also possible to create some kind of hybrid system which does create pseudonymous traceable logs which offer some trade-off between privacy and security, similar to how banknotes have serial numbers which can theoretically be traced, but practically mostly aren't. And the enormous advantage of a privacy-preserving e-cash/stored-value system over cash is that it works on the internet too.
kwhitefoot 3y ago
> Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either You can solve that by actually having the money in the device so that reconciliation is not required, digital cash like the abandoned Mondex stored value system.
lxgr 3y ago
> Then, when does reconciliation happen? When either party goes online? In many existing systems, there's a split between "merchant" and "customer" cards, of which only merchant cards are allowed to accept payments. Merchants often have to go online once per day and batch-submit all of the day's payments in order to be guaranteed settlement. Among other advantages, this allows for a "lost/stolen" card feature: If a user loses a card, that card can be denylisted on a global list synchronized to all merchant terminals daily. After another day of waiting for straggler transactions, it's possible to determine the remaining balance of the lost card from the backend, and reimburse its owner, since further funds on the card can no longer be spent anywhere in the system. One day is essentially just an arbitrary timespan here – you could make it 14 days, or an hour. In the systems I've looked at closely, one day makes sense because these are historically transit-focused, and e.g. buses don't have continuous network connectivity, but do go to a depot in the evening, which is a good opportunity to clear and settle all of the day's payments. Customer cards never need to be online in such a scheme.
predictabl3 3y ago
Please don't scorch me HN, this isn't an endorsement, just a question for thought -- but isn't this one of the things Lightning is sort of meant to solve? lol, literally less than 20 seconds. > Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario. Again, literally the exact problem statement and value proposition of Lightning, but stupid, stupid me for daring to mention it here, I guess. Feel free to ignore that the idea behind Lightning could be useful without being tied to crypto, but can't possibly have a conversation about that. Nope.
- callalex 3y ago
  >but can't possibly have a conversation about that. Nope. What conversation? You just dropped in here with flamewar bait and complaining about some self-imagined persecution without contributing any substance. Hence your comment is now gray.
  - ImPostingOnHN 3y ago
    they didn't even explain what they were talking about. Where I'm from, lightning is an electrical discharge weather phenomenon usually accompanied by thunder
    - predictabl3 3y ago
      [flagged]
- intotheabyss 3y ago
  No, not lightning. If anything, it would be something like this: https://blog.gridplus.io/the-phonon-network-59835328b799 https://blog.gridplus.io/the-phonon-network-59835328b799

bertman 3y ago

>For open systems like UPI we have recently introduced offline payments capability with very small stored value stored as tokens on the mobile phone and used for very small transactions. Sounds interesting! I read about India's UPI for the first time a couple of months ago in an Economist article: https://archive.ph/WoqQp https://archive.ph/WoqQp

londons_explore 3y ago

The real solution is to let the receiver of the money have a "verify" button which will, if connected to the internet, contact a central server and check that no double-spends etc. have happened. Up until verification is done, the money shows as "provisional" in your account - but you can still spend it. Only one person in the chain needs to verify for the whole chain to become permanent. Then the users and merchants can decide if they wait to click the verify button. And the default for anyone with data connectivity should probably be auto-verification. There is an incentive to verify, because if any double-spending has happened, the first to verify is the one who gets the money. Double-spends will happen in any system that allows offline transactions, because a user has to be allowed to log into a new device (if they lose their old one), and there is no way to know if the money spent from their old device was synced to the server yet.

vinay_ys 3y ago
> because a user has to be allowed to log into a new device (if they lose their old one) You can solve for that by having short validity of the offline tokens on device and having that equal the cool-off period for reclaiming those funds when new device is provisioned. If I had ₹100 unspent tokens in my offline capable device that I lost, and got a new device provisioned the same day, then that ₹100 will show up in my account and be available to load on my device only after, say 7 days, of cooling-off period. In those 7 days, if someone who found your device could spend it and if so you lose it. If you know you are likely to be offline only sporadically for few hours and not for days, you can reduce the validity (and hence cooling-off period) significantly to just 12 or 24 hours.
- londons_explore 3y ago
  I think this system has to be designed for some users who will never be online. Think of villages where there is no internet access yet (only 8% of Eritrea has access to the internet for example!). Hence there can't be a 'if you don't log in for 7 days you lose your money' mode.
  - vinay_ys 3y ago
    Let me clarify: if you have you device with you (didn't lose the device) and you didn't make contact with another online device for more than cool-off period, your device tokens won't be refreshed and they will expire and become unspendable. You don't lose that money – it is still in your account and will be available for you spend as soon as you go online. The "lose your money" scenario is only if you lose your device and someone finds your device and spends the money on the device within the cool-off period. It is equivalent to losing your cash wallet and someone else spending your cash. Except in case of cash, that stolen/found cash is lost forever and is valid to be spent by the thief/finder forever whereas in this case there is a small time-window after which you automatically don't actually lose your money!
lxgr 3y ago
> Up until verification is done, the money shows as "provisional" in your account - but you can still spend it. Who would accept "provisional money" though, if there is a realistic risk of it being double spent and therefore effectively worthless? > Double-spends will happen in any system that allows offline transactions Only if you assume untrusted devices. That's why in most past and existing stored-value systems, smartcards are being used – these have different security properties.

endgame 3y ago

If both parties are offline, exchanging cash trivially solves this problem.

vinay_ys 3y ago
:-) that assumes cash is trivial. It is not for so many reasons. Cash is bulky and discrete. Cash is visible and easily snatched/coerced from you. Apart from classical robbery held at knifepoint or gunpoint and taken to an atm and being robbed or being blackmailed to actually do instant money transfer online which do happen, there are other lower threshold but more frequently occurring and more painful cash "thefts". One eye-opening story I learnt a while ago was this: the women daily wage workers (or the household help that comes to my home) who are typically the breadwinners for the family are coerced by their drunk husbands to give their hard earned cash which they will waste on more alcohol or gambling. This was the situation for decades. Now, with zero-balance, zero-cost bank accounts being made available at scale in India, these women can now keep their money safe and provide care for their children by refusing to give money to their husbands (usually it involves telling them they don't have the money to give when in fact they do in their banks). Such is the social reality for so many.
- jameson71 3y ago
  That doesn’t sound a lot different than “hiding” the cash. If she is working, the husband knows she is getting money. I do not think the loss of privacy is worth the convenience when talking about replacing cash in a society.
  - lxgr 3y ago
    I fully agree, but in fact stored-value cards offer a plausible path forward for private electronic money: Most existing stored-value systems use "shadow accounts" for reconciliation (in case one of the card-level private keys gets compromised and makes it possible to "double-spend" electronic cash), but that's not really a required part of the system. If it's secure enough, it's possible to just leave these out! It's probably also possible to create some kind of hybrid system which does create pseudonymous traceable logs which offer some trade-off between privacy and security, similar to how banknotes have serial numbers which can theoretically be traced, but practically mostly aren't. And the enormous advantage of a privacy-preserving e-cash/stored-value system over cash is that it works on the internet too.

kwhitefoot 3y ago

> Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either You can solve that by actually having the money in the device so that reconciliation is not required, digital cash like the abandoned Mondex stored value system.

lxgr 3y ago

> Then, when does reconciliation happen? When either party goes online? In many existing systems, there's a split between "merchant" and "customer" cards, of which only merchant cards are allowed to accept payments. Merchants often have to go online once per day and batch-submit all of the day's payments in order to be guaranteed settlement. Among other advantages, this allows for a "lost/stolen" card feature: If a user loses a card, that card can be denylisted on a global list synchronized to all merchant terminals daily. After another day of waiting for straggler transactions, it's possible to determine the remaining balance of the lost card from the backend, and reimburse its owner, since further funds on the card can no longer be spent anywhere in the system. One day is essentially just an arbitrary timespan here – you could make it 14 days, or an hour. In the systems I've looked at closely, one day makes sense because these are historically transit-focused, and e.g. buses don't have continuous network connectivity, but do go to a depot in the evening, which is a good opportunity to clear and settle all of the day's payments. Customer cards never need to be online in such a scheme.

predictabl3 3y ago

Please don't scorch me HN, this isn't an endorsement, just a question for thought -- but isn't this one of the things Lightning is sort of meant to solve? lol, literally less than 20 seconds. > Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario. Again, literally the exact problem statement and value proposition of Lightning, but stupid, stupid me for daring to mention it here, I guess. Feel free to ignore that the idea behind Lightning could be useful without being tied to crypto, but can't possibly have a conversation about that. Nope.

callalex 3y ago
>but can't possibly have a conversation about that. Nope. What conversation? You just dropped in here with flamewar bait and complaining about some self-imagined persecution without contributing any substance. Hence your comment is now gray.
- ImPostingOnHN 3y ago
  they didn't even explain what they were talking about. Where I'm from, lightning is an electrical discharge weather phenomenon usually accompanied by thunder
  - predictabl3 3y ago
    [flagged]
intotheabyss 3y ago
No, not lightning. If anything, it would be something like this: https://blog.gridplus.io/the-phonon-network-59835328b799 https://blog.gridplus.io/the-phonon-network-59835328b799