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.
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.
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.
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.
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`.
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.
It isn't exactly a critical error situation when we disconnect a
socket, so we shouldn't be printing to stderr, entirely bypassing
user logging, when it happens. We do still print to stderr if we
fail to write the first message to the socket, but this should
never happen unless the user has a reasonably-configured system
with at least one packet in bytes available for the socket buffer.
