Published on: 2018-05-10T04:10:49+00:00
The Lightning Network WatchTower service is designed to monitor channels and detect breaches. However, the current approach of updating channels could potentially compromise privacy as attackers can identify and disable specific WatchTowers. To address this issue, several solutions have been proposed.One solution is to introduce a ticket scheme where the WatchTower demands a public key and signature from the client or knows the stable identity of the victim and attacker. This would help prevent attackers from targeting specific WatchTowers. Another approach involves implementing a charging system for each `(txid[:16], blob)` pair that the WatchTower stores and monitors. By charging for each pair, it would discourage attackers from attempting breaches.Clients can also add randomization to their updates to de-correlate them and batch multiple updates into a single message. This would further enhance privacy and make it harder for attackers to track specific channels. In terms of specific channel schemes, the Poon-Dryja scheme allows for revocation data to be distributed to a subset of serving WatchTowers. On the other hand, the Decker-Russell-Osuntokun scheme enables multiple watchtowers to advance the update transaction towards the most up-to-date state.A trustless, blinded WatchTower approach for eltoo channels using the "encrypted blob" used in Poon-Dryja channels was proposed by ZmnSCPxj. However, the update transactions in Decker-Russell-Osuntokun channels do not have a txid that can be used as a key for encrypted blobs. This means that the WatchTower can correlate the timing and number of updates for each channel. To mitigate this, clients can introduce randomization through a timer drawn from a particular distribution. However, this introduces a window of opportunity where a new state is in play, but the WatchTower has not yet been updated.The scalability tradeoff of using the "swap this blob" approach in Decker-Russell-Osuntokun channels is more scalable, as each WatchTower consumes a bounded amount of space that can be easily planned for. It is important to retain the property that the WatchTower cannot correlate updates to channels. In Decker-Russell-Osuntokun channels, every WatchTower should be informed of a new update since only the latest update transaction is valid.Another proposal discussed in an email is a solution for WatchTowers to monitor and prevent theft attempts on SegWit transactions. The proposed method involves pairing the hash of the message being signed with a blob, rather than just the txid. This provides more flexibility and generalization across different types of channels. The WatchTower verifies each transaction and decrypts the blob if it matches a watched blob. Depending on the type of channel, the WatchTower takes appropriate action. This method retains anonymity sets during the transition from Poon-Dryja to Decker-Russell-Osuntokun channels. The blob in Decker-Russell-Osuntokun channels contains state number, pubkeys, signatures, settlement details, and payment information. The WatchTower generates future update transactions iteratively until it finds the last channel update or reaches the maximum state number. It can then publish the latest update transaction and corresponding settlement transaction for justice.However, the proposed method requires significant effort on the part of the WatchTower. In case of a theft attempt, the WatchTower may be able to correlate blobs to a specific channel and reduce privacy leakage by not giving all updates to a single WatchTower.To address the issue of encrypted blobs in Decker-Russell-Osuntokun WatchTowers, ZmnSCPxj proposed using the trigger transaction, which has a stable txid. However, this approach allows the WatchTower to correlate the timing and number of updates for each channel. To overcome this, ZmnSCPxj suggested generalizing WatchTower pairs to `(hash[:16], blob)`, where `hash` is the message signed in the witness program. This approach can be used for both Poon-Dryja and Decker-Russell-Osuntokun WatchTowers. The main loop of the WatchTower involves verifying each transaction in a block and decrypting watched blobs if the hash matches. The WatchTower then takes appropriate action based on the type of decrypted blob. This retains the decorrelation property, but only up to a theft attempt.Overall, these proposals aim to enhance the security and privacy of Lightning Network WatchTowers by preventing breaches and correlating updates to specific channels. However, they also require careful consideration of scalability and tradeoffs, as well as the amount of effort needed from the WatchTower.
Updated on: 2023-07-31T20:16:27.177536+00:00