A custody architecture based on Revault but with cosigners instead of watchtowers

[darosior]

I've been discussing this a lot privately, mainly as a point of comparison when considering tradeoffs in Revault's architecture and/or deployment. Especially with regard to watchtowers, which bring a lot of tradeoffs. Here i describe how a custody protocol with the same feature set as Revault but with different tradeoffs could be concretely designed.

Conceptual description

We keep the stakeholders / managers types of participants. The purpose is to keep the restrictive delegation of Revault without the burden of managing watchtowers, the cost of using them, and the unpredictability of their enforcement of the policy. Starting from today's Revault, instead of pre-signing Cancel transaction and giving out an authorization by the form of the signature of an Unvault transaction, coins are locked to both the managers and a set of Cosigning Servers managed by stakeholders. The automated cosigning servers enforce any kind of policy: for instance, "notify the stakeholders and authorize by default after a hour if not told otherwise", or "don't accept any transaction with outputs that don't pay to one of these addresses or any deposit address (whitelist)". You can still, optionally, have the Emergency.

Concrete modifications to practical-revault

Scripts and transactions

The deposit policy is still a multisig between all the stakeholders.

We introduce a new "Delegation" transaction that spend any number of deposit UTxOs and creates one "delegated" UTxO.

The "delegated" policy has two branches:

• The multisig of the stakeholders; or
• A thresholds of the managers and a given combination of the Cosigning Servers

There is no Unvault, Cancel and UnvaultEmergency transaction anymore. The Spend transaction directly spends from "delegated" UTxOs. The Emergency descriptor and transaction may be kept as well as introducing a "DelegatedEmergency" transaction spending from a "delegated" UTxO.

Coordinator

We don't need the coordinator to synchronize the exchange of presigned transactions' signatures anymore (apart if keeping the Emergency), or to announce a Spend. It may still be used to coordinate the creation of a Spend or a "Delegation" transaction.

Watchtower

Removed, or rather "merged" with the Cosigning Servers in terms of functionality (not messages).

Cosigning server

In place of the single sign message we have today, we have 2 of them to allow the cosigning servers to enforce a timeout without the need to maintain a connection for a long period of time. We use the first one to "register" a Spend. The second one is used to poll fpr Spend signature by txid (the Cosigning Server may return "ack", "nack", "pending".

Discussion

This design is conceptually much simpler, it's essentially a cold -> warm design with integrated policy enforcement. The protocol is greatly simplified, too. The implementation would very likely be too.

The User Experience would obviously be way neater and intuitive:

• No need to think about the distribution of the coins value in order for managers to not be blocked on stakeholders pre-signing more transactions ("change issue")
• No need to think about the CPFP wallet, logic, or how to represent this as fees in the user interface
• No need to think about propagation issues for the Unvault transaction w/o package relay
• With dynamic fee-bumping, no need to refill every watchtower for every stakeholder

The cost would be much lower:

• No need for an Unvault transaction per deposit UTxO. The "Delegation" tx may be batched.
• No need to allocate some amount of sats per-Unvault and per-Spend for CPFP (a non-trivial amount)
• No need to overpay the fees of the presigned Unvault transaction
• No need to pay for a consolidation transaction (upcoming not-yet-spec'd way to workaround the coins distribution issue from above)
• The enforcement of the policy does not need an expensive onchain transaction
• With dynamic fee-bumping, no need to keep a non-trivial amount of coins for every watchtower for every stakeholder

It also presents some advantages compared to Today's Revault:

• No uncertainty from the fee market for policy enforcement. Policy in this model are applied before giving out the authorization (in the form of a signature of the Spend transaction), as opposed to today's Revault model of "approving by default". The latter relies on many liveness assumptions that are hard to reason about. This is by far the biggest win IMO.
• Plausible deniability. Here, everything is just multisig. By taking some care we can "blend into the mass", while Revault usage has an obvious onchain footprint.
• Easier to introduce a thresholds for Stakeholders. With today's Revault, having a threshold for stakeholders also means that they give up on all being able to enforce delegation/spending policies [0]. With the approach taken here they can have a threshold-based deposit but still always enforce spending policies.

Also note that it shares an advantage of "Revault-with-cosigning-servers-for-spending-policies":

• The keys for Cosigning Servers do not need to be backed up, they can be entirely stored on some kind of HSM. Only the keys of the stakehodlers do, actually.

The obvious disadvantage (heh, there needs to be one, at least!) compared to Revault is in the "securing by decentralizing". Watchtowers are (supposed to be) easy-and-inexpensive-to-spin-up servers that can directly enforce the delegation policies and can be replicated any number of time to reduce some liveness risks. Replacing them with cosigning servers involves introducing a limited number of "participants" which are identified and pre-committed to in the Script. I think that it is a big deal in theory, but not so much in practice. You can scale the number of Cosigning Servers up by a lot before being in any way remotely close to the cost of using Revault. In addition, you can add more Cosigning Servers with Musig so you can decentralize a lot at very little cost (with additional assumptions wrt the session state, but mutlisig security is additive).

The same goes with the manual broadcast of the Cancel transaction. In today's Revault you assume you can reach the Bitcoin network (or rather, a decent % of the hashrate) with a decent fee (if miners are still incentivized by those and not some out-of-band mechanism). In this version, you are trusting that not all of your cosigning servers were not compromised. It's hard to compare as the former is pretty fuzzy.

Another obvious disadvantage is the increased potential for downtimes. It is inherent to refusing the "authorized by default" mechanism". However, i don't think it's a valid con. To the contrary. Take the same situations for both architectures: a cosigning server down VS a watchtower down. In the former situation, the transaction is stuck. In the latter, the transaction does go through but the policy enforced by this watchtower aren't enforced. I think the best tradeoff in this situation is to prime "security" (as in policy enforcement) over availability.

[0] If that's not obvious: if the deposit multisig in Today's Revault is not an N-of-N then N-1 parties can sign an Unvault transaction without giving you the Cancel transaction as much as they can spend directly from the deposit ("bypass") without you.

[edouardparis]

Spend:

No need to think about the distribution of the coins value in order for managers to not be blocked on stakeholders pre-signing more transactions ("change issue")

Ok, The change output is going back to warm wallet. That is a very good point for usability

Stakeholders: Their role is finally reduced to delegation but it has an increase in risk managment: Not delegating too much or not enough (less protection that revault). I think it is a good tradeoff for small teams.

Emergency: Nice to have it can be an optional feature 2 presigned transactions: cold -> emergency and warm->emergency

---

Can we imagine a way for a team to switch from this warm/cold wallet to a revault setup with only the creation of the unvault descriptor ? (No new ceremony for the stakeholders multisig) This makes me think: what if a cosigner hot key is compromised, can we just change the managers part (warm wallet or unvault wallet) without doing the full ceremony ?

[darosior]

Ok, The change output is going back to warm wallet. That is a very good point for usability

Yeah, in this model what is delegated stays delegated. The delegation and spending policies are separated one from another. The former is done manually (without the caveats and cost of using pre-signed txs) and the latter automatically from the "warm" wallet.

Their role is finally reduced to delegation but it has an increase in risk managment: not delegating too much or not enough (less protection than revault).

What do you mean? In this model the delegation is way more granular: you delegate exactly the amount you expect. With Revault you have thresholds by which you may delegate, it is either coarse grained (and you don't decide the thresholds) or expensive and complex (with a consolidation-split transaction created beforehand).

2 presigned transactions: cold -> emergency and warm->emergency

Oh, right, thanks!

Can we imagine a way for a team to switch from this warm/cold wallet to a revault setup with only the creation of the unvault descriptor ? (No new ceremony for the stakeholders multisig) This makes me think: what if a cosigner hot key is compromised, can we just change the managers part (warm wallet or unvault wallet) without doing the full ceremony ?

I believe the answer is yes to both.

[edouardparis]

Maybe this idea can be part of the revault setup: we can introduce a new descriptor warm wallet with the delegated policy you described Stakeholders have then two delegation choices:

1. Full delegation: founds are sent to warm wallet -> spend policy enforced by cosigners
2. Locked time delegation: unvault txs are given to managers, spend change output must go back to deposit descriptor. -> spend policy enforced by watchtowers.

Emergency txs are signed for both delegation kinds

It can give way more flexibility: If amount needed to be spent is important and not frequent: managers will use locked time delegated funds If amount is small and frequent: managers will use their full delegated funds

[danielabrozzoni]

I really like the proposal! I think Revault should offer both products, and then let the clients choose what's best for them.

Coordinator [...] It may still be used to coordinate the creation of a Spend or a "Delegation" transaction.

YAAAAAY looks at https://github.com/revault/practical-revault/issues/82 impatiently

Nice to have it can be an optional feature 2 presigned transactions: cold -> emergency and warm->emergency

Agreed, since you have anyways the NofN spend path in the delegation tx, you should just go with a "delegation emergency" tx.

Also, notice that in the watchtower model you could have watchtowers enforcing different policies, and the "global policy" will be a sum of the strictest ones. In this case, if you have just a thresh of the cosig servers needed for spending, the actual policy applied is not necessarily a sum of the strictest ones.

For example (supposing no server is dead):

watchtower	time policy	amount policy
1	spend at any time	max 10 BTC a day
2	spend only on Mondays	max 11 BTC a day

In this case, you can only spend on Mondays, max 10 BTC a day

cosig	time policy	amount policy
1	spend at any time	max 10 BTC a day
2	spend only on Mondays	max 11 BTC a day

In this case, if the thresh is 1 cosigner, you might decide to spend 10 BTC on a Tuesday, or 11 BTC on a Monday.

This makes it a bit harder to reason on the various constraints you have on the spends.

[darosior]

Thanks everyone for the feedback!

@edouardparis

Maybe this idea can be part of the revault setup [...] Stakeholders have then two delegation choices

I'm not sure. The entire point of today Revault was to make things easier for stakeholders. Our insight was that making a larger multisig more usable would make people actually use it, thereby increasing SeCuRiTy :tm:. It is arguable whether we achieved this, but adding more choices to the user is just going to add more confusion, i'm afraid. I believe users should rather be made aware of the tradeoffs of both approaches, and pick one.

It can give way more flexibility

I don't think it's that simple. The incentive of the managers here is for the software to not get in their way. I can't think of any situation where they would bother themselves with several more transactions, and timelocks, and the uncertainty of the payment making it through, and give away the change output, when they can just make a regular payment immediately. The incentive of the stakeholders is aligned IMO: why would they use the method with a MUCH larger cost, and where the probability of managers bothering them to re-delegate sooner is higher?

@danielabrozzoni

Also, notice that in the watchtower model you could have watchtowers enforcing different policies, and the "global policy" will be a sum of the strictest ones. In this case, if you have just a thresh of the cosig servers needed for spending, the actual policy applied is not necessarily a sum of the strictest ones.

Yes. It not necessarily is, but it can. It's just more flexible. I find it very interesting to think about all the possible combinations in different Taproot leaves with or without Musig, available at a very small cost. I agree it makes it harder to reason about, but i'm sure we would stay conservative until we are able to confidently do so. :)