In general, we should always allow users to query for how much is
currently in-flight being claimed on-chain at any time.
This does so by examining the confirmed claims on-chain and
breaking down what is left to be claimed into a new
`ClaimableBalance` enum.
Fixes#995.
PaymentFailed events contain an optional NetworkUpdate describing
changes to the NetworkGraph as conveyed by a node along a failed payment
path according to BOLT 4. An EventHandler should apply the update to the
graph so that future routing decisions can account for it.
Implement EventHandler for NetGraphMsgHandler to update NetworkGraph.
Previously, NetGraphMsgHandler::handle_htlc_fail_channel_update
implemented this behavior.
MessageSendEvent::PaymentFailureNetworkUpdate served as a hack to pass
an HTLCFailChannelUpdate from ChannelManager to NetGraphMsgHandler via
PeerManager. Instead, remove the event entirely and move the contained
data (renamed NetworkUpdate) to Event::PaymentFailed to be processed by
an event handler.
CounterpartyForwardingInfo is public (previously exposed with a
`pub use`), and used inside of ChannelCounterparty in
channelmanager.rs. However, it is defined in channel.rs, away from
where it is used.
This would be fine, except that the bindings generator is somewhat
confused by this - it doesn't currently support interpreting
`pub use` as a struct to expose, instead ignoring it.
Fixes https://github.com/lightningdevkit/ldk-garbagecollected/issues/44
Now that NetworkGraph uses interior mutability, the RwLock used around
it in NetGraphMsgHandler is no longer needed. This allows for shared
ownership without a lock.
When communicating the maximum fee we're willing to accept on a
cooperative closing transaction to our peer, we currently tell them
we'll accept `u64::max_value()` if they're the ones who have to pay
it. Spec-wise this is fine - they aren't allowed to try to claim
our balance, and we don't care how much of their own funds they
want to spend on transaction fees.
However, the Eclair folks prefer to check all values on the wire
do not exceed 21 million BTC, which seems like generally good
practice to avoid overflows and such issues. Thus, our close
messages are rejected by Eclair.
Here we simply relax our stated maximum to be the real value - our
counterparty's current balance in satoshis.
Fixes#1071
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)
```
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 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."
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.
