Topic: Offline Transactions and Bluetooth! (Read 9924 times)

A little bit late but still: It seems I can only do one offline transaction from a single address as long as the previous one can not be read from the blockchain.

You need to know the tx hash (32 bytes) and the script and of course the value. You don't really need the entire transaction.

  OK. Would a single output be enough (a 100bytes??)? Could I fly blind with that?

Gregory Maxwell actually looked into that at one point. It turns out you can rent a satellite transponder on an old satellite for less than one might imagine. It's not actually financially infeasible. However, receiving the data would require special equipment obviously.

I'd love to see someone broadcasting the blockchain on a wavelength that goes around the globe. Devices with a radio might be able to receive and decode those, even in remote areas without cell coverage. Well, just dreaming...

You can't "fly blind" like that, the Bitcoin protocol doesn't work that way. Without access to transaction data you can't build a valid spend that will be accepted by the network. However, nothing says you have to get transactions by downloading the block chain. They could be delivered via bluetooth or a wifi connection from a co-operating device.

Will do.

Maybe it could fly blind if I manually tell it how many coins there are on a key scanned.

Agreed, once Trezor et al are available it is only a matter of not having to buy a new device...

The Bluetooth channel will currently not be set up again.

However, you're right that you could also use the "transaction QR code" feature to submit a transaction. You can also use NFC. The problem with that is that QR codes are limited in size, so some transactions will not fit.

If this turns out to be a real problem, we can work on the bitcoinj default coin selector to not build transactions exceeding a given byte size.

Why don't you just try it out? I'd be interested in real feedback.

What phelix is proposing should work fine, we can always fix bugs in the Bluetooth code if there are any.

The missing piece is getting money into the offline wallet. You need the ability to sync a wallet online without any private keys (bitcoinj can do this, but currently the Android app can't), and then send the online/pubkey-only wallet to the cold storage device, and have the cold storage device do the merge.

This isn't technically very complicated, but I wonder how useful it really is given that we have the Trezor coming up. That seems like a more robust approach. I guess some people may have old phones lying around that they wouldn't mind using just as a wallet but I guess it's not so common.

Actually I would be more interested in the QR Code variant as I expect it to be still a little safer.

The way I understand you the problem is that the offline transaction can not be recreated. So what about manually taking a screenshot of the QR code to be able to retry the broadcast?

One could even create a stripped down, hardened rom (tinfoilrom).

In theory, this should be possible.

In practise, the current implementation is not designed for 100% robustness. If the Bluetooth submission fails for some reason, you'll need to connect to regular Bitcoin peers to get the tx through.

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

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.

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)?

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... )-:

Yes, send you a mail.


Yes, Galaxy S2 :-/

Sounds like a  bug. Is it reproducable?


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.

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

Thanks, fixed.

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.

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.