Hi all, Recently I've been looking at refactoring some of the watchtower code in Electrum, and not wanting to have to do it again soon, was also considering how it should be adapted to option_anchor_outputs.
This made me realise there does not seem to be a way for a watchtower to trustlessly sweep HTLCs if option_anchor_outputs is enabled for the channel (unlike without the option). Specifically, consider the scenario where the breacher also broadcasted second-stage HTLC transactions (HTLC-Timeout or HTLC-Success) [0], along with some old commitment tx. The watchtower would have to react within the relative timelock (CSV) and spend the output using the branch that requires revocationpubkey. Note that the watchtower cannot be given (the privkey for) revocationpubkey as then it would be able to spend the output to any address (such as their own). Without option_anchor_outputs, the Electrum watchtower is currently given a complete pre-signed transaction that spends the (revoked) second-stage output to a user wallet address whenever the commitment tx is updated off-chain. However, with option_anchor_outputs enabled, the txid of the second-stage HTLC tx can no longer be predicted (due to the use of SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for the signature in the input). As all current sighash flags commit to the outpoint being spent (see item 4 "outpoint" in bip-143 [1]), this seems to imply a signature using the revocationpubkey cannot be constructed ahead of time by the client to be given to the watchtower. Even if we had sighash_noinput (or similar), some care would need to be taken, given the address-reuse between each second-stage HTLC output (and even the to_local output). Also, as noinput/anyprevout as per current proposal will only work with witness v1 outputs, the current tx template will need to be changed to use those. A watchtower that does not sweep HTLC outputs seems to be of limited utility to me: to mitigate risk, max_htlc_value_in_flight_msat would have to be set to a small fraction of the channel capacity. I was told on IRC that this regression is a "clear" tradeoff of using option_anchor_outputs - but as I have not seen this discussed anywhere previously and as it was not completely obvious to me at first, I just wanted to explicitly point it out for the benefit of others. ghost43 [0]: https://github.com/lightningnetwork/lightning-rfc/blob/7e8c478aef0d23a445845b7d297b0e804583697c/03-transactions.md#htlc-timeout-and-htlc-success-transactions [1]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#specification _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
