It's unclear what values 1-hop blinded paths should set their BlindedPayInfos
to, because those values are meant to refer to the fees/cltv delta on the path
*between* the intro node and the destination. We zero out these values in the
new variant's methods so they don't mess with path finding/construction.
This commit also adds two new maps to `PeerState` for keeping track
of `OutboundV1Channel`s and `InboundV1Channel`s so that further
commits are a bit easier to review.
To reduce interleaving in commits, we introduce a `context` variable
in methods to be moved in upcoming commits so there is minimal change
with the moves.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
f s/tarcontext.get_/target_/
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses these methods through the `context` field where
needed for compilation and tests to pass due to the above change.
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This is a first step for simplifying the channel state and introducing
new unfunded channel types that hold similar state before being promoted
to funded channels.
Essentially, we want the outer `Channel` type (and upcoming channel types)
to wrap the context so we can apply typestate patterns to the that wrapper
while also deduplicating code for common state and other internal fields.
When generating onion message fuzz data, the same public key was used
for each node. However, the code now advances the blinded path if the
sender is the introduction node. Use different node secrets for each
node to avoid this. Note that the exercised handling code is for the
sender's immediate peer.
Add a trait for finding routes for onion messages and parameterize
OnionMessenger with it. This allows OnionMessenger to reply to messages
that it handles via one of its handlers (e.g., OffersMessageHandler).
To avoid confusion in the upcoming MessageRouter trait, introduce an
OnionMessagePath struct that wraps the intermediate nodes and the
destination. Use this in OnionMessenger::send_onion_message.
Add a trait for handling BOLT 12 Offers messages to OnionMessenger and a
skeleton implementation of it for ChannelManager. This allows users to
either provide their own custom handling Offers messages or rely on a
version provided by LDK using stateless verification.
BOLT 12 Offers makes use of onion messages to request and respond with
invoices. Add these types and an error type to OnionMessageContents
along with the necessary parsing and encoding.
In an upcoming commit, messages for BOLT 12 offers are read from the
onion payload. Passing a logger allows for logging semantic errors when
parsing the messages.
If an InvoiceRequest or an Invoice delivered via an onion message cannot
be handled, the recipient should reply with an InvoiceError if a reply
path was given. Define the message and conversion from SemanticError.
