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

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

[Michael Gronager]

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

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1444 bytes --]

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@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]