* [Bitcoin-development] BIP-12, 16, 17
@ 2012-01-28 10:21 Michael Gronager
2012-01-30 10:57 ` Andy Parkins
0 siblings, 1 reply; 2+ messages in thread
From: Michael Gronager @ 2012-01-28 10:21 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bitcoin-development] BIP-12, 16, 17
2012-01-28 10:21 [Bitcoin-development] BIP-12, 16, 17 Michael Gronager
@ 2012-01-30 10:57 ` Andy Parkins
0 siblings, 0 replies; 2+ messages in thread
From: Andy Parkins @ 2012-01-30 10:57 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-01-30 10:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-28 10:21 [Bitcoin-development] BIP-12, 16, 17 Michael Gronager
2012-01-30 10:57 ` Andy Parkins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox