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.

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?

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 footin the Hal's quest forum it is mentioned. not only having a shorter key but also properly encoded from bitcoin point of view.

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.

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.

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?

Quote

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.

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.

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

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/bitcointoolsYou will need my version of bitcointools to use privkeyimport (unless Gavin merges it).

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

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.