Knots Privacy Tweaks

[pithosian]

Running Knots has far less potential to be personally identifying than it used to, thanks to the recent surge in Knots users 🎉, but it would still be nice for Knots users to blend in if they want to. Toward that end, this PR:

• Removes the temporary REPLACE_BY_FEE service flag; full-rbf is well deployed and all the flag achieves now is providing information for fingerprinting.
• Adds a uahideknots option (default false) to not add Knots:YYYYMMDD to the subversion string, using the existing bool base_name_only = false argument on clientversion.h::FormatSubVersion.

I know of at least two people attempting to ban Knots peers based on these metrics; the service flag doesn't provide any value afaik, and hiding the UA identifier is a useful option to have in case more decide to filter peers.

[chrisguida]

Looks cool!

I'm confused as to why you think turning off the fullrbf service bit would allow blending in with LR; LR signals for fullrbf by default in the version I based GM on (tag libre-relay-v28.1-2).

Oddly, the diff comparing the latest tag (libre-relay-v29.0-1) to this tag does not show this line being deleted (petertodd/bitcoin@libre-relay-v28.1-2...libre-relay-v29.0-1), but it definitely was, so I'm not exactly sure what's going on there. But it's definitely true that the latest tag of LR does not signal for fullrbf. So yes, it's true that newer versions of LR don't signal for fullrbf, but this is far from a unique identifier for GM.

If we remove fullrbf signaling from Knots, will Knots still "do" fullrbf? Because that seems like the desired behavior.

[pithosian]

I'm confused as to why you think turning off the fullrbf service bit would allow blending in with LR; LR signals for fullrbf by default in the version I based GM on (tag libre-relay-v28.1-2).

Yep, you're completely right, I'd somehow managed to confuse the 28.1 tag with 29.0 when I was looking at LR previously. When Knots gets bumped to 29.0 or beyond, GM will want to remove the flag, but 28.1 is correct to have it there. For blending in with Core, no flag is the correct behavior.

If we remove fullrbf signaling from Knots, will Knots still "do" fullrbf? Because that seems like the desired behavior.

Yep, the service bit is just advertisement; it was used by Knots, LR and Elements (the last of which replaces the 'Satoshi' client name), but to my knowledge never by Core.

[1440000bytes]

Yep, the service bit is just advertisement; it was used by Knots, LR and Elements (the last of which replaces the 'Satoshi' client name), but to my knowledge never by Core.

Yes its not used in Core.

Related pull request: bitcoin#25600

Adds a uahideknots option (default false) to not add Knots:YYYYMMDD to the subversion string, using the existing bool base_name_only = false argument on clientversion.h::FormatSubVersion.

This could be useful.

[chrisguida]

@pithosian Well, with GM we are not trying to emulate core, we are trying to emulate LR, so I think it's fine to leave it for now. But yes, in v29 I'm guessing Knots will remove the flag and make fullrbf the default behavior. @luke-jr can confirm.

[luke-jr]

Full RBF has been default for years...

[chrisguida]

@luke-jr even with the flag removed as in this PR?