New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement uacomment config parameter which can add comments to user agent as per BIP-0014 #6462
Conversation
Concept ACK. Needs some sort of size limiting. |
@@ -99,11 +100,20 @@ std::string FormatSubVersion(const std::string& name, int nClientVersion, const | |||
std::ostringstream ss; | |||
ss << "/"; | |||
ss << name << ":" << FormatVersion(nClientVersion); | |||
if (!comments.empty()) | |||
|
|||
const std::string key = "-uacomment"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, FormatSubVersion is a pure utility function that doesn't use any global state. I think it should stay that way. E.g. by adding an const std::vector<std::string> &commentList
argument. Then pass in this data at the caller side.
Also makes it easier to test this in util_tests
.
Concept ACK. |
Concept ACK, agree with @laanwj. |
Updated commit to reflect @laanwj request (to not have FormatSubVersion function dependent on global object). (Actually, this was my original code, but I changed it, because I did not want to duplicate the logic in two files). |
@jgarzik What is the maximum desired length of user agent string? Or should we just limit the number of comments and their length (e.g. max 5 comments of max 40 characters)? |
Bitcoin Core will reject strings longer than 256 characters for the subser string in "version" messages. |
Tested ACK. Named a few nodes.
Names are returned both by
It will happily send a
... which, as expected, gets me only connections to old versions. The result is quite interesting. Some nodes send me a REJECT message, which, as it arrives before full version negotiation is seen as misbehavior:
Although not an easy to trigger issue, we should avoid sending a string longer than we accept ourselves. I share your concern about duplicating code: but you could still define a function that calls |
which can add comments to user agent as per BIP-0014
Easiest logic would be to discard all of the comments if strlen > 256. |
It's a workable solution but failing silently is unexpected behavior. I'd prefer to check this in AppInit2 and fail if the subversion string is too long. |
Added check to AppInit2 function. (No more than 4 comments and no longer than 40 characters allowed). |
utACK. Nit: now you can provide 4string x 40bytes. What if one likes to provide 1x50 bytes? |
Reworked check to check total length of all comments altogether. If it is more than 200 characters the error is issued. |
ut ACK |
utACK |
Reworked-By: Wladimir J. van der Laan <laanwj@gmail.com>
@prusnak I slightly reworked the last commit:
This reduces the amount of code, and cuts down on magic values. |
@laanwj Updated PR to your code. |
Thanks! |
I can't help but wonder if this conflicts somehow with #253 and the effort there which seemed to be to not identify or associate users... what might be the long-term effects of this effort which is to associate a bitcoin address with a node? No need to answer me here. |
// format user agent, check total size | ||
strSubVersion = FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, mapMultiArgs.count("-uacomment") ? mapMultiArgs["-uacomment"] : std::vector<string>()); | ||
if (strSubVersion.size() > MAX_SUBVERSION_LENGTH) { | ||
return InitError(strprintf("Total length of network version string %i exceeds maximum of %i characters. Reduce the number and/or size of uacomments.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't that one be translatable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'd say. Apart from being a specific technical error (which we don't translate for Googlability, see translation_strings_policy.md
) it's an extremely rare condition caused by almost-abuse of the configuration system. No need to waste translator time on that.
@ABISprotocol How is having this option a problem? It's not always a good idea to use it, but many people run essentially public nodes without wallet, and for those there is no need to 'hide in the crowd'. |
@laanwj Since you asked, my thinking was that there might be ancillary effects on other users, a butterfly effect if you will in the privacy context. Though different functionally (and thus not comparable in the way one might consider it to be), the address reuse problem comes to mind (again, this is perhaps not relevant here because it is addressed in other ways, such as implementing stealth or confidential transactions); but at the core of this, the concern is that when you have an option which encourages or motivates users to associate a node with an address, then that will have privacy implications not only for the user who makes that choice, but for other users in the network as well. |
The ability to change what software your node advertizes as is not the same
as encouraging to put an address there (which is indeed a bad idea IMHO).
|
I might be missing something but how does this implement BIP-0014? Current master happily accepts comments containing any of the "reserved symbols" mentioned in BIP-0014 and silently drops other characters when pushing to the network. My local node:
Some remote node:
|
Misc upstream PRs Cherry-picked from the following upstream PRs: - bitcoin/bitcoin#6077 - Second commit only (first was already applied to 0.11.X and then reverted) - bitcoin/bitcoin#6284 - bitcoin/bitcoin#6489 - bitcoin/bitcoin#6462 - bitcoin/bitcoin#6647 - bitcoin/bitcoin#6235 - bitcoin/bitcoin#6905 - bitcoin/bitcoin#6780 - Excluding second commit (QT) and third commit (requires bitcoin/bitcoin#6993) - bitcoin/bitcoin#6961 - Excluding QT parts, and a small `src/policy/policy.cpp` change which depends on a bunch of other PRs, which we'll have to remember to come back to. - bitcoin/bitcoin#7044 - bitcoin/bitcoin#8856 - bitcoin/bitcoin#9002 Part of #2074 and #2132.
User can add the following into theirs bitcoin.conf:
which will result in the following user agent: