Talk:BIP 0013: Difference between revisions
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Personally, I don't like the nomenclature "version". It's signalling far more than just a version. How about "address class"? | Personally, I don't like the nomenclature "version". It's signalling far more than just a version. How about "address class"? | ||
--[[User:Andyparkins|Andyparkins]] 11:49, 9 December 2011 (GMT) | --[[User:Andyparkins|Andyparkins]] 11:49, 9 December 2011 (GMT) | ||
The "version" portion of the address has so far been labeled "network id", and signals from which network and which chain the address can be used for. I thin that this change from network id to version is much more fundamental and should not just be squeezed in alone with bip16/17. | The "version" portion of the address has so far been labeled "network id", and signals from which network and which chain the address can be used for. I thin that this change from network id to version is much more fundamental and should not just be squeezed in alone with bip16/17. | ||
The right way to do this is to structure the bitcoin address into: | The right way to do this is to structure the bitcoin address into: | ||
base58-encode: [one-byte | |||
base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum] | |||
This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. | This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. | ||
An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... | An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... | ||
--[[User:gronager|Michael Gronager/libcoin]] 10:49, 20 February 2012 (GMT) | --[[User:gronager|Michael Gronager/libcoin]] 10:49, 20 February 2012 (GMT) | ||
Latest revision as of 10:51, 20 February 2012
Personally, I don't like the nomenclature "version". It's signalling far more than just a version. How about "address class"? --Andyparkins 11:49, 9 December 2011 (GMT)
The "version" portion of the address has so far been labeled "network id", and signals from which network and which chain the address can be used for. I thin that this change from network id to version is much more fundamental and should not just be squeezed in alone with bip16/17. The right way to do this is to structure the bitcoin address into:
base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum]
This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... --Michael Gronager/libcoin 10:49, 20 February 2012 (GMT)