Author: ZmnSCPxj 2018-04-18 10:16:26
Published on: 2018-04-18T10:16:26+00:00
A possible problem has been identified with the encrypted blob approach in Lightning Network. If a potential thief knows the commitment transaction and its ID, which includes the key that is part of the commitment transaction ID in the encrypted blob approach, they can send many (txid[16:], blob) with random blob to the WatchTower(s) that a user is using, causing various issues. The WatchTower would not know if it is the actual user or the thief who has the "right" to provide a given txid[16:]. An obvious solution would be for the WatchTower to charge a tiny amount for each (txid[16:] blob) pairs it keeps. However, since every successful and unsuccessful payment requires two channel updates, invalidating two commitment transactions and requiring two (txid[16:], blob) pairs, the loop can continue until Rusty runs out of money. One way to break this loop would be for WatchTowers to provide a "prepaid watching" service. Rusty can contact two WatchTowers, get invoices for prepaid watching, pay the invoices, get preimages as “tickets,” use the tickets to put blobs from one WatchTower to the other, and have multiple WatchTowers to reduce how much each WatchTower learns about Rusty.
Updated on: 2023-05-24T23:21:45.052932+00:00