I like the new witness_set_properties operation where we can use the witness signing key. However, on a multi-server setup, each server has a different key pair, so it may not be practical. For example:
- server 1 fails, use its signing key to enable server 2 to take over
- after fixing server 1, will have to use server 2's signing key to re-enable server 1.
Annoying, but can be circumvented with a script that fetches the public key on the blockchain and use the corresponding private key.
It would be preferable to have a new key role dedicated for witness operations, this would solve all the problems.
I’ve read somewhere a while back that new key authorities are expensive (as far as development time and complexity) to implement. If it can be solved by witnesses spending a few hours coding their scripts to handle it, that is probably the most practical way to go.
Have to agree with @drakos.
If I understood correctly, the action has to be confirmed with the private active signing key, which varies depending on the active signing-key.
That would require an additional fetch of the active public signing-key. Maybe it would be better to add the signing key as optional or create a separate key for updating witness-data.
A separate key for updating witness-data would be nice. With this set up, we would need every server to have access to every signing key, which is not ideal. One of the points of separate signing keys is to ensure if one server ever got compromised, witnesses could quickly switch to a different signing key and never use the old one again.
Either way, getting access to a signing key and being able to tweak witness parameters is less dangerous to the individual witness than having access to their active key, so overall applaud the change.
Exactly @lukestokes. And actually, it would be quite useful to have different keys/authorities for different dApps. So instead of creating a special witness key, it would be the smarter way to create a general way of adding 3rd party authorities.