Open ChaoticTempest opened 1 month ago
It adds complexity. It is a rare case that can be fixed by removing and adding the node. We can ask the node to sign an arbitrary payload to check that it possesses the PK.
Removing and adding the node back isn't so simple either though. It requires each of the nodes to agree to kick this node and add it back. This can take some time as this would require two different resharing. This would also not be possible in the case we are at threshold participants.
We can ask the node to sign an arbitrary payload to check that it possesses the PK.
This is what I was talking about the first part but like I said, this is not fool proof and still has user error. Allowing participants to edit their sign_pk
is much simpler and more flexible in this sense
When a participant goes and tries to
join
the network, they can potentially send in the wrongsign_pk
. We can either make it so thatjoin
call validates that thesign_pk
is correct by having the caller send in a signed message such that we can usesign_pk
to verify that this is indeed correct. Still some user error there but a bit less now since the user would have to make use of the key, and potentially learn that they're using the wrong key.A better way of handling this is post-join, by allowing the user/participant to modify their own credentials. There can be some weird side-effects with this such as a node having not picked up the new config of participants sign_pk where they're unable to verify that the messages are indeed coming from this newly updated participant. We will need a new test for this in that case.