A common issue in LN is not having fully synced the network graph
when we attempt to send a payment. This should be improved
substantially with gossip v1.5, but for now we should improve our
debugability by logging how many nodes we have in our graph when
we attempt to find a route.
For the same reason the `bitcoin` crate is re-exporting
the `secp256k1` crate the `lightning` crate should
re-export the `bitcoin` crate: to ease the burden on
calling code to maintain compatible `bitcoin` versions.
The `lightning` crate makes heavy use of types defined in
(or re-exported by) the `bitcoin` crate. Compilation will
fail if e.g. comparisons or `match` expressions are done with
types from `bitcoin` crate versions with a non-equal minor
version. This forces calling code to depend on a `bitcoin`
crate with a compatible version. This becomes a maintenance
nightmare once two or more crates, that use `bitcoin` types
in their public API, are used in calling code simultaneously.
This is required for bindings as passing types from Rust to GC'd
languages can't map the concept of a type that has a lifetime of
the called function but instead needs to clone for safety.
`Amount` is less than two pointers long, so there's no reason it
shouldn't be `Copy`. Further, because its an enum, bindings can't
map a reference to it in an `Option`. Thus, here, we simply make it
`Copy` and return it in `Option`s rather than a reference to it.
EcdsaChannelSigner is no longer deserialized as of version 0.0.113 and
downgrades before version 0.0.113 are no longer supported as of version
0.0.119.
If we prune one side of a channel's `ChannelUpdateInfo` that means
the node hasn't been online for two weeks (as they haven't
generated a new `channel_update` in that time). In such cases, even
if we haven't yet pruned the channel entirely, we should definitely
not be treating these channels as candidates for routing.
Note that this requires some additional `channel_update`s in the
router tests, but all of the new ones are added as disabled
channels.
Fixes#1824
When parsing lightning-invoice HRPs we want to read them
char-by-char, tracking at which offset different fields were. Prior
to this commit this was done first by reading char-by-char and then
by indexing using the byte offset which works for ASCII strings but
fails on multi-byte characters.
This commit fixes this issue by simply always walking byte-by-byte
and rejecting multi-byte characters which don't belong in HRPs.
When we added the additional deust exposure checks in
702196819e6445048b803574fcacef77d5ce8c9c we added several
additional feerate fetches which broke the `full_stack_target`
change-detection test.
This updates the hard-coded test to support the new feerate fetches
and also includes a comment on `FeeEstimator` to indicate that
users really need to be caching feerates as otherwise they'll slow
us down.
