When serialized, the TLVs in `OutboundOnionPayload`, unlike a normal
TLV stream, are prefixed with the length of the stream. To allow a user
to add arbitrary custom TLVs, we aren't able to communicate to our
serialization macros exactly which fields to expect, so this commit
adds new macro variants to allow appending an extra set of bytes (and
modifying the prefixed length accordingly).
Because the keysend preimage TLV has a type number in the custom type
range, and a user's TLVs may have type numbers above and/or below
keysend's type number, and because TLV streams must be serialized in
increasing order by type number, this commit also ensures the keysend
TLV is properly sorted/serialized amongst the custom TLVs.
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.
Decaying the channel liquidity bounds by a half life can result in a
large decrease, which may have an oscillating affect on whether a
channel is retried. Approximate an additional three-quarter life when
half of the next half life has passed to help smooth out the decay.
The current ChannelClosed event does not let
you know the counterparty during a channel close
event. This change adds the counterparty_node_id
and the channel_capacity to the ChannelClosed event.
This helps users to have more context during a
channel close event. Solves #2343
Doing `cargo test` causes us to build both the crate(s) themselves
and the test binaries, which depend on the main builds. However, it
can start building the test code while the actual program code for
the main crate(s) themselves are being built, making a
build -> test flow slightly slower than test -> build.
Its not really a huge deal, but I'm using `ci/ci-tests.sh` more
locally and it meaningfully changes the time-to-test-run.
b0d4ab8cf8 fixed a nasty bug where
we'd failed to include the payment preimage in keysend onions at
all. Ultimately, this was a test failure - the existing test suite
should which did keysend payments were not structured in a way that
would fail in this case, instead using the same preimage variable
both for sending and receiving.
Here we improve the main keysend test tweaked by b0d4ab8cf8
to make absolutely sure it cannot work if the preimage doesn't come
from the onion. We make the payment preimage on the sending side a
variable inside a scope which only exists for the send call. Once
that scope completes the payment preimage only exists in the
sending `ChannelManager`, which must have put it in the onion in
order for the receiving node to have it.
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.
This is actually a valid response in some cases, at least for the
`gettxout` command, where `null` is returned if no corresponding
UTXO was found, but the command otherwise succeeded.
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>
This should at least marginally more aggressively target things
which are more likely to have changed in CI, making `ci-tests.sh`
more useful as a "default" script for developers to run locally.
While this is generally uneccessary as users set the `no-std` or
`std` features on the `lightning` crate directly, having this
allows `lightning-background-processor` to be built by itself
without extra dep lines. Specifically, the bindings are moving to
using the `-Z avoid-dev-deps` option, which now causes
`lightning-background-processor` to fail to build directly.
