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.
In preparation for giving NetworkGraph shared ownership, wrap individual
fields in RwLock. This allows removing the outer RwLock used in
NetGraphMsgHandler.
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
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`.
