Multibit import formats

[tspacepilot]

Hi Multibit subform,

I have one more multibit question.  This one regards importing private keys.  I find that I can import private keys using the plain text, unencrypted WIF format:

Code:

# be carefulz w ur keys
# 5... T..Z
# end of private keys

But then multibit gets to decide whether to use the compress or uncompressed address for this key (in my most recent experiement, and this may be on an older version of multibit, it chose the uncompressed address).  My question is whether it's possible to import an address/privkey pair so that you can force which address to use?  Or, as a corrolary, whether there are other import formats which would give me more flexibility.

[jim618]

TBH Exporting and importing private keys between clients is like a very sharp knife - if you do ANYTHING wrong you can lose your bitcoins.

We recommend to only use Tools | Import private keys to restore a file you created with Tools | Export private keys for this reason.

The list of gotchas is quite long which is why we've moved away from random private keys and moved to purely deterministic wallets for MultiBit HD.

[btchris]

Of course, please heed jim618's advice. But that aside for a moment...

Code:

# be carefulz w ur keys
# 5... T..Z
# end of private keys

But then multibit gets to decide whether to use the compress or uncompressed address for this key

The "WIF" format encodes whether or not the public key generated from a given WIF-encoded private key should be compressed. See step 2 in the wiki: https://en.bitcoin.it/wiki/Wallet_import_format

As a result of that step, the WIF-encoded private key will always start with a 5 if the public key should be uncompressed, or with an L or K if the public key should be compressed.

If you're dealing with old or unmaintained software, you might find that importing a private key for a compressed public key may be misinterpreted as uncompressed, or may be broken in some other unpredictable way, so please be careful....

[tspacepilot]

Thanks guys, for the replies and the warnings.

I should emphasize, I write computer programs for a living and I don't deal in large amounts of bitcoin.  For me, I have a very keen academic interest and I hold a little BTC in a cold storage address, but I play around with small amounts in order to learn.  Part of that learning is exporting/importing keys, make and make install on bitcoind and sending raw transactions, etc.  So, I understand the caveat emptor of it all.  I'm also the kind of person who immediately erases all the software on my cell phone and makes cyanogenmod from source to flash.  Basically, I void warranties left and right and I understand that I take responsibility for my actions and cetera.

btchris explained the situation very well to me in a PM so I hope he won't mind if I quote it below.  Basically, what I said above about multibit "choosing" the address was incorrect. When I import the uncompressed 5.. format private key, I get the uncompressed address in the wallet.  When I import the compressed version with L or K, I get the compressed address.  Alle ist gud!

Thanks again fellas.

I'd like to know a little more about this but I didn't find much info on the wiki.  One thing I tried was signing a message with Multibit (where the uncompressed address appears) and then trying to verify it using the other address, that didn't work

Could you point me to any resources regarding this?

Thanks for any advice.

It's... complicated....

A public key is an (x,y) point on a 2D plane.

It turns out that if you have the x coordinate, that there are only 2 possible y coordinates.

So there are two ways to encode a public key.

1. The compressed way: the full x coordinate, and a single up/down indication -- is the y coordinate the upper one or the lower one?

2. The uncompressed (old) way: the full x coordinate and the full y coordinate.

Option 1 is the more "modern" way because it takes up less space (in the blockchain), but option 2 was more common in the olden days.