From: Michael Gronager <gronager@ceptacle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 28 Jan 2012 11:21:19 +0100
Message-Id: <B2F57365-3B00-4A0A-B0FC-92B823796F2B@ceptacle.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Mime-Version: 1.0 (Apple Message framework v1251.1)
Subject: [Bitcoin-development] BIP-12, 16, 17
Precedence: list

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):=20

PUBKEY_ADDRESS =3D 0,
SCRIPT_ADDRESS =3D 5,
PUBKEY_ADDRESS_TEST =3D 111,
SCRIPT_ADDRESS_TEST =3D 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=