Talk:BIP 0014 - Revision history

Nibor at 23:42, 26 December 2011

2011-12-26T23:42:21Z

← Older revision		Revision as of 23:42, 26 December 2011
Line 11:		Line 11:
	Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. I think the purpose of separating the useragent and the protocol is an excellent one, which the community clearly supported, but I don't think most people expected this to be some surprise legislation forcing nodes to identify themselves on the network in particular ways. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)		Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. I think the purpose of separating the useragent and the protocol is an excellent one, which the community clearly supported, but I don't think most people expected this to be some surprise legislation forcing nodes to identify themselves on the network in particular ways. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)
	* To clarify, I never said any information is required, and I agree clients may omit as much as they want. I do think that, as defined in the BIP, giving false information is in violation of, and entirely defeats the purpose of, the User Agent's designation as strictly "informational". On the contrary, I argue that such abuse of the field is more likely to result in other abuses, such as the cited all-browsers-are-mozilla issue which would not have been possible had browsers not begun lying (which was in itself a result of protocol behaviour changes based on User Agent, which is forbidden in this BIP). I oppose any attempt to modify the BIP to endorse this abuse of the User Agent field as it would render it utterly useless. Better to define it as a null string. --[[User:Luke-jr\|Luke-jr]] 06:02, 23 December 2011 (GMT)		* To clarify, I never said any information is required, and I agree clients may omit as much as they want. I do think that, as defined in the BIP, giving false information is in violation of, and entirely defeats the purpose of, the User Agent's designation as strictly "informational". On the contrary, I argue that such abuse of the field is more likely to result in other abuses, such as the cited all-browsers-are-mozilla issue which would not have been possible had browsers not begun lying (which was in itself a result of protocol behaviour changes based on User Agent, which is forbidden in this BIP). I oppose any attempt to modify the BIP to endorse this abuse of the User Agent field as it would render it utterly useless. Better to define it as a null string. --[[User:Luke-jr\|Luke-jr]] 06:02, 23 December 2011 (GMT)

			== The more data the better ==
			Any additional information would be useful for sites like http://bitcoinstatus.rowit.co.uk as this information can be tracked and reported back to the developers. --[[User:Nibor\|Nibor]] 23:41, 26 December 2011 (GMT)

Luke-jr at 06:02, 23 December 2011

2011-12-23T06:02:52Z

← Older revision		Revision as of 06:02, 23 December 2011
Line 1:		Line 1:
	Suggestion: be more explicit that the version in the protocol is a 32-bit integer, that 0.6.0 is represented by the number 60000, and that the 'subversion' field is an arbitrary string.		Suggestion: be more explicit that the version in the protocol is a 32-bit integer, that 0.6.0 is represented by the number 60000, and that the 'subversion' field is an arbitrary string.
	--[[User:Gavinandresen\|Gavin Andresen]] 19:19, 16 December 2011 (GMT)		--[[User:Gavinandresen\|Gavin Andresen]] 19:19, 16 December 2011 (GMT)
			* What "0.6.0"? The whole point of having a protocol version is that it isn't tied to the client version... --[[User:Luke-jr\|Luke-jr]] 06:02, 23 December 2011 (GMT)

	Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.		Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.
Line 9:		Line 10:

	Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. I think the purpose of separating the useragent and the protocol is an excellent one, which the community clearly supported, but I don't think most people expected this to be some surprise legislation forcing nodes to identify themselves on the network in particular ways. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)		Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. I think the purpose of separating the useragent and the protocol is an excellent one, which the community clearly supported, but I don't think most people expected this to be some surprise legislation forcing nodes to identify themselves on the network in particular ways. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)
			* To clarify, I never said any information is required, and I agree clients may omit as much as they want. I do think that, as defined in the BIP, giving false information is in violation of, and entirely defeats the purpose of, the User Agent's designation as strictly "informational". On the contrary, I argue that such abuse of the field is more likely to result in other abuses, such as the cited all-browsers-are-mozilla issue which would not have been possible had browsers not begun lying (which was in itself a result of protocol behaviour changes based on User Agent, which is forbidden in this BIP). I oppose any attempt to modify the BIP to endorse this abuse of the User Agent field as it would render it utterly useless. Better to define it as a null string. --[[User:Luke-jr\|Luke-jr]] 06:02, 23 December 2011 (GMT)

Gmaxwell: /* Arguments about requirements */

2011-12-23T04:13:52Z

Arguments about requirements

← Older revision		Revision as of 04:13, 23 December 2011
Line 8:		Line 8:


	Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)		Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. I think the purpose of separating the useragent and the protocol is an excellent one, which the community clearly supported, but I don't think most people expected this to be some surprise legislation forcing nodes to identify themselves on the network in particular ways. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)

Gmaxwell: /* Arguments about requirements */ new section

2011-12-23T04:08:38Z

Arguments about requirements: new section

← Older revision		Revision as of 04:08, 23 December 2011
Line 4:		Line 4:
	Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.		Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.
	--[[User:Andyparkins\|Andyparkins]] 11:45, 9 December 2011 (GMT)		--[[User:Andyparkins\|Andyparkins]] 11:45, 9 December 2011 (GMT)

			== Arguments about requirements ==


			Luke has been arguing that clients are required to write specific information into the various fields and forbidden from lying e.g. a merchant daemon can't claim to be running a GUI in order to avoid making it a target for attack. I don't believe this is actually required by the BIP as written. Nor do I think requiring it would make sense: the requirement can't really be enforced, required information disclosure would make users less secure, and the expectation of certain uses would lead to programs changing their behavior based on it because they think they can depend on it (much like all-browsers-are-mozilla). I think this can be clarified by the judicious addition of MAY and SHOULD into the document. Unless there is opposition I will go ahead and do it. --[[User:Gmaxwell\|Gmaxwell]] 04:08, 23 December 2011 (GMT)

Gavinandresen: Suggestion RE: integers versus strings

2011-12-16T19:19:49Z

Suggestion RE: integers versus strings

← Older revision		Revision as of 19:19, 16 December 2011
Line 1:		Line 1:
			Suggestion: be more explicit that the version in the protocol is a 32-bit integer, that 0.6.0 is represented by the number 60000, and that the 'subversion' field is an arbitrary string.
			--[[User:Gavinandresen\|Gavin Andresen]] 19:19, 16 December 2011 (GMT)

	Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.		Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.
	--[[User:Andyparkins\|Andyparkins]] 11:45, 9 December 2011 (GMT)		--[[User:Andyparkins\|Andyparkins]] 11:45, 9 December 2011 (GMT)

Andyparkins: Comment on non-incremental git commitish workaround

2011-12-09T11:45:48Z

Comment on non-incremental git commitish workaround

New page

Just as a point of information; "git describe" output solves the problem of non-incremental committish. It does this by providing a base version code (the most recent tag name) the number of commits past that tag and then a little bit of the commitish for the revision in question.
--[[User:Andyparkins|Andyparkins]] 11:45, 9 December 2011 (GMT)