Topic: Offline Transactions and Bluetooth! - page 2. (Read 9924 times)

A screenshot would help.

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.


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.

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.

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.


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.

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.

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.

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.

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

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.

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.

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.