Published on: 2018-11-15T08:23:36+00:00
The Lightning-dev mailing list has been discussing various issues regarding watchtowers, including the need for watchtowers to store all encrypted blobs that are keyed to the same partial txid. Conner Fromknecht has been working on a watchtower design where the server side has been implemented and accepts encrypted blobs from clients and stores them. The functionality related to scanning blocks and publishing justice transactions has also been implemented, but has not been merged yet.One of the main concerns is that if a watchtower is identified by a counterparty, the counterparty could give the commitment transaction's txid with a randomly-generated blob to the watchtower before giving the revocation key to the owner, thus spamming the watchtower until it runs out of resources and crashes. To prevent this, the chosen design uses a two-level bucketing structure that maps client_pubkey1 to encrypted_blob1 and client_pubkey2 to encrypted_blob2, ensuring that different clients can't overwrite each other.In terms of Decker-Russell-Osuntokun channels, if a watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? The design should be readily able to serve eltoo clients, with some slight modifications to breach detection and justice txn construction. However, the update-and-replace model leaks timing information about a particular channel to the tower, since the tower must know which prior state needs replacing.Overall, the watchtower design seems mostly solidified, and there will likely be follow-up posts on the ML. The tower could raise its price point if it detects such behavior and should only ever accept sessions if it can be certain it has the appropriate disk-space to facilitate them, so there isn't much risk in the node crashing due to a spam attack. Finally, the tower can't be sure which client is uploading the "real" blob, so the chosen design uses a two-level bucketing structure that maps client_pubkey1 to encrypted_blob1 and client_pubkey2 to encrypted_blob2.The email exchange between Conner and ZmnSCPxj is regarding the development of watchtowers. Conner has implemented much of the server side, which accepts encrypted blobs from watchtower clients and stores them. The functionality related to scanning blocks and publishing justice transactions has also been implemented but hasn't been merged yet. The remaining task is to integrate the client so that it backs up states after receiving revocations from the remote peer.ZmnSCPxj notes that watchtowers would need to keep all encrypted blobs that are keyed to the same partial txid in order to avoid possible spam attacks. However, even with this measure in place, an attacker could still spam the watchtower until it runs out of resources and crashes. To counter this, Conner suggests using a session-based, encrypted-blob approach that maps client public keys to encrypted blobs in a two-level bucketing structure, ensuring that different clients can't overwrite each other.Regarding watchtowers compatible with Decker-Russell-Osuntokun (DRO) channels, Laolu had previously suggested that DRO channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. However, this is unsafe unless the watchtower identifies the user somehow since an attacker can identify the watchtower and update the blob side with a randomly-generated, invalid blob before launching an attack. There is also the issue of privacy leakage if the watchtower identifies the user.ZmnSCPxj asks what plans the lnd developers have for these issues and expresses curiosity about their first moves into this area. The general design should be readily able to serve eltoo clients with some slight modifications to breach detection and justice txn construction. The concern with the update-and-replace model is that it leaks timing information about a particular channel to the tower since the tower must know which prior state needs replacing. Therefore, it is better to store all prior encrypted blobs to maintain adequate privacy. On private towers, this privacy/space tradeoff may be acceptable, but not sure if the tradeoff makes sense on public towers.The email is discussing the topic of watchtowers in relation to lnd and Decker-Russell-Osuntokun channels. The writer notes that some code related to watchtowers already exists in lnd, but it seems to be limited to data structures and messages without actual logic. They also mention a paper about paying watchtowers by simulating breaches, which would give evidence of liveness and incentivize correct behavior. However, watchtowers would need to keep all encrypted blobs that are keyed to the same partial txid to prevent potential attacks from a counterparty.The email also discusses the compatibility of watchtowers with Decker-Russell-Osuntokun channels.
Updated on: 2023-07-31T20:41:39.138920+00:00