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

sunnankar

legendary

Activity: 1031

Merit: 1000

Quote from: J-Norm on November 22, 2012, 09:29:29 PM

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.

BitBlitz

sr. member

Activity: 285

Merit: 250

Turning money into heat since 2011.

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

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

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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.

J-Norm

newbie

Activity: 56

Merit: 0

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

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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.

kjj

legendary

Activity: 1302

Merit: 1026

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.

BitBlitz

sr. member

Activity: 285

Merit: 250

Turning money into heat since 2011.

Still working on this one... Angry

I can get compressed key compatible clients to show the balance, but they all fail when I try to send them. Huh

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

legendary

Activity: 1302

Merit: 1026

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

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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

flatfly

legendary

Activity: 1092

Merit: 1016

760930

Quote from: casascius on October 30, 2012, 08:39:13 PM

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.

Garr255

legendary

Activity: 938

Merit: 1000

What's a GPU?

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

OpenYourEyes

full member

Activity: 238

Merit: 100

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.

BitBlitz

sr. member

Activity: 285

Merit: 250

Turning money into heat since 2011.

Quote from: Stephen Gornick on October 30, 2012, 11:52:08 PM

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 Shocked

BCB

vip

Activity: 1078

Merit: 1002

BCJ

BitBlitz

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

Stephen Gornick

legendary

Activity: 2506

Merit: 1010

Quote from: BitBlitz on October 30, 2012, 08:10:06 PM

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.

BitBlitz

sr. member

Activity: 285

Merit: 250

Turning money into heat since 2011.

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.

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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

sr. member

Activity: 285

Merit: 250

Turning money into heat since 2011.

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?

Topic: Is it the 52 char compressed key, or is this the worst keypair ever? (bounty) (Read 1866 times)