We generally allow routing nodes to forward less than the expected HTLC
amount, if the receiver knowingly accepts this and claims the
underpaying HTLC (see `ChannelConfig::accept_underpaying_htlcs`). This
use case is in particular useful for the LSPS2/JIT channel setting where
the intial underpaying HTLC pays for the channel open.
While we previously exposed the withheld amount as
`PaymentClaimable::counterparty_skimmed_fee_msat` on the receiver side,
we did not individually provide it on the forwarding node's side.
Here, we therefore expose this additionally withheld amount via
`PaymentForwarded::skimmed_fee_msat`.
- The first test make sure that the OutboundV1Channel is not
immediately removed when peers disconnect, but is removed after N timer
ticks.
- The second test makes sure that the SendOpenChannel is rebroadcasted
for the OutboundV1Channel if peer reconnects within time.
- Do not remove channel immediately when peer_disconnect, instead
removed it after some time if peer doesn't reconnect soon (handled in
previous commit).
- Do not mark per ok_to_remove if we have some OutboundV1Channels too.
- Rebroadcast SendOpenChannel for outboundV1Channel when peer
reconnects.
- Update the relevant tests to account for the behavior change.
- Repurpose the test_disconnect_in_funding_batch to test that all
channels in the batch close when one them closes.
In 26c1639ab6 (and later in
50c55dcf32) we switched to using
`Default::default()` to initialize `()` for scoring parameters in
tests. A number of `()`s slipped back in recently, which we replace
here.
The top-level module is only a few hundred lines, so there's not a
lot of reason to hide the `GraphSyncError` in its own module.
Instead, we simply move it to the top-level `lib.rs`, which doesn't
change the public API as it was previously re-exported at the top
level.
...as an arg to `Router`. Passing an `EntropySource` around all
the time is a bit strange as the `Router` may or may not actually
use it, and the `DefaultRouter` can just as easily store it.
In `three_hop_blinded_path_success`, the nodes in the test ended up
at radically different block heights after channel opening. At that
point, if the CLTV randomization is done slightly different the
test payment may fail, which we fix here by ensuring all nodes are
at the same height before we go to send a payment.
To avoid confusion and for accuracy going forward, we remove this method
as it is inconsistent with channel IDs generated during V2 channel
establishment. If one wants to create a V1, funding outpoint-based
channel ID, then `ChannelId::v1_from_funding_outpoint` should be used
instead.
A large portion of the library has always made the assumption that having
the funding outpoint will always allow us to generate the channel ID.
This will not be the case anymore and we need to pass the channel ID along
where appropriate. All channels that could have been persisted up to this
point could only have used V1 establishment, so if some structures don't
store a channel ID for them they can safely fall back to the funding
outpoint-based version.
The bindings cannot express lifetimes, so exposing any field which
is a reference (and not `clone`-able, at least for garbage
collected language bindings) is unsafe for those expecting a
high-level interface.
Thus, we simply no-export the `RouteHopCandidate` inner struct
fields which are references (there are relevant accessors for them
anyway).
There's not a lot of reason for downstream users to use the
`WithContext` wrapper, it mostly exists for our own downstream
crates anyway, and dealing with lifetimes in bindings isn't super
practical, so simply no-export it.
Because log `Record`s are now being passed by ownership to `log`,
the bindings get quite annoyed that there's a lifetime hanging
around. We already don't use this lifetime in bindings (the
`FormatArgs` is converted to a string and stored on the heap), so
we can just drop the lifetime, even though it requires some
macro'ing of the struct definition to do so.
Peer::their_node_id is set to Some during the handshake process.
However, df3ab2ee27 accesses the field
unconditionally, causing a panic. This may be triggered if a gossip
message is received mid-handshake from another peer or if the user calls
broadcast_node_announcement during this time. The latter tends to be
executed on a timer.
Ensure that Peer::their_node_id is only accessed once the handshake is
complete.
When handling calls to `batch_funding_transaction_generated` which
were missing outputs for one of the batch channels, we'd previously
deadlock when trying to clean up the now-closed channels. This
fixes that and adds a new test case for it.
Found by the full_stack_target fuzzer.
