(slightly) Simpler store pay method

[nelisky]

I was walking around a Mall and thought this up, probably based on ideas stolen here and there on these fora.

An android (or whatever you smartphone flavor is) app that is capable of generating bitcoin keys, and knows a little bit about encryption. The idea depends on thick clients both at home and in store, but the 'wallet' becomes much simpler to handle:

I have 100 btc on my osx bitcoin client, and I'm going out on a shopping spree. I'm not taking everything with me, I guess 20 btc is enough for what I'm doing anyway, so I pair my phone and my computer and press 'load 20 btc into phone wallet'. There is a static 'change' address associated with the phone wallet.

Getting to the store, I buy some porn^H^H^H^H educational dvds and head to the teller, where they say my total is 17.85 BTC. I punch that value into my wallet app, enter my pin and a QR code appear. The store scans it and I get my receipt.

At home I see I have .15 in my change address, and linking the phone to the computer I click 'empty wallet' (that name is really scary) and 2 BTC are moved to the computer wallet.

---

So what happened behind the scene?
- Loading BTC into the phone wallet: The phone generated 20 addresses, stored the priv keys pin encrypted and gave the adresses to the thick client, which transfered 1 BTC to each of these, thus putting a total of 20 BTC in. The 'change' address is set if not already so.
- Paying on the store: When we punch in 17.85, and having 1 BTC on each address, the app provides 18 priv keys in the QR code (or codes, probably need more than one) along with the change address. The store scans, imports addresses and transfers to their own key. Maybe wait a few confirms, maybe not, depending on the value of the tx? Because they received 18 BTC they then send the change to the set address.
- At home, the list of pub keys is sent to the thick client, it checks the balance on each address and cross references with what the phone app says happened. It identifies the two addresses that still have a balance and requests the priv keys for these, transfering to the change address.

So the addresses generated by the phone are really 'use and throw away', and all the phone needs to do is manage what addresses have balance available. Not good for full offline use, but you don't need to have a bitcoin client on the phone, and frankly you don't even need the phone, but it does provide some security as the priv keys are always kept encrypted and you can even use multiple amounts per address, just like paper bills, and have a different pin for each value (say 50x1BTC + 3x10BTC + 1x20BTC, that would be 3 pins).

Just an idea, didn't quite think this through, but this could easily be implemented that much I'm sure of.

[ineededausername]

This is one way to avoid the confirmations problem... By the time you get to the cashier the 1 BTC stored in each of those throwaway addresses already has 2 or 3 confirmations, which is pretty secure.

[Steve]

Neat idea!

I think you could improve upon it in this way:
- move 20 BTC into a single address for which the phone has the private key
- upon payment, the phone generates a new address and private key and moves the exact amount owed to that address (with change sent back to the original address)
- a QR code with that transaction and the private key is presented to the merchant (not sure if that would be too much to put into a single QR code)
- merchant publishes this funding transaction and a new transaction that sweeps the funds using the private key

There is no need for the phone to have good internet connectivity at the point of sale and you don't have to trust the merchant to provide change.  The merchant can also tack on whatever transaction fee to the sweep transaction that they think is necessary for the transactions to be included in the block chain in a timely fashion.  The merchant software can clear this transaction in just a few seconds by announcing and monitoring that a high percentage of nodes agree that they are valid transactions.

You can also make it such that the wallet software keeps a backup of original key on the phone (in case you lose your phone, you could have your wallet sweep everything that was on the phone and not lose any BTC).

P.S.  You can also make it so the funding of the phone can be done wirelessly and remotely (with a wallet that is in some way remotely accessible).  I think this solves an issue with the phone requiring connectivity right at the moment of the sale.  There are plenty of times when I've wanted to access a web site and my provider's mobile internet wasn't behaving well (or I happened to be in a dead zone).  Loading up a few spending bitcoins ahead of time is perfect if you have the ability to do it even while roaming about.

[nelisky]

I think you could improve upon it in this way:
- move 20 BTC into a single address for which the phone has the private key
- upon payment, the phone generates a new address and private key and moves the exact amount owed to that address (with change sent back to the original address)
- a QR code with that transaction and the private key is presented to the merchant (not sure if that would be too much to put into a single QR code)
- merchant publishes this funding transaction and a new transaction that sweeps the funds using the private key

Well, this kind of defeats the purpose of the thin phone app, which is to have very little logic and no connectivity requirements at the store. The use case I have is pretty simple, I travel a lot and don't have wifi / 3G available everywhere. On the other hand merchants are mostly static and have connectivity, so...

There is no need for the phone to have good internet connectivity at the point of sale and you don't have to trust the merchant to provide change.  The merchant can also tack on whatever transaction fee to the sweep transaction that they think is necessary for the transactions to be included in the block chain in a timely fashion.  The merchant software can clear this transaction in just a few seconds by announcing and monitoring that a high percentage of nodes agree that they are valid transactions.

Yep, the merchant certainly has the tools to be able to have a good level of confidence on the collected funds. And if you take out the outrageous fees credit card companies charge them, as well as all the chargebacks, I'm sure merchants would be happy to suck up the fees to have faster block inclusions. This could very well be the leverage needed to increase the fee per block to a place where it becomes interesting for miners.

You can also make it such that the wallet software keeps a backup of original key on the phone (in case you lose your phone, you could have your wallet sweep everything that was on the phone and not lose any BTC).

Yep, that is a great idea, I'd say that is pretty much mandatory.

P.S.  You can also make it so the funding of the phone can be done wirelessly and remotely (with a wallet that is in some way remotely accessible).  I think this solves an issue with the phone requiring connectivity right at the moment of the sale.  There are plenty of times when I've wanted to access a web site and my provider's mobile internet wasn't behaving well (or I happened to be in a dead zone).  Loading up a few spending bitcoins ahead of time is perfect if you have the ability to do it even while roaming about.

With the backup and encryption, we could go as far as having the phone part be completely dumb. The thick client generates 10k addresses, encrypts the priv keys and provides encryptedpriv+addr+balance to the phone. The phone limits its action to managing the payments. No network on the go needed, ever, to handle these wallets. The only caveat, which already existed with my original approach, is that is I double spend (human error, software bug, malice, whatever) the merchant will collect 18 priv keys and realize one is empty, thus requests another one from me. At this point I refuse to pay (or I don't have any more btc available) and go home... both myself and the merchant hold the priv keys, and this opens a trust problem.

Proving the address had balance and it was in fact the merchant that stole is pretty easy, just look at the blockchain timestamps, but with no central authority I screwed nonetheless. Though I'm sure the merchant would not get any more business from me or any of my peers, which might be enough security right there.

[hashman]

This eliminates the need for connectivity on one of the devices, but doesn't eliminate the need to wait for confirmations. 

It seems the only way to decrease POS time is to use a trusted third party. 

Don't forget that when you get home and find your new videos are fakes you are SOL.  Should have paid that extra few percent to a third party for fraud prevention  

 

[nelisky]

This eliminates the need for connectivity on one of the devices, but doesn't eliminate the need to wait for confirmations. 

It seems the only way to decrease POS time is to use a trusted third party. 

Don't forget that when you get home and find your new videos are fakes you are SOL.  Should have paid that extra few percent to a third party for fraud prevention  

I'm well aware of that, and that is not the case I'm trying to address at all. Ignore the educational videos, think about starbucks, a restaurant or a bookstore. Or any big chain that you already "trust".

[Steve]

This eliminates the need for connectivity on one of the devices, but doesn't eliminate the need to wait for confirmations. 

It seems the only way to decrease POS time is to use a trusted third party. 

You do not need to wait for confirmations...using a trusted third party has its risks as well.  If you wait on network acknowledgement of a transaction for just a few seconds, the risk of it being a double spend drops very substantially.  So close to zero that for small transactions, there's no need to wait on a block.  You will also be able to get insurance against losses under those circumstances.

Don't forget that when you get home and find your new videos are fakes you are SOL.  Should have paid that extra few percent to a third party for fraud prevention  

You mean just like when you pay with cash?

[the founder]

honestly this already exists in terms of a ewallet.   Just put your 20 coins there...  access your ewallet when your shopping via your iPhone / Android / whatever..  and when your done you can just dump what's left on the ewallet back to your desktop.   All the features you just described are already on most ewallets..

[Steve]

honestly this already exists in terms of a ewallet.   Just put your 20 coins there...  access your ewallet when your shopping via your iPhone / Android / whatever..  and when your done you can just dump what's left on the ewallet back to your desktop.   All the features you just described are already on most ewallets..

No, it's not the same thing.  The solution being discussed here does not require a third party that has control over private keys.  It also does not require the buyer to have an internet connection at the point of sale.

[the founder]

honestly this already exists in terms of a ewallet.   Just put your 20 coins there...  access your ewallet when your shopping via your iPhone / Android / whatever..  and when your done you can just dump what's left on the ewallet back to your desktop.   All the features you just described are already on most ewallets..

No, it's not the same thing.  The solution being discussed here does not require a third party that has control over private keys.  It also does not require the buyer to have an internet connection at the point of sale.

Yes it does.. someone needs internet access to send those coins over the blockchain....  I guess only the merchant needs it in that case?   Wait.. I see what you're saying...  since it goes over QR to the merchant he's the one that would need it only?   I'm still fuzzy on how it would transfer however in that case?

[MoonShadow]

If you mean that the QR code scanned is a transaction itself, then there isn't enough screenspace to produce a QR code large enough to reliablely hold a transaction.  But nor would it be necessary, if an android client were developed with my original specs for the bounty.  Namely the ability to directly commune with another client; such as by multicast over a shared open hotspot (internet connection helpful, but not necessary), bluetooth or (ideally) Dash7.

[the founder]

If you mean that the QR code scanned is a transaction itself, then there isn't enough screenspace to produce a QR code large enough to reliablely hold a transaction.  But nor would it be necessary, if an android client were developed with my original specs for the bounty.  Namely the ability to directly commune with another client; such as by multicast over a shared open hotspot (internet connection helpful, but not necessary), bluetooth or (ideally) Dash7.

see that's what my point was..   ideally something like that would work,  but in practice I see it being a huge cumbersome process that most likely won't work.

I hope they prove me wrong because I would love to see something like this happen...

[MoonShadow]

If you mean that the QR code scanned is a transaction itself, then there isn't enough screenspace to produce a QR code large enough to reliablely hold a transaction.  But nor would it be necessary, if an android client were developed with my original specs for the bounty.  Namely the ability to directly commune with another client; such as by multicast over a shared open hotspot (internet connection helpful, but not necessary), bluetooth or (ideally) Dash7.

see that's what my point was..   ideally something like that would work,  but in practice I see it being a huge cumbersome process that most likely won't work.

What won't work?  The cumberson process part is mostly automated, much like it is with credit cards today, just different.  In person & off network transactions might never come to pass, but it won't be because the process is cumbersome.  Stop and think about what you have to do to buy a Big Mac with a credit or debit card.  Nifty commericals aside, it's significantly less cumbersome for a customer to pay in cash than use a CC at McD's, yet people do it daily.

[Steve]

If you mean that the QR code scanned is a transaction itself, then there isn't enough screenspace to produce a QR code large enough to reliablely hold a transaction.  But nor would it be necessary, if an android client were developed with my original specs for the bounty.  Namely the ability to directly commune with another client; such as by multicast over a shared open hotspot (internet connection helpful, but not necessary), bluetooth or (ideally) Dash7.

That might be better than requiring internet connectivity, but it could still present a problem if the buyer has to set something up to do the communications.  I'm interested in the potential of a solution that requires no communications at all other than the display. 

The transaction would be about 300 bytes (1 input, 2 outputs).  The private key is 32 bytes.  I think you might be able to do that reliably on a typical smartphone screen with 8 bit encoding.

[nelisky]

I think my original idea is much simpler than what is being depicted. You know how mtgox allows you to enter a privkey and they import that key and transfer whatever bitcoins are there into your account? Same thing, except mtgox becomes starbucks.

Yes, the merchant will need internet and bitcoin, but it can be as blackboxed or open as required, that's not the point. The real point is me, the client, don't need to have internet or a bitcoin client on my phone to make payments in bitcoin, and I also don't need to use or trust 3rd parties to hold my wallet, and frankly no change to the protocol and almost no change to the bitcoin client is needed.

This is very 'low tech', we're not sharing transactions, just bitcoin keys, and in a controlled way, so if I'm paying 17.85 and I share the priv keys to 18 btc with the merchant, that's the extent of what they can steal, even if I have 1000 btc in priv keys on my phone. The time to market on such a solution is very small and although it is not by any means perfect, still leaving the door open for a number of attacks, it is something anyone with a smartphone and a computer can use without any technical knowledge of what's going on behind the scenes. Hell, my father would be able to use this, if he had a smartphone that is

As for the merchant side, if you can convince one major merchant to use bitcoins and they understand what these are, 80% of the hard work is already done. I could easily tweak the standard bitcoin client to operate on both the client and the merchant side as described. Why didn't I do it? Sheer lack of time, but if enough people agree with the idea and noone else takes the lead I'll be glad to take a stab at it, just find me a physical brick and mortar store willing to try it out

Or I may be full of hot air, it is Friday...

[nelisky]

Oh, and just to stress this point a bit more, the reason you can (could, to be honest, most places don't do it anymore) do offline transactions with credit cards is because the credit card company holds both sides of the deal in a tight grip; if the client didn't have enough credit, they'll not only allow the charge but also add fees and taxes to the client for going over the limit, and if the merchant did something bad, they keep the transactions hostage for a couple of weeks anyway, so they'll collect to repay the client without any extra cost to them.

That and they charge huge fees to both sides too, so they have plenty of leverage.

[MoonShadow]

If you mean that the QR code scanned is a transaction itself, then there isn't enough screenspace to produce a QR code large enough to reliablely hold a transaction.  But nor would it be necessary, if an android client were developed with my original specs for the bounty.  Namely the ability to directly commune with another client; such as by multicast over a shared open hotspot (internet connection helpful, but not necessary), bluetooth or (ideally) Dash7.

That might be better than requiring internet connectivity, but it could still present a problem if the buyer has to set something up to do the communications.  I'm interested in the potential of a solution that requires no communications at all other than the display. 

Then what does the vendor use to accept the QR code and bitcoin transaction, if he isn't willing to set up any bitcoin infrastructure at all?  A single wifi access point, whether connected to the POS computer, directly to the Internet, or stand alone in a piratebox setup (http://wiki.daviddarts.com/PirateBox) is still cheaper infrastructure than even the smartphone capable of running bitcoin.  And such a access point could serve the entire store.  If it's just two people with smartphones selling/buying something on Craigslist, one person with a piratebox and zero connectivity would still be workable.  If smartphones were to commonly have Dash7 radios in the future, even the piratebox would be unnecessary.  But no matter how you do it, there has to be some kind of bitcoin infrastructure at the vendor's POS, even if it's just a QR payment address sticker on the back of the POS register connected to an online wallet system.

[MoonShadow]

This is very 'low tech', we're not sharing transactions, just bitcoin keys, and in a controlled way, so if I'm paying 17.85 and I share the priv keys to 18 btc with the merchant, that's the extent of what they can steal, even if I have 1000 btc in priv keys on my phone. The time to market on such a solution is very small and although it is not by any means perfect, still leaving the door open for a number of attacks, it is something anyone with a smartphone and a computer can use without any technical knowledge of what's going on behind the scenes. Hell, my father would be able to use this, if he had a smartphone that is

I think I get it now, so you are sharing a single private key with the QR code, and trusting the vendor to give you back your change to a change address, then?  Much like one trusts the cashier at Starbucks to give back the change of the $20 bill.  The full client at home that you got the change return address from would have to be able to send your phone a text when it saw the change, so that you knew that it happened, but that would be trivial if the need was there.  You can't walk away from the POS, not get your change, and come back expecting anyone is going to believe you if there is a failure.  I can see how this could work with small amounts and trusted vendors.

[TTBit]

Love the idea. I have noticed a trend over the last year from keeping private keys "private" - no matter what, into another way to exchange information.

In a way, I just did this. I loaded up a bitaddress paper wallet with 5 btc each (x7), and sold one of the qr codes. He inputted into strongcoin and was able to send immediately (iirc?).

[TTBit]

Getting to the store, I buy some porn^H^H^H^H educational dvds and head to the teller, where they say my total is 17.85 BTC. I punch that value into my wallet app, enter my pin and a QR code appear. The store scans it and I get my receipt.

To take it one step further... why not just scan it on the shelf and walk out? It's now yours. Eliminate the middle man.