Topic: Printing bitcoins, an implementation - page 2. (Read 17811 times)

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

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

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.

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.

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

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?

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

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.

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

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

Indeed. Better?

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

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.

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?

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.

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.

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.

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?

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.

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