Some time ago I stumbled upon the be.cash project from Tobias Ruck that demonstrates a new technology for a completely offline wallet that can communicate directly to a Point-of-Sale (“PoS”) system to produce a bitcoin cash transaction based on Bitcoin Cash smart contracts.
I recognized that the technology was novel and kind of neat but I must admit that I didn’t actually see a compelling use-case that couldn’t be solved by, for instance, some NFC/bluetooth extensions to the existing Payment Protocol (BIP70). I guess I just couldn’t picture a non-smartphone wallet for this use case and my mind was also trapped in a “there’s always internet” mode and thus there shouldn’t be a big opportunity for be.cash.
Yesterday Tobias posted an interesting demo on Twitter that immediately resonated with me.
HOLY SATOSHI! ??
I did it! A smart card that produces valid #BitcoinCash signatures.
Who would love to pay with a card—to a phone??
Tap took less than a second!??
Imagine trying to set up shop accepting cards and all you need to do is install an app on your phone. ? pic.twitter.com/ielKlcPvDA— Tobias Ruck (@TobiasRuck) November 11, 2019
The paper describing be.cash is a good read but it can be quite hard to wrap ones head around how it actually works and therefor I will now break it down to an easier level. To make it a little bit more concrete I will describe specific implementation details that might be real in the future, although they are fully possible to implement. Remember that be.cash at this point is “just” a white paper and a proof-of-concept demonstration. Anyone that has spent some significant time in the software industry knows that a commercial product is quite far away, probably years.
I will describe the following things and how they work together:
- Smart card
- User wallet
- Merchant PoS
I will not go into how the smart contract works. Let’s just assume that it is magic and depends on some of the things that was enabled in the scheduled Bitcoin Cash protocol upgrades. I.e. it does not work on either BTC nor BSV.
Smart card
If be.cash is to be commercialized one of the most important things is that it can operate on a cheap, generic, common and available smart card. If the project ventures into some custom hardware territory the price of a card will sky-rocket and just not be viable.
The smart card will be delivered flashed with software for it functionality. I guess it would be possible for a user to buy a blank card and flash themselves but I highly doubt that many users will have the appropriate equipment.
The user will then generate a key pair and write it from his or her computer and/or smartphone to the card via NFC. In this step the user will be able to write down the seed phrase of the private key as a backup, just like pretty much any other bitcoin wallet. An integer counter (hereby called nonce, as in ‘number used once’) will also be initialized to a low number.
From this point the only time the user will need to handle the card is when he or she is paying for something! The user could also add a PIN code, but I will leave that detail in this article.
User wallet
The public key matching the private key that was written to the card will be used in a wallet running on a phone/computer to be able to (1) look at the balance of the card and (2) transfer some coins to the card.
The wallet should also be able to handle importing of the private key so a user can transfer coins on the card in case the card is lost and/or compromised.
Existing wallet software could be written to handle these be.cash use cases.
Merchant PoS
The merchant will need an internet connected PoS system with a NFC reader and some special software to be able to handle be.cash payments. A cheap Android smart phone will be sufficient though.
At checkout the merchant will enter the amount and the user will touch his or her card at the NFC reader for approx 1 second.
If everything is OK then the merchant PoS will display some kind of green acknowledge and everything is fine and done and an on-chain transaction will happen that moves the funds to the correct recipient.
If something went wrong, like a communication error or insufficient funds on the card, the payment was unsuccessful.
How does this work?
One thing to realize is that the card does not know anything about the state of the blockchain. It is completely oblivious to the amount of funds that it controls. One way to look at it is that the PoS gives the card and amount and a output address and the cards gives back a 1-time ticket to withdraw that exact amount to that exact address and also the address to where the funds can be drawn from.
The PoS will then check that there are sufficient funds in the address the card supplied, if not the payment has failed.
The PoS will also construct a bitcoin transaction, attach a mining fee, and broadcast the transaction to the bitcoin network.
Malicious merchants
One of the main concerns I read about so far is that the merchant PoS might display one amount but actually ask the smart card for a greater amount. If that happens the user will not notice until he or she checks the balance with another wallet. One thing to remember is that current systems with debit/credit cards works that way and there doesn’t seem to be a big problem with over-charging. The few cases I’ve personally seen has been honest mistakes from the merchant side that was solved directly by the merchant reimburse the user.
It should also be noted that this protocol will also work on a NFC enabled smart phone where the amount can be displayed before the ‘ticket’ is signed and sent to the PoS. For usage at suspicious merchants that might be preferable to some? Point being, the merchant can use the same PoS for be.cash smart cards and be.cash mobile wallets.
Also, be.cash is primarily designed for physical usage and the risk of a merchant of flesh and blood standing in front of you and ripping you off is quite low.
Lastly, there seems to be off-the-shelf smart cards with display and keypad available that could solve this problem, but in my opinion the cost factor of the card is critical for this whole thing to work on a grand scale.
In case of dispute with a merchant the user has a trail on the blockchain and can prove that he or she did do a transaction which might be helpful.
What about KaChing?
Some people have already stated that the KaChing card by bitcoin.no that operates on the BSV network already solved this. I had a quick look and, granted, it looks like a product that has been developed into a more commercially viable state. However, it does not look as novel as be.cash and more like a conventional wallet that is executing on a smart card. The major drawback of KaChing is that it has to maintain the UTXO:s by itself and will synchronizing the card once in a while, especially when moving more funds to the card. The offlineness of be.cash is what I consider to be the novel invention.
Multiple outputs: source of revenue?
One thing that I am curious to investigate is if it would be possible for the smart contract to enforce a certain amount of the payment amount to a designated receiver. This way the producer of the cards and/or PoS system could set up the business such that a small percentage of each transaction using be.cash could become the source of revenue for that business and it could still be entirely trust-less and non-custodial. This would be a big deal.
Summary
I think be.cash is one of the really interesting ideas in the Bitcoin Cash eco-system as of lately. I really hope that the malicious merchants concerns that people raises can be solved in a good way. But I do reckon that be.cash is far from being a commercial product and I hope that Tobias will want to see this thing thru. I will definitely keep an eye out. I must admit that I haven’t really grasped the importance of the offline use-case and I don’t think it is as widespread in the cryptocurrency communities as I think it should be. Especially since Bitcoin (BTC) is pushing further and further towards Lightning Network as the only payment solution which is completely orthogonal in terms of connectivity requirements.
