In order to avoid naming collisions with LDK's `Event` type, we rename
`lightning-liquidity`'s `Event` to `LiquidityEvent`. To minimize furhter
churn on the upcoming renaming changes, we also `impl From X for
LiquidityEvent` for the protocol-specific event variants, which also
allows us to reduce some boilerplate while enqueuing.
As we're not testing with `cfg(lsps1_service)`, the builds broke during
previous refactoring. This isn't bad as we're looking to completely
overhaul / rewrite LSPS1 service soon, but until then we fix this
pre-existing breakage to make sure following changes make sense.
Recently, LSPS0, 1, and 2 were upstreamed as bLIP-50, 51, and 52,
respectively. Here, we
1. start linking to the bLIPs instead of the LSP spec repository, which
is likely going to be deprecated.
2. start consistently citing the specs as `bLIP-5X / LSPSX` to avoid any
confusions and to potentially initiate a process in which the LSP
specs will be referred to by their bLIP number rather than their LSPS
number (especially given that any upcoming specs by the LSP
spec group will directly be drafted as bLIPs going forward).
In ecbab29386 we ran rustfmt blindly
on `lightning/src/onion_message/messenger.rs`. This exposed a few
untidy things in the file and made them worse, which we should have
cleaned up as we went.
Here we address these, removing some unnecessary generics,
condensing some lines by adding intermediate variables, and
reducing very vertical match statements.
In 3c3e93e7b5 we ran rustfmt blindly
on `lightning/src/onion_message/functional_tests.rs`. This left
the file with a handful of warts that really should have been
cleaned up as we went.
Here we take the opportunity to clean up the `peer_buffer_full`
test which used a constant for the number of messages we can push
before the buffer fills, rather than calculating the amount based
on the buffer size constant, also removing a comment that got moved
by rustfmt into a place where it was no longer understandable.
In 3c3e93e7b5 we ran rustfmt blindly
on `lightning/src/onion_message/functional_tests.rs`. This left
the file with a handful of warts that really should have been
cleaned up as we went.
Here we clean up a handful of rustfmt-isms, ranging from terrible
to somewhat ugly, introduced in `functional_tests.rs`.
In 3c3e93e7b5 we ran rustfmt blindly
on `lightning/src/onion_message/functional_tests.rs`. This left
the file with a handful of warts that really should have been
cleaned up as we went.
Here we clean up types a bit by importing structs directly and
adding a few type aliases.
It's not needed except for one place where we can just access the field
directly, so we can avoid the allocation on each call. For API
consumers, they may still access the funding script via
`ChannelMonitor::get_funding_script`.
As motivated by the previous commit, we do some of the same work here at
the `ChannelManager` level instead. Unfortunately, we still need to
track the funding outpoint to support downgrades by writing the in
flight monitor updates as two separate TLVs, one using the channel IDs,
and the other using the funding outpoints. Once we are willing to stop
supporting downgrades past this version, we can fully drop it.
Once dual funding/splicing is supported, channels will no longer
maintain their original funding outpoint. Ideally, we identify
`ChannelMonitor`s with a stable identifier, such as the channel ID,
which is fixed throughout the channel's lifetime.
This commit replaces the use of funding outpoints as the key to the
monitor index with the channel ID. Note that this is strictly done to
the in-memory state; it does not change how we track monitors within
their persisted state, they are still keyed by their funding outpoint
there. Addressing that is left for follow-up work.
If the counterparty broadcasts a revoked transaction with offered
HTLCs, the output is not immediately pinnable as the counterparty
cannot claim the HTLC until the CLTV expires and they use an
HTLC-Timeout path.
Here we properly set these packages as `Unpinnable`, changing some
transaction generation during tests.
If the counterparty broadcasts a revoked transaction with offered
HTLCs, the output is not immediately pinnable as the counterparty
cannot claim the HTLC until the CLTV expires and they use an
HTLC-Timeout path.
Here we fix the `counterparty_spendable_height` value we set on
counterparty revoked HTLC claims to match reality. Note that
because we still consider these outputs `Pinnable` the value is
not used. In the next commit we'll start making them `Unpinnable`
which will actually change behavior.
Note that when upgrading we have to wipe the
`counterparty_spendable_height` value for non-offered HTLCs as
otherwise we'd consider them `Unpinnable` when they are, in fact,
`Pinnable`.
For outbound Trampoline payments, we will need to generate onion
packets whose size matches their content. This allows them to be
included in individual hops at arbitrary positions.
A future spec change may involve defining a static size to improve
privacy from Trampoline nodes.
.. we planned to use the BP for some more advanced integration tests, but we
haven't actually implemented them as of now. Here we drop the
unnecessary dev-dependency for now.
After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when a peer reconnects.
After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when a peer disconnects.
After #3513 we have a bit more encapsulation of channel logic in
channel.rs with channelmanager.rs needing a bit less knowledge of
which specific state a channel is in.
This continues that trend slightly when unblocking the signer.
