@Read.Cash
edited
more from that month
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) https://be.cash/ https://v.redd.it/fbznequha8141 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. https://be.cash/becash.pdf 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"): https://be.cash/becash.pdf **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!**
11 comments
Not a bad idea. Could implement the fatURI scheme (https://github.com/unwriter/fatURI) when passing the signed transaction back to the merchant as a QR code.
Sure, interesting link. BTW Tobias says that his contract requires even less - about 100 bytes of data. So maybe it's even better.
If I understand the Be.Cash protocol correctly, all the card does is provide a signature of Sha256(merchantPKH||paymentAmount||nonce). ~71 byte (or 64 if schnorr?) Signature + 33 byte pubKey which satisfies an OP_CHECKDATASIG. So yeah, that might be even more applicable.
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!
> 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. I think you missed something here, this is the exact scenario that the article describes :) I start with the fact that only Tobias didn't have an internet connection (while the merchant had). The QR code, obviously, shows the number of BCH satoshis to send and where. > The only problem is that it requires trusting the merchant to tell you how much BCH to spend Yeah, it does. I think the best we can do here is show the conversion in "last known price". We can also probably have a trusted "oracle", which can say "It's 2019-11-29 11:00am and the price of BCH is $209.15" (it should be a few bytes actually in binary), the merchant can include this information, and offline phone can verify that the signature matches known "oracle" public key, therefore having been signed by the trusted oracle. Glad to see more thinking people in Bitcoin Cash ecosystem! Kudos!
Hello, i would like to report a new bug. The red little logo indicating i got new notifications, does not go away even if i check my notifications.
Click "Next" in notifications - you probably have unread notifications on second or third page
It worked, thank you. Please fix this somehow, for example, make the notifications go away even if only the first page is being visited.
This is not a bug. In that case you would have no idea that you had more notifications. Some of them are very important to see. We might make sure that all unread notifications are always shown on the first page, but we can't mark unread notifications as "read".
In that case, i suggest adding a red text in the first page, saying: you have unread messages on the second page. To avoid confusion. And a new button, saying: mark all as read.
We'll consider it.