search

revault / practical-revault

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

Ideas for the future #12

Open darosior opened 4 years ago

darosior commented 4 years ago

A bunch of stuff that "seems cool" but is not considered to be part of the actual implementation for now, or may still even be half-baked.

darosior commented 4 years ago
darosior commented 4 years ago

It'd be great to eventually split the "policy advertizer" and "policy enforcer" roles of the WT, which are currently fulfilled by a single entity (the actual WT). This would allow the WT to not have to establish connections at all. This would also simplify the protocol as it would allow for direct connections from the SS to the "policy advertizer".

                ___________ Advertizer A
             /
Sync Server  -------------------- Advertizer B
            \______________ Advertizer C

------------------------------------------------------

-------------------------------------------------
Watchtower A   |    Watchtower B  | Watchtower C |
-------------------------------------------------

This means 2 moving parts and slight overhead for changing the revaulting policy, but that's a pretty good tradeoff imho. Of course, they still need to fetch the fully signed spend txs but that could be done using a "fetch on chain event (unvault broadcast)" logic. This combined with the above would be pretty much remove any delay in the manager spending experience (no more explicit ACKs needed) while introducing some uncertainty.

Implemented in v0

darosior commented 4 years ago

Some new Revault 2.0 :tm: stuff from the November retreat:

darosior commented 3 years ago

As discussed in https://github.com/re-vault/practical-revault/issues/16 , i'd like to have some UX policies for fee batching. For instance, the GUI (it could even be enforced by the watchtowers) could hint the manager to batch when making a payment. At the coin selection tab, if the value of the vault chosen for spending and there exist another vault which value is less than 10% the vault being spent, let be a popup saying "hey, you should spend this one too". This would eventually reduce the number of vaults under watch without moving too much value at once. It would also sweep dust vaults before they become actual dust.

On the same vein, this batching could be done (to the cost of changing the Unvault transaction structure) by stakeholders themselves when pre-signing. We could have a configured or estimated vault value (this seems preferable to the absolute maximum of vaults no matter their value i suggested during the November retreat) below which deposits aren't signed yet but batched with eventual new deposits. This seems more natural than a Watchtower-enforced manager batching policy but does also incur a technical cost to the stakeholders.

darosior commented 2 years ago

As described in https://github.com/revault/practical-revault/issues/102#issuecomment-1014850960, a way to forward signed messages to the WTs through the coordinator could allow some interesting policies. For instance have a threshold for the managers and a limit on the amount that can be unvaulted, which can be lifted (or relaxed) if all managers sign.