Custom TLVs allow users to send extra application-specific data with
a payment. These have the additional flexibility compared to
`payment_metadata` that they don't have to reflect recipient generated
data provided in an invoice, in which `payment_metadata` could be
reused.
We ensure provided type numbers are unique, increasing, and within the
experimental range with the `RecipientOnionFields::with_custom_tlvs`
method.
This begins sender-side support for custom TLVs.
Fixes a bug where we wouldn't use the provided keysend preimage when
piping through OutboundPayment::pay_route_internal.
Also simplifies and refactors existing keysend tests to make sure this
gets hit.
To support route blinding, we want to split OnionHopData into two separate
structs, one for inbound onions and one for outbound onions. This is because
blinded payloads change the fields present in the onion hop data struct based
on whether we're sending vs receiving (outbound onions include encrypted blobs,
inbound onions can decrypt those blobs and contain the decrypted fields
themselves).
In upcoming commits, we'll add variants for blinded payloads to the new
InboundPayload enum.
Javadocs refuse unicode and as our rustdocs get copied over to Java
bindings (and thus get run through javadocs) we can't have unicode
in our rustdocs.
In Java/TypeScript, we map enums as a base class and each variant
as a class which extends the base. In Java/TypeScript, functions
and fields share the same namespace, which means we cannot have
functions on an enum which have the same name as any fields in any
enum variants.
`Balance`'s `claimable_amount_satoshis` method aliases with fields
in each variant, and thus ultimately doesn't compile in TypeScript.
Because `Balance::claimable_amount_satoshis` has the same name as
the fields, it's also a bit confusing, as it doesn't return the
field for each variant, but sometimes returns zero if we're not
sure we can claim the balance.
Instead, we rename the fields in each enum variant to simply
`amount_satoshis`, to avoid implying that we can definitely claim
the balance.
Makes it easier to add new arguments without a ton of resulting test changes.
Useful for route blinding testing because we need to check for malformed HTLCs,
which is not currently supported by reconnect_nodes. It also makes it easier to
tell what is being checked in relevant tests.
This gives people more freedom with the channel monitors. For Mutiny
this would be nice for us to be able to create copies of them and pass
aorund in memory without having to serialize until we actually want to.
Originally by benthecarman <benthecarman@live.com>
Small bugfix from Matt Corallo <git@bluematt.me>
Previously, we barely gave any hints why we excluded certain hops during
pathfinding. Here, we introduce more verbose logging by a) accounting
how much candidates we ignored for which reasons and b) logging any
first/last/blinded hops we end up ignoring.
Fixes#1646.
As `RouteParameters` are not included anymore in
`Event::PaymentPathFailed` since 0.0.115, and we don't give value/payee
as immediate arguments to `find_route` anymore.
A channel's `short_channel_id` is currently only set when the funding
transaction is confirmed via `transactions_confirmed`, which might be
well after the channel initally becomes usable, e.g., in the 0conf case.
Previously we would panic due to a reachable `unwrap` when receiving a
counterparty's `announcement_signatures` message for a 0conf channel
pending confirmation on-chain.
Here we fix this bug by avoiding unsafe `unwrap`s and just erroring out
and ignoring the announcement_signatures message if the `short_channel_id`
hasn't been set yet.
While bindings should probably be able to figure out that this is
the same type as `Self`, for now we simply swap the type to make
the bindings generator have an easier go of it.
The bindings are being updated to consider all traits even if the
trait itself is no-export, which causes issues generating code
around the `Duration` impl here.
We missed one method that now cannot be bindings exported - the
`payment_paths` method, as it returns a slice of objects, which
cannot be supported in bindings.
In bindings we can't practically pass a mutable PSBT, and instead
need to pass an owned transaction and have the sign method return a
signed copy. We do this here for all build modes as its not a
material API change for Rust users.
This code was always effectively dead - we have a special
`MultiThreadedLockableScore` type which wraps a `Mutex` for
bindings users, so there's no need to implement any
bindings-specific scoring logic for them.
Given we build `InFlightHtlcs` per route-fetch call, there's no
reason to pass them out by reference rather than simply giving the
user the full object. This also allows them to tweak the in-flight
set before fetching a route.
We already hold them in a vec, so there's no cost to passing them
by ownership vs making it a slice. Further, this helps bindings as
we can't represent slices to non-pointers in a sensible way.
In bindings we can't practically pass a mutable transaction, and
instead need to pass an owned transaction and have the sign method
return a signed copy. We do this here for all build modes as the
API is roughly equivalent also to Rust users.
We introduce a `UnfundedChannelContext` which contains a counter for the
current age of an unfunded channel in timer ticks. This age is incremented
for every `ChannelManager::timer_tick_ocurred` and the unfunded channel
is removed if it exceeds `UNFUNDED_CHANNEL_AGE_LIMIT_TICKS`.
The value will not be persisted as unfunded channels themselves are not
persisted.
