Watchtowers

[darosior]

@JSwambo wdyt ?

[JSwambo]

First we should probably state that the communication is secure (by an assumed correct set-up ceremony).

We should state that wallet <-> watchtower communication is only for associated wallet-WT pairs.

Wouldn't it be more efficient to have the sync server post spend requests to the WT rather than have the WT regularly poll the sync server?

Probably not the priority now but it would be good to get some WT spend-policy examples? Perhaps a set of templates that restrict amounts/ destinations/ subsets of traders/ time.

Wouldn't it be more efficient to have:

 SPENDER's WALLET                SYNC_SERVER
    ||   -- request_spend    ---->   ||  // I'd like to spend this vault.
    ||   <------- ACK ------------   ||  //  Acknowleged, getting oppinions.
    ||                      (...)                   ||  // Sync Server communicates with WTs
    ||  <--- spend_opinions  ---    ||  // Eventually all watchtowers responded. 

sig_ack: A reasonable balance for the WT to hold would be something which can historically (e.g. 99% of time) broadcast a tx which can be confirmed in 6 blocks. The total balanced doesn't need to be used, just available for ensuring security through availability of the revocation txs.

spend_requests: I notice there is a small risk that if each WT receives a fully signed spend tx, but not all WTs agree based on their spend policy, then the spend tx becomes a tx that any WT can broadcast to trigger the non-accepting WT to broadcast the revocation txs. Of course we want the watchtower to be able to revoke when it disagrees, but perhaps restricting malicious spend tx attempts to the wallet owners (rather than their WTs) leaves less room for DoS by compromised WTs? If we decide this is a significant risk, the countermeasure might be to provide a proof-of-knowledge of the set of valid signatures over the spend tx, instead of the signatures themselves.

spend_opinion: I think an extra signature is unnecessary with secure communications already set-up.

[darosior]

First we should probably state that the communication is secure (by an assumed correct set-up ceremony).

Yep, but even if it clarifies some of the choices made here I'm not sure it belongs to messages.md.

We should state that wallet <-> watchtower communication is only for associated wallet-WT pairs.

Absolutely, I'll amend if it it wasn't made explicit.

Wouldn't it be more efficient to have the sync server post spend requests to the WT rather than have the WT regularly poll the sync server?

It would. However having the watchtower initiate every connection to the sync server avoids us to have both the watchtower exposing a service (even a hidden one) to another entity than its paired wallet, and to have the (untrusted) sync server not knowing anything about how to connect the (so crucial) watchtowers.

Wouldn't it be more efficient to have: --snipped--

You mean to have the sync server explicitly ACK, instead of having the wallet polling to see if it updated itself ?

I don't think it's more efficient. It's for sure less explicit but has the nice property that we would never end up in a weird state (in case of a sneaky bug or anything) where the sync server would have ACK but not updated. By calling the same method the watchtower will call for retrieving our demand, we can just make the wallet re-transmit the request if it looks like the sync server dropped it.

sig_ack: A reasonable balance for the WT to hold would be something which can historically (e.g. 99% of time) broadcast a tx which can be confirmed in 6 blocks. The total balanced doesn't need to be used, just available for ensuring security through availability of the revocation txs.

Hmm in this case we hope for the feerate to never pass above the historical higher one ?

I think we should choose xsats such as x = [2/CONSERVATIVE feerate] * [sum of the size of all cancel tx of all vaults].

spend_requests: I notice there is a small risk that if each WT receives a fully signed spend tx, but not all WTs agree based on their spend policy, then the spend tx becomes a tx that any WT can broadcast to trigger the non-accepting WT to broadcast the revocation txs.

No, a watchtower cannot trigger another as no WT has any unvault transaction signature :).

However you pointed out a real concern here: DoS by a compromised wallet.

spend_opinion: I think an extra signature is unnecessary with secure communications already set-up.

I think you are right: as the sync server bridges these ACKs the wallet does need a sig from the WTs or it trusts the server.

[darosior]

Added a commit (which I couldn't squash because I renamed the file in the commit in-between..) to be clearer about the wallet-watchtower pair, the communication channel, and to add a signature to the spend_opinion message.

[JSwambo]

Hmm in this case we hope for the feerate to never pass above the historical higher one ?

I think we should choose xsats such as x = [2/CONSERVATIVE feerate] * [sum of the size of all cancel tx of all vaults].

Why 2/ Conservative feerate? I would have thought: x = (high feerate)*(sum of the size of all cancel tx of all vaults)

spend_requests: I notice there is a small risk that if each WT receives a fully signed spend tx, but not all WTs agree based on their spend policy, then the spend tx becomes a tx that any WT can broadcast to trigger the non-accepting WT to broadcast the revocation txs.

No, a watchtower cannot trigger another as no WT has any unvault transaction signature :).

I meant when the unvault is eventually broadcast. Then the WT can broadcast the rejected spend tx and trigger re-vault.

[darosior]

Why 2/ Conservative feerate? I would have thought: x = (high feerate)*(sum of the size of all cancel tx of all vaults)

Yeah. Means the same things but 2/CONSERVATIVE is the higher "reasonable" feerate bitcoind will give you for estimatesmartfee.

I meant when the unvault is eventually broadcast. Then the WT can broadcast the rejected spend tx and trigger re-vault.

Hmm. Yeah, ok this is a possibility. However there would be a race after the CSV expiration between the valid and invalid spend_tx, and the attack being overt if it succeeds the users won't play the game twice.

[darosior]

I'd like to merge this. If the force'em-to-revault DoS is the last concern about the changes, we can discuss it in an issue ?