RE: what's the use of b58_encode? It is dead code for this use-- bitcointools (where I first implemented this stuff) uses it to translate from binary hash160 to human-readable bitcoin addresses.

RE: 27 character bitcoin addresses: I'm puzzled. There's a mismatch between the way bitcoin treats leading zeros (leading 1's when base58 encoded) and the way my python code treats them.

ByteCoin: have you dissected the bitcoin code enough to explain how it decides how many leading zeros to add? According to my code, '14oLvT2' and '11111111111111111111111111114oLvT2' are the same bitcoin address (corresponding to the public key with a hash of all zero bytes).

But bitcoin only likes the 27-character '1111111111111111111114oLvT2' version.

I'll have to stare at the code some more tomorrow when I'm more awake.

How often do you get the chance to work on a potentially world-changing project?

For every leading 0x00 byte, add a leading 1 (encode). For every leading 1, add a 0x00 byte (decode). For encode, don't accept input that doesn't have an even number of bits (divisible by eight), as this doesn't make sense. For decode, pad leading zeros until you have an even number of bits.

I just check that the output immediately post-DecodeBase58 (including leading zeroes, checksum, versionNumber) is 25 bytes long. I think that Bitcoin does something similar to this.

Gavin, I'm trying to understand your usage of default.error_messages (first line in the snippet), vs. self.error_messages (last line in the snippet, above), in your code.Does Django somehow link those two together? Or is that a bug in the code? (I'm sure this code has been tested a lot since October!)

Seems to me that you should be using the same dictionary in both places.