Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement concurrent broadcast tolerance for distributed watchtowers #679

Merged
merged 3 commits into from
Sep 16, 2020
Merged

Implement concurrent broadcast tolerance for distributed watchtowers #679

merged 3 commits into from
Sep 16, 2020

Commits on Sep 15, 2020

  1. 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).
    Antoine Riard committed Sep 15, 2020
    Configuration menu
    Copy the full SHA
    e73036c View commit details
    Browse the repository at this point in the history

  2. Add test_concurrent_monitor_claim 

    Watchower Alice receives block 134, broadcasts state X, rejects state Y.
Watchtower Bob accepts state Y, receives blocks 135, broadcasts state Y.
State Y confirms onchain. Alice must be able to claim outputs.
    Antoine Riard committed Sep 15, 2020
    Configuration menu
    Copy the full SHA
    e706c67 View commit details
    Browse the repository at this point in the history

  3. Improve PermanentFailure requiremnts documentation 

    Sources of the failure may be multiple in case of distributed watchtower
deployment. In either case, the channel manager must return a final
update asking to its channel monitor(s) to broadcast the lastest state
available. Revocation secret must not be released for the faultive
channel.

In the future, we may return wider type of failures to take more
fine-grained processing decision (e.g if local disk failure and
redudant remote channel copy available channel may still be processed
forward).
    Antoine Riard committed Sep 15, 2020
    Configuration menu
    Copy the full SHA
    6622ea7 View commit details
    Browse the repository at this point in the history