Implement concurrent broadcast tolerance for distributed watchtowers
authorAntoine Riard <ariard@student.42.fr>
Fri, 28 Aug 2020 00:47:02 +0000 (20:47 -0400)
committerAntoine Riard <ariard@student.42.fr>
Tue, 15 Sep 2020 22:17:35 +0000 (18:17 -0400)
commite73036c6845fd3cc16479a1b497db82a5ebb3897
tree0d7d1ea42e4f8215a049584112dc7b067c9ed6ab
parent343aacc50c73e18ddb1ec52570c5050bdccd09ca
Implement concurrent broadcast tolerance for distributed watchtowers

With a distrbuted watchtowers deployment, where each monitor is plugged
to its own chain view, there is no guarantee that block are going to be
seen in same order. Watchtower may diverge in their acceptance of a
submitted `commitment_signed` update due to a block timing-out a HTLC
and provoking a subset but yet not seen by the other watchtower subset.
Any update reject by one of the watchtower must block offchain coordinator
to move channel state forward and release revocation secret for previous
state.

In this case, we want any watchtower from the rejection subset to still
be able to claim outputs if the concurrent state, has accepted by the
other subset, is confirming. This improve overall watchtower system
fault-tolerance.

This change stores local commitment transaction unconditionally and fail
the update if there is knowledge of an already signed commitment
transaction (ChannelMonitor.local_tx_signed=true).
lightning/src/ln/channelmonitor.rs
lightning/src/ln/onchaintx.rs