Xud: CLI - addAlias to peer

[offerm]

When having multiple peers it is hard to know which peer object represents which real entity (exchange).

Suggest adding an optional alias to a peer that can help to identify it.

I see two options:
a. the alias is set by the peer itself and provided as part of the handshake, or
b. the alias is set by the node for a connected peer

Option a is what LND is doing. This, however, is risky since the peer may provide a wrong alias and claims that he is not who he is. setting by the node is more cumbersome but more secured.

Another option to explore is using a secured P2P channel and taking the information from the client certificate.

[michael1011]

I would go for option a and do it similar to LND. Because when the alias isn't used as identifier of the node there is no risk involved imo.

[kilrau]

Good idea. I would not go for self-set alias (the LND way) because of the reason you mentioned. We've all seen the "Google uses Lightning" tweets. Also don't see how the client certificate solves this?

I'd strongly vouch for B and maybe even a generated one as default (google docs "anonymous squirrel" style).

[sangaman]

Yeah after thinking of this some I am leaning towards option B, there is little downside there and it seems like it could be a nice feature.

[kilrau]

Some more thoughts on option b:

• we can use a list of funny animal names and assign it to it
• drawback: when debugging/communicating with others one and the same peer will have different names so one had to fall back to the pubKey again.

Thoughts from a fresh set of eyes? @erkarl

[erkarl]

I'd also go for the option B because I saw how much unnecessary confusion it first created with lightning clients.

[kilrau]

Actually I'd like to hold off on this feature. Reasons:

• manually assigning an alias won't be a crucial feature
• an automated assigned alias is complicated

* both approaches have the drawback of being a "local point of view" - the assigned alias for a given peer will be different on other nodes

it's a debug feature and not reason enough to do the effort imo

[sangaman]

Should we leave it open tho even if having low priority? I don't think of it as a debug feature necessarily (for debugging purposes, I have no problem using hex pub keys), but as a way to make it more easily to identify peers at a glance. It's certainly superficial and not urgent in the least, but still something that seems like it's worth tracking.

[hatmer]

How about deterministically generating an easy-to-identify name for the peer using the pub key hex? This way it is both easy to read and consistent across all nodes. If this sounds good please assign me since I have a simple algorithm ready.

[kilrau]

That's actually a pretty neat idea - you got it!

[hatmer]

Yay thanks :)

[kilrau]

Could you quickly run your algorithm on 02b66438730d1fcdf4a4ae5d3d73e847a272f160fee2938e132b52cab0a0d9cfc6 ? Just want to see how such an alias would look like.

I have the alias generation algorithm working, but I am wondering where it should be used. Should the CLI allow using the alias interchangeably with the pubkey? Or maybe we just want it to show up in non-debug logs?

These are great questions. Just to give an answer to this:

• since it purely acts as local alias for a given node's pubkey I think it would be great to be able to use it interchangeably with the pubkey on the grpc & CLI. So basically whenever the pubkey is required as input on CLI & gRPC, we should also accept the alias which then maps to the pubkey internally. What do you think? @sangaman @erkarl @michael1011 @offerm
• it should add a new "alias" field to the JSON getinfo gRPC response right below "version": "1.0.0-testnet.1",. Formatting it to the nicer looking table, will be handled by @rsercano in https://github.com/ExchangeUnion/xud/issues/1174 (I just added it), you don't need to worry about this.
• I believe it should add the same alias field to the listpeers response (could you also fix up adding the pubkey to the address, which is missing as of right now):

  "peersList": [
    {
      "alias": "NiftyRoger",
      "nodePubKey": "02b66438730d1fcdf4a4ae5d3d73e847a272f160fee2938e132b52cab0a0d9cfc6",
      "address": "02[e-mail]:8885",

• we also should add it to logs for an easier read. Since theoretically the xud version on the other side could have a different alias algo, how about displaying node_pub_key (alias) where we currently have node_pub_key in the logs?

[hatmer]

Thank you for clarifying, this is very helpful.

Currently the xud test nodes' aliases are "advanced-pleasant-sierra", "curtain-ceaseless-lumber", and "coffee-happy-rabbit". I built a word list using a random word generator and some political correctness; it is hardcoded and easily modifiable.

We can definitely use the alias interchangeably with the pubkey in the CLI. There is a minor security concern, since an attacker could generate pubkeys until one generates the same alias as another node’s pubkey. This is easily preventable by checking for duplicates.

There are ~300 words in the word list, so ~27 million different combinations, which means there is a 50% probability of a collision at around ~5000 nodes via the birthday paradox, but non-malicious collisions with few nodes are very unlikely.

Rejecting the action and forcing the user to specify the public key if there is a collision seems like the only way to handle these unlikely-but-possible events.

Adding the alias to the logs next to the pub key is a very good idea since having both is ideal for debugging.

[sangaman]

I think a randomly generated nickname is a neat idea as well. I'm not sure it completely replaces the use-case of an alias that one can specify (like if you wanted to label a node as "MtGox") but it's still more readable/memorable than the hex hashes for random nodes.

What about using the BIP39 word list? It's a well-known and proven list. If it'd be a hassle to have to rework your algorithm for a different list maybe it's not worth it, but it might be nice and with 2048 words instead of 300 the collisions would become really unlikely.

[hatmer]

The word list is easily replaceable, thanks for the link! The nickname is perhaps most useful for preventing CLI accidents arising from using public keys that are hard to remember/recognise. I think the best way for users to share their node with a custom alias might be to use a tiny-url service that allows custom urls, so they could share tiny.cc/MtGox and it would point to their Xud endpoint. If they are allowed to specify and share their own aliases within the system then we could end up with homoglyph attacks

[sangaman]

Yes good points, but I'm thinking more of the case of locally labelling a node locally only - it's not the peer that shares their alias but the local node that assigns aliases to the peer. It might not wind up being that useful and I don't think we need it now, but still maybe a nice feature later on.

[kilrau]

It might not wind up being that useful and I don't think we need it now, but still maybe a nice feature later on.

Agree, might be useful in future (but might have to call it differently)! Please open an off-shoot issue @sangaman

For now I like the approach of the alias being deterministically derived from the pub key very much. Enables interesting things, like sharing the xud uri in a shorter format. We could even build this (centralized and optional) tiny URL service: xud.me/happy-squirrel

Given we switch to the BIP39 wordlist with n=2048 and change to r=2 to make the alias even shorter and more readable, that would leave us with about 4.2 million combinations. Do you think that's enough? If not, we could increase the word list to 4096, by e.g. adding Spanish (no doubles with English), increasing possible combinations to 16.7 million. Or even increase to 8192 (~67 million combinations).

What do you think? @hatmer @sangaman

[sangaman]

I'm not a fan of using spanish words, particularly because of the Ñ character potentially causing problems. I'm ok with just two english words for now, particularly because a collision isn't the end of the world. If/when the network grows to hundreds or thousands of nodes we can go with three words and make the chance of collision minimal.

Rejecting the action and forcing the user to specify the public key if there is a collision seems like the only way to handle these unlikely-but-possible events.

I don't think this would be practical because we won't always know of collisions, particularly not during initialization when we're creating a key, and we can't change our key once we're connected to nodes.

[hatmer]

Makes sense, two words first and three if collisions become a problem. I'll use the English BIP39 word list for now.

I don't think this would be practical because we won't always know of collisions, particularly not during initialization when we're creating a key, and we can't change our key once we're connected to nodes.

Ah I meant in the CLI, when looking up a node via the alias there might be two entries, indicating either a naturally occurring collision or an attempt to deceive (since a malicious user can simply generate strings until a collision is found, and provide that string as his public key), in which case the user should have to specify the public key for the action since there are two nodes with the same alias. I haven't gotten around to coding the CLI stuff yet though so I might be missing something.

[sangaman]

Ah I meant in the CLI, when looking up a node via the alias there might be two entries, indicating either a naturally occurring collision or an attempt to deceive (since a malicious user can simply generate strings until a collision is found, and provide that string as his public key), in which case the user should have to specify the public key for the action since there are two nodes with the same alias. I haven't gotten around to coding the CLI stuff yet though so I might be missing something.

Ah right, that makes sense then. Thanks for clarifying.

[kilrau]

https://wiki.ubuntu.com/DevelopmentCodeNames#A