wif decodes longer than expected

[sdp]

It looks as if my Satoshi client has a 33 byte secret.  Decoding the wif, which is a string I got from dumpprivkey.  Now, when decoded from base58 this much longer string should turn into something 37 bytes long.  Instead of that it is 38 bytes long.  Is there a longer magic number now?

[kjj]

compression flag?

[sdp]

Code:

function chomp( sequence o )
    if length(o) and o[length(o)]='\n' then
	return o[1..length(o)-1]
    end if
    return o
end function

constant pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
function decode_base_58(sequence s)
	atom answer = 0
	atom power_multicand = 1
	for i = length(s) to 1 by -1 do
		answer += power_multicand * (find(s[i],pszBase58)-1)
		power_multicand *= 58
	end for
	return answer
end function

sequence line = chomp(gets(0))

? log(decode_base_58(line))/log(256)

You'll need EUPHORIA for this.   (see openeuphoria.org)  Here this decodes a wif sent to standard input and prints the log base 256 of the value.  Now, if the smallest integer greater than or equal to this value is 38, then you need 38 bytes to represent it.

The fact that the numbers are not arbitrary length numbers means nothing for we only care about the magnitude.  I ran this on a wif I got from my bitcoin client and got:

37.87505791

You need 38 bytes for this value.  Arguably we should be able to import the wif I got from one client to another.  I will try this.  The most significant byte is 128 which is the magic number.

[sdp]

I see now you have two possible sizes for the secret.  It might be 32 bytes or 33 bytes.  I have found a bug in libbitcoin.

[kjj]

compression flag?

[sdp]

compression flag?

Yes, you were right.  I only used dumpprivkey and got a long string.  If the flag is true there is an extra byte before the checksum.  This library I am using handles only wifs with 37 byte secrets.

sdp