Is it the 52 char compressed key, or is this the worst keypair ever? (bounty)

[BitBlitz]

I have a 52 character private key (starts with 'L').  The wallet.dat was encrypted some time after the block was solved, and became corrupted to the point that the bitcoin.org client would not open with it.  I extracted the keys with pywallet and managed to import and spend all of the block rewards in the wallet except this one.

Here is what is interesting:
1) I can NOT import the key into an unencrypted wallet with pywallet.
2) I can import the key into an encrypted wallet with pywallet, and the balance is shown.
3) If I attempt to send all or part of that amount, the client reports "Transaction creation failed".
4) Nothing shows up in the debug log.
5) I can import the key to a blockchain wallet and the balance is shown (still cannot send).

Is pywallet able to handle 52 character keys correctly?  
Any ideas why this works with encrypted wallets only?

[1715087930]

1715087930

[1715087930]

1715087930

[1715087930]

1715087930

[casascius]

Private keys are 51 characters.

Maybe your key has an invisible character in it. Has caught me by surprise. Hand retype and see if it works.

[BitBlitz]

The 52 character private keys are paired with compressed public keys. I've imported and tried this key in 0.3.x, 0.4.x, and more current clients.  Always the same story...  It is a valid key---at least it imports to the right address with the lost block reward.

[Stephen Gornick]

The wallet.dat was encrypted some time after the block was solved, and became corrupted to the point that the bitcoin.org client would not open with it.

The Bitcoin.org client version 0.7.1 has a "-salvagewallet" option.  You might want to try that on a copy of the wallet.dat,
then if that loads, you can use the console from the Debug window to dumpprivkey.

[BCB]

BitBlitz

I believe I saw a discussion about a similar issue on bitcoin-dev  irc channel recently.  Have you tried there?

[BitBlitz]

The Bitcoin.org client version 0.7.1 has a "-salvagewallet" option.  You might want to try that on a copy of the wallet.dat,
then if that loads, you can use the console from the Debug window to dumpprivkey.

I tried salvagewallet a few times (and I forgot a data point).  Salvagewallet just deletes the key

[OpenYourEyes]

This isn't really my area, but have you tried using Armoury to import the key.

I had issues importing private keys before, tried many clients and blockchain.info, but Armoury came to the rescue in the end.

Edit: Post the key Lol.

[Garr255]

PM me the privkey (and wallet if you'd like) and I'll try my hand at it.

[flatfly]

Private keys are 51 characters.

Maybe your key has an invisible character in it. Has caught me by surprise. Hand retype and see if it works.

Actually compressed private keys are 52 characters, so the length is not the issue here. 

Also bitcoind releases prior to 0.6.0 do not support compressed keys so I'm not surprised you couldn't spend it from older releases.

There is a new python patch for Electrum (not merged in the release code yet) that supports importing of such keys - perhaps you could give that a try? It would probably work.  If you're willing to try this out and need some help, I'll be available to guide you through getting and merging the patch later today.

[casascius]

I just updated my Casascius Bitcoin Address Utility to fully support compressed private keys.  So yeah, now I definitely agree, 52 characters for a private key if it's compressed...

There is no way to use a compressed private key with a client that doesn't support it.  There is no "uncompressed equivalent" (well, there is, but it will have a different bitcoin address so it's useless).

[kjj]

I'd try the raw transaction API and see if I could move it that way.

[BitBlitz]

Still working on this one...    I can get compressed key compatible clients to show the balance, but they all fail when I try to send them.

Mike, The Casascius Address tool confirms that the 'other address' that I see in some tools or clients is an import of the private key without compressing the public key. 

[kjj]

Have you tried the importprivkey RPC call on a normal bitcoin 0.7.1 node?

Sounds to me like the WIF is incorrect, but the tools you are using aren't checking the checksum, so they happily import it, but since it isn't right, they can't actually make a valid signature for it.

It would be hard to know more without seeing it, and you probably don't want to hand a stranger on the internet what could be $500.  That said, I'd be willing to take a look at it if you'd like.

[casascius]

https://casascius.com/btcaddress-alpha.zip is the only version that recognizes compressed public keys.

My utility can ignore a bad checksum if you put a ? after the address. Converting it back from hex to WIF will give you one with a recalculated checksum.

Perhaps you can share the public key (starts with 02, 03, or 04). This is safe to share and may help.

[J-Norm]

I had a funny private key that the client would not accept.

I went to my blockchain.info wallet, then imported it as a private key. It worked, then I went to the "paper wallet" page and it gave me a normal private key that would import to the regular client.

If this works sent the bounty to: 1JNv6WZsh8rPfXYaKXXMnuKvsjZKhnoL5d

[casascius]

An example of a potential "funny" private key is one that starts with "y".

These are formed when pywallet misbehaves when encountering a private key that starts with a 00 byte. It is malformed but many utilities will still accept it. Others won't.  I believe mine will, since I am aware of the problem and likely would have accommodated it.  It can be converted to the proper format with no loss of funds. 

[BitBlitz]

Circling back to this... (I've been way too busy)
--By the way Mike, I missed the chance to meet you at DefCon.  Maybe next time.

J-Norm: paper wallet or key exports just issue the same privkey.  

Anyways, I think I just need to find a client that can sign a transaction with this key.  

[sunnankar]

I went to my blockchain.info wallet, then imported it as a private key. It worked, then I went to the "paper wallet" page and it gave me a normal private key that would import to the regular client.

That should work. Using BrainWallet.org and BitAddress.org tools may be a shorter method.