In cc78b77c71 it was discovered that
`impl_writeable_tlv_based_enum_upgradable` wasn't actually
upgradable - tuple variants weren't written with length-prefixes,
causing downgrades with new tuple variants to be unreadable by
older clients as they wouldn't know where to stop reading.
This was fixed by simply assuming that any new variants will be
non-tuple variants with a length prefix, but no code write-side
changes were made, allowing new code to freely continue to use the
broken tuple-variant serialization.
Here we address this be defining yet more serialization macros
which aren't broken, and convert existing usage of the existing
macros using non-length-prefixed tuple variants to renamed
`*_legacy` macros.
Note that this changes the serialization format of
`impl_writeable_tlv_based_enum[_upgradable]` when tuple fields are
written, and as such deliberately changes the call semantics for
such tuples.
Only the serialization format of `MessageContext` is changed here
which is fine as it has not yet reached a release of LDK.
We previously stated in the docs that the invoice description can be at most `1023`
bytes long, which is wrong. According to BOLT 11 it's at most 1023*5 bits (639 bytes) long.
Note: this does not test the CS -> RAA resend ordering, because this
requires handling async get_per_commitment_point for channel
reestablishment, which will be addressed in a follow up PR.
Includes simple changes to test util signers and tests, as well as
handling the error case for get_per_commitment_point in
HolderCommitmentPoint. This leaves a couple `.expect`s in places
that will be addressed in a separate PR for handling funding.
99aa6e27f6 detected that we had an
undefined feature in `lightning-invoice` called `strict`, which was
used to turn on `deny(warnings)`. It resolved that by adding the
feature to the `Cargo.toml`, but we actually don't need it - our CI
already builds with `-Dwarnings`, so any warnings should be
rejected during CI and there's not a lot of value in having a
(public) feature to do the same.
We previously upstreamed the `validate_merkle_proof` utility method,
which shipped with `electrum-client` 0.19.0.
Since we upgraded to that version recently, we can now drop our local
code and use the upstreamed version.
This uses the newly introduced conditional configuration checks that are
now configurable withint Cargo (beta).
This allows us to get rid of our custom python script that checks for
expected features and cfgs.
This does introduce a warning regarding the unknown lint in Cargo
versions prior to the current beta, but since these are not rustc errors,
they won't break any builds with the "-D warnings" RUSTFLAG.
Moving to this lint actually exposed the "strict" feature not being
present in the lightning-invoice crate, as our python script didnt
correctly parse the cfg_attr where it appeared.
This will be used later in send_payment_for_bolt12_invoice instead of
find_route_and_send_payment as it will allow for returning
RetryableSendFailure when path finding fails.
Instead of returning Ok when path finding fails, allow returning a
RetryableSendFailure from send_payment_for_bolt12_invoice. Follow up
commits will return such failures.
- Previously, the `create_blinded_path` function was limited to
returning a single `BlindedPath`, which restricted the usage of
`blinded_paths`.
- This commit extends the `create_blinded_path` function to return
the entire blinded path vector generated by the `MessageRouter`'s
`create_blinded_paths`.
- The updated functionality is integrated across the codebase, enabling
the sending of Offers Response messages, such as `InvoiceRequest`
(in `pay_for_offer`) and `Invoice` (in `request_refund_payment`),
utilizing multiple reply paths.
