Talk:BIP 0013: Difference between revisions
Andyparkins (talk | contribs) Comment on "version" nomenclature |
No edit summary |
||
| 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 right way to do this is to structure the bitcoin address into: | |||
base58-encode: [one-byte version][20-byte hash][1-bytes one for version][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... | |||
--[[User:gronager|Michael Gronager/libcoin]] 10:49, 20 February 2012 (GMT) | |||
Revision as of 10:50, 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 version][20-byte hash][1-bytes one for version][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)