Published on: 2019-12-04T13:53:39+00:00
A discussion on the Lightning-dev mailing list has brought up an issue with watchtowers in relation to the eltoo paper and channel construction. The issue arises from the fact that any update transaction can spend from any other, which means that the tower only needs the most recent update transaction to resolve disputes. However, in order for the tower to spend, it must produce a witness script that matches the input's witness program. Each update transaction uses unique keys for the settlement clause to ensure that settlement transactions can only spend from one update transaction, resulting in each state having a unique witness program.There have been suggestions for alternative approaches to solve this issue. One suggestion is to add a taproot branch with an `OP_RETURN` tapscript or to use BIP32 derivation. However, the original poster argues that update_tx and settlement_tx are self-contained, and there is no need to recover the prevout scriptPubKey or any value therein. They also believe that it is not the job of a watchtower to finalize the entire off-chain contract, but rather to watch the blockchain and react if anything triggers it.Conner Fromknecht suggests that the chain of noinput/anyprevout transactions is broken as soon as the signers are online and can interactively bind and sign without noinput/anyprevout. ZmnSCPxj agrees with this understanding and adds that any presigned descendants of a NOINPUT transaction must also use NOINPUT. This chain must continue until a signer is online to bind a transaction to a confirmed input. The use of NOINPUT ensures that settlement transactions can only spend from a particular update transaction.In another email exchange, Christian Decker and Conner Fromknecht discuss the implications of watchtowers on eltoo channel construction. Christian discusses two deployment options for watchtowers, one involving only the latest update transaction and the other involving both the settlement transaction and the update transaction. The second option ensures that the correct state is dropped on-chain but at the cost of the watchtower learning intermediate states or the size of the state. Conner raises an issue related to NOINPUT, where any update transaction can spend from any other, potentially allowing a tower to reconstruct arbitrary witness scripts. He proposes a workaround involving extended parent pubkeys and deriving non-hardened settlement keys on demand based on confirmed state numbers. However, this solution is not ideal as leaking one hot settlement key compromises all sibling settlement keys. The discussion also touches upon section 4.1.4 of the eltoo paper, which discusses the requirement for non-hardened keys.ZmnSCPxj discusses the use of watchtowers in the Lightning Network in another email exchange. They mention that the update transaction for a settlement can be posted at any time, and the only transaction that can spend it is the correct settlement. However, if a user's Lightning node is destroyed, there could be a total loss of funds. To prevent this, the update, settlement, and transaction spending the output of the settlement can be sent to a cold-storage address controlled by different hardware. This allows the watchtower to place part of the funds back into a cold-storage address, excluding those in HTLCs. While this is an edge case, it may be worth considering for certain scenarios. The use of `SIGHASH_NOINPUT` simplifies the implementation of watchtowers and increases the feasibility of deploying a watchtower network.In the email thread between Rusty Russell and ZmnSCPxj, they discuss potential concerns regarding watchtowers in relation to the eltoo paper. Due to NOINPUT, any update transaction can spend from any other, but in order for a tower to spend, it must produce a witness script that matches the input's witness program. Each update transaction uses unique keys for the settlement clause to ensure that settlement transactions can only spend from one update transaction. Rusty suggests changing keys every time or using taproot to add randomness as a solution.In another discussion on the Lightning-Dev mailing list, Rusty Russell and ZmnSCPxj discuss potential issues related to watchtowers in channel construction. Due to NOINPUT, any update transaction can spend from any other, but in order for a tower to spend, it must produce a witness script that matches the input's witness program. Each update transaction uses unique keys for the settlement clause to ensure that settlement transactions can only spend from one update transaction. ZmnSCPxj questions whether this is logically possible and suggests using an `OP_RETURN` tapscript or BIP32 derivation as a secure solution.In a conversation about watchtowers and the eltoo paper, Rusty comments that any update transaction can spend from any other due to NOINPUT. However, in order for a tower to spend, it must produce a witness script that matches the input's witness program. Each update transaction uses unique keys for the settlement clause to ensure that settlement transactions can only spend from one update transaction.
Updated on: 2023-07-31T22:23:30.595409+00:00