Queue BackgroundEvent to force close channels upon ChannelManager::read #2059
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ariard
reviewed
Mar 3, 2023
There was a problem hiding this comment.
Approach ACK. In the future if we move OnchainTxHandler as its own trait and we expose its API (e.g update_claims_view_from_requests), on ChannelManager::read the latest holder's commitment transaction could be directly scheduled for broadcast/fee-bumping, without the intermediary step of generating a ChannelMonitorUpdate.
| @@ -2322,6 +2317,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> { | |||
| }, | |||
| } | |||
| } | |||
|
|
|||
| // If the updates succeeded and we were in an already closed channel state, then there's no | |||
| // need to refuse any updates we expect to receive afer seeing a confirmed commitment. | |||
There was a problem hiding this comment.
The only case where we might have a secondary CLOSED_CHANNEL_UPDATED_ID arises from post-force-close preimage forwarding (i.e ChannelMonitorUpdateStep::PaymentPreimage) ? This could be verified.
TheBlueMatt
reviewed
Mar 6, 2023
Only loosely, because I want to write a test for this, but we first have to restore the anchors build in #2034. |
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
from
ce63b08
to
baf2bfb
Compare
|
Rather than adding a whole new test, I opted to slightly rework the one introduced in #2034 to trigger the new changes. |
|
Ah, I don't see why this is blocked on that. Its not like it has no test coverage (I hope? haven't verified) and I'd like to move to making the monitors durint startup non-mut, so this stands well on its own. |
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #2059 +/- ##
==========================================
- Coverage 91.43% 91.37% -0.06%
==========================================
Files 101 102 +1
Lines 49536 49599 +63
Branches 49536 49599 +63
==========================================
+ Hits 45291 45319 +28
- Misses 4245 4280 +35
... and 16 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
from
baf2bfb
to
7b78496
Compare
Currently, all that is required to force close a channel is to broadcast either of the available commitment transactions, but this changes with anchor outputs – commitment transactions may need to have additional fees attached in order to confirm in a timely manner. While we may be able to just queue a new update using the channel's next available update ID, this may result in a violation of the `ChannelMonitor` API (each update ID must strictly increase by 1) if the channel had updates that were persisted by its `ChannelMonitor`, but not the `ChannelManager`. Therefore, we choose to re-purpose the existing `CLOSED_CHANNEL_UPDATE_ID` update ID to also apply to `ChannelMonitorUpdate`s that will force close their respective channel by broadcasting the holder's latest commitment transaction.
This results in a new, potentially redundant, `ChannelMonitorUpdate` that must be applied to `ChannelMonitor`s to broadcast the holder's latest commitment transaction. This is a behavior change for anchor channels since their commitments may require additional fees to be attached through a child anchor transaction. Recall that anchor transactions are only generated by the event consumer after processing a `BumpTransactionEvent::ChannelClose` event, which is yielded after applying a `ChannelMonitorUpdateStep::ChannelForceClosed` monitor update. Assuming the node operator is not watching the mempool to generate these anchor transactions without LDK, an anchor channel which we had to fail when deserializing our `ChannelManager` would have its commitment transaction broadcast by itself, potentially exposing the node operator to loss of funds if the commitment transaction's fee is not enough to be accepted into the network's mempools.
There is no need to fill the user's logs with errors that are expected to be hit based on specific edge cases, like providing preimages after a monitor has seen a confirmed commitment on-chain. This doesn't really change our behavior – we still apply and persist the state changes resulting from processing these updates regardless of whether they succeed or not.
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
from
7b78496
to
04ee948
Compare
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
2 times, most recently
from
e1dc6e5
to
4b79c1c
Compare
TheBlueMatt
reviewed
Mar 28, 2023
TheBlueMatt
reviewed
Mar 28, 2023
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
from
4b79c1c
to
a1b5394
Compare
arik-so
requested changes
Mar 28, 2023
As long as the lock order on such locks is still valid, we should allow them regardless of whether they were constructed at the same location or not. Note that we can only really enforce this if we require one lock call per line, or if we have access to symbol columns (as we do on Linux and macOS). We opt for a smaller patch by relying on the latter. This was previously triggered by some recent test changes to `test_manager_serialize_deserialize_inconsistent_monitor`. When the test ends and a node is dropped causing us to persist each, we'd detect a possible lockorder violation deadlock across three different `Mutex` instances that are held at the same location when serializing our `per_peer_states` in `ChannelManager::write`. The presumed lockorder violation happens because the first `Mutex` held shares the same construction location with the third one, while the second `Mutex` has a different construction location. When we hold the second one, we consider the first as a dependency, and then consider the second as a dependency when holding the third, causing a circular dependency (since the third shares the same construction location as the first). This isn't considered a lockorder violation that could result in a deadlock as the comment suggests inline though, since we are under a dependent write lock which no one else can have access to.
wpaulino
force-pushed
the
broadcast-missing-anchors-event
branch
from
a1b5394
to
9fe4750
Compare
arik-so
approved these changes
Mar 29, 2023
TheBlueMatt
approved these changes
Mar 29, 2023
k0k0ne
pushed a commit
to bitlightlabs/rust-lightning
that referenced
this pull request
Sep 30, 2024
0.0.115 - Apr 24, 2023 - "Rebroadcast the Bugfixes" API Updates =========== * The MSRV of the main LDK crates has been increased to 1.48 (lightningdevkit#2107). * Attempting to claim an un-expired payment on a channel which has closed no longer fails. The expiry time of payments is exposed via `PaymentClaimable::claim_deadline` (lightningdevkit#2148). * `payment_metadata` is now supported in `Invoice` deserialization, sending, and receiving (via a new `RecipientOnionFields` struct) (lightningdevkit#2139, lightningdevkit#2127). * `Event::PaymentFailed` now exposes a failure reason (lightningdevkit#2142). * BOLT12 messages now support stateless generation and validation (lightningdevkit#1989). * The `NetworkGraph` is now pruned of stale data after RGS processing (lightningdevkit#2161). * Max inbound HTLCs in-flight can be changed in the handshake config (lightningdevkit#2138). * `lightning-transaction-sync` feature `esplora-async-https` was added (lightningdevkit#2085). * A `ChannelPending` event is now emitted after the initial handshake (lightningdevkit#2098). * `PaymentForwarded::outbound_amount_forwarded_msat` was added (lightningdevkit#2136). * `ChannelManager::list_channels_by_counterparty` was added (lightningdevkit#2079). * `ChannelDetails::feerate_sat_per_1000_weight` was added (lightningdevkit#2094). * `Invoice::fallback_addresses` was added to fetch `bitcoin` types (lightningdevkit#2023). * The offer/refund description is now exposed in `Invoice{,Request}` (lightningdevkit#2206). Backwards Compatibility ======================= * Payments sent with the legacy `*_with_route` methods on LDK 0.0.115+ will no longer be retryable via the LDK 0.0.114- `retry_payment` method (lightningdevkit#2139). * `Event::PaymentPathFailed::retry` was removed and will always be `None` for payments initiated on 0.0.115 which fail on an earlier version (lightningdevkit#2063). * `Route`s and `PaymentParameters` with blinded path information will not be readable on prior versions of LDK. Such objects are not currently constructed by LDK, but may be when processing BOLT12 data in a coming release (lightningdevkit#2146). * Providing `ChannelMonitorUpdate`s generated by LDK 0.0.115 to a `ChannelMonitor` on 0.0.114 or before may panic (lightningdevkit#2059). Note that this is in general unsupported, and included here only for completeness. Bug Fixes ========= * Fixed a case where `process_events_async` may `poll` a `Future` which has already completed (lightningdevkit#2081). * Fixed deserialization of `u16` arrays. This bug may have previously corrupted the historical buckets in a `ProbabilisticScorer`. Users relying on the historical buckets may wish to wipe their scorer on upgrade to remove corrupt data rather than waiting on it to decay (lightningdevkit#2191). * The `process_events_async` task is now `Send` and can thus be polled on a multi-threaded runtime (lightningdevkit#2199). * Fixed a missing macro export causing `impl_writeable_tlv_based_enum{,_upgradable}` calls to not compile (lightningdevkit#2091). * Fixed compilation of `lightning-invoice` with both `no-std` and serde (lightningdevkit#2187) * Fix an issue where the `background-processor` would not wake when a `ChannelMonitorUpdate` completed asynchronously, causing delays (lightningdevkit#2090). * Fix an issue where `process_events_async` would exit immediately (lightningdevkit#2145). * `Router` calls from the `ChannelManager` now call `find_route_with_id` rather than `find_route`, as was intended and described in the API (lightningdevkit#2092). * Ensure `process_events_async` always exits if any sleep future returns true, not just if all sleep futures repeatedly return true (lightningdevkit#2145). * `channel_update` messages no longer set the disable bit unless the peer has been disconnected for some time. This should resolve cases where channels are disabled for extended periods of time (lightningdevkit#2198). * We no longer remove CLN nodes from the network graph for violating the BOLT spec in some cases after failing to pay through them (lightningdevkit#2220). * Fixed a debug assertion which may panic under heavy load (lightningdevkit#2172). * `CounterpartyForceClosed::peer_msg` is now wrapped in UntrustedString (lightningdevkit#2114) * Fixed a potential deadlock in `funding_transaction_generated` (lightningdevkit#2158). Security ======== * Transaction re-broadcasting is now substantially more aggressive, including a new regular rebroadcast feature called on a timer from the `background-processor` or from `ChainMonitor::rebroadcast_pending_claims`. This should substantially increase transaction confirmation reliability without relying on downstream `TransactionBroadcaster` implementations for rebroadcasting (lightningdevkit#2203, lightningdevkit#2205, lightningdevkit#2208). * Implemented the changes from BOLT PRs lightningdevkit#1031, lightningdevkit#1032, and lightningdevkit#1040 which resolve a privacy vulnerability which allows an intermediate node on the path to discover the final destination for a payment (lightningdevkit#2062). In total, this release features 110 files changed, 11928 insertions, 6368 deletions in 215 commits from 21 authors, in alphabetical order: * Advait * Alan Cohen * Alec Chen * Allan Douglas R. de Oliveira * Arik Sosman * Elias Rohrer * Evan Feenstra * Jeffrey Czyz * John Cantrell * Lucas Soriano del Pino * Marc Tyndel * Matt Corallo * Paul Miller * Steven * Steven Williamson * Steven Zhao * Tony Giorgio * Valentine Wallace * Wilmer Paulino * benthecarman * munjesi
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This results in a new, potentially redundant,
ChannelMonitorUpdatethat must be applied toChannelMonitors to broadcast the holder's latest commitment transaction.This is a behavior change for anchor channels since their commitments may require additional fees to be attached through a child anchor transaction. Recall that anchor transactions are only generated by the event consumer after processing a
BumpTransactionEvent::ChannelCloseevent, which is yielded after applying aChannelMonitorUpdateStep::ChannelForceClosedmonitor update. Assuming the node operator is not watching the mempool to generate these anchor transactions without LDK, an anchor channel which we had to fail when deserializing ourChannelManagerwould have its commitment transaction broadcast by itself, potentially exposing the node operator to loss of funds if the commitment transaction's fee is not enough to be accepted into the network's mempools.Replaces #2001.