valentinewallace [Mon, 30 May 2022 17:05:01 +0000 (10:05 -0700)]
Merge pull request #1434 from TheBlueMatt/2022-04-robust-payment-claims
Improve Robustness of Inbound MPP Claims Across Restart
Matt Corallo [Sat, 28 May 2022 00:27:14 +0000 (00:27 +0000)]
Change `Event` `amt` fields to `amount_msat` for clarity
Elias Rohrer [Fri, 27 May 2022 23:55:27 +0000 (16:55 -0700)]
Mention backwards compatibility in CONTRIBUTING.
Matt Corallo [Fri, 22 Apr 2022 17:58:19 +0000 (17:58 +0000)]
Add internal docs for ChannelMonitor::payment_preimages
Matt Corallo [Tue, 19 Apr 2022 22:06:50 +0000 (22:06 +0000)]
Drop return value from `fail_htlc_backwards`, clarify docs
`ChannelManager::fail_htlc_backwards`' bool return value is quite
confusing - just because it returns false doesn't mean the payment
wasn't (already) failed. Worse, in some race cases around shutdown
where a payment was claimed before an unclean shutdown and then
retried on startup, `fail_htlc_backwards` could return true even
though (a duplicate copy of the same payment) was claimed, but the
claim event has not been seen by the user yet.
While its possible to use it correctly, its somewhat confusing to
have a return value at all, and definitely lends itself to misuse.
Instead, we should push users towards a model where they don't care
if `fail_htlc_backwards` succeeds - either they've locally marked
the payment as failed (prior to seeing any `PaymentReceived`
events) and will fail any attempts to pay it, or they have not and
the payment is still receivable until its timeout time is reached.
We can revisit this decision based on user feedback, but will need
to very carefully document the potential failure modes here if we
do.
Matt Corallo [Tue, 19 Apr 2022 21:46:44 +0000 (21:46 +0000)]
Do additional pre-flight checks before claiming a payment
As additional sanity checks, before claiming a payment, we check
that we have the full amount available in `claimable_htlcs` that
the payment should be for. Concretely, this prevents one
somewhat-absurd edge case where a user may receive an MPP payment,
wait many *blocks* before claiming it, allowing us to fail the
pending HTLCs and the sender to retry some subset of the payment
before we go to claim. More generally, this is just good
belt-and-suspenders against any edge cases we may have missed.
Matt Corallo [Wed, 4 May 2022 18:12:09 +0000 (18:12 +0000)]
Provide a redundant `Event::PaymentClaimed` on restart if needed
If we crashed during a payment claim and then detected a partial
claim on restart, we should ensure the user is aware that the
payment has been claimed. We do so here by using the new
partial-claim detection logic to create a `PaymentClaimed` event.
Matt Corallo [Mon, 18 Apr 2022 20:12:15 +0000 (20:12 +0000)]
Add a `PaymentClaimed` event to indicate a payment was claimed
This replaces the return value of `claim_funds` with an event. It
does not yet change behavior in any material way.
Matt Corallo [Fri, 27 May 2022 23:54:52 +0000 (16:54 -0700)]
Merge pull request #1401 from TheBlueMatt/2022-02-0conf-round-two
Zero Conf Channels
Matt Corallo [Wed, 4 May 2022 02:34:10 +0000 (02:34 +0000)]
Add note about SCID collisions in `PaymentPathFailed`
This isn't specific to 0-conf but is useful for users to note as
the network moves towards more SCID aliases.
Matt Corallo [Mon, 2 May 2022 15:23:52 +0000 (15:23 +0000)]
Add test of 0conf channels getting the funding transaction reorg'd
In a previous version of the 0-conf code we did not correctly
handle 0-conf channels getting the funding transaction reorg'd out
(and the real SCID possibly changing on us).
Matt Corallo [Fri, 1 Apr 2022 21:29:59 +0000 (21:29 +0000)]
Correctly handle sending announcement sigs on public 0conf channels
Matt Corallo [Fri, 1 Apr 2022 01:34:38 +0000 (01:34 +0000)]
Add a new test for 0conf-with-monitor-update-failures
This tests a few cases of monitor failure updates that were broken
in earlier versions of the 0conf patchset.
Matt Corallo [Fri, 1 Apr 2022 01:36:38 +0000 (01:36 +0000)]
Expose outbound SCID alias in `ChannelDetails` and use in routing
This supports routing outbound over 0-conf channels by utilizing
the outbound SCID alias that we assign to all channels to refer to
the selected channel when routing.
Matt Corallo [Thu, 10 Feb 2022 00:09:42 +0000 (00:09 +0000)]
Send funding_locked immediately for inbound channels with 0conf
Matt Corallo [Wed, 2 Feb 2022 23:01:05 +0000 (23:01 +0000)]
Add API and signaling to accept incoming channels at 0conf
Matt Corallo [Tue, 1 Feb 2022 21:57:01 +0000 (21:57 +0000)]
Lock outbound channels at 0conf if the peer indicates support for it
If our peer sets a minimum depth of 0, and we're set to trusting
ourselves to not double-spend our own funding transactions, send a
funding_locked message immediately after funding signed.
Note that some special care has to be taken around the
`channel_state` values - `ChannelFunded` no longer implies the
funding transaction is confirmed on-chain. Thus, for example, the
should-we-re-broadcast logic has to now accept `channel_state`
values greater than `ChannelFunded` as indicating we may still need
to re-broadcast our funding tranasction, unless `minimum_depth` is
greater than 0.
Further note that this starts writing `Channel` objects with a
`MIN_SERIALIZATION_VERSION` of 2. Thus, LDK versions prior to
0.0.99 (July 2021) will now refuse to read serialized
Channels/ChannelManagers.
Matt Corallo [Fri, 13 May 2022 18:30:12 +0000 (18:30 +0000)]
Define a crate-public constant for max fake SCID in blocks offset
Matt Corallo [Fri, 4 Mar 2022 21:24:39 +0000 (21:24 +0000)]
Handle cases where a channel is in use w/o an SCID in ChannelManager
In the next few commits we add support for 0conf channels, allowing
us to have an active channel with HTLC and other updates flying
prior to having an SCID available. This would break several
assumptions made in `ChannelManager`, which we address here by
looking at SCID aliases in addition to SCIDs.
valentinewallace [Fri, 27 May 2022 17:38:42 +0000 (10:38 -0700)]
Merge pull request #1481 from TheBlueMatt/2022-05-new-chain-tests
Test coverage for `transaction_unconfirmed`
Matt Corallo [Fri, 27 May 2022 04:51:46 +0000 (21:51 -0700)]
Merge pull request #1499 from tnull/2022-05-fix-unreachable-warning
Fix `rapid-gossip-sync` warning and version number
Matt Corallo [Fri, 27 May 2022 02:05:52 +0000 (19:05 -0700)]
Merge pull request #1491 from tnull/2022-05-build-route-from-pubkeys
Build route from hop pubkey list.
Elias Rohrer [Fri, 27 May 2022 00:48:29 +0000 (17:48 -0700)]
Fix `rapid-gossip-sync` warning and version number
Elias Rohrer [Wed, 25 May 2022 23:44:22 +0000 (16:44 -0700)]
Allow building of a route from given hops
Implements `build_route_from_hops`, which provides a simple way to build
a route from us (payer) to the target node (payee) via the given hops
(which should exclude the payer, but include the payee). This may be
useful, e.g., for probing the chosen path.
Matt Corallo [Thu, 26 May 2022 18:11:08 +0000 (11:11 -0700)]
Merge pull request #1494 from TheBlueMatt/2022-05-mon-cleanups-renames
Correct variable names in `ChannelMonitor` and DRY tests
Matt Corallo [Mon, 18 Apr 2022 15:42:11 +0000 (15:42 +0000)]
Ensure all HTLCs for a claimed payment are claimed on startup
While the HTLC-claim process happens across all MPP parts under one
lock, this doesn't imply that they are claimed fully atomically on
disk. Ultimately, an application can crash after persisting one
`ChannelMonitorUpdate` out of multiple monitor updates needed for
the full claim.
Previously, this would leave us in a very bad state - because of
the all-channels-available check in `claim_funds` we'd refuse to
claim the payment again on restart (even though the
`PaymentReceived` event will be passed to the user again), and we'd
end up having partially claimed the payment!
The fix for the consistency part of this issue is pretty
straightforward - just check for this condition on startup and
complete the claim across all channels/`ChannelMonitor`s if we
detect it.
This still leaves us in a confused state from the perspective of
the user, however - we've actually claimed a payment but when they
call `claim_funds` we return `false` indicating it could not be
claimed.
Matt Corallo [Tue, 24 May 2022 22:02:15 +0000 (22:02 +0000)]
Correct bogus references to `revocation_point` in `ChannelMonitor`
The `ChannelMonitor` had a field for the counterparty's
`cur_revocation_points`. Somewhat confusingly, this actually stored
the counterparty's *per-commitment* points, not the (derived)
revocation points.
Here we correct this by simply renaming the references as
appropriate. Note the update in `channel.rs` makes the variable
names align correctly.
Matt Corallo [Thu, 19 May 2022 00:56:16 +0000 (00:56 +0000)]
Rename HTLC `onchain_value_satoshis` to `htlc_value_satoshis`
In `HTLCUpdate` and `OnchainEvent` tracking, we store the HTLC
value (rounded down to whole satoshis). This is somewhat
confusingly referred to as the `onchain_value_satoshis` even though
it refers to the commitment transaction output value, not the value
available on chain (which may have been reduced by an
HTLC-Timeout/HTLC-Success transaction).
Matt Corallo [Fri, 20 May 2022 01:42:06 +0000 (01:42 +0000)]
DRY SpendableOutput tests in `monitor_tests.rs`
Jeffrey Czyz [Wed, 25 May 2022 21:40:00 +0000 (16:40 -0500)]
Merge pull request #1155 from arik-so/graph_sync_crate
Introduce graph sync crate
Jeffrey Czyz [Wed, 25 May 2022 21:26:51 +0000 (16:26 -0500)]
Merge pull request #1478 from mattfaltyn/issue1462
Document `lightning` crate features
Arik Sosman [Wed, 3 Nov 2021 17:50:08 +0000 (10:50 -0700)]
Introduce graph sync crate for fast-forwarding through gossip data downloaded from a server.
Mateusz Faltyn [Tue, 24 May 2022 23:21:29 +0000 (16:21 -0700)]
Document lightning crate features
Matt Corallo [Sun, 24 Apr 2022 20:30:50 +0000 (20:30 +0000)]
Rename HTLC `input_idx` fields to `commitment_tx_output_idx`
Several fields used in tracking on-chain HTLC outputs were
named `input_idx` despite referring to the output index in the
commitment transaction. Here they are all renamed
`commitment_tx_output_idx` for clarity.
Jeffrey Czyz [Mon, 23 May 2022 05:16:04 +0000 (00:16 -0500)]
Merge pull request #1490 from arik-so/rust_beta_doc_fix
Fix rust beta docs for lightning-invoice crate.
Arik Sosman [Fri, 20 May 2022 18:20:55 +0000 (11:20 -0700)]
Merge pull request #1492 from tnull/2022-05-fix-bolts-url
Docs: Update to 'new' spec repository URL.
Arik Sosman [Fri, 20 May 2022 17:56:10 +0000 (10:56 -0700)]
Merge pull request #1456 from jkczyz/2022-04-effective-capacity
Use `EffectiveCapacity` in `Score` trait
Arik Sosman [Thu, 19 May 2022 17:07:35 +0000 (10:07 -0700)]
Fix rust beta docs lightning-invoice crate.
Elias Rohrer [Fri, 20 May 2022 15:17:29 +0000 (17:17 +0200)]
Use new spec repository URL.
Jeffrey Czyz [Wed, 27 Apr 2022 20:55:33 +0000 (15:55 -0500)]
Score without uncertainty for exact liquidity
For direct channels, the channel liquidity is known with certainty. Use
this knowledge in ProbabilisticScorer by either penalizing with the
per-hop penalty or u64::max_value depending on the amount.
Jeffrey Czyz [Fri, 22 Apr 2022 13:21:18 +0000 (08:21 -0500)]
Pass effective capacity to scorer
Scorers could benefit from having the channel's EffectiveCapacity rather
than a u64 msat value. For instance, ProbabilisticScorer can give a more
accurate penalty when given the ExactLiquidity variant. Pass a struct
wrapping the effective capacity, the proposed amount, and any in-flight
HTLC value.
Jeffrey Czyz [Tue, 17 May 2022 21:57:55 +0000 (16:57 -0500)]
Use correct penalty and CLTV delta in route hints
For route hints, the aggregate next hops path penalty and CLTV delta
should be computed after considering each hop rather than before.
Otherwise, these aggregate values will include values from the current
hop, too.
Jeffrey Czyz [Tue, 17 May 2022 21:43:36 +0000 (16:43 -0500)]
Use the correct amount when scoring route hints
When scoring route hints, the amount passed to the scorer should include
any fees needed for subsequent hops. This worked correctly for single-
hop hints since there are no further hops, but not for multi-hint hops
(except the final one).
Jeffrey Czyz [Sun, 23 Jan 2022 23:25:38 +0000 (17:25 -0600)]
Distinguish maximum HTLC from effective capacity
Using EffectiveCapacity in scoring gives more accurate success
probabilities when the maximum HTLC value is less than the channel
capacity. Change EffectiveCapacity to prefer the channel's capacity
over its maximum HTLC limit, but still use the latter for route finding.
Matt Corallo [Wed, 4 May 2022 17:49:09 +0000 (17:49 +0000)]
Store an `events::PaymentPurpose` with each claimable payment
In
fc77c57c3c6e165d26cb5c1f5d1afee0ecd02589 we stopped using the
`FInalOnionHopData` in `OnionPayload::Invoice` directly and intend
to remove it eventually. However, in the next few commits we need
access to the payment secret when claimaing a payment, as we create
a new `PaymentPurpose` during the claim process for a new event.
In order to get access to a `PaymentPurpose` without having access
to the `FinalOnionHopData` we here change the storage of
`claimable_htlcs` to store a single `PaymentPurpose` explicitly
with each set of claimable HTLCs.
Matt Corallo [Wed, 4 May 2022 16:29:29 +0000 (16:29 +0000)]
Enable removal of `OnionPayload::Invoice::_legacy_hop_data` later
In
fc77c57c3c6e165d26cb5c1f5d1afee0ecd02589 we stopped using the
`FinalOnionHopData` in `OnionPayload::Invoice` directly and renamed
it `_legacy_hop_data` with the intent of removing it in a few
versions. However, we continue to check that it was included in the
serialized data, meaning we would not be able to remove it without
breaking ability to serialize full `ChannelManager`s.
This fixes that by making the `_legacy_hop_data` an `Option` which
we will happily handle just fine if its `None`.
Jeffrey Czyz [Thu, 5 May 2022 21:19:40 +0000 (16:19 -0500)]
PathBuildingHop::value_contribution_msat in Debug
Matt Corallo [Wed, 18 May 2022 19:22:42 +0000 (19:22 +0000)]
Merge pull request #1476 from tnull/2022-05-maximum-path-length
Consider maximum path length during path finding.
Elias Rohrer [Wed, 18 May 2022 16:50:43 +0000 (18:50 +0200)]
Consider maximum path length during path finding.
Matt Corallo [Sun, 15 May 2022 19:13:43 +0000 (19:13 +0000)]
Randomize the `ConnectStyle` during tests
We have a bunch of fancy infrastructure to ensure we can connect
blocks using all our different connection interfaces, but we only
bother to use it in a few select tests.
This expands our use of `ConnectStyle` to most of our tests by
simply randomizing the style in each test. This makes our tests
non-deterministic, but we print the connection style at start so
that it's easy to reproduce a failure deterministically.
Matt Corallo [Sun, 15 May 2022 19:38:01 +0000 (19:38 +0000)]
Make tests more robust against different connection styles
In the next commit we'll randomize the `ConnectStyle` used in each
test. However, some tests are slightly too prescriptive, which we
address here in a few places.
Matt Corallo [Sun, 15 May 2022 19:03:45 +0000 (19:03 +0000)]
Add new block `ConnectionStyle`s for `transaction_unconfirmed`
Previously `transaction_unconfirmed` was never called in tests!
valentinewallace [Tue, 17 May 2022 20:10:09 +0000 (16:10 -0400)]
Merge pull request #1472 from TheBlueMatt/2022-06-less-secp-ctx
Pull secp256k1 contexts from per-peer to per-PeerManager
Matt Corallo [Tue, 17 May 2022 17:32:46 +0000 (17:32 +0000)]
Merge pull request #1418 from bruteforcecat/timeout-outbound-paymnet-retires-instead-of-count-out
add timeout retry strategy to outbound payment
KaFai Choi [Sat, 14 May 2022 02:52:38 +0000 (09:52 +0700)]
add timeout retry strategy to outbound payment
Matt Corallo [Mon, 16 May 2022 21:48:51 +0000 (21:48 +0000)]
Merge pull request #1485 from ViktorTigerstrom/2022-05-add-force-close-param
Add missing `counterparty_node_id` in `force_close_channel` calls
Viktor Tigerström [Mon, 16 May 2022 20:25:46 +0000 (22:25 +0200)]
Add missing `counterparty_node_id` in `force_close_channel` calls
Arik Sosman [Mon, 16 May 2022 19:44:16 +0000 (12:44 -0700)]
Merge pull request #1479 from ViktorTigerstrom/2022-05-pass-counterparty-id-to-functions
Pass `counterparty_node_id` to `ChannelManager` functions
valentinewallace [Mon, 16 May 2022 18:21:39 +0000 (14:21 -0400)]
Merge pull request #1475 from atalw/2022-04-paymentforwarded-event
Expose `next_channel_id` in `PaymentForwarded` event
Matt Corallo [Sun, 15 May 2022 18:47:32 +0000 (18:47 +0000)]
Store full blocks in the test blockchain tracker instead of headers
atalw [Fri, 22 Apr 2022 07:03:18 +0000 (12:33 +0530)]
Add `next_channel_id` in `PaymentForwarded` event
This update also includes a minor refactor. The return type of
`pending_monitor_events` has been changed to a `Vec` tuple with the
`OutPoint` type. This associates a `Vec` of `MonitorEvent`s with a
funding outpoint.
We've also renamed `source/sink_channel_id` to `prev/next_channel_id` in
the favour of clarity.
Matt Corallo [Sat, 14 May 2022 19:35:47 +0000 (19:35 +0000)]
Merge pull request #1429 from TheBlueMatt/2022-04-drop-no-conn-possible
Viktor Tigerström [Fri, 13 May 2022 21:52:20 +0000 (23:52 +0200)]
Update `OpenChannelRequest` documentation
As the `counterparty_node_id` is now required to be passed back to the
`ChannelManager` to accept or reject an inbound channel request, the
documentation is updated to reflect that.
Viktor Tigerström [Thu, 12 May 2022 22:13:39 +0000 (00:13 +0200)]
Pass `counterparty_node_id` to `accept_inbound_channel`
Viktor Tigerström [Thu, 12 May 2022 21:59:41 +0000 (23:59 +0200)]
Pass `counterparty_node_id` to `funding_transaction_generated`
Viktor Tigerström [Thu, 12 May 2022 21:26:32 +0000 (23:26 +0200)]
Pass `counterparty_node_id` to `force_close_channel`
Viktor Tigerström [Thu, 12 May 2022 20:31:29 +0000 (22:31 +0200)]
Pass `counterparty_node_id` to `close_channel` functions
KaFai Choi [Mon, 18 Apr 2022 03:32:13 +0000 (10:32 +0700)]
move Time trait from scoring mod to util::time and set it visibile within crate
Viktor Tigerström [Fri, 13 May 2022 21:43:25 +0000 (23:43 +0200)]
Add `counterparty_node_id` to `FundingGenerationReady`
Jeffrey Czyz [Fri, 13 May 2022 17:20:56 +0000 (12:20 -0500)]
Merge pull request #1480 from tnull/2022-05-fix-test-warnings
Fix unused code warnings test.
Elias Rohrer [Fri, 13 May 2022 16:03:51 +0000 (18:03 +0200)]
Fix unused code warnings.
Matt Corallo [Mon, 9 May 2022 23:03:50 +0000 (23:03 +0000)]
Pull secp256k1 contexts from per-peer to per-PeerManager
Instead of including a `Secp256k1` context per
`PeerChannelEncryptor`, which is relatively expensive memory-wise
and nontrivial CPU-wise to construct, we should keep one for all
peers and simply reuse it.
This is relatively trivial so we do so in this commit.
Since its trivial to do so, we also take this opportunity to
randomize the new PeerManager context.
Matt Corallo [Wed, 11 May 2022 17:24:16 +0000 (17:24 +0000)]
Merge pull request #1023 from TheBlueMatt/2021-07-par-gossip-processing
Matt Corallo [Wed, 11 May 2022 16:12:15 +0000 (16:12 +0000)]
Merge pull request #1477 from dunxen/2022-05-invoice-expiry-nits
Duncan Dean [Wed, 11 May 2022 08:57:38 +0000 (10:57 +0200)]
Address post-ACK formatting nits from #1474
Matt Corallo [Tue, 12 Apr 2022 19:19:00 +0000 (19:19 +0000)]
Add a few more simple tests of the PeerHandler
These increase coverage and caught previous lockorder inversions.
Matt Corallo [Tue, 12 Apr 2022 19:16:38 +0000 (19:16 +0000)]
Add support for testing recvd messages in TestChannelMessageHandler
Matt Corallo [Tue, 12 Apr 2022 19:05:15 +0000 (19:05 +0000)]
Require `PartialEq` for `wire::Message` in `cfg(test)`
...and implement wire::Type for `()` for `feature = "_test_utils"`.
Matt Corallo [Mon, 11 Apr 2022 17:34:11 +0000 (17:34 +0000)]
Drop a needless match in favor of an `if let`
Matt Corallo [Tue, 22 Mar 2022 21:03:41 +0000 (21:03 +0000)]
[net-tokio] Explicitly yield after processing messages from a peer
This reduces instances of disconnect peers after single timer
intervals somewhat, at least on Tokio 1.14.
Matt Corallo [Fri, 25 Feb 2022 21:57:57 +0000 (21:57 +0000)]
Drop `PeerHolder` as it now only has one field
Matt Corallo [Mon, 11 Oct 2021 05:03:45 +0000 (05:03 +0000)]
Keep the same read buffer unless the last message was overly large
This avoids repeatedly deallocating-allocating a Vec for the peer
read buffer after every message/header.
Matt Corallo [Wed, 6 Oct 2021 16:58:56 +0000 (16:58 +0000)]
Create a simple `FairRwLock` to avoid readers starving writers
Because we handle messages (which can take some time, persisting
things to disk or validating cryptographic signatures) with the
top-level read lock, but require the top-level write lock to
connect new peers or handle disconnection, we are particularly
sensitive to writer starvation issues.
Rust's libstd RwLock does not provide any fairness guarantees,
using whatever the OS provides as-is. On Linux, pthreads defaults
to starving writers, which Rust's RwLock exposes to us (without
any configurability).
Here we work around that issue by blocking readers if there are
pending writers, optimizing for readable code over
perfectly-optimized blocking.
Matt Corallo [Sun, 3 Oct 2021 21:44:52 +0000 (21:44 +0000)]
Wake reader future when we fail to flush socket buffer
This avoids any extra calls to `read_event` after a write fails to
flush the write buffer fully, as is required by the PeerManager
API (though it isn't critical).
Matt Corallo [Wed, 6 Oct 2021 04:45:07 +0000 (04:45 +0000)]
Limit blocked PeerManager::process_events waiters to two
Only one instance of PeerManager::process_events can run at a time,
and each run always finishes all available work before returning.
Thus, having several threads blocked on the process_events lock
doesn't accomplish anything but blocking more threads.
Here we limit the number of blocked calls on process_events to two
- one processing events and one blocked at the top which will
process all available events after the first completes.
Matt Corallo [Wed, 6 Oct 2021 06:10:01 +0000 (06:10 +0000)]
Avoid the peers write lock unless we need it in timer_tick_occurred
Similar to the previous commit, this avoids "blocking the world" on
every timer tick unless we need to disconnect peers.
Matt Corallo [Sat, 25 Sep 2021 22:24:23 +0000 (22:24 +0000)]
Avoid taking the peers write lock during event processing
Because the peers write lock "blocks the world", and happens after
each read event, always taking the write lock has pretty severe
impacts on parallelism. Instead, here, we only take the global
write lock if we have to disconnect a peer.
Matt Corallo [Wed, 6 Oct 2021 04:29:19 +0000 (04:29 +0000)]
[net-tokio] Call PeerManager::process_events without blocking reads
Unlike very ancient versions of lightning-net-tokio, this does not
rely on a single global process_events future, but instead has one
per connection. This could still cause significant contention, so
we'll ensure only two process_events calls can exist at once in
the next few commits.
Matt Corallo [Wed, 6 Oct 2021 06:58:15 +0000 (06:58 +0000)]
Process messages with only the top-level read lock held
Users are required to only ever call `read_event` serially
per-peer, thus we actually don't need any locks while we're
processing messages - we can only be processing messages in one
thread per-peer.
That said, we do need to ensure that another thread doesn't
disconnect the peer we're processing messages for, as that could
result in a peer_disconencted call while we're processing a
message for the same peer - somewhat nonsensical.
This significantly improves parallelism especially during gossip
processing as it avoids waiting on the entire set of individual
peer locks to forward a gossip message while several other threads
are validating gossip messages with their individual peer locks
held.
Matt Corallo [Fri, 30 Jul 2021 18:03:28 +0000 (18:03 +0000)]
Process messages from peers in parallel in `PeerManager`.
This adds the required locking to process messages from different
peers simultaneously in `PeerManager`. Note that channel messages
are still processed under a global lock in `ChannelManager`, and
most work is still processed under a global lock in gossip message
handling, but parallelizing message deserialization and message
decryption is somewhat helpful.
Matt Corallo [Tue, 10 May 2022 23:23:57 +0000 (23:23 +0000)]
Merge pull request #1474 from dunxen/2022-05-actually-add-expiry
lightning-invoice/utils: Actually add expiry to invoices
Duncan Dean [Tue, 10 May 2022 17:01:15 +0000 (19:01 +0200)]
Add expiry to non-phantom invoice utils
Duncan Dean [Tue, 10 May 2022 16:56:02 +0000 (18:56 +0200)]
Actually add expiry to phantom invoice utils
Matt Corallo [Mon, 9 May 2022 19:11:56 +0000 (19:11 +0000)]
Merge pull request #1465 from tnull/2022-05-encode-update-type-bytes
Encode & test `channel_update` message type in failure messages.
Matt Corallo [Mon, 9 May 2022 16:29:57 +0000 (16:29 +0000)]
Merge pull request #1471 from ViktorTigerstrom/2022-05-test-disconnected-before-funding-broadcasted
Add test coverage for `ClosureReason::DisconnectedPeer`
valentinewallace [Mon, 9 May 2022 16:09:52 +0000 (12:09 -0400)]
Merge pull request #1467 from arik-so/fuzz_new_target_docs
Add documentation for creating new fuzz test targets.
Viktor Tigerström [Sun, 8 May 2022 21:45:08 +0000 (23:45 +0200)]
Add test for `ClosureReason::DisconnectedPeer`
Add test that ensures that channels are closed with
`ClosureReason::DisconnectedPeer` if the peer disconnects before the
funding transaction has been broadcasted.
Elias Rohrer [Fri, 6 May 2022 17:46:49 +0000 (19:46 +0200)]
Encode channel update type in failure messages.
Jeffrey Czyz [Thu, 5 May 2022 19:08:16 +0000 (14:08 -0500)]
Merge pull request #1389 from lightning-signer/2022-03-bitcoin
Update bitcoin crate to 0.28.1
Arik Sosman [Thu, 5 May 2022 00:34:35 +0000 (17:34 -0700)]
Add documentation for creating new fuzz test targets.