revault / practical-revault

Version 0 specifications for a Revault deployment
Creative Commons Attribution 4.0 International
33 stars 9 forks source link

refac sync-server #64

Closed edouardparis closed 2 years ago

edouardparis commented 3 years ago

Problem:

suggested solution: Each stakeholder has a sync-server like a mail box, messages are send by each participants to each sync-server. The central sync-server no longer exists. The personal sync-server can have a "cosigning" feature in order to be a cosigning server.

example: sign round each stakeholder sign the cancel tx and share it to other stakeholder through their sync-servers

sign-round(1)

example: manager ask for spending: opinion-round

Hopefully we do not have to implement a big change to the interface, calls are the same only duplicated.

future: I believe that with system we can integrate a lot more services as sync-server plugins for the stakeholder. For example, if the manager want to have an other watchtower, this time hosted by revault corp: he only have to give special credentials and address of the sync-server.

the personal sync-server is still not trusted, each communication keys are handled by revaultd and watchtowers received emergency transactions/cancel transactions from revaultd

darosior commented 3 years ago

Thanks for bringing this up, this is a quite interesting idea.

The personal sync-server can have a "cosigning" feature in order to be a cosigning server.

Nope, we want the sync server(s) to not be trusted. Giving it a key of our onchain Scripts (even if it's the least important one) breaks this assumption.

example: sign round

Hmm. This adds quite a lot of communication keys. I was rather thinking of something like this when we discussed it: image

But then, we can trivially see it's useless to have multiple sync servers.

example: manager ask for spending:

Here, this helps as a watchtower coordinator.

the personal sync-server is still not trusted, each communication keys are handled by revaultd and watchtowers received emergency transactions/cancel transactions from revaultd

That's the interesting part. The more i'm thinking about it, the more i believe there is no benefit from duplicating the sync servers if we don't introduce new trust assumptions. For instance, i believe it would be super useful to have each stakeholder in order to get rid of our clunky encryption of the emergency transaction and our inefficient protocol for this matter. But then you would have to trust the sync server for not permitting the managers to poll the emergency signatures. Another matter for which it would be super useful is as a proxy for the watchtowers. Right now, watchtowers are inefficiently polling the central sync server in order to not accept any incoming connection. A semi-trusted sync server would be allowed to establish connections to the WT(s) which would result in a far quicker spending process for the managers.

Therefore the question becomes: do we want to introduce a trust sync server for an increased efficiency? If so, what is our new threat model?