Offline Transactions and Bluetooth!

[Andreas Schildbach]

Over the last few days, I was busy with finally including Bluetooth based offline transactions and making QR-code and NFC based offline transactions usable again, which are already in the app since 2011 albeit hidden.

First, let me explain. An offline transaction is a transaction that is directly transmitted between the sender (customer) and the receiver (merchant). It does not require an Internet connection. This is especially useful for the case where a customer comes into a shop and his or her phone is disconnected, maybe because the shop is located in an area with weak cell coverage or maybe the customer simply does not want to pay exorbitant roaming fees. It's also useful in other scenarios, for example at a tech conference with flakey wifi.

Probably the easiest way will be Bluetooth based: It is based on work Mike, Grazcoin and me started at a Bitcoin Hackathon a year ago. Basically, it saves one "pairing interaction". By scanning the Bitcoin request a Bluetooth channel is established in the background which is being used to communicate the signed transaction back. Because it is a labs feature for now, both parties need to enable the feature in the settings. The merchant needs to actively request coins, and stay on that request screen. As soon as the customer has scanned the request and signed the transaction, the Bluetooth channel is used for broadcasting, in addition to the usual Bitcoin P2P network.

The old methods of pairing twice are still there - QR-code and NFC: If the customer taps a transaction that he would like to get to the merchant, it is put onto NFC. Also a QR code is available in the action bar. The merchant needs to scan either of the two. Caveat: Some large transactions do not fit into a QR-code, so that feature may not be available at all times.

A word about security. As a merchant, you must be aware that transactions received directly from the customer are much more easy to spoof. For that reason, the growing grey dot of validations will initially not be there for a direct transaction just received. If at least your device has Internet connectivity, it will broadcast offline transactions to the network and listen for validations. If you see that dot grow, you're reasonably safe for small values. If you see the green "pie progress" grow, that means the transaction is confirmed via the blockchain and you're very safe. If you see neither of the two, you should have reason to trust whom you're dealing with.

All of this stuff is being made available in beta 3.18, downloadable either from

http://code.google.com/p/bitcoin-wallet/downloads/list

or from the Google Play beta channel. See this thread on how to participate in the beta channel.

Please do comment and report any quirks you may find.

[Mike Hearn]

That's cool.

Discoverability needs work though. I had no idea you could tap a transaction and send it via NFC that way, and I guess I'm considered a power user There's no visual indication on screen that this is the case.

What's the next step? Making the server run even when the main screen is also displayed is probably the biggest usability win.

[Andreas Schildbach]

Next steps are moving the reception of Bluetooth messages into a service (it's currently bound to an activity) and polishing the workflow in general. I have a pretty clear vision of how it will look like once it's promoted out of labs. We also need more clear user communication in terms of security/tx confidence, but that depends a bit on what bitcoinj will provide.

I'm not sure I will put much effort into the QR- and NFC-based flows. I just kept them for traditional reasons and people who know that they're there. Btw. previously they were even more hidden in the transaction details screen which is now gone.

I could also imagine supplementing the Bluetooth flow with a Wifi Direct flow, once there is evidence that Androids Wifi Direct implementation is good for anything else than rebooting your phone without android.permission.REBOOT.

[Ego]

Am I to assume that this will only work with your app on both sides as (as far as I am aware) no other app / program would support such a feature.
Thanks for an awesome app

[Andreas Schildbach]

Am I to assume that this will only work with your app on both sides as (as far as I am aware) no other app / program would support such a feature.

Yes, currently no one else has implemented this. If I remember right, Mike had something that could be used for bitcoin-qt. Why do you think no other app would support such a feature? It's open source and if anyone is interested, I'll explain the (simple) protocol.

[caveden]

Congrats!

Do you consider using the payment protocol under development?
That would cover the compatibility issue mentioned by Ego, as we can expect that protocol to become a standard.

[Andreas Schildbach]

Do you consider using the payment protocol under development?
That would cover the compatibility issue mentioned by Ego, as we can expect that protocol to become a standard.

I'm considering it.

However, I'm not sure if it's a good fit. For example, how can X.509 signature verification work if devices are offline?

For in person transfers, I know who I'm trading with. Both QR and NFC make pretty sure there cannot be a man in the middle. The first retrieval of the payment request (via http) can be intercepted much more easily however. I think the standard needs to take care of that usecase.

[Mike Hearn]

However, I'm not sure if it's a good fit. For example, how can X.509 signature verification work if devices are offline?

Couple of misunderstandings here:

Firstly, you can easily verify the signatures on a payment request offline. That's the reason I designed the protocol to work that way. All the data you need to verify is in the request protocol buffer + your local cert store, which on Android is provided by the OS. No network interaction is needed.

Secondly, the payment protocol does not require signatures. It can be useful even without signing. It provides multiple features, like a "memo" field that can be used to label transactions and support for refund addresses, and will provide more in future.

The payment protocol is definitely the right direction to go with this work. There's a guy who is preparing to work on implementing it in bitcoinj at the moment, and at that point it should be easy to come up with a transition plan for the Bluetooth protocol.

For in person transfers, I know who I'm trading with. Both QR and NFC make pretty sure there cannot be a man in the middle. The first retrieval of the payment request (via http) can be intercepted much more easily however. I think the standard needs to take care of that usecase.

You wouldn't retrieve the payment request via HTTP. It'd all be done via Bluetooth. The protocol would look like this:

1) Open a bt socket to the MAC given in the &request= param of the bitcoin: URI (this is similar to how it works today)

2) Client sends a new custom message that says, basically, "Give me a payment request"

3) Server sends back a signed payment request message (length prefixed as always). The submit URL in the payment request can either be ignored or (perhaps better) be another bluetooth mac address.

4) Client parses it and verifies the signature if there is one. Displays to user for confirmation. If the user confirms, it then sends a PaymentACK back over the BT socket.

5) Server accepts message and payment is done.

It's basically like the normal payment protocol, except with a bit of extra custom glue.

Now the interesting question is what to do about encryption. As described the protocol is unauthenticated and unencrypted (that's how you skip the pairing process). If the payment request isn't signed, that means it can be MITMd. What might make sense is if the QRcode/bitcoin URI not only included a MAC address but also a public key.

[Mike Hearn]

BTW I noticed that the text next to the qrcode clips on my N4 when bt is active. The labels can't quite fit in the available space.

[Andreas Schildbach]

Firstly, you can easily verify the signatures on a payment request offline.

Ok, let's see how it works out. It is just from my experience with web browsers which do lazy-load the missing intermediate parts in certificate chains. But anyway, the significance of a X.509 certificate is negliable, as users have no chance of getting their trust store right.

Now the interesting question is what to do about encryption. As described the protocol is unauthenticated and unencrypted (that's how you skip the pairing process). If the payment request isn't signed, that means it can be MITMd. What might make sense is if the QRcode/bitcoin URI not only included a MAC address but also a public key.

I think the right way is skip the intermediate step and send a payment request right away. For NFC, this is pretty straightforward. Put the BIP70 formatted request onto the tag with the appropriate BIP71 MIME type. For QR, I'd suggest Base43-encode the request and put it into a bitcoin: uri (perhaps gzip compress it first) - just like it is done with transactions already. We can skip the signature because we're meeting the person f2f already, so the QR should stay small enough to be scanned easily.

Edit: I just thought that PaymentDetails/payment_url should be a list 0..x of urls. How should the merchant know the capabilities of the customer? He should provide all alternatives he can handle.
Edit 2: On #bitcoin-dev, the consensus seems to be dedicated fields for each medium of communication rather than a list of generic uris.

[Andreas Schildbach]

BTW I noticed that the text next to the qrcode clips on my N4 when bt is active. The labels can't quite fit in the available space.

A screenshot would help.

[Mike Hearn]

People who are paying shouldn't have to think about trust stores at all, and I don't intend that they will. It should operate exactly like SSL in that regard.

Small business owners who want to sign their payment requests might need a wizard or something to help them get set up, yes. It shouldn't involve much beyond opening the file that the CA sent you, confirming the import into the Android cert store, and then telling BW to use it. But I never tried it myself and it's a more advanced feature for next year, perhaps. For now being able to scan QRcodes from websites and pay from your phone is good enough.

I sent you a screenshot of the clipping issue.

[Andreas Schildbach]

I sent you a screenshot of the clipping issue.

Thanks, fixed.

[Borph]

Tried it with official 3.19 and works like a charm 

Mobile (offline) scans QR from tablet (online) and sends per Bluetooth, nice! Two questions:

1. After sending, the mobile said that bluetooth transmission was rejected, although successful.
2. Does the 'scan QR' button activate the camera in a different way? Seemed to have no autofocus, while "Barcode Scanner" activates it.

Peter

[Andreas Schildbach]

1. After sending, the mobile said that bluetooth transmission was rejected, although successful.

Sounds like a  bug. Is it reproducable?

2. Does the 'scan QR' button activate the camera in a different way? Seemed to have no autofocus, while "Barcode Scanner" activates it.

All app-provided buttons use the internal barcode scanner. What phone do you use? There is a known issue with the Galaxy S2 that autofocus does not work but I don't know why. I don't have non-nexus phones to test with.

[Borph]

Sounds like a  bug. Is it reproducable?

Yes, send you a mail.

All app-provided buttons use the internal barcode scanner. What phone do you use? There is a known issue with the Galaxy S2 that autofocus does not work but I don't know why. I don't have non-nexus phones to test with.

Yes, Galaxy S2 :-/

[Andreas Schildbach]

Yes, Galaxy S2 :-/

If anyone has got a spare S2 device (which hopefully got replaced by a shiny Nexus phone), it would make a great donation! These TouchWiz devices have a lot of device dependent quirks unfortunately... )-:

[ikilled]

What happens if you have 2 merchants and an offline customer:
 - the 1st is offline, but still accepts offline BT transactions
 - the 2nd is online and accepts offline BT tansactions

For example If I as a customer send a offline BT transaction to the 1st merchant (offline)
After I go to the 2nd merchant (online) and send him another BT offline transaction.

Now the 2nd merchant sends my signed BT transaction to the network BEFFORE the 1st merchant.
Will be the this transaction valid?
And what about the validity of the first offline transaction (sent to the 1st merchant)?

[Andreas Schildbach]

It does not yet send a chain of transactions, if that's what you're aiming for. This is planned, but bitcoinj does not offer the API yet.

So yes, the second merchant will throw away your transaction if it builds on your first transaction and he doesn't know about it. It will all sort out later when parties get online and (re-)broadcast their pending transactions.

However, in reality your wallet should be fragmented enough that pending transactions don't build on each other.

[phelix]

Could this be used as cold storage with an old smartphone?

1.) Send some coins to the wallet
2.) remove sim and keep it in airplane mode forever (change wlan pw on router)
3.) Do offline txs as needed