Prize for importing private key [WON]

[Hal]

This is a base58 encoded plain private key (256 bit value from a "key" entry in my wallet) worth 20 BTC. We're now at block 109180. Let's see how long it takes for someone to input the key and collect the bitcoins.

2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy

ETA: this is wrong, the correct value is later in the thread

[Hal]

The corresponding bitcoin address is 17kzeh4N8g49GFvdDzSf8PjaPfyoD1MndL. Here's the blockexplorer link: http://blockexplorer.com/address/17kzeh4N8g49GFvdDzSf8PjaPfyoD1MndL. When the balance goes to zero, someone's got it.

[grondilu]

Damn it Hal, that's very mean.  Now we have to work on this or we'll look like fools.

I think I could manage to do that by tweaking the bitcoin code and recompiling.  But I'd have to use a brand new wallet cause I don't like to mess with my wallet.

PS.  pff  I give up.  I've tried to tweak the code for generating a new address.

Code:

vector<unsigned char> GenerateNewKey()
{
    RandAddSeedPerfmon();
    CKey key;
    key.MakeNewKey();
    if (!AddKey(key))
	throw runtime_error("GenerateNewKey() : AddKey failed");

    //  this is what I tried
    unsigned int nSize = i2d_ECPrivateKey(key.pkey, NULL);  // I had to set pkey public in Ckey
    if (!nSize)
	throw key_error("CKey::GetPrivKey() : i2d_ECPrivateKey failed");
    CPrivKey vchPrivKey(nSize, 0);
    unsigned char* pbegin = &vchPrivKey[0];
    vector<unsigned char>& vchRet;
    DecodeBase58("2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy", vchRet);
    strcpy(pbegin, vchRet);  
    key.SetPrivKey(vchRet); 
    //  end of what I tried

    return key.GetPubKey();
}

The idea was to create the private key with the getnewaddress command.

It doesn't compile since vchRet is not a CPrivKey object.   I don't understand well enough what CPrivKey is.

Good luck to other people who will try.

[myrkul]

Correct me if I'm wrong, but aren't Bitcoin private keys 279 bytes long?

Base 58. Each digit in that string can hold a lot of numbers: 123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ

It's a great way to have a LOT of possibilities, in a small space, with little chance of error when hand-entering data.

So, it is 279 bytes long, if it were converted out. (or, it should be. I don't feel like doing the math at the moment)

[theymos]

You can get the hex version here:
http://blockexplorer.com/q/addresstohash/2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy

[kvk]

As far i understand the bitcoin, it's not really possible to redeem the coins with only private key, the script expects full public key to compare with hash160 and to verify signature. Since no coins were redeemed with this address, the pubkey is not known and the task of reversing the hash is impossible.

[myrkul]

The corresponding bitcoin address is 17kzeh4N8g49GFvdDzSf8PjaPfyoD1MndL. Here's the blockexplorer link: http://blockexplorer.com/address/17kzeh4N8g49GFvdDzSf8PjaPfyoD1MndL. When the balance goes to zero, someone's got it.

Address is the public key. He's given us everything we need, we just need to figure out how to stick the private key into a wallet, and then send ourselves the coins.

[theymos]

As far i understand the bitcoin, it's not really possible to redeem the coins with only private key, the script expects full public key to compare with hash160 and to verify signature. Since no coins were redeemed with this address, the pubkey is not known and the task of reversing the hash is impossible.

ECDSA public keys are derived from their private keys. It makes the challenge even more difficult, though.

Address is the public key. He's given us everything we need, we just need to figure out how to stick the private key into a wallet, and then send ourselves the coins.

The address is the hash of the public key. You need the full public key to spend it.

[Binford 6100]

so it goes like this?
1) base58decode the private key
2) find out the public key
3) modify your wallet.dat to include the key pair
4) rescan the blockchain
5) spend

btw added a btc to the bounty (hope hal does not spend it

[myrkul]

The address is the hash of the public key. You need the full public key to spend it.

Ahhh... Interesting. Deceptively simple problem he's given us... essentially, we need to re-mine his block, then?

[m0mchil]

Hal, could you please provide HEX encoded private key ?

[0x6763]

As far i understand the bitcoin, it's not really possible to redeem the coins with only private key, the script expects full public key to compare with hash160 and to verify signature. Since no coins were redeemed with this address, the pubkey is not known and the task of reversing the hash is impossible.

ECDSA public keys are derived from their private keys. It makes the challenge even more difficult, though.

I wrote some code (that I'll share after I get the 20 BTC, haha) that will generate a public key from a private key.  I've tested it on multiple private keys in my wallet and it always generated the correct public key.  The problem is that it doesn't generate a public key that makes the address Hal provided.  Either my base58 decoding function is wrong, or Hal's base58 encoding function is wrong, or he gave us the wrong private key.

Address is the public key. He's given us everything we need, we just need to figure out how to stick the private key into a wallet, and then send ourselves the coins.

The address is the hash of the public key. You need the full public key to spend it.

The private key was really the only info we needed, since the public key could be calculated from that, and then the address created from that, and the block chain could be searched for any payments to that address.

[m0mchil]

0x6763, what public key do you get?

17KzV7RfQnmqcFC3cnS3RqWXQm1CREtNmj or something else?

[0x6763]

0x6763, what public key do you get?

17KzV7RfQnmqcFC3cnS3RqWXQm1CREtNmj or something else?

Yeah, that's it.

[Pieter Wuille]

Correct me if I'm wrong, but aren't Bitcoin private keys 279 bytes long?

As I understand it, private keys are indeed 279 bytes long (though with some redundancy in them), public keys are 0x04 + 32-byte X-coordinate + 32-byte Y-coordinate (totalling 65 bytes, 520 bits), and addresses contain a 20-byte (160 bit) hash of the public key.

Not sure what you've given us Hal, but as it is only 256 bit, I doubt it's a private key.

PS: base58 encoding is more efficient than hex encoding, but it still can't turn a 279-byte key into a 44-character string...

[0x6763]

Correct me if I'm wrong, but aren't Bitcoin private keys 279 bytes long?

As I understand it, private keys are indeed 279 bytes long (though with some redundancy in them), public keys are 0x04 + 32-byte X-coordinate + 32-byte Y-coordinate (totalling 65 bytes, 520 bits), and addresses contain a 20-byte (160 bit) hash of the public key.

Not sure what you've given us Hal, but as it is only 256 bit, I doubt it's a private key.

PS: base58 encoding is more efficient than hex encoding, but it still can't turn a 279-byte key into a 44-character string...

The private key is actually just a 256-bit number. The public key is two 256-bit numbers.  All of those other bytes that Bitcoin is using just contains redundant information about the elliptic curve (redundant since Bitcoin already knows the curve info anyway, and therefore doesn't need it stored with the key).

[0x6763]

If Hal did give us the wrong private key on accident, he might want to remove that key pair from his wallet so he doesn't accidentally give that address out in the future, since anyone else could spend any money sent to that address.

[0x6763]

Haha, the stakes are a little higher now. Another 1.05 BTC went to that address. http://blockexplorer.com/address/17kzeh4N8g49GFvdDzSf8PjaPfyoD1MndL

[jav]

You can get the hex version here:
http://blockexplorer.com/q/addresstohash/2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy

That website claims 66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC46 is the hash version.
What exactly is being calculated there? I wrote my own decode58 code and I get this value:
1B66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC4677BE50CA

Represented in binary the blockexplorer hex is only 215 bit, whereas my hex is 253 bit. Add another 3 leading zeroes and you get 256 bit.

Here is the Haskell code I used to decode the string:


import Maybe

decode :: [Char] -> [(Char, Integer)] -> Integer
decode s mapping = worker (reverse s) mapping bases
    where
    bases = iterate (58 *) 1
    worker :: [Char] -> [(Char, Integer)] -> [Integer] -> Integer
    worker [] _ _ = 0
    worker (c:cs) mapping (b:bs) =
        (fromJust (lookup c mapping)) * b + (worker cs mapping bs)

main = do
    let chars = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    let mapping = zip chars [0..]
    print $ decode "2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy" mapping

[0x6763]

You can get the hex version here:
http://blockexplorer.com/q/addresstohash/2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy

That website claims 66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC46 is the hash version.
What exactly is being calculated there? I wrote my own decode58 code and I get this value:
1B66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC4677BE50CA

Represented in binary the blockexplorer hex is only 215 bit, whereas my hex is 253 bit. Add another 3 leading zeroes and you get 256 bit.

Theymos's link doesn't make any sense, since 2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy is not an address, but is instead a base58 encoded 256-bit number.  Bitcoin addresses are much shorter than that base58 encoded number.

I'm also getting 1b66ff9f63ace537b537be1f7f0cb585649c226c72eeff43d59fac4677be50ca when I decode the base58 string.