Talk:BIP 0013 - Revision history

Gronager at 10:51, 20 February 2012

2012-02-20T10:51:37Z

← Older revision		Revision as of 10:51, 20 February 2012
Line 5:		Line 5:
	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 ~~version~~][20-byte hash][1-~~bytes one for version~~][3-byte checksum]		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)

Gronager at 10:50, 20 February 2012

2012-02-20T10:50:53Z

← Older revision		Revision as of 10:50, 20 February 2012
Line 4:		Line 4:
	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 version][20-byte hash][1-bytes one for version][3-byte checksum]		base58-encode: [one-byte version][20-byte hash][1-bytes one for version][3-byte checksum]

Gronager at 10:50, 20 February 2012

2012-02-20T10:50:37Z

← Older revision		Revision as of 10:50, 20 February 2012
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:

Gronager at 10:50, 20 February 2012

2012-02-20T10:50:02Z

← Older revision		Revision as of 10:50, 20 February 2012
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)

Andyparkins: Comment on "version" nomenclature

2011-12-09T11:49:07Z

Comment on "version" nomenclature

New page

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)