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.
`counterparty_spendable_height` is not used outside of `package.rs`
so there's not much reason to have an accessor for it. Also, in the
next commit an issue with setting the correct value for revoked
counterparty HTLC outputs is fixed, and the upgrade path causes the
value to be 0 in some cases, making using the value in too many
places somewhat fraught.
Support more ergonomically sending payments to specific routes.
We removed the original version of this API because it was hard to work with,
but the concept of sending a payment to a specific route is still useful.
Previously, users were able to do this via manually matching the payment id in
their router, but that's cumbersome when we could just handle it internally.
