Antoine Riard [Tue, 13 Jul 2021 16:56:40 +0000 (12:56 -0400)]
Add ChannelClosed generation at cooperative/force-close/error processing
When we detect a channel `is_shutdown()` or call on it
`force_shutdown()`, we notify the user with a Event::ChannelClosed
informing about the id and closure reason in a best effort.
Matt Corallo [Wed, 25 Aug 2021 20:13:01 +0000 (20:13 +0000)]
Add an accessor to `ChainMonitor` to get the claimable balances
The common user desire is to get the set of claimable balances for
all non-closed channels. In order to do so, they really want to
just ask their `ChainMonitor` for the set of balances, which they
can do here by passing the `ChannelManager::list_channels` output
to `ChainMonitor::get_claimable_balances`.
Matt Corallo [Wed, 4 Aug 2021 15:16:43 +0000 (15:16 +0000)]
Track how our HTLCs are resolved on-chain persistently
This tracks how any HTLC outputs in broadcast commitment
transactions are resolved on-chain, storing the result of the HTLC
resolution persistently in the ChannelMonitor.
This can be used to determine which outputs may still be available
for claiming on-chain.
Decorate the user-supplied EventHandler with NetGraphMsgHandler in
the BackgroundProcessor. The resulting handler will intercept
PaymentFailed events in order to update the NetworkGraph in the
background before delegating to the user's event handler.
Jeffrey Czyz [Thu, 12 Aug 2021 21:02:42 +0000 (16:02 -0500)]
EventHandler for applying NetworkUpdate
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.
Jeffrey Czyz [Thu, 12 Aug 2021 20:30:53 +0000 (15:30 -0500)]
Refactor PaymentFailureNetworkUpdate event
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.
Matt Corallo [Mon, 6 Sep 2021 03:25:27 +0000 (03:25 +0000)]
Move CounterpartyForwardingInfo from channel to channelmanager
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.
Jeffrey Czyz [Tue, 10 Aug 2021 14:47:27 +0000 (09:47 -0500)]
Remove RwLock from around NetworkGraph
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.
Jeffrey Czyz [Tue, 10 Aug 2021 03:24:41 +0000 (22:24 -0500)]
Individually lock NetworkGraph fields
In preparation for giving NetworkGraph shared ownership, wrap individual
fields in RwLock. This allows removing the outer RwLock used in
NetGraphMsgHandler.
Matt Corallo [Thu, 9 Sep 2021 01:09:41 +0000 (01:09 +0000)]
Reduce our stated max closing-transaction fee to be the true value
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.
Matt Corallo [Tue, 24 Aug 2021 23:15:07 +0000 (23:15 +0000)]
[invoice] Ignore InvalidLength fields
BOLT 11 states that a reader "MUST skip over...`p`, `h`, `s` or `n`
fields that do NOT have data_lengths of 52, 52, 52 or 53,
respectively." Here we do so by simply ignoring any invalid-length
field.
Matt Corallo [Sun, 22 Aug 2021 19:42:29 +0000 (19:42 +0000)]
Convert the invoice creation API to millisats and req it for parse
The BOLT 11 invalid invoice test vectors suggest failing to parse
invoices which have an amount which is not a whole number of
millisatoshis. lightning-invoice, however, happily parses such
invoices. While we could continue to parse them, failing them makes
for one less check on the user code side, so we might as well.
In order to keep the invoice creation less likely to fail, we also
switch the Builder amount-setting function to use millisatoshis.
Matt Corallo [Sun, 22 Aug 2021 19:36:01 +0000 (19:36 +0000)]
[invoice] Fix non-recoverable sig handling and bogus SI prefix err
This adds two additional tests from the BOLT 11 invalid invoice
tests, fixing the two errors that broke them. It fixes a panic on
the "nonrecoverable signature" test and makes the error variant
more sensible on the bogus SI prefix test.
abhik-99 [Mon, 9 Aug 2021 15:06:51 +0000 (20:36 +0530)]
Multi-Hop Route Hint as per Bolt 12 now considered
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.
Antoine Riard [Tue, 26 May 2020 07:55:03 +0000 (09:55 +0200)]
Add get_anchor_script
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.
Matt Corallo [Sun, 1 Aug 2021 02:34:08 +0000 (02:34 +0000)]
Don't initialise Vecs being read with VecReadWrapper explicitly
This simplifies the tlv serialization read macro somewhat by
allowing callsites to simply read into an `Option<Vec>` instead of
needing to read into an `Option<VecReadWrapper>` when using
`vec_type`.
Matt Corallo [Wed, 18 Aug 2021 00:33:56 +0000 (00:33 +0000)]
Fix trailing semicolon warnings on latest rustc nightly
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)
```