Bolt 12 details the process of picking up route hints from payee
using the lightning invoice. This PR brings the changes to use
multiple route hints from payee picked from the invoice.
The route hints are processed in the following manner:-
- `get_route()` receives the hints in `last_hops`.
- Every `RouteHintHop` in `RouteHint` is processed based on
feasiblity of channel capacity and fees.
- If a `RouteHintHop` then preceeding `RouteHintHop`s are not
processed.
- A direct route is checked from `first_hops_targets` to the
first `RouteHintHop` if the respective `RouteHint` is
processed from the payee's end till the first `RouteHintHop`.
`partial_route_hint_test`, `ignores_empty_last_hops_test`,
`multi_hint_last_hops_test` and `last_hops_with_public_channel_test`
test usage of partial route hints for building optimal route,
processing empty route hint hops, complete usage of private route
hints and presence of public channels in route hints respectively.
Resolves: #945
This is a script builder to generate anchor output ones. They can be
satisfied either by a signature for the committed funding pubkey or anyone
after CSV delay expiration.
This is used at anchor output addition while generating commitment transaction.
Latest rustc nightly compiles are filled with warnings like the
following, which we fix here:
```
warning: trailing semicolon in macro used in expression position
--> lightning/src/util/macro_logger.rs:163:114
|
163 | $logger.log(&$crate::util::logger::Record::new($lvl, format_args!($($arg)+), module_path!(), file!(), line!()));
| ^
|
::: lightning/src/chain/chainmonitor.rs:165:9
|
165 | log_debug!(self.logger, "New best block {} at height {} provided via block_connected", header.block_hash(), height);
| -------------------------------------------------------------------------------------------------------------------- in this macro invocation
|
= note: `#[warn(semicolon_in_expressions_from_macros)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
= note: this warning originates in the macro `log_internal` (in Nightly builds, run with -Z macro-backtrace for more info)
```
For users with many ChannelMonitors, we log a large volume per
block simply because each ChannelMonitor lots several times per
block. Instead, we move to log only once at the TRACE level per
block call in ChannelMonitors, relying instead on a DEBUG level
log in ChainMonitor before we call any ChannelMonitor functions.
For most users, this will reduce redundant logging and also log at
the DEBUG level for block events, which is appropriate.
Fixes#980.
This doesn't exhaustively test closing fee negotiation at all, but
ensures that it is at least basically able to come to consensus and
sign cooperative closing transactions.
Because ln::functional_tests if over 9000 LoC long, its useful to
move tests into new modules as we can. Here we move all
cooperative shutdown related tests into a new module entitled
`shutdown_tests`
This adds the new range-based closing_signed negotiation specified
in https://github.com/lightningnetwork/lightning-rfc/pull/847 as
well as cleans up the existing closing_signed negotiation to unify
the new codepaths and the old ones.
Note that because the new range-based closing_signed negotiation
allows the channel fundee to ultimately select the fee out of a
range specified by the funder, which we, of course, always select
the highest allowed amount from. Thus, we've added an extra round
of closing_signed in the common case as we will not simply accept
the first fee we see, always preferring to make the funder pay as
much as they're willing to.
When we added the support for external signing, many of the
signing functions were allowed to return an error, closing the
channel in such a case. `sign_closing_transaction` is one such
function which can now return an error, except instead of handling
it properly we'd simply never send a `closing_signed` message,
hanging the channel until users intervene and force-close it.
Piping the channel-closing error back through the various callsites
(several of which already have pending results by the time they
call `maybe_propose_first_closing_signed`) may be rather
complicated, so instead we simply attempt to propose the initial
`closing_signed` in `get_and_clear_pending_msg_events` like we do
for holding-cell freeing.
Further, since we now (possibly) generate a `ChannelMonitorUpdate`
on `shutdown`, we may need to wait for monitor updating to complete
before we can send a `closing_signed`, meaning we need to handle
the send asynchronously anyway.
This simplifies a few function interfaces and has no impact on
behavior, aside from a few message-ordering edge-cases, as seen in
the two small test changes required.
This adds a new TLV-based enum serialization macro entitled
`impl_writeable_tlv_based_enum_upgradable`. As the name implies,
the new macro allows us to ignore odd-numbered variant entries.
Because the new macro implements only `MaybeReadable` and not
`Readable`, it is not applicable in many contexts, here only being
added for the two `OnchainEvent` structs.
This makes it much simpler to deal with `MaybeReadable` types in
`Vec`s in TLVs as we can transparently deal with them as `vec`,
with the wrapper doing the Right Thing.
This requires we implement `MaybeReadable` for all `Readable` which
has some downstream implications, but nothing too bad.
We're supposed to write `Channel` to disk as if
`remove_uncommitted_htlcs_and_mark_paused` had just run, however we
were writing `last_sent_closing_fee` to disk (if it is not-None),
whereas `remove_uncommitted_htlcs_and_mark_paused` clears it.
Indeed, the BOLTs say fee "... negotiation restarts on
reconnection."
This allows decode_tlv_stream!() to be called with either a mutable
reference to a stream or a stream itself and allows
encode_tlv_stream!() to be called with an excess , at the end of
the parameter list.
We don't actually yet support `warning` messages as there are
issues left to resolve in the spec PR, but there's nothing to stop
us adding an internal enum variant for sending a warning message
before we actually support doing so.
Inbound fee udpates are rather broken in lightning as they can
impact the non-fundee despite the funder paying the fee, but only
in the dust exposure it places on the fundee.
At least lnd is fairly aggressively high in their (non-anchor) fee
estimation, running the risk of force-closure. Further, because we
relied on a fee estimator we don't have full control over, we
were assuming our users' fees are particularly conservative, and
thus were at a lot of risk to force-closures.
This converts our fee limiting to use an absurd upper bound,
focusing on whether we are over-exposed to in-flight dust when we
receive an update_fee.
If we receive an update_fee but do not receive a commitment_signed,
we should not persist the pending fee update to disk or hold on to
it after our peer disconnects.
In order to make the code the most readable, we add a state enum
which matches the relevant states from InboundHTLCState, allowing
for more simple code comparison between inbound HTLC handling and
update_fee handling.
When we send an update_fee to our counterparty on an outbound
channel, if we need to re-send a commitment update after
reconnection, the update_fee must be present in the re-sent
commitment update messages. However, wewere always setting the
update_fee field in the commitment update to None, causing us to
generate invalid commitment signatures and get channel
force-closures.
This fixes the issue by correctly detecting when an update_fee
needs to be re-sent, doing so when required.
