Prize for importing private key [WON]

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

However it does show that our base58 decoding functions must be functioning the same as Theymos's (which I suspect is correct as it's consistent with other instances of the base58 decoding that I've seen):

Code:

Ours:  1B66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC4677BE50CA
Theymos: 66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC46

(the first and last 4 bytes are removed after decoding the base58 encoded data in attempt to extract the hash of the public key, which is obviously incorrect here)

Currently my conclusion is that Hal made an error either in finding the correct private key that goes along with the address he shared, or in encoding the key in base58.

[m0mchil]

Last four bytes of address are check sum. Not sure what happens to first byte though.

I guess there is some minor discrepancy between what Hal used to 'encode' his private key and what we use.

[grondilu]

To me the difficult part is the modification of the wallet.dat file.

To decode base58, one can use my bash library:

Code:

#!/bin/bash
# 
# Requires bc, dc, openssl, xxd
#

base58=({1..9} {A..H} {J..N} {P..Z} {a..k} {m..z})
bitcoinregex="^[$(printf "%s" "${base58[@]}")]{34}$"

decodeBase58() {
    local s=$1
    for i in {0..57}
    do s="${s//${base58[i]}/ $i}"
    done
    dc <<< "16o0d${s// /+58*}+f" 
}

encodeBase58() {
    # 58 = 0x3A
    bc <<<"ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }" |
    tac |
    while read n
    do echo -n ${base58[n]}
    done
}

checksum() {
    xxd -p -r <<<"$1" |
    openssl dgst -sha256 -binary |
    openssl dgst -sha256 -hex |
    sed 's/^.* //' |
    head -c 8
}

checkBitcoinAddress() {
    if [[ "$1" =~ $bitcoinregex ]]
    then
        h=$(decodeBase58 "$1")
        checksum "00${h::${#h}-8}" |
        grep -qi "^${h: -8}$"
    else return 2
    fi
}

hash160() {
    openssl dgst -sha256 -binary |
    openssl dgst -rmd160 -hex |
    sed 's/^.* //'
}

hash160ToAddress() {
    printf "%34s\n" "$(encodeBase58 "00$1$(checksum "00$1")")" |
    sed "y/ /1/"
}

publicKeyToAddress() {
    hash160ToAddress $(
    openssl ec -pubin -pubout -outform DER |
    tail -c 65 |
    hash160
    )
}

timestamp() {
    hash160ToAddress "$(hash160)"
}

$ decodeBase58 2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy
1B66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC4677BE50CA

$ !! |xxd -r -p |base64
G2b/n2Os5Te1N74ffwy1hWScImxy7v9D1Z+sRne+UMo=


FWIW

[0x6763]

I'm not even bothering to put it in my wallet.  I'm just going to create a transaction that spends it (sending it to one of the addresses already in my wallet) as soon as I get the correct private key.  Putting it in my wallet would mean requiring bitcoin to rescan the block chain so it knows that it has another 21.05+ BTC to spend, and then after it's finally done doing that, I'd have to spend my entire bitcoin balance to a new address just to make sure that the official Bitcoin software spends the specific bitcoins we're all trying to get.  Just sending out a transaction with my own custom code is a lot easier and faster. 

[grondilu]

Ok but how do you plan on making a transaction without having the key in your wallet ?

[xenon481]

When trying to decode the Private Key, I'm not getting the same hex that y'all are. But that's because, apparently, our base58 alphabets are different from eachother.

My base58 alphabet (the one I see all over Google): "123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"

When I use your alphabet, I get the same thing y'all are. Why are the cases reversed between yours and my alphabets?

[Pieter Wuille]

I've also created some code that generates a "full" (279-byte) private key based on a given 256-bit private key number (using openssl's EC_KEY_generate_key after setting the private key as a parameter). The problem is (more or less expected?) that the corresponding public key varies each time.

Are we sure that a public key can be generated deterministically from *just* the 256-bit private number? It is stored in full in the 279-byte version, which may be becsause multiple public keys can correspond to the same private number.

I do wonder why/how 0x6763 and m0mchil managed to get the same (wrong?) public key from that private number. Maybe I'm still not getting something

[grondilu]

My base58 alphabet (the one I see all over Google): "123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"

Just use Satoshi's alphabet:

$ grep abcde bitcoin/src/base58.h
static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

[0x6763]

Ok but how do you plan on making a transaction without having the key in your wallet ?

I've written almost a complete bitcoin client in Clojure.  And since Clojure has a REPL, I can build any Bitcoin data structure I want as fast as I can type the function name and the pieces of information that needs to go in it, and can send it out on the wire just as easily.  I don't have to bother with the write, compile, run cycle.  I just write, and it evaluates when I press "Enter", like Python's REPL.  And for this little challenge I quickly wrote up a function that already has all of the needed information, except for the public key, to build a transaction to spend these 21.05+ BTC.  All I have to do is give the function the correct private key, and it will calculate the public key, put it in the script in the transaction input, and spend those bitcoins.

I suppose I didn't update my function for the two new payments that address received, yet, though, so unless I do that, that money will still be available for others.

One thing to note is that if I don't put it in my wallet, it means that any future money going to that address won't automatically become part of my balance.  Another thing to note is that if I someone to put it in their wallet, their balance could go up or down as other people pay that address money, and others that have the private key spend the money available to that address.

[0x6763]

Someone sent another 0.01 BTC to that address, lol.

[alkor]

Someone sent another 0.01 BTC to that address, lol.

Yes, that was my one cent.

[ribuck]

My base58 alphabet (the one I see all over Google): "123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"

That alphabet is "all over Google" because it's the one that Flickr uses. But if you search for "base 58" bitcoin then the correct variation will be "all over Google".

Better still, ask the source code for the authoritative answer:
https://github.com/bitcoin/bitcoin/blob/master/base58.h

[Mike Hearn]

Yeah, I got to the same point :-( Looks like either we're all missing something fundamental, or Hal gave out an incorrect private key.

Seems we're all doing it with private code, interesting.

[Hal]

Sorry! I did screw up the encoding. Here is the 256-bit private key in big-endian hex:

C85AFBACCF3E1EE40BDCD721A9AD1341344775D51840EFC0511E0182AE92F78E

My new attempt to base58 encode this is:

EV71KQfoePBeWT79sV1VE7fWRgv1KNUxTNapH6ZbaRfB

That's custom code, maybe somebody could check it.

To apologize, I've added 30 BTC to the address. We're now at block 109352.

The reason I did it this way is that it would be a good format for passing around or backing up bitcoins.

BTW the new version of Bitcoin has a -rescan switch to find all txns that are for wallet keys. Only takes a couple minutes.

[Mike Hearn]

Why thankyou Hal, you are a scholar and a gentleman. That was an unexpectedly profitable Sunday evening! If we ever meet I will be glad to buy you drinks for the evening.

Now I'm wondering what I should do with this ⓑ50 ? I quite like this challenge concept ... I'm thinking I should make the coins available to somebody who can craft a particular type of transaction, but it'd need a miner willing to incorporate it.

Anyone else got ideas for the next step for these coins?

[tcatm]

Donate them to someone making a patch for importing private keys into the wallet.

[Binford 6100]

The reason I did it this way is that it would be a good format for passing around or backing up bitcoins.

yes, this way is much more convenient than dealing with all the wallet data

a private key could fit into a QR code while the smallest amount of space needed by a wallet is always around 30 kB

Now I'm wondering what I should do ...

could you, please, publish your code? : )

[m0mchil]

I really can't hide my disappointment   waited hours for Hal to provide the correct key - and to see that someone got it 3 blocks earlier. Should master my 'F5' key.

There is a rather old patch (SVN 195) at https://github.com/m0mchil/bitcoin-impex-keys which supports RPC initiated exporting and importing of keys in PEM format. It also exports corresponding block numbers to speed up import.

The reason I didn't announce it back then is that it doesn't solve the double spend problem. The patch could be easily modified to not remove exported key from wallet (it does so at the moment) allowing copying of keys.

If anyone's interested I can easily add import method using just private key.

[Mike Hearn]

Sorry m0mchil, I have to admit I was surprised when I reloaded the page and saw Hal had replied. I just got lucky.

(edit to rephrase question)

Though fun I don't really understand the point of this. For backing your wallet you can just shut down the software and make a copy of wallet.dat. For moving coins between different wallets you can just send them as regular transactions.

Is there a use case for exporting private keys I haven't grokked yet?

[Mike Hearn]

By the way, I did this with a private Java implementation of BitCoin. I'm working on getting it open sourced, but because my employer owns the code I have to get various approvals from them first.  So right now I can't release the code, sorry.