Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2012-01-30 📝 Original message:On 2012 January 28 ...

📅 Original date posted:2012-01-30
📝 Original message: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>;