Instead of requesting a key, would be an easier flow especially in the spin up to create your own key, store it in memory (in the tdx machine) and then send it to other validators to be stored in their kvdb at periodic intervals, which sounds less secure but because of the tdx it is more secure and for me at least easier to manage. This can also allow you to "reshare" this key as validators leave, and maybe at intervals like a pre update, can also maybe have the chain manage the state of who has what

That being said, there is a chance of someone running multiple validators and getting the decryption key sent to themselves which I don't like

Instead of requesting a key, would be an easier flow especially in the spin up to create your own key, store it in memory (in the tdx machine) and then send it to other validators to be stored in their kvdb at periodic intervals, which sounds less secure but because of the tdx it is more secure and for me at least easier to manage. This can also allow you to "reshare" this key as validators leave, and maybe at intervals like a pre update, can also maybe have the chain manage the state of who has what

I don't see why we couldn't do that. Either way, both tss-nodes end up knowing the key, i'm not sure if it matters so much which of them generated it. It would complicate things a little more as then you need separate http routes for backup and restore.

I'm less keen on having the chain manage state. It would make it easier to report bad behavior, but i think it would make this feature take significantly longer to implement.

Yeah validators leaving is the difficult bit with this, im not sure how we can know that a node we are using to store our key has unbonded without polling the chain.

Thinking about it I am uncomfortable having other nodes store the password of other nodes in their kvdb because they would potentially have access to it outside of the kvdb.

I propose having a node send their password and store it in the memory of another validator, by doing that they would only have access inside the tdx machine and would make the system more redundant without sacrificing security.

They can also hold the password in their own memory and reshare it at intervals, maybe after every reshare to the new signers? or before an update etc

@JesseAbram

I propose having a node send their password and store it in the memory of another validator, by doing that they would only have access inside the tdx machine and would make the system more redundant without sacrificing security.

Im not too worried about this, as in theory since the kvdb is encrypted the host operator should not have access to the backed-up keys. But to be on the safe side i have gone ahead and switched to storing them in-memory only.

As for making multiple backups, im totally open to this but i propose to keep it as just one for now to keep things simple, and iterate on the design in followups.

Im not very keen on the idea of specifically choosing the signers to hold backups as there is a conflict of interest: Each signer holds both a keyshare and the keys to decrypt the other keyshares.

As for making multiple backups, im totally open to this but i propose to keep it as just one for now to keep things simple, and iterate on the design in followups.

ya for sure, just talking about where I see this going

One thing Im struggling with and just gonna write it out, is not keeping the tss keys in the kvdb and requiring a check with the chain to restart, this way we can be sure that nodes aren't colluding to skirt the TDX. That being said then really it is only the signers that need this as this would stop only a reshare if a node goes down and comes back up

One thing Im struggling with and just gonna write it out, is not keeping the tss keys in the kvdb and requiring a check with the chain to restart, this way we can be sure that nodes aren't colluding to skirt the TDX. That being said then really it is only the signers that need this as this would stop only a reshare if a node goes down and comes back up

The tricky thing with doing an on-chain attestation on restart is that either:

• If not keeping the tss account and starting with a fresh one: we have the problem that the recovered keyshare is tied to the wrong party id.
• If keeping the same tss account in the kvdb: you then need to fund a temporary account in order to submit the extrinsic for the on-chain attestation so you can get back the encryption key for your old account. (free transactions would solve this problem).