Printing bitcoins, an implementation

[FatherMcGruder]

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.

[1713860667]

1713860667

[1713860667]

1713860667

[1713860667]

1713860667

[we6jbo]

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.

[myrkul]

Perhaps invisible ink can satisfy that requirement.

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?

[Garrett Burgwardt]

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.

[we6jbo]

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?

[myrkul]

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.

[JollyGreen]

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?

[Mike Hearn]

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

[JollyGreen]

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

[Binford 6100]

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.

[mgiuca]

Yeayy! I got it!

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?

[JollyGreen]

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.

[JollyGreen]

Yeayy! I got it!

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?

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.

[mgiuca]

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 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 (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?

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

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.

[Mike Hearn]

Code:

        // ASN1_SEQUENCE(EC_PRIVATEKEY) = {
        //   ASN1_SIMPLE(EC_PRIVATEKEY, version, LONG),
        //   ASN1_SIMPLE(EC_PRIVATEKEY, privateKey, ASN1_OCTET_STRING),
        //   ASN1_EXP_OPT(EC_PRIVATEKEY, parameters, ECPKPARAMETERS, 0),
        //   ASN1_EXP_OPT(EC_PRIVATEKEY, publicKey, ASN1_BIT_STRING, 1)
        // } ASN1_SEQUENCE_END(EC_PRIVATEKEY)

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.

[mgiuca]

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

[db]

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.

Indeed. Better?

[mgiuca]

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

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

[mgiuca]

Indeed. Better?

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

[FatherMcGruder]

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?

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.