Topic: Prize for importing private key [WON] (Read 18149 times)

I think the advantages of base58 (unambigous 1lLiI for humans) is lost in a QR encoded message. Base93 (x21-x7E) is more data dense. Base10 (decimal) is almost as dense due to the four encoding types (numeric, alpha, pseudo-binary, and kanji). Data Matrix (as opposed to QR) has the advantage of a true binary format.

I agree. I always choose Python if I can In this case, I chose a mixture of Python and C. I am glad I stuck with C/OpenSSL when other people are using Java/Bouncy Castle or other approaches. My code can be integrated into the main Bitcoin codebase without introducing any new dependencies. I am interested to see if I can extend it to deal with this .bitkey format people are talking about.

I have stated elsewhere that I wanted to replace the Wallet format (which I regard as an ugly black box with way too much unnecessary data in it -- data like transactions and public keys are redundant and are not necessary for restoring precious coins from a backup) with a new one. I see now (having worked with the wallet) that it's quite integral to Bitcoin and it isn't going to be replaced any time soon.

Therefore, I am thinking that Bitcoin should be reading and writing two formats simultaneously. It keeps a wallet.bitkey file in the home directory. Whenever it writes a new private key to the wallet.dat, it also appends it to wallet.bitkey in human-readable format. When it starts up, it scans wallet.bitkey and if it sees any private keys which aren't in the wallet, it loads them in. That way, you can always check your wallet.bitkey file to see what keys you have in human readable format. And you can import/merge such files manually, and Bitcoin will slurp them in at startup.

In this case, my code would be useful because it uses OpenSSL to read in a private key and make a full DER key which is required by wallet.dat. The code to read wallet.bitkey and insert keys into wallet.dat would need this mechanism.

It's in there. My code looked a little something like this (from memory, so it may very well be WRONG):

AutoSeededRandomPool prng;
Integer pkey("TheHexStringOfTheKeyUnhashed");
ECDSA::PrivateKey privateKey;
ECDSA::PublicKey publicKey;

privateKey.Initialize(prng, ASN1::secp256k1());
privateKey.SetPrivateExponent(pkey);
privateKey.MakePublicKey(publicKey);


And volia, a public key from a private key.

Nice work again, python just seems so much easier to deal with than these other libraries, I guess just preference though

I looked into this library and I couldn't find that it supported ecdsa 256k1.  Maybe it's just a matter of adding the curve constants to their library....

Little late to this party...

...I was also working on the challenge, and I found that Crypto++ worked really well for this. What I found was a nice surprise was that the ECDSA classes were nice enough to generate public keys from a private one if you had the data:

http://www.cryptopp.com/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Found it much, MUCH easier to use than OpenSSL. Downside is, well, you gotta know C++.

Thanks for your help mike. Actually I just spent ... fricking ... too many hours to admit ... trawling through OpenSSL to figure out how to do it.

My code is online here:
https://code.launchpad.net/~mgiuca/+junk/bitcoin-import

It depends on OpenSSL and BitcoinTools, and is otherwise fairly automatic. It takes a 32-bit private key in base58 and automatically inserts it into your Bitcoin wallet. Yay!

Hey mike,
Thanks for the help once again   I actually have gotten some java code to run that is ready to do the math for generating a public key from the private key.  I just don't have the Base58.decodeToBigInteger function.  Is that something you could release?   It would save me some time.

G is a constant specified by the curve parameters. BitCoin uses the secp256k1 curve in which G is equal to

  02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798

in compressed form.

If you want to do what we've been doing on this thread I suggest you either:

a) Wait for me or somebody else to release code showing how to do it

b) Study the lightweight Bouncy Castle API and see how to do EC crypto with that, as it's probably easier to understand than OpenSSL

@JollyGreen: I have had a closer look at the DER structure for the 279-byte private key. Not looking at the OpenSSL code -- it is rat nests of macros. Just experimenting with my own data. Looks like the 256-bit "actual private key" is located in bytes 9 through 40 (inclusive) of the DER key. The public key is located in bytes 214 through 279. All of the remaining bytes (0 through 8 and 41 through 213) are constant.

Therefore, grabbing out bytes 9 through 40 of the private key dumped by bitcointools is sufficient for getting the 256-bit key. What I don't understand still is how to derive the public key from this private key. I know you are supposed to find a number called "G" and elliptically-multiply it with the private key. But I have no idea how to a) find G, or b) do elliptic curve multiplication.

search for forum where a bounty was for wallet key dump tool
keywords grondilu, wallet dump key ...

or as mike wrote, try to mod the client. i'm not sure if bitcointools are as userfriendly as the solution of grondilu

not answering how to remove the key from a wallet.
if you need to get hands on private keys, please start with an empty new wallet to avoid any losses

unless you know what you're doing

imho no way to get this to the main client. dump keys maybe but no print outs.
this ain't steampunk

It seems from the bitcoin code that the private keys are stored in CPrivKey structures as DER encoded private keys.  Is there a way to decode these out of the DER structure?  Is there a way to pull just the private key from the EC_KEY structure?

If you look at the CKey class, they store the private key in the EC_KEY* pkey structure, but the only way it gets into or out of that class is through a CPrivKey, which looks to be DER encoded or decoded into pkey.

I'm trying to figure out how to get the raw 256 bit value from the private keys stored in the wallet.  There seems to be no direct route, so I'm trying to create one.

I think the basic idea is that people want to backup their coins on paper, so it seems one way to do that is to store the private key on paper in a few different methods.  I can also see it being useful if the bitcoin client offered this paper backup method as an option.

Presumably Hal modified his copy of BitCoin to extract the private key, or maybe he used Gavins bitcointools package which reads the database directly.

DER encoding is just a way of wrapping up a binary data structure in a 'somewhat' self describing form. If you read up on Google protocol buffers, DER/ASN1 encoding is a very similar concept to that but much older and not at all widely used, as it's kind of a pain to deal with. The key Hal posted is not DER encoded. The DER encoded privkey structure has some goop in there that isn't necessary, it's only the 256 bit value that is important.

How was Hal able to get the private key?  It seems the private key is stored in a CPrivKey structure in bitcoin and that is stored in the wallet.  Are the bytes that make up the CPrivKey structure the same as the base58 decoded bytes of Hal's private key?

I'm new to all this, but it looks like CPrivKey structures are DER encoded private keys.  Can you explain what it means to DER encode or decode something and is Hal's private key DER encoded?

Cool, thanks! My first earned bitcoins

After exams I'll have a look at the bitcoin c++ source code and try to come up with the import/export.

JollyGreen, I posted the (single) line of code you need to do that with the Bouncy Castle implementation above, see here:

   pub = ecParams.getG().multiply(priv).getEncoded();

Note that the multiply method here is an elliptic curve point multiplication, not an arithmetic multiply.

If you're asking what an EC point multiply is, I suggest reading this:

  http://www.imperialviolet.org/2010/12/04/ecc.html

or possibly asking Hal, as he is the professional cryptographer on this forum not me

I sent you 50 coins Hendi, thanks. That program is still kind of useless without the implementation of key import/export. Perhaps somebody will step up at some point and implement it.

Did anyone ever come up with an algorithm they wanted to release that generates a public key from a private key? 

Cool! If there's anything else you (or someone else) wants this small script to do, don't hesitate to ask

I now validate each line by checking for a valid base58 bitcoin address followed by the blocknumber. If an invalid line is found, you'll get notified with a popup. I'm not sure if this is the best notification style, I'll try later with showing the .bitkeys file and highlight wrong formatted lines, maybe that's better?

Done.

i'm ok with not reaching the full potential audience by hiding the link here
i could just add it to my signature and see who picks up the link