After the merge of #984, Jeff pointed out that `ChannelDetails` has
become a bit of a "bag of variables", and that a few of the variable
names in #984 were more confusing than necessary in context.
This addresses several issues by:
* Splitting counterparty parameters into a separate
`ChannelCounterpartyParameters` struct,
* using the name `unspendable_punishment_reserve` for both outbound
and inbound channel reserves, differentiating them based on their
position in the counterparty parameters struct or not,
* Using the name `force_close_spend_delay` instead of
`spend_csv_on_our_commitment_funds` to better communicate what
is occurring.
There are ~zero functions in lightning-invoice that are materially
callable from C, so there isn't any reason to tag it as a cdylib
(and make rustc build it as such). Instead, we have C bindings now.
Lightning invoices allow for zero or more multi-hop route hints. Update
get_route's interface to accept such hints, although only the last hop
from each is used for the time being.
Moves RouteHint from lightning-invoice crate to lightning crate. Adds a
PrivateRoute wrapper around RouteHint for use in lightning-invoice.
This increases the CLTV_CLAIM_BUFFER constant to 18, much better
capturing how long it takes to go on chain to claim payments.
This is also more in line with other clients, and the spec, which
sets the default CLTV delay in invoices to 18.
As a side effect, we have to increase MIN_CLTV_EXPIRY_DELTA as
otherwise as are subject to an attack where someone can hold an
HTLC being forwarded long enough that we *also* close the channel
on which we received the HTLC.
Since InvoiceFeatures are an implementation detail of InvoiceBuilder, an
explicit call is needed to support the basic_mpp feature. Since it is
dependent on the payment_secret feature, conditionally define the
builder's method only when payment_secret has been set.
Instead of relying on users to set an invoice's features correctly,
enforce the semantics inside InvoiceBuilder. For instance, if the user
sets a PaymentSecret then InvoiceBuilder should ensure the appropriate
feature bits are set. Thus, for this example, the TaggedField
abstraction can be retained while still ensuring BOLT 11 semantics at
the builder abstraction.
While this is less readable, I spent way too long trying to adapt
the bindings generation code to handle glob imports and concluded
it would take refactoring almost the entire import-resolution
logic. While this may be a good refactor to do eventually, its
probably not worth it today.
The C bindings generator now looks to default generic types as the
way to map a struct or enum parameter. Because SignOrCreationError
is only used directly with an error type of `()`, we set that to
the default and assume no other error types are needed.
This prevents aliasing the global secp256k1::Signature name in C
bindings and also makes it a little more explicit that the object
is different from other signature types.
There is generally never a reason to return a non-mutable reference
to a u64 vs just copying it, same applies here. It makes the API
slightly less consistent, but is easier to map in bindings and just
makes more sense.
