BIP-12, 16, 17

Dear Bitcoiners,

I have been following some of the debate on the various BIP suggestions for enabling e.g. multisignature transactions. ( First a little rant - it seems like the discussion takes place in at least 5 different forums plus the IRC, this is so annoying. Please keep the discussion at one place and refer to this for people asking questions other places - including me, now... ).

I have some issues with BIP-16, it is mainly the lines 265-269 in the reference implementation (https://github.com/gavinandresen/bitcoin-git/blob/pay_to_script_hash/src/base58.h):

PUBKEY_ADDRESS = 0, SCRIPT_ADDRESS = 5, PUBKEY_ADDRESS_TEST = 111, SCRIPT_ADDRESS_TEST = 196,

The purpose of the networkID is broken by this, as it ties additional information into an address as a hack. In the BIP-12 implementation I argued that this notification on address level is not needed, and should not be introduced, I am still of the same opinion. The bitcoin code has enough of globals and cross references inside the code s it is today, lets not add another one...

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.

The BIP-17 seems a step forward, but I also agree with Gavins note on one on the forums, that it behaves differently in input and output scripts. So it obviously need some further work too.

Cheers,

Michael

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