As part of preparing to expose some of its methods as pub for ChannelManager-less
phantom invoice generation.
Pure code move of the module + the addition of module-level documentation
There's not a lot of reason to keep it given its used in one place
outside of tests, and this lets us clean up some of the byte_utils
calls that are still lying around.
When we fail an HTLC which was destined for a channel that the HTLC
sender didn't know the real SCID for, we should ensure we continue
to use the alias in the channel_update we provide them. Otherwise
we will leak the channel's real SCID to HTLC senders.
This reduces unwraps in channelmanager by a good bit, providing
robustness for the upcoming 0conf changes which allow SCIDs to be
missing after a channel is in use, making
`get_channel_update_for_unicast` more fallible.
This also serves as a useful refactor for the next commit,
consolidating the channel_update creation sites which are changed
in the next commit.
Because negotiating `scid_alias` for all of our channels will cause
us to create channels which LDK versions prior to 0.0.106 do not
understand, we disable `scid_alias` negotiation by default.
This does not, however, ever send the scid_alias feature bit for
outgoing channels, as that would cause the immediately prior
version of LDK to be unable to read channel data.
As we add new supported channel types, inbound channels which use
new features may cause backwards-compatibility issues for clients.
If a new channel is opened using new features while a client still
wishes to ensure support for downgrading to a previous version of
LDK, that new channel may cause the `ChannelManager` to fail
deserialization due to unsupported feature flags.
By exposing the channel type flags to the user in channel requests,
users wishing to support downgrading to previous versions of LDK
can reject channels which use channel features which previous
versions of LDK do not understand.
Type aliases are now more robustly being exported in the C bindings
generator, which requires ensuring we don't include some type
aliases which make no sense in bindings.
On connection, if our peer supports gossip queries, and we never
send a `gossip_timestamp_filter`, our peer is supposed to never
send us gossip outside of explicit queries. Thus, we'll end up
always having stale gossip information after the first few
connections we make to peers.
The solution is to send a dummy `gossip_timestamp_filter`
immediately after connecting to peers.
Its somewhat strange to have a trait method which is named after
the intended action, rather than the action that occurred, leaving
it up to the implementor what action they want to take.
Previously, if we were offline when a funding transaction was
locked in, and then we came back online, calling
`best_block_updated` once followed by `transactions_confirmed`,
we'd not generate a funding_locked until the next
`best_block_updated`.
We address this by re-calling `best_block_updated` in
`transactions_confirmed`, similar to how `ChannelMonitor` works.
As a part of adding SCID aliases to channels, we now have to accept
otherwise-redundant funding_locked messages which serve only to
update the SCID alias. Previously, we'd failt he channel as such
an update used to be bogus.
This creates an SCID alias for all of our outbound channels, which
we send to our counterparties as a part of the `funding_locked`
message and then recognize in any HTLC forwarding instructions.
Note that we generate an SCID alias for all channels, including
already open ones, even though we currently have no way of
communicating to our peers the SCID alias for already-open
channels.
New `funding_locked` messages can include SCID aliases which our
counterparty will recognize as "ours" for the purposes of relaying
transactions to us. This avoids telling the world about our
on-chain transactions every time we want to receive a payment, and
will allow for receiving payments before the funding transaction
appears on-chain.
Here we store the new SCID aliases and use them in invoices instead
of he "standard" SCIDs.
`handle_monitor_err!()` has a number of different forms depending
on which messages and actions were outstanding when the monitor
updating first failed. Instead of matching by argument count, its
much more readable to put an explicit string in the arguments to
make it easy to scan for the called form.
This makes tests slightly more realistic by delivering
`channel_update`s to `ChannelManager`s, ensuring we have
forwarding data stored locally for all channels, including public
ones.
In 2d3a210897, we increased the
default ping timer in `lightning-background-processor` to ten
seconds from five. However, we didn't change the timer count at
which we disconnect peers if they're not responding, which we
likely should have done. We do so here, as well as update the
documentation for `PeerManager::timer_tick_occurred` to suggest
always ticking the timer every ten seconds instead of five.
Its very confusing to have multiple fields that do the same thing,
one of which isn't even used for its stated purpose anymore after
the previous few commits.
There are currently two issues with
`bolt2_open_channel_sending_node_checks_part1` which counteract
each other and hide that the test isn't testing what it should be.
First of all, the final `create_channel` call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.
However, when we fix the create_channel call to panic, when we
drop `nodes[1]` after `create_channel` panics, we fail the
no-pending-messages test as it as an expeted `accept_channel` in
its outbound buffer. This causes a double-panic.
Previously, these two offset each other - instead of panicing in
`create_channel` we'd panic in the Node drop checks.
This fixes both by fetching the `accept_channel` before we go into
the panic'ing `create_channel` call (who's arguments were
corrected).
