Implement pending claim rebroadcast on force-closed channels #2208
Conversation
| F::Target: FeeEstimator, | ||
| L::Target: Logger, | ||
| { | ||
| let mut bump_requests = Vec::with_capacity(self.pending_claim_requests.len()); |
There was a problem hiding this comment.
god we really need to fix this so we can just iterate the map and build as we go, rather than adding intermediate vecs and then looking up in the map and updating it later.
There was a problem hiding this comment.
Yeah I want to address this for the next release.
| // rebroadcast/re-sign the previous claim. | ||
| debug_assert!(new_feerate >= previous_feerate); | ||
| if new_feerate == previous_feerate { | ||
| return Some((new_fee, new_feerate)); |
There was a problem hiding this comment.
Shall we still check RBF rule 4? I can understand if it’s a rebroadcast to ensure sane p2p propagation and therefore it’s okay if it fails because there is already one of our claims in the network mempools. However if it’s rebroadcast due to height tick, where the rational is to increase the claim feerate, I think we should bump by at least the RBF penalty, even if there is no enough input_amounts to satisfy the bumped_fee, and therefore ensure new_feerate > previous_feerate.
There was a problem hiding this comment.
I think we can leave this for a follow-up. I plan to address a bunch of things in this area for the next release. Our bumper is way too aggressive in its current form when claims are more than a few blocks away from their deadline, and yesterday I realized that our MIN_RELAY_FEE_SAT_PER_1000_WEIGHT constant is wrong by a factor of 16.
| log_info!(logger, "Triggering rebroadcast/fee-bump for request with inputs {:?}", inputs); | ||
| bump_requests.push((*package_id, request.clone())); | ||
| } | ||
| for (package_id, request) in bump_requests { |
There was a problem hiding this comment.
if we can prefix the package_id with custom_package_id or ldk_package_id, just some sanity codebase as Core is working on introducing package at the p2p-level and there is a real formalized package id introduced. Avoid some confusion in the future.
There was a problem hiding this comment.
It's also used in a few other places. We can likely address it when we update our BroadcasterInterface to support broadcasting transaction packages.
| // Test that ChannelManager's and PeerManager's `timer_tick_occurred` is called every | ||
| // `FRESHNESS_TIMER`. | ||
| // Test that `ChannelManager::timer_tick_occurred` and | ||
| // `ChainMonitor::rebroadcast_pending_claims` is called every `FRESHNESS_TIMER` and |
There was a problem hiding this comment.
FRESHNESS_TIMER=60, should we introduce a bit of noise by randomnizing rebroadcast interval to avoid leaking a static rebroadcast pattern to a deanonymization attacker at the transaction-propagation layer ? independently of the logic that the transaction-propagation layer can have
There was a problem hiding this comment.
I mean we're rebroadcasting a spend of the same output each time, I don't think the timing analysis is the problem :)
wpaulino
force-pushed
the
monitor-rebroadcast-pending-claims
branch
from
59d91f5
to
868cff5
Compare
In the next commit, we plan to extend the `OnchainTxHandler` to retry pending claims on a timer. This timer may fire with much more frequency than incoming blocks, so we want to avoid manually bumping feerates (currently by 25%) each time our fee estimator provides a lower feerate than before.
This attempts to rebroadcast/fee-bump each pending claim a monitor is tracking for a force-closed channel. This is crucial in preventing certain classes of pinning attacks and ensures reliability if broadcasting fails. For implementations of `FeeEstimator` that also support mempool fee estimation, we may broadcast a fee-bumped claim instead, ensuring we can also react to mempool fee spikes between blocks.
This will prompt monitors to rebroadcast/fee-bump their pending claims on a force-closed channel once on startup and every 30 seconds after.
wpaulino
force-pushed
the
monitor-rebroadcast-pending-claims
branch
from
868cff5
to
453b3a1
Compare
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 #2208 +/- ##
========================================
Coverage 91.50% 91.50%
========================================
Files 104 104
Lines 51176 51332 +156
Branches 51176 51332 +156
========================================
+ Hits 46829 46973 +144
- Misses 4347 4359 +12
... and 1 file 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. |
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
This attempts to rebroadcast/fee-bump each pending claim a monitor is tracking for a force-closed channel. This is crucial in preventing certain classes of pinning attacks and ensures reliability if broadcasting fails. For implementations of
FeeEstimatorthat also support mempool fee estimation, we may broadcast a fee-bumped claim instead, ensuring we can also react to mempool fee spikes between blocks.