Offline Bitcoin Cash payments
When Tobias Ruck from be.cash ("be-dot-cash") told his anecdote about being in a bar in a foreign country (Australia) and having poor to no internet connection and therefore being unable to use Bitcoin Cash for payments (which ultimately lead him to creation of his amazing idea for the offline smart card) I've had an idea of my own. (Turns out Tobias had that idea also and it's described in his white paper, so presented here without the claims of authorship)
Currently, it's a serious problem. If your phone has no internet connection (you're inside, downstairs, in a foreign country with roaming charges) - you can't pay. Or can you?
Smart cards ideas is fantastic, no arguing about it, but what if we could do the same, but using a regular phone and a regular tablet for a merchant (just like the ones that merchants currently use), only with a bit of software magic.
(The images are a bit ugly, sorry, but bear with me for a moment)
The process starts as usual: the customer is presented with a QR code to scan with the wallet.
However, the customer's phone has no internet connection.
Not a problem, the phone displays the raw transaction that it wants to broadcast.
The customer clicks "Done" or whatever button is on a POS with this new software.
The POS activates the camera (that most tablets have).
POS terminal scans the QR code, containing the full raw transaction and broadcasts it.
The customer also taps "Done" on the phone, the phone records that these outputs have been spent, updates the UTXO in its memory to spend the new ones next time.
Bitcoin Cash can work just like credit cards - offline - no internet required (for the customer, merchant usually has a good connection anyway).
It requires some software modifications on both sides: both POS (merchant's terminal) and the wallet, but only in software.
The terminal needs to be able to activate the camera and broadcast the transaction - a very simple change.
The wallet needs to be able to manage UTXOs (unspent transaction outputs) using Tobias Ruck's be.cash's contract that protects the customer from the merchant that doesn't broadcast the transaction. This is a bit harder, but thanks to Tobias - a solved problem.
Oh yeah, the sweet part!
Fast and easy version on Bitcoin Cash exclusively due to use of CHECKDATASIG in be.cash's contract.
Tobias, is my understanding correct that without CHECKDATASIG it's impossible to do the safe offline UTXO management
Tobias: No, just slow, cumbersome and hard to implement or expensive if you are on ETH
Here's an excerpt from the white paper (note that in text "this approach" refers to "QR codes, but not using the contract"):
1.1 Drawbacks
There are three main drawbacks of this approach, compared to a fully offline solution.
First, if the merchant fails to broadcast the transaction, the wallet will update the UTXO set erroneously, which means Payee must either undo this transaction manually in their wallet, or re-sync their wallet using the Internet.
One more thing:
Tobias, is my understanding correct that your scheme uses ever increasing nonce as a "priority" mechanism, so that even if the first merchant didn't broadcast the TX, the second transaction will still work, erasing the possibility for the first transaction to ever be valid?
Tobias: yes
Though to make it work - we need to petition the wallet makers and POS software makers to support the idea (we probably need a name, though, any ideas?)...
One small step towards making a usable worldwide peer-to-peer electronic cash system!
What is the pricing source? How does anyone know how much BCH to charge/send? This requires an internet connection.
Trying to serve markets that don't have internet access is a little bit like selling ice cream to people without electricity. It's just going to be a mess.
We're better off focusing on the many many places in the world where there is internet access, and further the use case where the merchant has it but the person paying does not. This one is very common because merchants will maintain wifi and cellular data for their own purposes, but consumers will often be out of minutes.
In this scenario, the merchant can get the pricing data and then the rest of the above scenario becomes relevant and interesting. The only problem is that it requires trusting the merchant to tell you how much BCH to spend, which is a problem still in need of solving.
Kudos on the writeup!