Topic: PaperCoins (Read 4126 times)
Seems like a pretty good idea, I just wish more store accepted bitcoins
It's better (and cool) but I think it's a little too complicated to use (for both the buyer and the seller). A different paper layout that hides the QR code is much easier to do and offers the same security.
I wonder if a better scheme might be to print papercoin QR codes in invisible ink.
You only need a UV light to scan it.
http://www.lifehack.org/articles/lifehack/how-to-make-invisible-ink-for-ink-jet-printers.html
You only need a UV light to scan it.
http://www.lifehack.org/articles/lifehack/how-to-make-invisible-ink-for-ink-jet-printers.html
I was also trying to decide if its worth having it laid out so you can fold the note to cover the private key.
If you get a nice design, please post it. In the mean time, I got my hands on a business card holder that opens on a side, so I can put the bills with the qr code first. When I need one, I only extract haft the bills, enough to see the numbers on them, but not also the QR code. If someone can manage to steal the key in this way, they deserve the coins
I'd be happy with improved CSS for bitaddress.org I started playing around with the paper wallet layout, but couldn't come up with anything I liked more.
I was also trying to decide if its worth having it laid out so you can fold the note to cover the private key.
I was also trying to decide if its worth having it laid out so you can fold the note to cover the private key.
+1 i would like that too
I'd be happy with improved CSS for bitaddress.org I started playing around with the paper wallet layout, but couldn't come up with anything I liked more.
I was also trying to decide if its worth having it laid out so you can fold the note to cover the private key.
I was also trying to decide if its worth having it laid out so you can fold the note to cover the private key.
The idea that someone could use a URL to their own server is a credible concern and not a whole lot can be done to stop it.
EV SSL (https with green bar) would help but surely there's a lot of people who wouldn't know to look or notice.
Idea would still work among known/trusted trading partners and as a proof of concept, but no magic bullet.
EV SSL (https with green bar) would help but surely there's a lot of people who wouldn't know to look or notice.
Idea would still work among known/trusted trading partners and as a proof of concept, but no magic bullet.
Something else I've also been thinking about: wouldn't bitcoin debit cards function in much the same way as a bitcoin bill? Instead of having the private key written onto the paper, it would be electronically stored on the card. The data on the card would be encrypted and the PIN could be the key to decrypt it. The public address would be written on the front of the card, and you could refill the card simply by sending funds to that address. The card would have no expiry date. The card would only be a one time purchase. Are there any projects like this?
edit: I found this but not sure how trustworthy it is.
edit: I found this but not sure how trustworthy it is.
Also comitted a proposal for the QR code format: https://github.com/ovidiusoft/bitcoin-scripts/blob/master/PaperCoins/QR-code-format.txt
If includes the URL field proposed by casascius, and a few others. Don't take it as a full proposal, it's basically just a bunch of random ideas, with the only intention of starting a discussion. I'll post some scripts that produce the new QR codes soon.
So, waiting for your comments. As I said, I would love to get the attention of POS/client developers.
If includes the URL field proposed by casascius, and a few others. Don't take it as a full proposal, it's basically just a bunch of random ideas, with the only intention of starting a discussion. I'll post some scripts that produce the new QR codes soon.
So, waiting for your comments. As I said, I would love to get the attention of POS/client developers.
I comitted a new script for Electrum users at https://github.com/ovidiusoft/bitcoin-scripts/tree/master/PaperCoins . It's called papercoins-electrum.sh and can use your existing Electrum wallet to create, fund and make a PDF of your PaperCoins. It can either only generate the tx or also commit it to the network. Creates 2 files: the wallet (you can use it later to get back funds if you didn't use the PaperCoins) and the PDF to print. It can take a random number of arguments (the amounts). Here's a sample run for only 1 PaperCoin:
At the moment, it requires a patched electrum client (it's in the same dir). Read the README file for more information.
I hope this POC will attract some developers who will want to integrate a PaperCoins feature in their clients
Code:
$ ./papercoins-electrum.sh 0.0001
Will create 1 PaperCoins, with values of 0.0001 for a total of .0001 BTC.
Electrum wallet balance: 0.0053
Creating new wallet (default values, 1 addresses): PaperCoins-1327998249.wallet
Your seed is 0d9324da5b6a34236a2c4c26dab02563
Please store it safely
1M2ZUxZBNgfKkAAXZszNrJEjocqz4qqA5
1GQ6C4RhFb17ALoULnXqefkmA32RwR6L3c
Funding the PaperCoins.
===[ Transaction to fund PaperCoin #1 (0.0001 BTC, address 1GQ6C4RhFb17ALoULnXqefkmA32RwR6L3c) ]===
01000000067272ba77b911c5380d97928dc71967acbcda238cb6a4203aecacab045d520f44270000008c493046022100c17e8214792ba4f3bcc7a72bcf3fabf09b10cc7d297683ceaf75a3c48e54c276022100a79f233ac362f863dd0354a14f64b94cc5a450838707f70f8fc19949829b3cfa0141040027fa8d5f979fdb398b4fbdf44578cd70c525ada56ed55131f4b792caf237aea4c01fddd30483bb3f2cb578be484fdb687f90da208824040013056abce6038ffffffaaafff0a9574415ef55bca6c9bcb9f02bd4dcdef91de4f7ddad1f69b41d00b2aba95834b0000008b483045022100bd128f33870fb0451699d2d5c329300f7a453da7a61b11830976b667eabaf446022068b616470e882e21c4d45429a6ee604b49b9ce44dfbacc7ee5263f8e3332c0380141040027fa8d5f979fdb398b4fbdf44578cd70c525ada56ed55131f4b792caf237aea4c01f30483bb3f2cb578b1dee484fdb687f90da208824040013056abce6038fffffffff38649b74374d14ea9c7b465bec19ba49980c13b10ab1a6ffd81d9bae1238fa374c0100008b483045022100a4b6e90e6eeb03a9c85de16c6d6fd88b8fdc5a78ac50bca098e948dc43e8a85302206a383dab28416289e0d98f852dbc7e17bcf0796a203b8a6bd64110c27f85e01410405979236764b8b6bf5549f5a5e669f3d8bf651951b2138659a3a948b07edeaf437b89a2e6556dc551a3bca443647740a992deab6eb530101eb99c60a1b3f6b93ffffffffdc1d42b99a2c3b0cf4858a1d4131694efe11ce8c9b0abc33cb9aa1e546ede8f9010008b48aaa30450221008f2020fdac4bfcb36698a0c4475e056a72d72aaf986ade920679d52e350eec1502207ed0585563c66560dc173ddda34982db3421c2827d9c869af340767bbb2f24cf0141040da5b697f47fcf4c006977a7f543a4e054cae560d13f1260a73ee7ba7082d6eb1c6db38a1fa9d48409b2ea29c3786b783c191830e9eb31063395a77058309446ffffffff63c06e18a563e389873c20c142e75522bd265756614a1d196218b2b9219f8b7f270100008a47304402203cc5037eeb7594b8213a7d899ca603f8a855804067dcaeb108dbb53787edeae2022077f7d6e66cfff17d8ca7251185a5e5c4f4530b9ec2a3b0a27430996e5d423b6901410405979236764b8b6bf5549f5a5e669f3d8bf651951b2138659a3a948b07edeaf437b89a2e6556dc551a3bca443647740a992deab6eb530101eb99c60a1b3f6b93ffffffff88ba3187b4720034c54fd1814af40a0c9b09d6b67d4b4acdca93f25fb0788a5d430000008c493046022100ca5cab5770c08ea72a877d382b9e7405e85c5d9c4fce41df8d43a6d2660bee7e022100a16c029696194d5f3e7f3b8270001fbe6c028b4d59603ae15c3b04eb9c391e580141040027fa8d5f979fdb398b4fbdf44578cd70c525ada56ed55131f4b792caf237aea4c01f30483bb3f2cb578b1dee484fdb687f90da208824040013056abce6038fffffffff0210270000000000001976a914a8e7c96df1e0cb905dce42961ef4f03e8d167c7988ac204e0000000000001976a91482953d9d97767b99a78149edc335084b7052c3ac88ac00000000
=========================================================================
Generating the PDF to print your PaperCoins.
LABEL FILE = designs/papercoins-ovidiusoft.glabels
Created: PaperCoins-1327998249.wallet
Created: PaperCoins-1327998249.pdf
At the moment, it requires a patched electrum client (it's in the same dir). Read the README file for more information.
I hope this POC will attract some developers who will want to integrate a PaperCoins feature in their clients
If the user has an app to scan this, such an app would disregard the URL portion anyway, so I don't think including it is a big deal. Providing the private key alone would be perfect in a world where everyone already had a suitable app on their phone ready to read this, an app which of course would exist for every phone on the market, including those whose app store owner forbids bitcoin apps on non-jailbroken phones.
I started with the assumption (I might be wrong...) that a store will run a custom POS. I checked out a few projects and services and this seems to be the trend. The problem I was trying to solve was "how to emulate cash transaction using BTC in such a way that it's as fast or even faster".
You're imagining a scenario where a seller is using a dumb QR code reader on a mobile phone by the rotten fruits company
. I am not sure that your scenario can happen in a real store, at least not until Bitcoin will become so popular that everyone, irregardless of their knowledge, will want to accept BTC payments *NOW!*.Quote
The actual world is not perfect, and such a user would be only "using" the service long enough to initiate a transaction and collect their bitcoins, giving no personal information in the process. There is a big difference between being a "user" of a service versus a casual unregistered visitor - someone scanning a code would be no more a forced user of said service than me becoming a forced "user" of pastebin when I view something published there.
The user will be using the service long enough to be scammed by the website and/or the buyer. Imagine this scenario:
I am the evil attacker and I know that you don't run a custom POS, you're using online services from the QR codes. I quickly go home, create a custom QR code which points to my server. It looks just like you would expect, just that instead of sweeping the funds to your address, it displays a ok message. I walk out of the store with merchendise, you find out hours later that you don't have the money.
For even extra evilness, my server could actually commit the sweep, just use a different destination address (also mine). Even if you do get your hands on me, I will show you the tx and blame it on you for not pasting the correct address (I also had plenty of time to change my server so that now it's running as expected - I will even invite you to audit it
). I'm innocent until proven guilty, which you can't do. You'll take the loss and (probably) give up Bitcoin forever. Only such a successful attack is needed to have a lot of people lose trust in the system.So no, the seller should not trust any service pushed by the user, only data that he can verify on the spot. If this means running a Bitcoin POS app on a real computer instead of using the phone, I think he should (well, if he cares about the money, of course...).
On the other hand, I did some tests with the Goggles app on my Android phone. It's capable of correctly detecting a URL even if the QR code is actually:
Code:
DATA,PRIKEY=12345,URL=https://google.com/12345/,bla,bla,bla
So I think we can support your scenario without too much trouble, if the QR scanner runs a decent app. Alternatively, it's copy-paste time for the seller
. I'll post later some ideas about QR code formats and I'll also include your URL idea. But I do hope you'll change your mind i think using a sig instead might have an advantage
you can send multiple amounts to the same address
and when paying provide the sigs needed to redeem specific transactions
i am just a bit paranoid when it comes to private keys
you can send multiple amounts to the same address
and when paying provide the sigs needed to redeem specific transactions
i am just a bit paranoid when it comes to private keys
For that to work, the payee and amount would need to be known in advance. In which case you would just send the funds directly, no need to bother with a paper note.
i think using a sig instead might have an advantage
you can send multiple amounts to the same address
and when paying provide the sigs needed to redeem specific transactions
i am just a bit paranoid when it comes to private keys
you can send multiple amounts to the same address
and when paying provide the sigs needed to redeem specific transactions
i am just a bit paranoid when it comes to private keys
Quote
a big no nono private keys should be ever transmitted over the web. ever.never
use sigs instead
That's your opinion. I don't share it. On a bill with a couple BTC on it that I'm exchanging for a quick purchase, I'm not going to worry about it much. It's good advice for a large amount, so don't buy a car this way. Yeah, sure it can get stolen once in a while, so can my wallet, that's why I don't walk around with thousands in cash.
Quote
a big no nono private keys should be ever transmitted over the web. ever.never
use sigs instead
edit. didnt notice the s. SSL might be OK but its still scary
I don't think the payer should try to force a service onto the seller. Just providing the private key should be enough. The seller's POS can then do whatever he wants with that private key: sweep it directly, send it to a online service like you described, etc... My opinion is that we should not use a URL on the QR code.
If the user has an app to scan this, such an app would disregard the URL portion anyway, so I don't think including it is a big deal. Providing the private key alone would be perfect in a world where everyone already had a suitable app on their phone ready to read this, an app which of course would exist for every phone on the market, including those whose app store owner forbids bitcoin apps on non-jailbroken phones.
The actual world is not perfect, and such a user would be only "using" the service long enough to initiate a transaction and collect their bitcoins, giving no personal information in the process. There is a big difference between being a "user" of a service versus a casual unregistered visitor - someone scanning a code would be no more a forced user of said service than me becoming a forced "user" of pastebin when I view something published there.
I don't think the payer should try to force a service onto the seller. Just providing the private key should be enough. The seller's POS can then do whatever he wants with that private key: sweep it directly, send it to a online service like you described, etc... My opinion is that we should not use a URL on the QR code.
Someone could easily implement instant papercoins without an app.
Imagine this: I set up a website for mobile phones called "btcwhatever.us" which requires no registration - it is a semi-stateless web application that allows transfer of bitcoins. The only registration you would ever do is surf there with your mobile phone and register a receiving bitcoin address for yourself so that you can capture bitcoins from other people's bitcoin bills without wasting time telling it where to send the BTC. That registration will simply create a cookie on the mobile phone - it doesn't even need to be stored server-side.
Anyway, someone prints and funds Bitcoin bills. On the Bitcoin bill is a QR code with a full URL as follows:
https://btcwhatever.us/privkey/PRIVATEKEYGOESHERE
If this QR code is scanned by any smartphone, it will instantly pop up a web browser and go to that URL. No application is needed other than a generic QR code reader. This is just a plain URL, the phone need merely be able to surf the web.
At the URL, the server uses the private key to query the block chain, and simply says, for example, "OK there's 20.00 BTC here."
Question #1 will be: do you want to sweep some of these BTC or all of them? If "some" is chosen, change will be left on the bill.
Question #2 will be: do you want to send those BTC to the address registered in your cookie, or somewhere else?
Regardless of what you do, that private key is kept in temporary session memory. You can scan more private key URLs, and the website shall tally them up. And if you scan a bitcoin address URL (e.g. https://btcwhatever.us/address/ADDRESSGOESHERE) then the website will offer that as a destination for the payment (and/or the change, as the case may be...)
Anyway, once your full transaction is constructed, Click Submit, and the resulting bitcoin transaction is instantly broadcast to the network.
The screen that appears after you click "Submit" refreshes every 30 seconds and shows confirmation status of the payment. One can stare at their mobile phone and wait for a full blockchain confirmation if necessary, or otherwise, at the very least, they can assure themselves after waiting 30-60 seconds that the network hasn't seen a conflicting double spend.
Imagine this: I set up a website for mobile phones called "btcwhatever.us" which requires no registration - it is a semi-stateless web application that allows transfer of bitcoins. The only registration you would ever do is surf there with your mobile phone and register a receiving bitcoin address for yourself so that you can capture bitcoins from other people's bitcoin bills without wasting time telling it where to send the BTC. That registration will simply create a cookie on the mobile phone - it doesn't even need to be stored server-side.
Anyway, someone prints and funds Bitcoin bills. On the Bitcoin bill is a QR code with a full URL as follows:
https://btcwhatever.us/privkey/PRIVATEKEYGOESHERE
If this QR code is scanned by any smartphone, it will instantly pop up a web browser and go to that URL. No application is needed other than a generic QR code reader. This is just a plain URL, the phone need merely be able to surf the web.
At the URL, the server uses the private key to query the block chain, and simply says, for example, "OK there's 20.00 BTC here."
Question #1 will be: do you want to sweep some of these BTC or all of them? If "some" is chosen, change will be left on the bill.
Question #2 will be: do you want to send those BTC to the address registered in your cookie, or somewhere else?
Regardless of what you do, that private key is kept in temporary session memory. You can scan more private key URLs, and the website shall tally them up. And if you scan a bitcoin address URL (e.g. https://btcwhatever.us/address/ADDRESSGOESHERE) then the website will offer that as a destination for the payment (and/or the change, as the case may be...)
Anyway, once your full transaction is constructed, Click Submit, and the resulting bitcoin transaction is instantly broadcast to the network.
The screen that appears after you click "Submit" refreshes every 30 seconds and shows confirmation status of the payment. One can stare at their mobile phone and wait for a full blockchain confirmation if necessary, or otherwise, at the very least, they can assure themselves after waiting 30-60 seconds that the network hasn't seen a conflicting double spend.
PaperCoins in bitcoin client?
Awesome idea! Hope it gets the attention it deserves!
Awesome idea! Hope it gets the attention it deserves!
I use https://www.bitaddress.org to print me some bills. Then i cut them and fund with whatever small amounts i need. I write the value they carry by hand after funding with an android phone. The page script is clients side so the priv keys are in your possession at all times so you can even save the page as html and it will work. I'm not affiliated in any way just using the service.
I'd love to see this automated in the official frontend client - select amount, hit print.
I don't like the temptation of reusing bills. Reusing instead of tearing up and making a new one really defeats much of the point of Bitcoin doesn't it. Same for holograms really; I prefer those for promotion.
Temptation to reuse? Meh. Just tear them up, it's not like they are hard to make. I don't understand your objection to holograms. They make it so you can't reuse the physical tokens (which is what you just said you didn't like). I don't understand how you can be against both of those options.
Jump to: