Idea: Offline portable wallet

[neoranga]

First I'll explain the problem and then my proposed solution:
The problem is that if you want to go on holidays or somewhere where you don't have data connection in your cellphone (ey! I'm on holidays in Berlin http://tinyurl.com/bwg33vf and I want to use my bitcoins), it's not possible to pay in any shop where they accept Bitcoins because you can't broadcast the transaction from your cellphone.

Of course, you can access WiFi or pay the data-roaming cost but I imagine a much easier scenario for the end user by using the shop's Point of Sell to broadcast the transaction. Here is the explanation:
1. When paying, the user scans the QR code of the shop address where the payment has to be sent to
2. The user includes the amount to pay and signs the transaction in the phone (android/iphone/etc) wallet
3. Now the transaction gets converted into a transaction QR code in the user's phone -> Offline broadcasting
4. The shop seller can now scan the transaction QR code in the shop's POS which has to be connected to internet
5. The shop's POS broadcast the client's transaction and immediately verifies the payment


Remarks:
- Size of transaction: QR codes can't handle too much data (less than 3Kb according to http://www.qrcode.com/en/faq.html) but if the user were to use a specific address only for this offline portable wallet, like the physical wallet you take with you, the transaction size should be quite small as there is only one address to take the funds from and one to send funds to (usually).
- Security: The portable wallet should have it's own address and private key separated from the rest of the wallets, therefore, if the phone gets compromised/stolen, only one address with the day to day cash amount is lost.


This is very similar to what Armory is currently doing for offline wallets but the transference method through usb stick is not as simple as the QR code, specially in the mobile environment. I haven't seen this already implemented in any of the wallets but maybe I'm mistaken and some android wallet is already able to do this transference of offline transactions.


Let me know what you think of the idea and if there is any extra trouble you can think of.

[1713557201]

1713557201

[1713557201]

1713557201

[1713557201]

1713557201

[1713557201]

1713557201

[zackclark70]

you might beable to add to my thred https://bitcointalk.org/index.php?topic=226582.0
i am open to ideas

[Stephen Gornick]

This is very similar to what Armory is currently doing for offline wallets but the transference method through usb stick is not as simple as the QR code,

But Armory's offline signing isn't standalone.

That's all the offline computer does:  lets you confirm the transaction details, and sign it.  

It still needs the connected instance to create the unsigned transaction which is than brought over to the offline system for signing.

And here's the reason you wouldn't want to trust the merchant to build the unsigned transaction for you:
 - http://bitcointalk.org/index.php?topic=68482.msg1187718#msg1187718

I haven't looked at this closely but the approach is interesting

VisualBTC - Android-based hardware offline wallet using animated QR codes
 - http://bitcointalk.org/index.php?topic=210371.0

[neoranga]

This is very similar to what Armory is currently doing for offline wallets but the transference method through usb stick is not as simple as the QR code,

But Armory's offline signing isn't standalone.

That's all the offline computer does:  lets you confirm the transaction details, and sign it.  

It still needs the connected instance to create the unsigned transaction which is than brought over to the offline system for signing.

And here's the reason you wouldn't want to trust the merchant to build the unsigned transaction for you:
 - http://bitcointalk.org/index.php?topic=68482.msg1187718#msg1187718

I haven't looked at this closely but the approach is interesting

VisualBTC - Android-based hardware offline wallet using animated QR codes
 - http://bitcointalk.org/index.php?topic=210371.0

Thanks for the feedback, very interesting limitation and great to see that someone already put the idea to practice.

[Preschoolv2]

https://bitcoinpaperwallet.com/

[neoranga]

https://bitcoinpaperwallet.com/

This link has not much to do with the problem proposed in the thread 

[CIYAM]

The CIYAM Safe project on github (https://github.com/ciyam/safe) has some scripts and tools to do offline tx signing with QR codes (also combined with GPG for greater security).

I also put together a SUSE Studio distro (http://susestudio.com/a/kp8B3G/ciyam-safe) which incorporates those tools along with Bitcoin, Vanitygen and a number of other packages and projects (sorry but the distro is not very small).

Welcome to use anything there that might be of help (I use this distro and and old laptop with no networking capability to handle offline tx signing).

[apetersson]

We are working furiously on the Mycelium Bitocoincard that will enable true offline payments - and also hybrid solutions where one party is online.

For internet connectivity with smartphones among bitcoiners, i would suggest Opengarden. their philosophy aligns very much with Bitcoin.

For situations where the merchant is online and the customer just wants to sign+send a transaction, i can imagine that there will be a way to do this via bluetooth or even NFC somehow.

[zackclark70]

why cant you load a wallet onto a blank credit card ?

[Cyberdyne]

Remarks:
- Size of transaction: QR codes can't handle too much data

How about animated QR codes? I know they are not common yet, and demos of such have shown very slow frame rates, but even 0.5 fps should be fine to flip through a few QR frames and have the reader pick up ~3kb per frame.

[CIYAM]

Remarks:
- Size of transaction: QR codes can't handle too much data

How about animated QR codes?

Firstly they can handle maybe more than many people think (8K or more depending upon the resolution available to scan).

Also - animated works perfectly - I actually have utilised an old "book reader" (with no internet capability or changeable OS) as a way of transferring multiple GPG encrypted private keys from an offline PC to an online one (I do this using its "slideshow" mode for displaying pics achieving around 8K per second - not very fast but that's the fastest it allows a slideshow to work).

[Cyberdyne]

Remarks:
- Size of transaction: QR codes can't handle too much data

How about animated QR codes?

Firstly they can handle maybe more than many people think (8K or more depending upon the resolution available to scan).

Also - animated works perfectly - I actually have utilised an old "book reader" (with no internet capability or changeable OS) as a way of transferring multiple GPG encrypted private keys from an offline PC to an online one (I do this using its "slideshow" mode for displaying pics achieving around 8K per second - not very fast but that's the fastest it allows a slideshow to work).

That would be plenty - you could have 24Kb transferred within a few seconds.

[CIYAM]

That would be plenty - you could have 24Kb transferred within a few seconds.

Indeed I don't know why so many people are *against* using QR codes (seems to be some sort of strange anti-technology thing).

BTW - https://bitcointalk.org/index.php?topic=257246.0

I think that QR + GPG can go a long way towards changing things.

[neoranga]

I have nothing against using multiple QR codes, maybe in addition to animation you can even pack several QR codes in one single screen scan, today phone cameras have enough resolution for it and a tablet screen is big enough for 4 QR codes.

[Valle]

You forgot that client is in offline, so it doesn't know what his outputs are available for spending. In this case you have to do 4(!!!) qr codes scans to perform a transaction:
online POS ->(amount to pay) offline client
client -> (payment address/addresses) POS
POS ->(transaction to sign) client
client ->(signed transaction) POS

[Andreas Schildbach]

1. When paying, the user scans the QR code of the shop address where the payment has to be sent to
2. The user includes the amount to pay and signs the transaction in the phone (android/iphone/etc) wallet
3. Now the transaction gets converted into a transaction QR code in the user's phone -> Offline broadcasting
4. The shop seller can now scan the transaction QR code in the shop's POS which has to be connected to internet
5. The shop's POS broadcast the client's transaction and immediately verifies the payment

Let me know what you think of the idea and if there is any extra trouble you can think of.

This idea is implemented in Bitcoin Wallet since about 2 years.

You can even use NFC for transmitting Bitcoin requests and transactions.

Problem using QR: Some transactions are too big (in bytes) for QR codes.

There is even a branch "bluetooth-offline-payments" that pairs a Bluetooth channel with requesting Bitcoins and uses that for sending the tx. Advantage: You don't need to scan a code twice (or use NFC twice).

[CIYAM]

You divide the work up into online and offline parts so you only generally need 2 QR codes - one for the unsigned raw tx to send to the offline computer and one to send back the signed raw tx.

If a tx has numerous UTXOs then it may have to be divided up into multiple QR codes (not having numerous tiny UTXOs I've never had this problem).

[niko]

First I'll explain the problem and then my proposed solution:
The problem is that if you want to go on holidays or somewhere where you don't have data connection in your cellphone (ey! I'm on holidays in Berlin http://tinyurl.com/bwg33vf and I want to use my bitcoins), it's not possible to pay in any shop where they accept Bitcoins because you can't broadcast the transaction from your cellphone.

Of course, you can access WiFi or pay the data-roaming cost but I imagine a much easier scenario for the end user by using the shop's Point of Sell to broadcast the transaction. Here is the explanation:
1. When paying, the user scans the QR code of the shop address where the payment has to be sent to
2. The user includes the amount to pay and signs the transaction in the phone (android/iphone/etc) wallet
3. Now the transaction gets converted into a transaction QR code in the user's phone -> Offline broadcasting
4. The shop seller can now scan the transaction QR code in the shop's POS which has to be connected to internet
5. The shop's POS broadcast the client's transaction and immediately verifies the payment


Remarks:
- Size of transaction: QR codes can't handle too much data (less than 3Kb according to http://www.qrcode.com/en/faq.html) but if the user were to use a specific address only for this offline portable wallet, like the physical wallet you take with you, the transaction size should be quite small as there is only one address to take the funds from and one to send funds to (usually).
- Security: The portable wallet should have it's own address and private key separated from the rest of the wallets, therefore, if the phone gets compromised/stolen, only one address with the day to day cash amount is lost.


This is very similar to what Armory is currently doing for offline wallets but the transference method through usb stick is not as simple as the QR code, specially in the mobile environment. I haven't seen this already implemented in any of the wallets but maybe I'm mistaken and some android wallet is already able to do this transference of offline transactions.


Let me know what you think of the idea and if there is any extra trouble you can think of.

With Mycelium, I can move funds to one my addresses, then export its private key as an on-screen QR code. The merchant, assuming they are prepared for this, scans the code and spends it away into their system.

Other private keys are not exposed. Any problems with this solution?

[neoranga]

First I'll explain the problem and then my proposed solution:
The problem is that if you want to go on holidays or somewhere where you don't have data connection in your cellphone (ey! I'm on holidays in Berlin http://tinyurl.com/bwg33vf and I want to use my bitcoins), it's not possible to pay in any shop where they accept Bitcoins because you can't broadcast the transaction from your cellphone.

Of course, you can access WiFi or pay the data-roaming cost but I imagine a much easier scenario for the end user by using the shop's Point of Sell to broadcast the transaction. Here is the explanation:
1. When paying, the user scans the QR code of the shop address where the payment has to be sent to
2. The user includes the amount to pay and signs the transaction in the phone (android/iphone/etc) wallet
3. Now the transaction gets converted into a transaction QR code in the user's phone -> Offline broadcasting
4. The shop seller can now scan the transaction QR code in the shop's POS which has to be connected to internet
5. The shop's POS broadcast the client's transaction and immediately verifies the payment


Remarks:
- Size of transaction: QR codes can't handle too much data (less than 3Kb according to http://www.qrcode.com/en/faq.html) but if the user were to use a specific address only for this offline portable wallet, like the physical wallet you take with you, the transaction size should be quite small as there is only one address to take the funds from and one to send funds to (usually).
- Security: The portable wallet should have it's own address and private key separated from the rest of the wallets, therefore, if the phone gets compromised/stolen, only one address with the day to day cash amount is lost.


This is very similar to what Armory is currently doing for offline wallets but the transference method through usb stick is not as simple as the QR code, specially in the mobile environment. I haven't seen this already implemented in any of the wallets but maybe I'm mistaken and some android wallet is already able to do this transference of offline transactions.


Let me know what you think of the idea and if there is any extra trouble you can think of.

With Mycelium, I can move funds to one my addresses, then export its private key as an on-screen QR code. The merchant, assuming they are prepared for this, scans the code and spends it away into their system.

Other private keys are not exposed. Any problems with this solution?

How do you transfer the exact amount you have to pay to the merchant to one of your addresses if you don't have network connection in the shop?
Giving a merchant the private key of an address with a random amount of bitcoins is basically like opening your wallet to the merchant and asking him/her to take the money from your wallet while you look away...

[niko]

I should have gotten some sleep before posting