Published on: 2018-04-18T10:16:26+00:00
A problem has been identified with the encrypted blob approach in Lightning Network, where a potential thief could send random blobs to WatchTowers, causing issues. One solution proposed is for WatchTowers to charge for each (txid[16:], blob) pair they keep. Another solution is to provide a prepaid watching service where users can contact multiple WatchTowers and use tickets to put blobs from one WatchTower to another.The email suggests simplifying the construction of WatchTowers by creating one-blob-one-justice pairs for each revoked commitment transaction outpoint. This would allow for more insurance and easy adaptation to changes in channel commitment structure.The discussion between Conner Fromknecht and ZmnSCPxj revolves around implementing a watchtower feature that detects spent second-level transactions and forgoes sweeping them entirely. They also discuss the separation of commitment outpoints from HTLC outpoints and agree that this approach is a reasonable compromise.Changes in the lightning network code are proposed to prevent attackers from exploiting the network. The changes involve detecting spent commitment outputs and second-level transactions, and forgoing the sweeping of already spent second-level transactions. A new BOLT document may be created to formalize the approach. Separating commitment outpoints from HTLC outpoints is also discussed to prevent the broadcasting of commitment transactions before CLTVs expire.Conner and ZmnSCPxj discuss planning a new BOLT document for implementation details but note that it may be too soon and that there are still implementation details to address. They also discuss the confirmation of second-level HTLC transactions being separated by arbitrary delays, which can give an attacker control over when the transactions appear on the network. The need to sweep each HTLC independently is emphasized.The conversation between Conner and ZmnSCPxj discusses the "encrypted blob" approach for watchtowers. They discuss the storage requirements for watchtowers and propose sending signatures for independent sweep transactions. The ability to sweep each HTLC independently is seen as a requirement given the complexity of the on-chain state-space.The email thread discusses various approaches to implementing a trustless watchtower for Lightning Network. The "encrypted blob" method is discussed, along with observations that can inform an efficient set of signatures to include in the encrypted blobs. The need to sweep each HTLC independently is emphasized.In a conversation between Laolu and ZmnSCPxj, they discuss implementing a trustless WatchTower. Alternative approaches are proposed, but the current implementation uses the "encrypted blob" approach, which allows for typed internal payloads and supports a "swap" protocol.ZmnSCPxj asks for ways to implement a trustless WatchTower system, expressing concern about collaboration between the WatchTower and the counterparty to steal funds. The suggestion is made to generate fully-signed justice transactions immediately after every commitment transaction is revoked and transmit them to the WatchTower. Laolu suggests sending only the latest items in the script template and a series of signatures, forcing the server to reproduce the justice transaction. The current implementation uses the "encrypted blob" approach.Nicolas Dorier requests additional hooks in c-lightning for a simple WatchTower system, but concerns are raised about the current interface requiring a trusted WatchTower. The suggestion is made to have nodes generate fully-signed justice transactions and transmit them to the WatchTower. It is unclear if this has been addressed in BOLT v1.0.
Updated on: 2023-07-31T20:00:41.740858+00:00