I thought of this lately and wanted to propose some options:

• Make --overwritekey actually overwrite completely with no way back and guard against accidents by requiring a user confirmation from standard input. (+ also we better make that flag a command line only flag, i.e. not available using a config file).
• Do not provide such an option at all and tower owners should wipe their tower DB completely if it gets compromised.

Requiring a user interaction (the first option) to confirm overwriting the key would minimize the chances of mistakenly deleting the secret key, so it's somewhat similar in protection to the second option. But it does of course keep the stored appointments intact, which might be favorable if the tower was altruistic.

Any thoughts @sr-gi?

After giving this some thought on and off I think the best we can do is actually make the option dev only, and remove it from the docs.

Also, I will suggest only keeping the last key.

Rationale:

No matter what we do there will be a use case that would require the user manually do something with the database, either delete it, delete the tower key so the backend generates a new one, or let them load an old key. So I'd keep things simple and assume that the user needs to either generate a new key for dev purposes, or wipe the whole database because the tower has been compromised.