Duncan Dean [Thu, 30 Nov 2023 11:31:24 +0000 (13:31 +0200)]
Introduce basic incremental mutation testing
We introduce a CI job for mutation testing of PR diffs using cargo-mutants.
Missed cases do not trigger a fail of this job yet as we just introduce it
now for visibility. We may start enforcing stricter rules at a later stage.
Jeffrey Czyz [Thu, 27 Jun 2024 19:39:26 +0000 (14:39 -0500)]
Merge pull request #3129 from optout21/splicing-msgs-update
Update splice messages according to new spec draft
Elias Rohrer [Thu, 27 Jun 2024 15:03:24 +0000 (11:03 -0400)]
Merge pull request #3147 from TheBlueMatt/2024-06-feerate-overflow
Handle feerates of `u32::MAX` without overflowing
dunxen [Thu, 27 Jun 2024 08:37:39 +0000 (10:37 +0200)]
Merge pull request #2989 from optout21/iatx-shared-output
Interactive TX negotiation tracks shared outputs
Matt Corallo [Wed, 26 Jun 2024 14:16:50 +0000 (14:16 +0000)]
Handle feerates of `u32::MAX` without overflowing
Though we generally shouldn't be seeing these, and the
`get_dust_buffer_feerate` implementation will still return
`u32::MAX` in spite of the overflow, we should handle the overflow
to avoid panic when `debug_assertions` are enabled.
Found by the `full_stack_target` fuzzer
valentinewallace [Wed, 26 Jun 2024 14:19:22 +0000 (10:19 -0400)]
Merge pull request #3145 from valentinewallace/2024-06-AP-prefactor-followup
Followups to #3125
Valentine Wallace [Tue, 25 Jun 2024 20:17:48 +0000 (16:17 -0400)]
Implement AsyncPaymentsMessageHandler for ChanMan and use everywhere
Dummy implementation for now. This avoids having to change a bunch of type
signatures in the future when we replace the dummy impl with a real one.
Valentine Wallace [Tue, 25 Jun 2024 19:51:03 +0000 (15:51 -0400)]
Onion message fuzzer: update held_htlc_available handling
Fuzzers should always do more, not less. Post-merge feedback on
e8f154dd3c299c7988762909df48b0c9d919d6f8.
valentinewallace [Mon, 24 Jun 2024 16:06:17 +0000 (12:06 -0400)]
Merge pull request #3125 from valentinewallace/2024-06-async-payments-prefactor
Async payments message encoding and prefactor
optout [Mon, 24 Jun 2024 11:05:45 +0000 (13:05 +0200)]
Update splice messages according to new spec draft
Valentine Wallace [Thu, 13 Jun 2024 18:09:12 +0000 (14:09 -0400)]
Cfg-gate async payments module and public enum variants.
Valentine Wallace [Thu, 13 Jun 2024 18:08:03 +0000 (14:08 -0400)]
Remove unused imports in static_invoice.rs
Valentine Wallace [Wed, 29 May 2024 18:48:05 +0000 (14:48 -0400)]
Add OffersMessage variant for static invoices.
Valentine Wallace [Thu, 6 Jun 2024 15:56:37 +0000 (11:56 -0400)]
DRY responder instantiation for onion messages.
Valentine Wallace [Wed, 5 Jun 2024 20:00:18 +0000 (16:00 -0400)]
AsyncPaymentsMessageHandler trait for OnionMessenger
Add a trait for handling async payments messages to OnionMessenger. This allows
users to either provide their own custom handling for async payments messages
or rely on a version provided by LDK.
Matt Corallo [Thu, 20 Jun 2024 16:51:54 +0000 (09:51 -0700)]
Merge pull request #2966 from G8XSU/2647-distribute
Optimize ChannelMonitor persistence on block connections.
optout [Thu, 20 Jun 2024 15:28:56 +0000 (17:28 +0200)]
Interactive TX negotiation tracks shared outputs
Matt Corallo [Thu, 20 Jun 2024 14:26:43 +0000 (07:26 -0700)]
Merge pull request #3127 from wvanlint/non_strict_forwarding
Implement non-strict forwarding
Valentine Wallace [Wed, 5 Jun 2024 17:41:07 +0000 (13:41 -0400)]
Onion message payload for async payments
Async payments uses onion messages to indicate when HTLCs are held and
released. Add these types along with the necessary parsing and encoding.
Elias Rohrer [Thu, 20 Jun 2024 11:46:06 +0000 (13:46 +0200)]
Merge pull request #3135 from tnull/2024-06-rustfmt-rgs
Run `rustfmt` on `lightning-rapid-gossip-sync`
Elias Rohrer [Thu, 20 Jun 2024 08:59:21 +0000 (10:59 +0200)]
`rustfmt`: Drop `benches/src/bench.rs` from excluded files
Elias Rohrer [Thu, 20 Jun 2024 08:55:49 +0000 (10:55 +0200)]
`rustfmt`: Run on `lightning-rapid-gossip-sync/src/lib.rs`
Elias Rohrer [Thu, 20 Jun 2024 08:54:27 +0000 (10:54 +0200)]
`rustfmt`: Run on `lightning-rapid-gossip-sync/src/processing.rs`
Elias Rohrer [Thu, 20 Jun 2024 08:53:29 +0000 (10:53 +0200)]
`rustfmt`: Prepare `lightning-rapid-gossip-sync/src/processing.rs`
Willem Van Lint [Tue, 11 Jun 2024 23:05:57 +0000 (16:05 -0700)]
Implement non-strict forwarding
This change implements non-strict forwarding, allowing the node to
forward an HTLC along a channel other than the one specified
by short_channel_id in the onion message, so long as the receiver has
the same node public key intended by short_channel_id
([BOLT](https://github.com/lightning/bolts/blob/
57ce4b1e05c996fa649f00dc13521f6d496a288f/04-onion-routing.md#non-strict-forwarding)).
This can improve payment reliability when there are multiple channels
with the same peer e.g. when outbound liquidity is replenished by
opening a new channel.
The implemented forwarding strategy now chooses the channel with the
lowest outbound liquidity that can forward an HTLC to maximize the
probability of being able to successfully forward a subsequent HTLC.
Fixes #1278.
Elias Rohrer [Wed, 19 Jun 2024 12:42:08 +0000 (14:42 +0200)]
Merge pull request #3132 from jkczyz/2024-06-bolt12-unannounced
Blinded paths with unannounced introduction nodes
G8XSU [Fri, 14 Jun 2024 23:56:36 +0000 (16:56 -0700)]
Optimize ChannelMonitor persistence on block connections.
Currently, every block connection triggers the persistence of all
ChannelMonitors with an updated best_block. This approach poses
challenges for large node operators managing thousands of channels.
Furthermore, it leads to a thundering herd problem
(https://en.wikipedia.org/wiki/Thundering_herd_problem), overwhelming
the storage with simultaneous requests.
To address this issue, we now persist ChannelMonitors at a
regular cadence, spreading their persistence across blocks to
mitigate spikes in write operations.
Outcome: After doing this, Ldk's IO footprint should be reduced
by ~50 times. The processing time required to sync each block
will be significantly reduced, particularly for nodes with 1000s
of channels, as write latency plays a significant role in this process.
As a result, the Node/ChainMonitor will be blocked for a shorter
duration, leading to further efficiency gains.
Gursharan Singh [Tue, 18 Jun 2024 20:31:38 +0000 (13:31 -0700)]
Merge pull request #3126 from TheBlueMatt/2024-06-preimage-removal-blocked-by-claim-event
(Very) marginally expand `test_monitor_update_fail_claim`
Matt Corallo [Thu, 13 Jun 2024 18:59:51 +0000 (18:59 +0000)]
(Very) marginally expand `test_monitor_update_fail_claim`
For some reason I wasn't sure this happened yet, so making the
test for no-`PaymentClaimed`-event-before-preimage-on-disk explicit
is nice.
Matt Corallo [Tue, 18 Jun 2024 15:33:43 +0000 (08:33 -0700)]
Merge pull request #3115 from alecchendev/2024-06-specific-async-sign
Refactor async signing test utils to toggle specific method availability
Jeffrey Czyz [Mon, 17 Jun 2024 19:41:32 +0000 (14:41 -0500)]
Relax channel count check for unannounced nodes
When creating blinded paths, introduction nodes are limited to peers
with at least three channels to prevent easily guessing the recipient.
Relax this check when the recipient is unannounced since they won't be
in the NetworkGraph.
Jeffrey Czyz [Thu, 13 Jun 2024 22:15:19 +0000 (17:15 -0500)]
Advance self blinded payment paths
DefaultRouter will ignore blinded paths where the sender is the
introduction node. Similar to message paths, advance such paths by one
so that payments may be sent to them.
Jeffrey Czyz [Thu, 13 Jun 2024 19:35:21 +0000 (14:35 -0500)]
Re-order imports
Jeffrey Czyz [Fri, 14 Jun 2024 14:32:17 +0000 (09:32 -0500)]
Rename variable
Jeffrey Czyz [Fri, 14 Jun 2024 21:57:41 +0000 (16:57 -0500)]
Add advance_path_by_one for blinded payment paths
Similar to blinded paths for onion messages, if given a blinded payment
path where we are the introduction node, the path must be advanced by
one in order to use it.
Jeffrey Czyz [Fri, 14 Jun 2024 14:04:47 +0000 (09:04 -0500)]
Don't modify path when advance_path_by_one errors
When using advance_path_by_one when we are the introduction node, any
error will result having the first hop of the input blinded path
removed. Instead, only remove the first hop on success. Otherwise, the
path will be invalid.
Jeffrey Czyz [Wed, 12 Jun 2024 21:54:19 +0000 (16:54 -0500)]
Blinded payments to unannounced introduction node
When creating blinded paths for receiving onion payments, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending payments without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.
Jeffrey Czyz [Wed, 12 Jun 2024 15:58:18 +0000 (10:58 -0500)]
BlindedPath with unannounced introduction node
When creating blinded paths for receiving onion messages, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending messages without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.
Elias Rohrer [Tue, 18 Jun 2024 12:49:38 +0000 (14:49 +0200)]
Merge pull request #3130 from TheBlueMatt/2024-06-doc-fee-present
Document when `Events::PaymentSent::pending_fee_msat` is `Some`
Alec Chen [Tue, 11 Jun 2024 00:18:52 +0000 (17:18 -0700)]
Remove global availability logic for testing async signing
Alec Chen [Mon, 17 Jun 2024 21:28:21 +0000 (14:28 -0700)]
Refactor tests to use specific async signing ops
Alec Chen [Mon, 10 Jun 2024 22:01:11 +0000 (15:01 -0700)]
Allow toggling specific signing methods in test channel signer
G8XSU [Fri, 14 Jun 2024 23:55:39 +0000 (16:55 -0700)]
Start tracking chain_sync_monitor_persistences in TestPersister
It is helpful to assert that chain-sync did trigger a monitor
persist.
valentinewallace [Mon, 17 Jun 2024 14:13:04 +0000 (10:13 -0400)]
Merge pull request #3128 from TheBlueMatt/2024-06-no-claim-ret
Drop unused return value from `claim_funds_from_hop`
Matt Corallo [Mon, 17 Jun 2024 13:53:20 +0000 (13:53 +0000)]
Document when `Events::PaymentSent::pending_fee_msat` is `Some`
Elias Rohrer [Mon, 17 Jun 2024 07:23:18 +0000 (09:23 +0200)]
Merge pull request #3123 from dunxen/2024-06-channelrefactor
Move accept_channel checks into `ChannelContext::do_accept_channel_checks`
Matt Corallo [Sun, 16 Jun 2024 14:15:07 +0000 (14:15 +0000)]
Drop unused return value from `claim_funds_from_hop`
Duncan Dean [Thu, 13 Jun 2024 12:12:47 +0000 (14:12 +0200)]
Move accept_channel checks into `ChannelContext::do_accept_channel_checks`
This is done ahead of getting the dual-funding implementation to reduce
refactoring noise there.
Valentine Wallace [Wed, 5 Jun 2024 17:06:11 +0000 (13:06 -0400)]
ser_macros: support messages with no fields
Matt Corallo [Thu, 13 Jun 2024 13:56:33 +0000 (06:56 -0700)]
Merge pull request #3102 from tnull/2024-06-rustfmt-fuzz
`rustfmt`: Reformat the `fuzz` dir
Elias Rohrer [Thu, 13 Jun 2024 06:48:06 +0000 (08:48 +0200)]
Merge pull request #3098 from arik-so/arik/gossip-v2-parsing
Parse v2 gossip
Elias Rohrer [Thu, 13 Jun 2024 06:25:59 +0000 (08:25 +0200)]
Merge pull request #3078 from jkczyz/2024-05-invoice-event
Asynchronous `Bolt12Invoice` payment
Arik Sosman [Tue, 11 Jun 2024 19:10:44 +0000 (12:10 -0700)]
Update documentation.
Arik Sosman [Thu, 9 May 2024 16:42:14 +0000 (09:42 -0700)]
Parse v2 gossip.
Jeffrey Czyz [Wed, 22 May 2024 16:28:31 +0000 (11:28 -0500)]
Add pays_bolt12_invoice_asynchronously test
Jeffrey Czyz [Tue, 21 May 2024 23:47:32 +0000 (18:47 -0500)]
Expose send_payment_for_bolt12_invoice
UserConfig::manually_handle_bolt12_invoices allows deferring payment of
BOLT12 invoices by generating Event::InvoiceReceived. Expose
ChannelManager::send_payment_for_bolt12_invoice to allow users to pay
the Bolt12Invoice included in the event. While the event contains the
PaymentId for reference, that parameter is now removed from the method
in favor of extracting the PaymentId from the invoice's payer_metadata.
Jeffrey Czyz [Wed, 12 Jun 2024 16:51:23 +0000 (11:51 -0500)]
Reformat and tick config docs
Jeffrey Czyz [Tue, 21 May 2024 21:58:10 +0000 (16:58 -0500)]
Add UserConfig::manually_handle_bolt12_invoices
BOLT12 invoices are automatically paid once they have been verified.
Users may want to manually pay them by first performing additional
checks. Add a manually_handle_bolt12_invoices configuration option that
when set generates an Event::InvoiceReceived instead of paying the
invoice.
Matt Corallo [Wed, 12 Jun 2024 22:17:48 +0000 (15:17 -0700)]
Merge pull request #3082 from valentinewallace/2024-04-bolt12-keysend-invoice
BOLT 12 static invoice encoding and building
Matt Corallo [Wed, 12 Jun 2024 22:17:25 +0000 (15:17 -0700)]
Merge pull request #3103 from TheBlueMatt/2024-06-real-bench
Use a real (probing-generated) scorer in benchmarks
Valentine Wallace [Fri, 31 May 2024 20:17:38 +0000 (16:17 -0400)]
Static invoice parsing tests
Valentine Wallace [Tue, 4 Jun 2024 23:12:54 +0000 (19:12 -0400)]
Static invoice building tests
Valentine Wallace [Thu, 9 May 2024 21:15:34 +0000 (17:15 -0400)]
Builder for creating static invoices from offers
Add a builder for creating static invoices for an offer. Building produces a
semantically valid static invoice for the offer, which can then be signed with
the key associated with the offer's signing pubkey.
Jeffrey Czyz [Tue, 21 May 2024 19:33:56 +0000 (14:33 -0500)]
Add an InvoiceReceived event
Some users may want to handle a Bolt12Invoice asynchronously, either in
a different process or by first performing additional verification
before paying the invoice. Add an InvoiceReceived event to facilitate
this.
Elias Rohrer [Mon, 10 Jun 2024 08:48:19 +0000 (10:48 +0200)]
`rustfmt`: `fuzz/src/full_stack.rs`
Elias Rohrer [Mon, 10 Jun 2024 08:47:50 +0000 (10:47 +0200)]
Prepare `fuzz/src/full_stack.rs` for `rustfmt`
Elias Rohrer [Mon, 10 Jun 2024 08:37:50 +0000 (10:37 +0200)]
`rustfmt`: `fuzz/src/chanmon_consistency.rs`
Elias Rohrer [Wed, 12 Jun 2024 17:51:10 +0000 (19:51 +0200)]
Introduce `noret` wrappers
Matt Corallo [Wed, 12 Jun 2024 14:06:54 +0000 (14:06 +0000)]
Drop unnecessary key derivation in route tests
In our route tests we need some "random" bytes for the router to
randomize amounts using. We generate this by building an actual
`KeysManager` and then deriving some random bytes using the
`EntropySource` trait. However, `get_route` (what we're normally
testing) doesn't actually use the random bytes, and even if it did,
using a `KeysManager` is just a fancy way of creating a constant,
so there's really no reason to do all the fancy crypto.
Instead, here, we change our routing tests and benchmarks to simply
use `[42; 32]` as the "random" bytes.
Matt Corallo [Sat, 9 Dec 2023 18:51:09 +0000 (18:51 +0000)]
Push the route benchmark results into a separate uninlined function
This ensures the route benchmarks themselves will appear with a
distinct callgraph, making router profiling somewhat easier.
Matt Corallo [Sun, 10 Dec 2023 18:23:17 +0000 (18:23 +0000)]
Use a real (probing-generated) scorer in benchmarks
Until now, our routing benchmarks used a synthetic scorer,
generated by scoring random paths to build up some history. This is
pretty far removed from real-world routing conditions, as
alternative paths generally have no scoring information and even
the paths we do take have only one or two past scoring results.
Instead, we fetch a static serialized scorer, generated using
minutely probes. This means future changes to the scorer's data may
be harder to benchmark, but makes for substantially more realistic
benchmarks for changes which don't impact the serialized state.
Valentine Wallace [Thu, 9 May 2024 18:29:08 +0000 (14:29 -0400)]
Static invoice encoding and parsing
Define an interface for BOLT 12 static invoice messages. The underlying
format consists of the original bytes and the parsed contents.
The bytes are later needed for serialization. This is because it must
mirror all the offer TLV records, including unknown ones, which aren't
represented in the contents.
Invoices may be created from an offer.
Elias Rohrer [Wed, 12 Jun 2024 17:58:06 +0000 (19:58 +0200)]
Merge pull request #3116 from TheBlueMatt/2024-06-3107-nit
Clarify `Display` text for `ClosureReason::HolderForceClosed` some
Elias Rohrer [Mon, 10 Jun 2024 11:40:38 +0000 (13:40 +0200)]
Prepare `chanmon_consistency.rs` for `rustfmt`
Elias Rohrer [Wed, 12 Jun 2024 17:20:28 +0000 (19:20 +0200)]
Merge pull request #3113 from TheBlueMatt/2024-04-async-monitor-fuzz
Fuzz reloading with a stale monitor in chanmon_consistency
Matt Corallo [Tue, 11 Jun 2024 01:39:48 +0000 (01:39 +0000)]
Unblock channels awaiting monitor update based on `ChanMan` queue
When we have `ChannelMonitorUpdate`s which are completing both
synchronously and asynchronously, we need to consider a channel as
unblocked based on the `ChannelManager` monitor update queue,
rather than by checking the `update_id`s.
Consider the case where a channel is updated, leading to a
`ChannelMonitorUpdate` which completes asynchronously. The update
completes, but prior to the `ChannelManager` receiving the
`MonitorEvent::Completed` it generates a further
`ChannelMonitorUpdate`. This second update completes synchronously.
As a result, when the `MonitorEvent` is processed, the event's
`monitor_update_id` is the first update, but there are no updates
queued and the channel should be free to return to be unblocked.
Here we fix this by looking only at the `ChannelManager` update
queue, rather than the update_id of the `MonitorEvent`.
While we don't anticipate many users having both synchronous and
asynchronous persists in the same application, there isn't much
cost to supporting it, which we do here.
Found by the chanmon_consistency target.
Matt Corallo [Mon, 15 Apr 2024 19:25:05 +0000 (19:25 +0000)]
Fuzz reloading with a stale monitor in chanmon_consistency
Now that we are gearing up to support fully async monitor storage,
we really need to fuzz monitor updates not completing before a
reload, which we do here in the `chanmon_consistency` fuzzer.
While there are more parts to async monitor updating that we need
to fuzz, this at least gets us started by having basic async
restart cases handled. In the future, we should extend this to make
sure some basic properties (eg claim/balance consistency) remain
true through `chanmon_consistency` runs.
Valentine Wallace [Thu, 6 Jun 2024 18:43:10 +0000 (14:43 -0400)]
InvoiceTlvStream{Ref}: add message_paths field
Will be used in static invoices. Also test that we'll fail to decode if these
paths are included in single-use BOLT 12 invoices.
Matt Corallo [Tue, 11 Jun 2024 18:59:02 +0000 (18:59 +0000)]
Clarify `Display` text for `ClosureReason::HolderForceClosed` some
... to make it clear that we elected not to broadcast, rather than
failed to broadcast.
Matt Corallo [Tue, 11 Jun 2024 18:55:11 +0000 (11:55 -0700)]
Merge pull request #3107 from mhrheaume/mhr/closure_reason_abandoned
Updated `ClosureReason::HolderForceClosed` with whether txn was broadcasted.
Valentine Wallace [Tue, 4 Jun 2024 22:17:45 +0000 (18:17 -0400)]
Use ? instead of matching in BOLT 12 invoice parsing.
Minor cleanup to be more concise.
Valentine Wallace [Tue, 4 Jun 2024 22:21:50 +0000 (18:21 -0400)]
BOLT 12 invoice: extract helper for invoice signing pubkey checks
Will be useful for static invoices.
Valentine Wallace [Thu, 9 May 2024 18:23:40 +0000 (14:23 -0400)]
BOLT 12 invoice: expose common helper methods and fields
Useful for static invoice support.
Valentine Wallace [Wed, 22 May 2024 20:13:10 +0000 (16:13 -0400)]
Genericize BOLT 12 invoice{_builder} common macro docs over invoice type
Will be useful so the docs generated work for static invoices.
Jeffrey Czyz [Tue, 21 May 2024 19:32:40 +0000 (14:32 -0500)]
Implement Readable for Responder
A future InvoiceReceived event will include a Responder. Since Event
implements Readable, so must Responder.
Jeffrey Czyz [Tue, 21 May 2024 19:28:56 +0000 (14:28 -0500)]
Implement Readable for Bolt12Invoice
A future InvoiceReceived event will include a Bolt12Invoice. Since Event
implements Readable, so must Bolt12Invoice.
Jeffrey Czyz [Tue, 21 May 2024 18:49:38 +0000 (13:49 -0500)]
Re-order imports in events module
Jeffrey Czyz [Thu, 16 May 2024 21:14:59 +0000 (16:14 -0500)]
Clean up invoice handling result logic
Jeffrey Czyz [Thu, 16 May 2024 21:02:42 +0000 (16:02 -0500)]
Use implicit returns from match expressions
Matt Corallo [Tue, 11 Jun 2024 14:20:00 +0000 (07:20 -0700)]
Merge pull request #3037 from TheBlueMatt/2024-05-close-on-stale-fees
Force-close channels if their feerate gets stale without any update
valentinewallace [Mon, 10 Jun 2024 22:30:09 +0000 (18:30 -0400)]
Merge pull request #3086 from alecchendev/2024-05-holder-commitment
Add `HolderCommitmentPoint` struct to track commitment points
Alec Chen [Thu, 30 May 2024 22:09:56 +0000 (17:09 -0500)]
Get per commitment point everywhere else with HolderCommitmentPoint
This includes when building TxCreationKeys, as well as for open_channel
and accept_channel messages. Note: this is only for places where we are
retrieving the current per commitment point, which excludes
channel_reestablish.
Alec Chen [Thu, 30 May 2024 22:07:03 +0000 (17:07 -0500)]
Get per commitment point for channel ready using HolderCommitmentPoint
Matthew Rheaume [Thu, 6 Jun 2024 20:54:51 +0000 (13:54 -0700)]
Updated `ClosureReason::HolderForceClosed` with broadcasted txn.
Alec Chen [Thu, 30 May 2024 21:11:08 +0000 (16:11 -0500)]
Use HolderCommitmentPoint for commitment number
Alec Chen [Thu, 30 May 2024 20:35:11 +0000 (15:35 -0500)]
Add HolderCommitmentPoint struct to ChannelContext
Matt Corallo [Thu, 30 May 2024 20:59:42 +0000 (20:59 +0000)]
Add a test of stale-feerate-force-closure behavior
Matt Corallo [Sun, 5 May 2024 23:22:23 +0000 (23:22 +0000)]
Force-close channels if their feerate gets stale without any update
For quite some time, LDK has force-closed channels if the peer
sends us a feerate update which is below our `FeeEstimator`'s
concept of a channel lower-bound. This is intended to ensure that
channel feerates are always sufficient to get our commitment
transaction confirmed on-chain if we do need to force-close.
However, we've never checked our channel feerate regularly - if a
peer is offline (or just uninterested in updating the channel
feerate) and the prevailing feerates on-chain go up, we'll simply
ignore it and allow our commitment transaction to sit around with a
feerate too low to get confirmed.
Here we rectify this oversight by force-closing channels with stale
feerates, checking after each block. However, because fee
estimators are often buggy and force-closures piss off users, we
only do so rather conservatively. Specifically, we only force-close
if a channel's feerate is below the minimum `FeeEstimator`-provided
minimum across the last day.
Further, because fee estimators are often especially buggy on
startup (and because peers haven't had a chance to update the
channel feerates yet), we don't force-close channels until we have
a full day of feerate lower-bound history.
This should reduce the incidence of force-closures substantially,
but it is expected this will still increase force-closures somewhat
substantially depending on the users' `FeeEstimator`.
Fixes #993
Matt Corallo [Fri, 31 May 2024 17:42:49 +0000 (17:42 +0000)]
Skip fee reads in `full_stack_target` when connecting many blocks
When we connect 100 blocks in a row, requiring the fuzz input to
contain 100 fee estimator results is uneccessary, so add a bool
that lets us skip those reads.
Matt Corallo [Sun, 5 May 2024 23:21:13 +0000 (23:21 +0000)]
Add a new `ClosureReason::PeerFeerateTooLow`
Closure due to feerate disagreements are a specific closure reason
which admins can understand and tune their config (in the form of
their `FeeEstimator`) to avoid, so having a separate
`ClosureReason` for it is useful.