Jeffrey Czyz [Thu, 9 Jun 2022 20:17:01 +0000 (15:17 -0500)]
Define NodeAlias struct and Display impl
Provide a wrapper struct for 32-byte node aliases, which implements
Display for printing. Support the UTF-8 character encoding, but replace
control characters and terminate at the first null character. Fall back
to ASCII if the byte sequence is an invalid encoding.
Antoine Riard [Thu, 9 Jun 2022 21:31:04 +0000 (17:31 -0400)]
Check if funding transaction is final for propagation
If the funding transaction is timelocked beyond the next block of
our best known chain tip, return an APIError instead of silently
failing at broadcast attempt.
Elias Rohrer [Fri, 10 Jun 2022 08:45:57 +0000 (10:45 +0200)]
Check release build profile in CI
So far, CI did not check the code in the `release` build profile, which
could result in some things not getting caught. To fix this, we now
implement a new CI job that runs checks in the `release` profile.
Wilmer Paulino [Thu, 9 Jun 2022 21:01:56 +0000 (14:01 -0700)]
Introduce LegacyChannelConfig to remain backwards compatible
ChannelConfig now has its static fields removed. We introduce a new
LegacyChannelConfig struct that maintains the serialization as
previously defined by ChannelConfig to remain backwards compatible with
clients running 0.0.107 and earlier.
Wilmer Paulino [Wed, 8 Jun 2022 22:40:58 +0000 (15:40 -0700)]
Move commit_upfront_shutdown_pubkey to ChannelHandshakeConfig
As like the previous commit, `commit_upfront_shutdown_pubkey` is another
static field that cannot change after the initial channel handshake. We
therefore move it out from its existing place in `ChannelConfig`.
Wilmer Paulino [Thu, 9 Jun 2022 23:11:15 +0000 (16:11 -0700)]
Move announced_channel to ChannelHandshakeConfig
In the near future, we plan to allow users to update their
`ChannelConfig` after the initial channel handshake. In order to reuse
the same struct and expose it to users, we opt to move out all static
fields that cannot be updated after the initial channel handshake.
Jeffrey Czyz [Thu, 2 Jun 2022 21:48:32 +0000 (14:48 -0700)]
Support only one GossipSync in BackgroundProcessor
BackgroundProcessor can take an optional P2PGossipSync and an optional
RapidGossipSync, but doing so may be easy to misuse. Each has a
reference to a NetworkGraph, which could be different between the two,
but only one is actually used.
Instead, allow passing one object wrapped in a GossipSync enum. Also,
fix a bug where the NetworkGraph is not persisted on shutdown if only a
RapidGossipSync is given.
Jeffrey Czyz [Fri, 3 Jun 2022 05:59:14 +0000 (22:59 -0700)]
Implement EventHandler for NetworkGraph
Instead of implementing EventHandler for P2PGossipSync, implement it on
NetworkGraph. This allows RapidGossipSync to handle events, too, by
delegating to its NetworkGraph.
Jeffrey Czyz [Sat, 4 Jun 2022 04:35:37 +0000 (21:35 -0700)]
Parameterize NetworkGraph with Logger
P2PGossipSync logs before delegating to NetworkGraph in its
EventHandler. In order to share this handling with RapidGossipSync,
NetworkGraph needs to take a logger so that it can implement
EventHandler instead.
Jeffrey Czyz [Fri, 3 Jun 2022 04:37:59 +0000 (21:37 -0700)]
Move Secp256k1 context to NetworkGraph
P2PGossipSync has a Secp256k1 context field, which it only uses to pass
to NetworkGraph methods. Move the field to NetworkGraph so other callers
don't need to pass in a Secp256k1 context.
Jeffrey Czyz [Wed, 1 Jun 2022 17:28:34 +0000 (10:28 -0700)]
Rename NetGraphMsgHandler to P2PGossipSync
NetGraphMsgHandler implements RoutingMessageHandler to handle gossip
messages defined in BOLT 7 and maintains a view of the network by
updating NetworkGraph. Rename it to P2PGossipSync, which better
describes its purpose, and to contrast with RapidGossipSync.
Jeffrey Czyz [Fri, 5 Nov 2021 17:55:25 +0000 (12:55 -0500)]
Rename ChannelClosed to ChannelFailure
A NetworkUpdate indicating ChannelClosed actually corresponds to a
channel failure as described in BOLT 4:
0x2000 (NODE): node failure (otherwise channel)
Rename the enum variant to ChannelFailure and rename NetworkGraph
methods close_channel_from_update and fail_node to channel_failed and
node_failed, respectively.
Arik Sosman [Wed, 1 Jun 2022 22:26:07 +0000 (15:26 -0700)]
Indicate ongoing rapid sync to background processor.
Create a wrapper struct for rapid gossip sync that can be passed to
BackgroundProcessor's start method, allowing it to only start pruning
the network graph upon rapid gossip sync's completion.
Matt Corallo [Thu, 2 Jun 2022 03:37:16 +0000 (03:37 +0000)]
Do not panic on early tx broadcasts in fuzzing
If the user broadcasts a funding transaction before the
counterparty provides a `funding_signed` we will panic in
`check_get_channel_ready`. This is expected - the user did
something which may lead to loss of funds, and we *really* need to
let them know.
However, the fuzzer can do this and we shouldn't treat it as a bug,
its a totally expected panic. Thus, we disable the panic in fuzz.
Thanks to Chaincode for providing fuzzing resources which managed
to hit this panic.
Matt Corallo [Mon, 30 May 2022 17:50:02 +0000 (17:50 +0000)]
Re-export `core2::io` or `std::io` depending on feature flags
This is useful in bindings as the `lightning::io` module is used in
the public interface, but also useful for users who want to refer
to the `io` as used in lightning irrespective of the feature flags.
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, 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 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 [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, 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.
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 [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).