Bitcoin Forum

There has been much talk about printing bitcoins. Here is a program to do it.

http://bitcoin.modernjob.info/print.html

It takes a wallet.dat file and generates PDF and EPS (http://bitcoin.modernjob.info/notes/39d670bf27/) bitcoin cheques looking like this:

http://bitcoin.modernjob.info/1BTC.png
http://bitcoin.modernjob.info/500mBTC.png

Each bitcoin address in the wallet with available coins gets a note containing the amount and the private key that controls it, both human readable and in QR Code.

(The notes above are real. The first person to take them gets them.)

Edit: PDF / EPS link.

So how should I use this without the according public key? I like this idea though. You could use that as a physical backup if combined with the public key.

The public key is derived from the private key.

user Hal organized a similar quest on weekend
his was a bit more complicated (he provided us with a base58 encoded pvt key and for the first round with an invalid key : )))
at least 2 people have a valid implementation for spending transactions based on private key
if they find out, they might claim your bitcoins instantly by reusing what they wrote for the Hal challenge.

How does one convert those paper bitcoins back to electronic ones?

EDIT: Just found this thread (http://bitcointalk.org/index.php?topic=3638.0). Seems complicated.

I have tried several QR decoders that are free on the internet and none seem to be able to read the images or cropped images.  Has anyone been able to decode these QR images?

+1, QR decoder libraries

Works for me with Barcode Scanner on Android. Still, I don’t know how to get the public key out of the private one.

Well, I'm not sure you would have to if you just insert it back into a wallet.dat file and then use bitcoin to open the wallet.dat

following instructions from the other forum post,

here is the block for the "1.0" BTC bill.

http://blockexplorer.com/address/1BNiV3yU9VjdAgHDtdN3rNYT9MbhuNLw2Z

So, I guess we do need to compute a Public Key from the private.  If you look in "key.h" in the BitCoin source there is a function "GetPubKey()".  It is calling a function "i2o_ECPublicKey".  I've spent way too much time on this for one BTC :)  Hopefully someone else can figure this out and create a python interface.  I would contribute more BTC but I only have "0.11" haha

yes, it's been solved on weekend in the forum you found
Prize for importing private key [WON]

and when the folks who solved it find this forum, they will just run the apps they wrote with the keys
from the banknotes.

what  you can do is PM them with link to this forum and ask for a small tip, share of the bounty, imho

it's not that complicated. just 3 or 4 steps but requires some coding experience.

So with a few extra coded tools this could make bitcoins easily transferred via paper? Or even better, with mobile phones(android, iphone)?

You know, when you're transferring BTC this way, maybe you don't even bother importing the private key into a wallet. You could scan the block chain looking for the coins associated with the key having been spent and create a transaction using that key, sending to another Bitcoin address you control. Broadcast to the network and wait for a confirmation. That way they can't spend those coins after they have given you the key.

As long as you trust them to give you a valid note or can verify and claim it before you let them out of your sight. Still, printed bitcoins could even work in a grocery store. Scan the note with the barcode reader and immediately check that the coins are not spent and that there is no double spending announced. Print the change on the receipt.

Nice but doesn't this take some time for there first to be confirmations? Wouldn't that kind of make it a little less practical to use?

Hey db, this is very nice, but would you consider modifying the program to use the terminology discussed here?

http://bitcointalk.org/index.php?topic=3311.msg46648#msg46648

That way it will be tidier when we get down to the smallest subdivisions of a bitcoin.

As discussed in the fast transaction acceptance thread (http://bitcointalk.org/index.php?topic=3441.0) you don't have to wait for confirmations. Just check that no double spendings are announced. Then the only way to do fraud is to have found a block in advance that spends the coins. In a mature Bitcoin economy that is expensive and very unlikely as there will always only be about six blocks per hour.

If / when we get down to the smallest subdivision we will have much bigger problems than having to call it "10 nBTC" (what's even bad about that at all?). All the inconsistency and confusion from changing the basic unit to bitcent (what is the proposed three letter(?) abbreviation for that by the way?) and mixing powers of 100 and 1000 is not worth it to solve something that isn't even a problem.

I like the paper version.

Well, my coding experience consists of me floating through CSE 123 eight years ago and then a little bit of Matlab here and there. So, pardon me for looking for something along the lines of the OP's link but in reverse.

This is using a format you just made up, there's no such thing as a bitcoin:priv= URL. You should be using the format I just made up instead ;)

v=1
base58 encoded privkey,block number

See the other thread where Hal posts a similar challenge for the real "spec". I could take these coins but somebody else can do it this time. Once is enough.

You appear to have provided a privkey in ASN.1 format. That's inefficient. You only need to provide the 256bit number. Less data makes for QRcodes that are easier to read.

I still think handing bitcoin addresses around on paper like this is kind of dumb, but whatever. If you're going to do this, we might as well try and standardize it!

I rather like it. I imaging that handing a bartender a bitcoin bill could more easily get me a beer than fiddling with a smart phone. You'd just have to trust the bill's issuer, but no more than you would have to MyBitcoin, for example.

I like the idea of a mutual bank issuing bitcoin bills utilizing invisible ink. Normally, the bill would display a public key that one could use to verify the bill's backing in bitcoins. To redeem these bitcoins, one could apply some heat iodine to the bill, and its invisible ink would display a private key and QR code. Doing so, of course, would void the bill.

http://blog.makezine.com/archive/2008/11/invisible-ink-printer.html (http://blog.makezine.com/archive/2008/11/invisible-ink-printer.html)

Is there really no way to read the invisible ink without leaving obvious signs the ink has been seen already?

The probably depends on the particular invisible ink. I suppose some might show under UV, but the issuer could always print the private key on top of ink that also fluoresced under UV.

How might one defraud the issuer of invisible ink bitcoin bills? What countermeasures can such an issuer employ?

This is awesome =)

I really like the idea of printed bitcoins.. if only as a reliable backup mechanism.

Really? I'd think phones would be much more convenient, if implemented well. Buying beers is always a slow process with cash because of fiddling with change. With an NFC smartphone it could just be take phone out of pocket, unlock screen, tap on the bar ... done.

Photocopy the invisible ink bitcoin bill, and spend it. When the new owner tries to redeem it, they discover that the invisible ink is a lie.

This is not directly defrauding the issuer of the bills, but it would bring the system into disrepute.

Emphasis on "implemented well". Some smart phones stink ("hold on, I have to run app-kill") and the prospect of getting drunks and technology to play nice doesn't sit well with me. An electronic system would have to work easier than a paper/plastic one. For example, the bartender would tell me the price, I touch the screen no more than once after unlocking my phone, wave it, and get beer. Having to aim the phone at a QR code or coordinate precisely with the bartender won't work.

The issuer can employ watermarks that show up on photocopies, as banks already do with checks.

Better idea, Scan the note, digitally process it to bring out the private key (using filters, perhaps?), transfer the money out, then spend the original, now worthless, paper.

Seriously, though... When even the dude in the mud hut in Zimbabwe has a smart-phone, Do we really need paper money anymore?

we'll be doing the scratch card method prints
QR code of the funded address is visible
QR code of the private key is under a layer of metallic paint

see DIY howto here http://artmind-etcetera.blogspot.com/2009/05/how-to-make-scratch-off-lottery-tickets.html

that way no need for invisible ink and co, just print all data and cover the sensitive parts
also no need for standardization. printouts will remain a marginal form of btc circulation, more or less as gift cards
 +a way to build reputation in community (issuing printed btc requires audience that trusts that they will not be spent by issuer)

This. Scratch cards are the way to go, if you're going to print the things...

And yeah, I can see grandmas sending scratch card bitcoins to kids every christmas. Heck, they might even make cards with the BTC already printed on them.

I can also see the news story when a whole bunch of them get to their recipients already spent because some unscrupulous employee snagged the Private keys off the cards before they got their protective coating of scratchy-paint. (Possible, but very difficult... involves a hi-speed digital camera and the willingness to place pieces of yourself close to machinery that's moving very very fast.) Remember, parents, verify before you buy!

Interesting concept of a "bitcoin note".  I also like the design you suggested.

However, such a note is different from usual bank notes, since it has value only during a limited period of time.  Basically until someone redeem  the bitcoin on the address and transfer it to an other address.

That's why I think there should be a note saying what exactly this is.

Something like:

<< This is a private key of a bitcoin address which was holding 1 BTC at block number NNNN. >>

But the ink is invisible. There's nothing to filter.

What's to stop someone from painting another scratch-off layer?

It'd be nice though to just use a code without having to figure out which standard it followed.

It's invisible to every specrtum of light, or just the human-visible ones?

Let's say you have ink that is invisible to human eyes, but it is visible in IR. You could just print it on top of ink or paper that is as visible in IR. You can do the same with UV too. Beyond the UV to IR spectrum though, the cost of trying to read this invisible ink gets high. The issuer can avoid this problem by not letting the note represent too many bitcoins.

Or... He could cover the sensitive data with metallic paint. Works fine for the lottery.

Global community note: in the US, scratch cards such as ptmhd suggested are used extensively, in raffles of all kinds, but mostly in state-run lottery schemes. They are priced at 1-5 dollars per scratch cards, and have prizes in excess of $1000, depending on the state and card. It's a proven technology, and fairly secure.

That said, I don't see why BOTH technologies couldn't co-exist, though I do lean towards scratch cards being more economically viable. (code + paint vs code (special ink) + UV layer (special ink) + IR layer (Special ink) + solvent to redeem)

It's secure for the issuer, because there's also a checksum printed on the card. But it's not so secure for the layperson, who depends for security upon buying the scratchcard from a trusted vendor. As these scratchcards are not widely used as money, that's good enough.

But one only has a small probability that cheating a scratch-off game will earn a reward. Assuming an honest issuer, freshly issued notes carry a probability of 1 that they represent bitcoins.

Scratch-offs would only work if the issuer printed a difficult to replicate but easily verifiable image on top of the scratch area. That requires three layers of printing, versus one or two for invisible ink. Therefore, scratch-off bitcoin notes are more expensive and must represent more bitcoins to offset their production cost. Subsequently, they are a nicer target than invisible ink notes.

If the notes are cheap to produce then the issuer can afford to periodically recall notes and issue new ones. This way, the issuer can keep up with technology, preserve the value of his notes and reclaim the bitcoins associated with lost or destroyed notes. Holders who can't bring their notes back to the issuer to receive new ones can just reveal the invisible ink and redeem the bitcoins themselves before the end of the recall period.

Here's how I think a one bitcoin note might look (https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B72XpX7bclq8YWQ1NmM2ZjAtNzY4MS00MWNkLWJjN2QtZTRlMTFkNWI3Y2Zk&hl=en&authkey=CICZ4foK). I'm happy to share the .idw file if anyone would like.

here in Italy, 100% of the cards for buying phone prepaid credit are scratch cards, instant lottery tickets are scratch cards, etc... I've never heard of someone buying a card that was used and re-printed with the metal layer.
OFC I must say usually you don't buy them from other people but from "commercial entities". Still, if one can quickly check if the money is in the process of being double-spent, this is still way more safer then cheques.

I don't recall seeing scratch-off layers on anything except for relatively stiff card stock or plastic. Paper money gets folded, crumpled, washed, used as narcotic paraphernalia, and manipulated by moist genitalia. Could a bitcoin note utilizing a scratch-off layer stand up to such abuse? I doubt it. In fact, I have a used scratch-off game right here. After folding it a few times, I see cracks in the remaining paint. We'd do well to look into other more durable methods. Perhaps invisible ink can satisfy that requirement.

There's two issues that I see in this. The first one is that there's nothing protecting the image and anyone that sees the image can take the currency. In addition, there's nothing on the note that guarantees that the note is even worth anything. The only way to verify that the note is worth something is to scan the note. It's also a huge waste of paper since once the note is used it's worthless. What I would suggest is using a digital note on e-ink technology. The printed bitcoin could then be used over again. In addition there should be something added to the note that can be sensed through touch, sight or sound to tell if the note is lineament or not and then finally there needs to be some key such as a password, biometric print or fob that can be used to lock and unlock the note.

Boy, you are married to that invisible ink idea, aren't ya? ;)

I think the difference here is in our ideas of the use case. I see it as a replacement for giftcards, being secure enough to get to the grandkids intact.

You see it as a replacement for FRNs, needing to stand up to the abuse and attacks that they do. Certainly, you're welcome to print access codes to digital money on a note that would then be subjected to getting "folded, crumpled, washed, used as narcotic paraphernalia, and manipulated by moist genitalia."

 If you can keep the cost of such a note low enough, while maintaining security, go for it. I'd still say that digital, via debit cards, smart-phone apps, and the like, will replace FRNs for daily use, though. Why give up all the advantages that digital currency has over printed?

Wouldn't it be possible to have a QR code of the associated public key on the note, so that someone could scan the bill and say 'yep this bill has X bitcoins assigned to it'?

I haven't read the entire thread so forgive me if this is repetitive.

How long would it take to verify the note? 10min?

How long does it take to verify the contents of a mybitcoin account?
Or how much money is on your walmart gift card?

It's a very simple matter, only takes a second.

Something doesn't seem quite right with this challenege,
looking at the other thread with basically the same premise and goal, Hal provided his private key

"C85AFBACCF3E1EE40BDCD721A9AD1341344775D51840EFC0511E0182AE92F78E

My new attempt to base58 encode this is:

EV71KQfoePBeWT79sV1VE7fWRgv1KNUxTNapH6ZbaRfB"

The base58 encoded block on the bitbill is much much longer than Hal's example base58 encoded private key.  Am I missing something?

As I said, I think the bitbill is using an ASN.1/DER encoded form of the key which is inefficient and unnecessary.

Cool, thanks, i figured that out after your last post, I appreciate the help! :)  Hey, at least I'm slowly learning :)

thumbs up for learning new stuff

also please use the bitcoin / "satoshi" base58 alphabet to start with the right foot
in the Hal's quest forum it is mentioned.
not only having a shorter key but also properly encoded from bitcoin point of view.

Yeayy! I got it!

http://blockexplorer.com/address/1BNiV3yU9VjdAgHDtdN3rNYT9MbhuNLw2Z (http://blockexplorer.com/address/1BNiV3yU9VjdAgHDtdN3rNYT9MbhuNLw2Z)

I only took the 1BTC one, someone else can get the 50 bitcent one.

Wow, that was an epic amount of work, and I had to write a lot of code to do it. It's pretty sad, really, how much work it was to take a private key (i.e., all you need) and create a transaction out of it. Maybe I went about it the wrong way. I found the public key and then inserted it into my wallet, then used the normal Bitcoin client to send it to another account.

I will post my code later. Thanks for a fun challenge, db. Since it was all in good fun, you can leave your bitcoin address and I'll post it back to you.

@JollyGreen: I was, and still am, really confused by this as well (Hal's base58-encoded private key). Hal posted a 32-byte private key. I wouldn't know how to get his one. As far as I know, all Bitcoin private keys are 279 bytes in length. Therefore, I could get db's key into the wallet, but now Hal's. Someone on the other thread explained, I think, that there are only 32 useful bytes in the private key; the other 247 bytes are redundant configuration information. I haven't looked in detail enough -- it's possible that all Bitcoin private keys share 247 bytes in common, and only differ in 32 bytes. I'll investigate further later. Edit: Ah Mike explained something similar. Can you confirm or correct my above statement?

Will do, that base58 implementation seems to make the most sense.  Well, I guess the easiest route if the private key is DER encoded is to to just read those bytes back into a CPrivKey structure, create a CKey class and use the SetPrivKey method then call GetPubKey().  I think that should give you a private/public key pair that you can then insert into a wallet, or use to assign the coins to a new address.

Nice work!  Did you use the bitcoin code/functions or did you use python?  I spent sometime trying to figure out how to use python crypto libraries to work with the keys, but the bitcoin code seemed to be the easiest method.  I got stumped for a while on why the private key wasn't just 256 bits :)  It would be cool if Hal released his method for pulling the 256 bit key out of the DER/ANS.1 encoded bytes.  We can strip off the DER encoding, but then you need to pull the bits out of the ANS.1 strucuted data, it all seems fairly painful :)

If people wanted to print their coins to a pdf for backup, or bitbills then it would be best to use the 256 bit key and then use error correction.

I possibly should have used the Bitcoin code and modified it, but I still haven't gotten it to compile, due to wx. I swear, that codebase needs massive refactoring. Ideally, Bitcoin should be a C library, with a separate GUI on top of it.

So I used Python. I took the CKey class from Bitcoin and ported it to Python (using the C API), so I now have a Python class called Key which can convert private keys to public keys. This works naturally on the 279-byte DER encoded private keys; I have no idea what to do with the 32-byte private keys that Hal uses. Then I used BitcoinTools (https://github.com/gavinandresen/bitcointools) (Python) to get it into the wallet. BitcoinTools can only read, not write, a wallet, so I had to figure out how BSDDB worked as well as Satoshi's key encoding, and add some code to write back to a wallet. This is likely not the best way to go about it -- ideally I would just craft a transaction and send it. Is there any code for manually creating a transaction?

Yes, I agree. If indeed only 32 bytes are useful, then the printed money should only use that. It would make the Qr code easier to scan. I'd like to figure out what the relationship is between the 32-byte keys and the 279-byte keys.

As you can see the ASN1/DER encoded form of the privkey is surrounded by stuff we don't care about like version, EC params (fixed by the bitcoin protocol) and the public key which, as you know, is derivable from the private key by doing a point multiply with the generator.

It's only the second part of the sequence that actually matters.

Oh shoot! You're telling me that I did all that work to get the public key and it was right there! Ah, yep, I just checked. It is the last 65 bytes of the 279-byte private key.

So I guess when I call d2i_ECPrivateKey followed by i2o_ECPublicKey (that is, CKey::SetPrivKey followed by CKey::GetPubKey), all it is doing is writing the 279 bytes into memory, and then reading 65 bytes back out of memory. Not actually doing the priv->pub calculation at all.

Therefore, my technique would be inappropriate if I was only given the 32-byte private key. I've got no idea how to actually compute it :(

Indeed. Better (http://bitcoin.modernjob.info/notes/2c0ca5b079/)?

http://bitcoin.modernjob.info/6.66BTC.png

Alright, I finally got my code online. You need to get it from two places.

Firstly, I have patched bitcointools to enable writing to wallets. That is available here:
https://github.com/mgiuca/bitcointools (https://github.com/mgiuca/bitcointools)
You will need my version of bitcointools to use privkeyimport (unless Gavin merges it).

Secondly, I have made a new tool called privkeyimport, which lets you import a private key (the 279-byte one) straight into your wallet:
https://code.launchpad.net/~mgiuca/+junk/bitcoin-import (https://code.launchpad.net/~mgiuca/+junk/bitcoin-import)

That file contains the full instructions. Note that this doesn't read QR codes or EPS files. You will need to manually open the EPS file and copy the text into a text file, or use a QR scanner to extract the text from the QR code. The input to this program is a text file containing the private key.

USE AT YOUR OWN RISK. I RECOMMEND YOU BACK UP YOUR WALLET BEFORE DOING SO.

I have tested it on my wallet and it's fine, but I can't be held responsible if this trashes your wallet.

Also note that you need a bit of trickery to get it out of the wallet. If you import it into your main wallet, there is no way to tell Bitcoin that you want to send it out. So you will probably want to back up your wallet, start a new one, import it there, then send the money to yourself. Hopefully someone will write a better tool that just lets you create a new transaction without using the wallet at all!

For those interested, I also made the Python key implementation I mentioned above online:
https://code.launchpad.net/~mgiuca/+junk/bitcoin-key (https://code.launchpad.net/~mgiuca/+junk/bitcoin-key)
I didn't end up using it, since as Mike pointed out, you can just extract the public key straight from the private key (which is what I ended up doing).

Damnit! Well, my code won't work on that thing. I have no idea how to extract the public key out of a 32-byte private key.

Can anybody give me any pointers (preferably using OpenSSL)? (By all means, take the money first. I'm in this for the software development.)

That clears it up. Making bitcoin payments via "gift card" makes sense. I think it could get me a beer rather easily. However, it involves vendors charging an account, which opens up the possibility for charge-back fraud. Bitcoin bills would avoid that just like actual bitcoins they represent. Also, I like the idea of issuing my own paper money and the way US FRNs smell. Bitcoins don't smell, one of their few drawbacks.

I view it as a benefit, eau d'Cocaine and ass-crack isn't exactly my cup of tea. ;) I can, however, see the draw of issuing your own paper money.

One thing, though: the biggest benefit of debit cards is their convenience and speed. Would a bitcoin debit card be able to compete? the current credit/debit card system works thus:

Cust. swipes card
merchant transmit card data to operating company (visa, MC, etc)
Data is passed to issuing bank
Bank checks if customer has available balance (or credit, as the case may be)
If yes, bank places hold on funds
bank sends response (approve/deny) back to operating company
Operating company sends response back to merchant
At the end of the day, the merchant totals up all his actual charges, and sends them to the operating company(ies)
the operating company confirms the transaction with the issuing bank
customer's balance is updated, and the hold is removed

One example of this is, at some gas stations, the pump "authorizes" for $50, to make sure you have enough in your account to cover if you fill up your tank. Let's say you only buy $20 worth, though... That $50 hold is still there, until the gas station closes out it's books for the day and sends the finalized $20 charge.

Seeing as Bitcoin combines those two transactions when you attempt to spend some, and the confirmation doesn't come until another block is made... Can it keep up?

The bank would be a computer that holds the wallet of the customer, it would fire the transaction as soon as requested, it would take the usual time for BTC online transfers but if the wallet holder is reliable, the busyness places would believe when the bank says the customer has funds and the transaction is gonna take place.

I know of no finer scent then that of debauchery and broken dreams.

I would think that a bitcoin card would work just like a typical debit card, except the transfer of funds arrives an hour later instead of a day later, and the bank and operating company would probably be one in the same. The vendor would have to trust that entity.

Perhaps the customer's home computer or smart phone could act as the bank/operating entity. The vendor would just have to make sure somehow that the customer doesn't run cheating software. Is that possible?

I don't think so, at least not without additional network traffic being required on the store's own equippment confirming things with the block chain and stuff; resources would be better spent by having the store use their own machines to read the customer's card (in whatever form it might be presented, smart card, RFID, bluetooth enabled smartphone etc) and talk with a trusted bank/operator confirming the presence of funds and instructing the initiation of the transfer on behalf of the customer.

What if the card stores an actual wallet.dat file, and the vendor just loads it into his client to make the transaction? On a separate network, he could rapidly confirm with other vendors that a multi-spend isn't going on. If the vendors' computers could talk, it would go like this in the case of a good transfer:

Computer 1: beep boop Hey guys, I have this wallet here with 200BTC, trying to transfer 5BTC. Does that check out?
Other computers: boop beep We think so. We have no evidence that the value on that wallet is inaccurate.

In the case of a bad transfer:

Computer 1: beep boop Hey guys, I have this wallet here with 200BTC, trying to transfer 5BTC. Does that check out?
Other computers: boop beep Nope. Within the last ten minutes, that wallet just transferred some bitcoins to one of us and claimed that it also held a value of 200BTC. Fail.

That would involve trusting the the store to not clone your wallet, they alreayd do it with regular credit cards....

If you at least needs some sort of challange/response or the very least password or signature from the owner of the account that gets verified by the bank/operator, then things get more secure.

Dang, someone just took the 6.66 BTC!  Congrats to the winner.  I'm working on some java code and will release after I can verify it works.

that's bad style, but on the other hand, your fault for printing it plain text

better joke would be to "steal" just a few percent to lower the value a bit.
not to make it completely worthless

I didn't print anything in plain text... :)

Ah, sorry Jolly. I just got it again. I was bugged that my previous attempt couldn't get public keys out of private keys. Spent another couple of hours working on it, and wrote a tool to take a 32-byte private key and turn it into the full 279-byte DER key.

Had to trawl through the OpenSSL codebase for hours to find out how to do this. There are almost zero comments in that code, and absolutely none in the headers. Insane.

I've put my code online here:
https://code.launchpad.net/~mgiuca/+junk/bitcoin-import (https://code.launchpad.net/~mgiuca/+junk/bitcoin-import)

I'd be interested to see what your code does when you put it up. Does yours use the Bitcoin wallet, or are you making your own transactions?

The online QR encoder at http://zxing.org/w/decode.jspx (http://zxing.org/w/decode.jspx) works on the 6.66 Bitcoin note above, while it failed on the earlier ones. Helps to encode less data probably. Here's what it decodes to:

   bitcoin:priv=4RPhNpsD95XcjXG4637DwTNgQLh2eqQ7r7hH5yeLA16F;amount=6.660000;

On the other thread, Mike and Gavin suggested an important optimization: Include an optional block number where the address first appears. Otherwise the recipient has to scan the entire block chain to find transactions for that address, which can reportedly take a couple of minutes on a slow machine. Including the starting block number means you only have to scan from there, which will be very fast assuming it's a relatively new address.

I'm not a coder, or developer, and I am feeling lost here.  Sure, I downloaded stuff to install on linux that will enable me to print a certain amount of bitcoins in paper form, but I have not installed all these packages and run the python application.  Even if I did, is there another application for Reading a bill and then inserting the data into a wallet.dat?  If I manually insert data into a wallet.dat, how would I actually do it?  I've looked at the contents of my wallet.dat file, it's a confusing jumble of Hex stuff to me.  Until you developer types come up with an Easy tool to use to both print, and read, these Bitcoin bills, I think I'm going to be too lost to even attempt it.  Someone please develop a linux Package, that installs all the dependencies, or something.  Sheesh.

I went to the website and uploaded a fresh wallet containing only .20 BTC, and it quickly gave me a PDF file, and some other file I don't know what to do with.  I like the PDF, and printed it.  Very cool. :)

Software development takes time. The idea of printing bitcoins is just one idea that people are toying with, and this forum thread is the very first time someone has seriously attempted it. Accordingly, we have written some of the very first software that can read it back in, but it's just command-line tools. You can't expect us to polish it up into a proper user-friendly UI with a Linux package and so on, when really we are just experimenting with an idea that might not work.

As I said above, I have provided the reader software online that I wrote. It isn't pretty, but you can get it working on the command-line as follows:
1. You will need Bazaar, Git, build essentials and libssl (sudo apt-get install bzr git build-essential libssl-dev).
2. See https://code.launchpad.net/~mgiuca/+junk/bitcoin-import (https://code.launchpad.net/~mgiuca/+junk/bitcoin-import), with further instructions here (http://bazaar.launchpad.net/~mgiuca/+junk/bitcoin-import/view/head:/privkeyimport.py).
3. As instructed on my page, type: bzr branch lp:~mgiuca/+junk/bitcoin-import -- this will create a new directory called bitcoin-import wherever you are.
4. You also need Gavin's BitcoinTools (https://github.com/gavinandresen/bitcointools) if you haven't already got it. Type: git clone git://github.com/gavinandresen/bitcointools.git
5. Unfortunately, if you use Ubuntu, the supplied version of pycrypto will not work, so you need to get the full version here (http://www.dlitz.net/software/pycrypto/) and set that up as per its installation instructions.
6. cd into bitcoin-import and type: make

Now the instructions for use, as given in privkeyimport.py (http://bazaar.launchpad.net/~mgiuca/+junk/bitcoin-import/view/head:/privkeyimport.py):

1. Get the private key you wish to import in a text file. To do this, you either need to download the PDF of the printed money in a reader that can select the text and copy it, then paste it into a text file, OR get a QR code reader and paste the output text into a file. Whitespace is not important.
2. Run privkeyimport.py KEYFILE. This will write the key into your Bitcoin wallet. Use -n to just print without writing to the wallet.
3. Run bitcoin -rescan to ensure any transactions belonging to the imported key are added to the transaction list and balance.

As you can see, it requires a lot of technical fiddling, but no programming. Cleaner solutions will appear in time.

Thank you for the summary!

Encourage to use a DataMatrix!

QR-code is more proprietary than DataMatrix and DataMatrix fully implemented in very good open source library and utils called 'dmtx'.

Also DataMatrix supports real 8 bit encoding, but QR-code is really not:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604882

QR-code has one advantage - it is recognizable by 'typical users'.

http://www.symbology.com/images/DataMatrix_2D-500.jpg
http://upload.wikimedia.org/wikipedia/commons/5/58/Data_Matrix.jpg

Does it got error correction, like, could i replace a big part of it with an image of my choice and still have it work like how happens with QR code? And is it at least as easy to dentify and read by devices as QR code?

Yes. All the same, only the DataMatrix uses a little less space

I've been following this thread with interest, because one of my first ideas for Bitcoin was to use it as a backing for paper notes. These are still useful sometimes for in-person transactions, and would probably be good PR as well, since paper currency is familiar and comfortable. I can see myself tipping a bartender an extra 1 BTC just to get their attention.

I had not thought of printing a private key directly on the note! I'd just figured you could have something like a Bitcoin Reserve Agency printing hard-to-counterfeit promissory notes. Printing the key in invisible ink or under a scratch-off is clever, but I'm not sure it resolves the trust issues that a promissory note system has:

• You have to trust that the private key will really be there when you go looking for it.
• You have to trust that the private key will actually match the public key printed on the same note (if a public key is printed). This can be verified retroactively, but by then it's too late.
• You have to trust that the money will really be linked to the private key.
• You have to trust that the bill wasn't counterfeited.

All of these issues can be resolved if the issuer creates a hard-to-counterfeit note and maintains a good track record, but the important point is that printing the private key doesn't reduce the amount of trust necessary. All it does is make redemption easier.

Printing a private key also produces unique problems:

• If some type of note is widely adopted, and then someone finds a new technique of reading the private key without altering the note, there could be an immediate financial crisis. (At best, businesses would have to stop accepting cash until the notes could be replaced).
• Stolen cash can be immediately redeemed and then destroyed, making recovery difficult or impossible. Arguably this is a feature, not a bug, but it is a tough sell to someone used to the present system.

I've thought about this from a lot of angles, because I really like the idea of self-redeeming notes. But I really can't come up with a solution to these problems that isn't also a solution to the problems that central banks have in the first place. Maybe someone else can.

On the other hand, the scratch-off thing is plenty secure enough for a one-shot "check" that will be redeemed immediately by the recipient. So is a tamper-proof envelope, for that matter.

They wouldn't have to stop accepting alltogether, they would just need to cash in in the contents of the presented wallet before considering the payment as having been effectuated(sp?), it would reduce the trust people have on the notes though, and probably in Bitcoin as a whole (most people don't know the difference between their web browser and the whole Internet, or even that they aren't the same thing)

I have a friend who, for years, thought the Internet was called Netscape.  It was incredibly hard for me to convince him that Netscape is just the name of a web browser, that there are plenty of browsers out there, and that the World Wide Web of pages he thinks is the Internet is actually only one Aspect of what the Internet actually is.  It was a major pain.

As for bitcoin printing, I just can't do all that work getting this stuff running.  Once you guys iron out all the kinks and get all this stuff solidly figured out, you have to make it easy for the village idiot to use, and that would probably mean a Windows program, or an iPhone app, or something.  Good luck with that, I'll be waiting with extreme excitement. :)

A similar take on the signing check idea, is to symmetrically encrypt the private key before encoding in QR/Data matrix. Then writing the password on the check 'signs' it. Of course the paper money isn't transferable before 'password signing'.

might be related (and please do not overthink the following example that i might however compare any parent of any of us to any village type user ...

Quote from: gavinandresen on May 19, 2011, 05:08:27 pm
I think it is important to set expectations; I still wouldn't recommend that my mom use bitcoin for anything just yet, because it is not easy enough to use securely. And the road ahead is likely to be bumpy; there will be technical issues that need fixing, there will be legal questions, there will be price bubbles, and there will be scams. I predict that some company using bitcoins to do something illegal will be caught and prosecuted, and that will be mis-reported as "Bitcoin is illegal."

in the meantime someone is printing bitcoins but for cca 10% of their face value
& you have to trust him/her that you have the only copy of the keys ...

If this is one time use paper(private key) - it wont work. Paper consumption around the world will be insane.
And another problem - if someone will see and just take photo of our money - we will lose it.

So we are coming to the beginning  - banks - we will need them to keep bitcoins and get paper edition of them without public/private keys printed in it but:
a) only with security signs like current USD or other money have to prove their validity
b) just with PUBLIC key to check if it is really somewhere in the network, also backed up in one of the central points.

It's not that easy to get it safe.

mine 0.02 btc

I'm so confused trying to read this thread.  I really like BitBills, plastic cards containing Bitcoins, very cool concept. :)

Very good thread! I read it all and understood half but it is extremly interesting. I do believe that a one time use paper will soon find lot of uses, specially as for gifting. Is there a new thread about this?


Idea1 - where the issuer knows the new holder: There could be a free central colector (not bank) which holds paper transfered bitcoins so as to avoid trusting in each individual user. This collector shall reccord every transaction as individual and save some aditional data as a password to check the validity of the holder. QR eps would be issued to add it were ever you want, recalling this central colector and will ask for the password which will be revealed by the issuer as revealing the signature in the creditcard. Then the coins could be redeemed or change the password for fowarding them to a new holder or send them into a wallet. The system should allow to transfer many different amounts and have a central user control pannel.

Idea2 - the issuer don't knows the new holder: same central colector, QR+password hidden under metal ink. Obviously onetime redeem per paper.

Is this too simple and wrong? Sorry my english please.

Used my Android but a bunch of letters pop up and now I am confused  >:(

I could invision a service whereby I generate key pairs and send them off to be minted.

I generate key pairs on my computer. I then symmetrically encrypt the private key and send them to the print-minting service along with identifying information, perhaps even my photo. The print-mint prints unique bill-notes (with my smiling mug in the center) and sends them back to me. I can then write the passphrase on the bill-notes (either in advance or upon purchase/distribution).

Recipients must trust me or transfer the bitcoins from the bill-note immediately. Recipients must trust the print-mint not to duplicate bill-notes and that counterfeiting is impractical, or again just transfer bitcoins to themselves upon receipt. The print-mint can verify that I have not duplicated the keys (at least with respect to the block chain and the print-mints own public key records).

"Therefore, my technique would be inappropriate if I was only given the 32-byte private key. I've got no idea how to actually compute it :("

It's all in the CKey class in key.h

CKey::GetPrivKey and CKey::SetPrivKey use the 279-byte DER key.
CKey::GetSecret and CKey::SetSecret use the 32-byte private key.

Look at the satoshi client source code for details on how to call the OpenSSL library.

https://github.com/bitcoin/bitcoin/blob/master/src/key.h