Matt Corallo [Sun, 3 Dec 2023 20:03:51 +0000 (20:03 +0000)]
Ensure `ChannelMonitor` `Logger`s are always wrapped with metadata
In order to ensure log lines generated by `ChannelMonitor` always
have a counterparty and channel ID entry, this consistently wraps
`Logger`s in a decorator in all `pub(X)` `ChannelMonitor` functions,
removing `pub` markings on `ChannelMonitorImpl` methods that aren't
actually publicly reachable anyway.
This also lets us clean up the `Logger` types in various
`ChannelMonitor` methods.
Jeffrey Czyz [Wed, 29 Nov 2023 16:51:33 +0000 (10:51 -0600)]
Refactor ChainMonitor::update_channel error case
Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.
Jeffrey Czyz [Tue, 21 Nov 2023 16:47:12 +0000 (10:47 -0600)]
Add semantics to logger::Records
Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.
Set HTLCPreviousHopData::blinded on intro node forward.
Useful so we know to fail back blinded HTLCs where we are the intro node with
the invalid_onion_blinding error per BOLT 4.
We don't set this field for blinded received HTLCs because we don't support
receiving to multi-hop blinded paths yet, and there's no point in setting it
for HTLCs received to 1-hop blinded paths because per the spec they should fail
back using an unblinded error code.
A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.
A blinding point is provided in update_add_htlc messages if we are relaying or
receiving a payment within a blinded path, to decrypt the onion routing packet
and the recipient-provided encrypted payload within. Will be used in upcoming
commits.
Arik Sosman [Mon, 28 Aug 2023 23:06:41 +0000 (16:06 -0700)]
Move ECDSA-specific signers into ecdsa.rs
To separate out the logic in the `sign` module, which will start to be
convoluted with multiple signer types, we're splitting out each signer
type into its own submodule, following the taproot.rs example from a
previous commit.
Arik Sosman [Mon, 6 Nov 2023 05:51:15 +0000 (21:51 -0800)]
Reparametrize ChannelSignerType by SignerProvider.
ChannelSignerType is an enum that contains variants of all currently
supported signer types. Given that those signer types are enumerated
as associated types in multiple places, it is prudent to denote one
type as the authority on signer types.
SignerProvider seemed like the best option. Thus, instead of
ChannelSignerType declaring the associated types itself, it simply
uses their definitions from SignerProvider.
Arik Sosman [Mon, 6 Nov 2023 05:36:59 +0000 (21:36 -0800)]
Add TaprootSigner variant to SignerProvider.
Previously, SignerProvider was not laid out to support multiple signer
types. However, with the distinction between ECDSA and Taproot signers,
we now need to account for SignerProviders needing to support both.
This approach does mean that if ever we introduced another signer type
in the future, all implementers of SignerProvider would need to add it
as an associated type, and would also need to write a set of dummy
implementations for any Signer trait they do not wish to support.
For the time being, the TaprootSigner associated type is cfg-gated.
Arik Sosman [Sun, 7 May 2023 04:13:53 +0000 (21:13 -0700)]
Introduce TaprootSigner trait.
For Taproot support, we need to define an alternative trait to
EcdsaChannelSigner. This trait will be implemented by all signers
that wish to support Taproot channels.
Matt Corallo [Thu, 9 Nov 2023 04:14:15 +0000 (04:14 +0000)]
Handle missing case in reestablish local commitment number checks
If we're behind exactly one commitment (which we've revoked), we'd
previously force-close the channel, guaranteeing we'll lose funds
as the counterparty has our latest local commitment state's
revocation secret.
While this shouldn't happen because users should never lose data,
sometimes issues happen, and we should ensure we always panic.
Further, `test_data_loss_protect` is updated to test this case.
Matt Corallo [Thu, 9 Nov 2023 03:28:45 +0000 (03:28 +0000)]
Clean up error messages and conditionals in reestablish handling
When we reestablish there are generally always 4 conditions for
both local and remote commitment transactions:
* we're stale and have possibly lost data
* we're ahead and the peer has lost data
* we're caught up
* we're nearly caught up and need to retransmit one update.
In especially the local commitment case we had a mess of different
comparisons, which is improved here. Further, the error messages
are clarified and include more information.
Matt Corallo [Mon, 27 Nov 2023 21:37:42 +0000 (21:37 +0000)]
Add `channel_keys_id` to `SpendableOutputDescriptor::StaticOutput`
In 7f0fd868ad4e8072440f1eb79e78894de1629157, `channel_keys_id` was
added as an argument to `SignerProvider::get_destination_script`,
allowing implementors to generate a new script for each channel.
This is great, however users then have no way to re-derive the
corresponding private key when they ultimately receive a
`SpendableOutputDescriptor::StaticOutput`. Instead, they have to
track all the addresses as they derive them separately. In many
cases this is fine, but we should support both deployments, which
we do here by simply including the missing `channel_keys_id` for
the user.
olegkubrakov [Tue, 14 Nov 2023 18:08:25 +0000 (10:08 -0800)]
Implement struct wrappers for channel key types to avoid confusion.
Currently all channel keys and their basepoints exist uniformly as
`PublicKey` type, which not only makes in harder for a developer to
distinguish those entities, but also does not engage the language
type system to check if the correct key is being used in any
particular function.
Having struct wrappers around keys also enables more nuanced
semantics allowing to express Lightning Protocol rules in language.
For example, the code allows to derive `HtlcKey` from
`HtlcBasepoint` and not from `PaymentBasepoint`.
This change is transparent for channel monitors that will use the
internal public key of a wrapper.
Payment, DelayedPayment, HTLC and Revocation basepoints and their
derived keys are now wrapped into a specific struct that make it
distinguishable for the Rust type system. Functions that require a
specific key or basepoint should not use generic Public Key, but
require a specific key wrapper struct to engage Rust type
verification system and make it more clear for developers which
key is used.
Matt Corallo [Sun, 26 Nov 2023 19:09:06 +0000 (19:09 +0000)]
Remove now-redundant checks in BOLT12 `Invoice` fallback addresses
Now that we use the `rust-bitcoin` `WitnessProgram` to check our
addresses, we can just rely on it, rather than checking the program
length and version.
Matt Corallo [Sun, 26 Nov 2023 19:07:10 +0000 (19:07 +0000)]
Drop panic if `rust-bitcoin` adds a new `Network`
`rust-bitcoin` 0.30 added `#[non_exhaustive]` to the `Network`
enum, allowing them to "add support" for a new network type without
a major version change in the future. When upgrading, we added a
simple `unreachable` for the general match arm, which would break
in a minor version change of `rust-bitcoin`.
While it seems [possible rust-bitcoin will change
this](https://github.com/rust-bitcoin/rust-bitcoin/issues/2225),
we still shouldn't ba panicking, which we drop here in favor of a
`debug_assert`ion, and a default value.
shaavan [Tue, 21 Nov 2023 14:41:46 +0000 (20:11 +0530)]
Explicitly reject routes that double-back
- If a path within a route passes through the same channelID twice,
that shows the path is looped and will be rejected by nodes.
- Add a check to explicitly reject such payment before trying to send
them.
Matt Corallo [Mon, 13 Nov 2023 22:50:40 +0000 (22:50 +0000)]
`derive(Hash)` for P2P messages
In other languages (Java and C#, notably), overriding `Eq` without
overriding `Hash` can lead to surprising or broken behavior. Even
in Rust, its usually the case that you actually want both. Here we
add missing `Hash` derivations for P2P messages, to at least
address the first pile of warnings the C# compiler dumps.
Matt Corallo [Mon, 13 Nov 2023 22:48:48 +0000 (22:48 +0000)]
Rely on const generic big arrays for `PartialEq` in msgs
Implementation of standard traits on arrays longer than 32 elements
was shipped in rustc 1.47, which is below our MSRV of 1.48 and we
can use to remove some unnecessary manual implementation of
`PartialEq` on `OnionPacket`.
Matt Corallo [Sat, 26 Aug 2023 19:59:21 +0000 (19:59 +0000)]
Don't send init `closing_signed` too early after final HTLC removal
If we remove an HTLC (or fee update), commit, and receive our
counterparty's `revoke_and_ack`, we remove all knowledge of said
HTLC (or fee update). However, the latest local commitment
transaction that we can broadcast still contains the HTLC (or old
fee), thus we are not eligible for initiating the `closing_signed`
negotiation if we're shutting down and are generally expecting a
counterparty `commitment_signed` immediately.
Because we don't have any tracking of these updates in the `Channel`
(only the `ChannelMonitor` is aware of the HTLC being in our latest
local commitment transaction), we'd previously send a
`closing_signed` too early, causing LDK<->LDK channels with an HTLC
pending towards the channel initiator at the time of `shutdown` to
always fail to cooperatively close.
To fix this race, we add an additional unpersisted bool to
`Channel` and use that to gate sending the initial `closing_signed`.
Matt Corallo [Tue, 31 Oct 2023 18:39:04 +0000 (18:39 +0000)]
Drop non-anchor channel fee upper bound limit entirely
Quite a while ago we added checks for the total current dust
exposure on a channel to explicitly limit dust inflation attacks.
When we did this, we kept the existing upper bound on the channel's
feerate in place. However, these two things are redundant - the
point of the feerate upper bound is to prevent dust inflation, and
it does so in a crude way that can cause spurious force-closures.
Here we simply drop the upper bound entirely, relying on the dust
inflation limit to prevent dust inflation instead.