Added example for the identities of a multikey setup #791
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sstanculeanu
previously approved these changes
Jan 8, 2024
raduchis
reviewed
Jan 8, 2024
| # NamedIdentity represents an identity that runs nodes on the multikey | ||
| # There can be multiple identities set on the same node, each one of them having different bls keys, just by duplicating the NamedIdentity | ||
| [[NamedIdentity]] | ||
| # Identity represents the keybase/GitHub identity for the current NamedIdentity |
There was a problem hiding this comment.
should we still mention keybase?
There was a problem hiding this comment.
removed, thanks
| @@ -163,10 +163,151 @@ At the first sight, this can be seen as a security degradation in terms of means | |||
|
|
|||
| Regarding point 3, each managed BLS key will create a virtual p2p identity that no node from the network can connect to since it does not advertise the connection info but is only used to sign p2p messages. | |||
| Associated with a separate named identity, the system will make that BLS key virtually unreachable, and its origin hidden from the multikey nodes. Therefore, the node operators will need to apply the following changes on the `prefs.toml` file: | |||
| * in the `[Preference]` section, the 2 options called `NodeDisplayName` and `Identity` will be changed to something relevant for the nodes that are running the multikey group; | |||
| * in the `[Preference]` section, the 2 options called `NodeDisplayName` and `Identity` will be changed to something different used in the BLS' definitions to prevent easy matching. Generic names like `gateway` or `observer` are suitable for this section. | |||
There was a problem hiding this comment.
Generic names like gateway or observer are NOT suitable for this section?
There was a problem hiding this comment.
are suitable. As they are too generic to show you some links with the keys managed.
There was a problem hiding this comment.
added also the possibility of having random strings. Used random string in the example
| # In multikey mode, all bls keys not mentioned in NamedIdentity section will use this one as default | ||
| NodeDisplayName = "observer" | ||
|
|
||
| # Identity represents the keybase/GitHub identity when the node does not run in multikey mode |
There was a problem hiding this comment.
keybase is mentioned also here
There was a problem hiding this comment.
removed, thanks
| @@ -163,10 +163,151 @@ At the first sight, this can be seen as a security degradation in terms of means | |||
|
|
|||
| Regarding point 3, each managed BLS key will create a virtual p2p identity that no node from the network can connect to since it does not advertise the connection info but is only used to sign p2p messages. | |||
| Associated with a separate named identity, the system will make that BLS key virtually unreachable, and its origin hidden from the multikey nodes. Therefore, the node operators will need to apply the following changes on the `prefs.toml` file: | |||
| * in the `[Preference]` section, the 2 options called `NodeDisplayName` and `Identity` will be changed to something relevant for the nodes that are running the multikey group; | |||
| * in the `[Preference]` section, the 2 options called `NodeDisplayName` and `Identity` will be changed to something different used in the BLS' definitions to prevent easy matching. Generic names like `gateway` or `observer` are suitable for this section. | |||
There was a problem hiding this comment.
called NodeDisplayName and Identity will -> should be changed to something different
raduchis
approved these changes
Jan 8, 2024
sstanculeanu
approved these changes
Jan 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the pull request (what is new / what has changed)
Did you test the changes locally ?
Which category (categories) does this pull request belong to?