We only use it to check the amount when processing MPP parts, but
store the full object (including new payment metadata) in it.
Because we now store the amount in the parent structure, there is
no need for it at all in the `OnionPayload`. Sadly, for
serialization compatibility, we need it to continue to exist, at
least temporarily, but we can avoid populating the new fields in
that case.
...instead of accessing it via the `OnionPayload::Invoice` form.
This may be useful if we add MPP keysend support, but is directly
useful to allow us to drop `FinalOnionHopData` from `OnionPayload`.
The `chain::Listen` interface provides a block-connection-based
alternative to the `chain::Confirm` interface, which supports
providing transaction data at a time separate from the block
connection time.
For users who are downloading the full headers tree (e.g. from a
node over the Bitcoin P2P protocol) but who are not downloading
full blocks (e.g. because they're using BIP 157/158 filtering)
there is no API that matches exactly their event stream -
`chain::Listen` requries full blocks for each block,
`chain::Confirm` requires breaking each connection event into two
calls.
Given its incredibly trivial to take a `TransactionData` in
addition to a `Block` in `chain::Listen` we do so here, adding a
default-implementation `block_connected` which simply creates the
`TransactionData`, which ultimately all of the `chain::Listen`
implementations currently do anyway.
Closes#1128.
`ChannelDetails::outbound_capacity_msat` describes the total amount
available for sending across several HTLCs, basically just our
balance minus the reserve value maintained by our counterparty.
However, when routing we use it to guess the maximum amount we can
send in a single additional HTLC, which it is not.
There are numerous reasons why our balance may not match the amount
we can send in a single HTLC, whether the HTLC in-flight limit, the
channe's HTLC maximum, or our feerate buffer.
This commit splits the `outbound_capacity_msat` field into two -
`outbound_capacity_msat` and `outbound_htlc_limit_msat`, setting us
up for correctly handling our next-HTLC-limit in the future.
This also addresses the first of the reasons why the values may
not match - the max-in-flight limit. The inaccuracy is ultimately
tracked as #1126.
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.
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.
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.
Failing an HTLC with onion error channel_disabled requires encoding a 'flags' field into the failure
packet. However, we were encoding this 'flags' field for all failures packets that were failing on
update_add_htlc with an update (error 0x1000 UPDATE).
Discovered in the course of adding phantom payment failure tests, which also added testing for this bug
In any place where fail_htlc_backwards_internal was called for a phantom payment
failure, we weren't encoding the onion failure as if the phantom were the one
failing. Instead, we were encoding the failure as if it were coming from the
second-to-last hop. This caused our failures to not be parsed properly on the
payer's side.
Places we were encoding failures incorrectly include:
* on failure of a call to inbound_payment::verify
* on a user call to fail_htlc_backwards
Also drop some unnecessary panics when reading OnionHopData objects. This also
enables one of the phantom failure tests because we can construct OnionHopDatas
with invalid amounts.
Lastly, remove a bogus comment
