[Bitcoin-development] BIP-12, 16, 17

[Andy Parkins]

On 2012 January 28 Saturday, Michael Gronager wrote:

> If we want more information in a bitcoin address we could just as well
> cannibalize it from the checksum - today it is 4 bytes (1 to 4mia) it
> could be 2 or 3 bytes (1 to 65k or 16M) and that would not break the
> current meaning of the network ID. This would have the same effect - that
> you could not mistake two different addresses and create a non-redeemable
> transaction.

I'm throwing this out as an idea; not necessarily saying it's doable or even 
good.

There is spare capacity in the base58 encoding.

 - The address hash is 20 bytes
 - The checksum is 4 bytes
 - The address type is 1 byte
 
The longest and largest address is therefore 25 bytes of 0xff (it's not 
possible to all be 0xff of course).  Converting those 25 bytes of 0xff to 
base58...

 hex:    ffffffffffffffffffffffffffffffffffffffffffffffffff
 base58: 2mXR4oJkmBdJMxhBGQGb96gQ88xUzxLFyG

This is 34 base58 symbols.  It's not the largest base 58 number that will fit 
in 34 symbols though...

 base58: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
 hex:    20a8469deca6b5a6d367cbc0907d07e6a5584778de27ffffffff
 vs hex:   ffffffffffffffffffffffffffffffffffffffffffffffffff

i.e. there are a few unused bits (~5) available in the base58 representation 
that can be added without changing the number of symbols in the address.



Andy

-- 
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120130/18318a15/attachment.sig>