Watchtower support: expose channel monitor data for external watchtower implementations

[FreeOnlineUser]

Summary

We've implemented an LDK-to-LND watchtower bridge that lets ldk-node mobile clients use existing LND watchtower infrastructure for channel protection. This is running in production on Android (GrapheneOS) with verified blob pushes to a live LND tower.

We'd like to upstream the ldk-node side of this, which is minimal and opt-in.

Problem

Mobile Lightning nodes are intermittently offline. LND has mature watchtower infrastructure deployed on thousands of home nodes (Umbrel, Start9, RaspiBlitz), but there's no way for ldk-node clients to use it.

What we built

In ldk-node (proposed upstream, ~300 lines):

• WatchtowerPersister: wraps MonitorUpdatingPersister, intercepts persist_new_channel and update_persisted_channel callbacks to capture commitment data in real time
• 3 new methods on Node:
  • watchtower_drain_justice_blobs() -- returns pending commitment data, clears queue
  • watchtower_set_sweep_address(bytes) -- sets the address for justice tx outputs
  • watchtower_list_monitors() -- lists monitored channel points
• UniFFI bindings (Kotlin/Swift)
• Zero behavior change when not used. Wrapper delegates all existing Persist calls untouched

Changes are 2 files + 1 new file:

• src/watchtower.rs (new) -- WatchtowerPersister + types
• src/types.rs -- type alias update (2 lines)
• src/builder.rs -- wrap persister (3 lines)

Separate crate (not proposed for upstream):

• ldk-watchtower-client: LND wire protocol (Brontide/Noise_XK with secp256k1), justice blob encryption, embedded Tor via Arti for direct .onion connections

Proven in production

• Bitcoin Pocket Node: Android app running full bitcoind + ldk-node
• Justice blobs successfully pushed to live LND 0.20.0-beta tower on Umbrel
• Tor connection verified on Pixel 9 (GrapheneOS) -- no SSH tunnel, no Orbot
• Custom Brontide implementation verified against BOLT 8 test vectors

Questions for maintainers

1. Is this the right abstraction level? We expose raw commitment data rather than implementing a specific watchtower protocol in ldk-node itself
2. Should WatchtowerPersister be opt-in via a builder flag, or always-on with zero overhead when unused?
3. Any concerns about the wrapper pattern around MonitorUpdatingPersister?

Happy to adjust the approach based on feedback. Fork with implementation: FreeOnlineUser/ldk-node (6 commits, all tests pass)

[TheBlueMatt]

Cool!

I'm not 100% sure if we want to add support for the LND-proprietary watchtower model (at a minimum there are better ways to do watchtowers - its weird that the LND watchtower model both breaks your privacy and doesn't enforce HTLCs, if its not gonna enforce HTLCs it really should offer privacy!), but we definitely want to improve the watchtower API in LDK so that most of your code can go upstream and you can have a much, much, much simpler patchset to maintain.

As you discovered, using the ChannelMonitor "watchtower" API from lightningdevkit/rust-lightning#2337 requires tracking a bunch of state outside the ChannelMonitor and firuging out how to track (and persist!) that state.

There was a followup attempted at lightningdevkit/rust-lightning#2552 to clean up that API so that that tracking can be done inside the ChannelMonitor and fetching the justice data is a simple call into the updated ChannelMonitor but sadly the original author moved on to other projects before finishing it. Do you have any interest in picking that back up?

[FreeOnlineUser]

Thanks Matt. Appreciate the detailed response.

Agreed on the LND tower model's privacy trade-offs. The reason I went with it is purely pragmatic: it's what's deployed on most home nodes today, and the target user for this project already has an Umbrel/Start9 running LND. Meeting users where their infrastructure is.

I'll review #2552 and see where it left off. The external state tracking was the most painful part of the implementation, so having that handled inside ChannelMonitor would be a big improvement. I've been through the persist callbacks and the signing flow enough to have opinions on where the abstractions should sit.

I should be upfront that I'm currently unfunded on this project, so my bandwidth is limited. But I'm definitely interested in contributing what I can toward cleaning up the watchtower API. Happy to share what I learned from building the bridge if that's useful context for the design.

[FreeOnlineUser]

Reviewed #2552 and the review thread. The PR takes an external utility approach (JusticeTxTracker alongside the Persist impl), but your feedback suggested moving the state tracking inside ChannelMonitor itself so extracting justice data becomes a single call with no external storage. That aligns with my experience: the external state tracking was the most complex part of my implementation. I'll look at what it would take to store the latest counterparty commitment inside ChannelMonitor and expose a method to extract signed justice txs directly.

[FreeOnlineUser]

Following up on @TheBlueMatt's suggestion to move justice tx state tracking inside ChannelMonitor rather than using an external utility.

I've prototyped this approach against current rust-lightning main. Draft PR here: lightningdevkit/rust-lightning#4453

Short version: adds ChannelMonitor::get_justice_txs(feerate_per_kw, destination_script) returning signed justice transactions for all revoked counterparty commitments in a single call. No external queue or state tracking needed. The test WatchtowerPersister drops from ~80 lines of queue management to ~10.

A few design questions in the PR description where I'd appreciate input before finalizing.

[tnull]

Cool!

I'm not 100% sure if we want to add support for the LND-proprietary watchtower model (at a minimum there are better ways to do watchtowers - its weird that the LND watchtower model both breaks your privacy and doesn't enforce HTLCs, if its not gonna enforce HTLCs it really should offer privacy!), but we definitely want to improve the watchtower API in LDK so that most of your code can go upstream and you can have a much, much, much simpler patchset to maintain.

As you discovered, using the ChannelMonitor "watchtower" API from lightningdevkit/rust-lightning#2337 requires tracking a bunch of state outside the ChannelMonitor and firuging out how to track (and persist!) that state.

There was a followup attempted at lightningdevkit/rust-lightning#2552 to clean up that API so that that tracking can be done inside the ChannelMonitor and fetching the justice data is a simple call into the updated ChannelMonitor but sadly the original author moved on to other projects before finishing it. Do you have any interest in picking that back up?

I agree here - thank you for the interest, watchtowers are definitely something we want to support (finally).

However, @FreeOnlineUser if you intend to pick some of this up, please make sure to coordinate with @enigbe who also intends to work on finishing watchtower support for LDK/LDK Node in the coming months.

[FreeOnlineUser]

Thanks @tnull. I put up a draft at lightningdevkit/rust-lightning#4453 as a starting point, but happy to defer to @enigbe on direction here. My watchtower integration already works via an ldk-node fork, so this is more about reducing the downstream patchset than anything urgent. If the approach or API needs to change, no problem. Happy to help however's useful.

Really enjoying building on ldk-node, great work.