Idea: Offline portable wallet | Bitcointalksearch.org

niko

hero member

Activity: 756

Merit: 501

There is more to Bitcoin than bitcoins.

Quote from: neoranga on August 12, 2013, 02:39:24 AM

Let's make some numbers on this solution as an example:
1- Let's say I want to move on the street with my wallet fill with 100$ in bitcoin (whatever is the exchange rate that day) for my day to day usage.
2- This translated to bitcoins will mean I'll need to have enough addresses with me to create transactions that can go as high as 100$ and as low as 10 cents (we don't want to give away too much change on every transaction)
3- The total amount of addresses will be 1000

This is possible but I imagine the fees that go into creating the daily wallet (or every time you have to get another 100$ for the bitcoin ATM) will not be trivial. In addition, the size of each transaction combining several addresses into one payment means there will be a lot of QR codes sent and waiting a long time for the camera to recognize all of them (up to 1000 addresses in one transaction to pay something of 100$).

No need for a 1000 addresses in this scenario. For each purchase, you will need to have ready only 10 keys: 10, 20, 40, 80 cents, and $1.60, $3.20, $6.40, $12.80, $25.60, and $51.20. This minimizes the number of inputs to a transaction, thus minimizing the fees. It requires you to carry a total which is N*Pmax, where N is the anticipated maximum number of purchases, and Pmax is the maximum price of a single purchase - all divided in the geometric series, as above. This is not a problem (either way you can run out of money, right?), except a risk of higher loss if you get robbed at a knife point and forced to reveal the PIN or whatever secures your wallet. Chances are, the robber won't even know you've got bitcoins, so no real danger there today.

Once you are back online, you can refill the binary bins as needed, adjusting N and Pmax for that day. I have not gotten enough sleep again, so somebody else please try to build a model to evaluate the overall TX fees in this whole story. Does it even make things better?

neoranga

newbie

Activity: 50

Merit: 0

Quote from: ffcitatos on August 09, 2013, 09:54:11 AM

Quote from: niko on July 31, 2013, 04:34:56 PM

I should have gotten some sleep before posting

Sorry for resurrecting an old thread but I think this is not that stupid after all (not an elegant solution either, I admit).

As far as I understand, an implementation of niko's solution would be to maintain a list of 50 addresses of 0.01 BTC in each one of them (generated at home), and give the required number
of them in the form of QR codes to the seller (who typically is a brick-and-mortar with internet connection) . Assuming that

1. there are no problems with network fees

and

2. rounding error of <1$ is acceptable to either the seller and the buyer

this would work nicely

Let's make some numbers on this solution as an example:
1- Let's say I want to move on the street with my wallet fill with 100$ in bitcoin (whatever is the exchange rate that day) for my day to day usage.
2- This translated to bitcoins will mean I'll need to have enough addresses with me to create transactions that can go as high as 100$ and as low as 10 cents (we don't want to give away too much change on every transaction)
3- The total amount of addresses will be 1000

This is possible but I imagine the fees that go into creating the daily wallet (or every time you have to get another 100$ for the bitcoin ATM) will not be trivial. In addition, the size of each transaction combining several addresses into one payment means there will be a lot of QR codes sent and waiting a long time for the camera to recognize all of them (up to 1000 addresses in one transaction to pay something of 100$).

ffcitatos

member

Activity: 71

Merit: 10

Quote from: niko on July 31, 2013, 04:34:56 PM

I should have gotten some sleep before posting

Sorry for resurrecting an old thread but I think this is not that stupid after all (not an elegant solution either, I admit).

As far as I understand, an implementation of niko's solution would be to maintain a list of 50 addresses of 0.01 BTC in each one of them (generated at home), and give the required number
of them in the form of QR codes to the seller (who typically is a brick-and-mortar with internet connection) . Assuming that

1. there are no problems with network fees

and

2. rounding error of <1$ is acceptable to either the seller and the buyer

this would work nicely

niko

hero member

Activity: 756

Merit: 501

There is more to Bitcoin than bitcoins.

I should have gotten some sleep before posting

neoranga

newbie

Activity: 50

Merit: 0

Quote from: niko on July 31, 2013, 11:46:41 AM

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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

hero member

Activity: 756

Merit: 501

There is more to Bitcoin than bitcoins.

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

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

Andreas Schildbach

hero member

Activity: 483

Merit: 551

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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

Valle

full member

Activity: 177

Merit: 101

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

neoranga

newbie

Activity: 50

Merit: 0

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.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Cyberdyne on July 17, 2013, 08:29:22 AM

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://bitcointalksearch.org/topic/going-offline-a-different-approach-for-a-future-hardware-device-257246

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

Cyberdyne

hero member

Activity: 630

Merit: 500

Quote from: CIYAM on July 17, 2013, 08:01:19 AM

Quote from: Cyberdyne on July 17, 2013, 07:40:14 AM

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Cyberdyne on July 17, 2013, 07:40:14 AM

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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

hero member

Activity: 630

Merit: 500

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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.

zackclark70

legendary

Activity: 868

Merit: 1000

ADT developer

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

apetersson

hero member

Activity: 668

Merit: 501

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.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

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

neoranga

newbie

Activity: 50

Merit: 0

Quote from: Preschoolv2 on June 09, 2013, 04:15:11 PM

https://bitcoinpaperwallet.com/

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

Preschoolv2

newbie

Activity: 14

Merit: 0

https://bitcoinpaperwallet.com/

neoranga

newbie

Activity: 50

Merit: 0

Quote from: Stephen Gornick on June 09, 2013, 11:35:46 AM

Quote from: neoranga on June 09, 2013, 07:38:49 AM

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.

Quote from: etotheipi on June 05, 2013, 08:26:11 AM

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:
- https://bitcointalksearch.org/topic/m.1187718

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

VisualBTC - Android-based hardware offline wallet using animated QR codes
- https://bitcointalksearch.org/topic/ann-visualbtc-android-based-hardware-offline-wallet-using-animated-qr-codes-210371

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

Topic: Idea: Offline portable wallet (Read 3509 times)