wip: bolt 12#10671
Draft
f321x wants to merge 34 commits into
Draft
Conversation
f321x
force-pushed
the
bolt12_2
branch
5 times, most recently
from
82edaab to
9195022
Compare
f321x
force-pushed
the
bolt12_2
branch
7 times, most recently
from
c8b41e3 to
d41111b
Compare
move decryption of recipient_data to process_onion_packet, add handling of blinding in peer msgs, handle properties in ProcessedOnionPacket in case of path blinding, move repeated next blinding key derivation to func lnonion.next_blinding_from_shared_secret() Co-Authored-By: f321x <f@f321x.com>
…EATURES ... and lnutil.LN_FEATURES_IMPLEMENTED
when we have tried all blinded paths and for none of them we could find a route and we have a network address available for the destination (either node_id or blinded path introduction point).
Adds a separate method to `Peer` specifically for sending onion messages. This allows to 'enqueue' a (onion) message send before the peer is initialized without having to externalize waiting for init from `Peer`. This way we can establish a peer connection in `OnionMessageManager` and immediately fire an onion message on the `Peer`. Using the Queue also prevents the timing/retry logic in `OnionMessageManager` from breaking down if a single peer (of multiple available ones) takes a long time to send for whatever reason. Also creates a simpler API for callers (they don't have to pass a message_name and packet len).
Only catch UserFacingException. The scope of Exception is way too large, this caught all kinds of exceptions from LNWallet etc. It is not useful to show the user an error popup with e.g. "KeyError".
Introduce dataclasses for blinded path related structures. This allows safer and cleaner handling. - BlindedPathHop - BlindedPath - BlindedPayInfo - BlindedPathInfo
Introduce typed dataclass hierarchy for BOLT12 objects: - BOLT12Offer, BOLT12InvoiceRequest, BOLT12Invoice - validation in __post_init__() methods - helper functions - unittests (test_bolt12.py) Co-Authored-By: Sander van Grieken <sander@outrightsolutions.nl>
Adds unittest to check if we handle malformed bolt12 strings according to the specification using the format-string-test.json test vector. https://github.com/lightning/bolts/blob/5f31faa0b6e2cdbe32171d79464305f90bda9585/bolt12/format-string-test.json
Tests BOLT12Offer validation against the test vector json from the bolts repository.
Co-Authored-By: f321x <f@f321x.com>
Implements methods in LNWallet to create and send invoice_requests, handles incoming invoices. Supports both offerless and offer based invreqs
Add unittests for the invoice_request creation and invoice handling.
Store BOLT12 invoices as bech32-encoded strings (lni...) in the lightning_invoice field of the persisted Invoice class. Decode on demand and cache instance via cached_property. The `Invoice` can act as sort of abstraction over bolt11 and bolt12 invoices for the GUI. Co-Authored-By: Sander van Grieken <sander@outrightsolutions.nl>
Add unnittests for bolt12 payment identifier.
Implement `calc_hops_data_for_blinded_payment`, which takes a route to the introduction point of a blinded payment as well as the blinded path and assembles the hop payloads for the whole payment (unblinded path + blinded path). Co-Authored-By: f321x <f@f321x.com>
Introduce RoutingInfo class to make the lightning payment flow (LNWallet.pay_invoice and following) less specific to bolt11 but act on generic `RoutingInfo`.
Add a random offset to the `min_final_cltv_delta` of lightning payments. Renames the `RoutingInfo` fields to `final_cltv_delta` to make the distinction that this is not the same value as from the invoice more clear. For the blinded payments we need to add some value to the local_height for the final onion, however using a constant would allow the recipient to rather easily detect the sender is using Electrum. So using the same random offset as lightning-kmp/Phoenix seems good. At the same time we can add it to the unblinded payments as well, they profit from additional privacy against the forwarders.
Adapt the LNWallet payment flow to handle blinded/bolt12 payments. Paying via Trampoline is added in a future commit. Co-Authored-By: Sander van Grieken <sander@outrightsolutions.nl>
Implement initial LNWallet method `create_offer` to create bolt12 offer for sharing with external parties. Add CLI command `add_offer` to use this method.
Co-Authored-By: Sander van Grieken <sander@outrightsolutions.nl>
Add method to substract fees required for blinded path from a PaymentFeeBudget to calculate the remaining budget for the unblinded path.
Eclair interprets the invoice_features tlv for legacy trampoline payments as bytes, potentially this u64 conversion is outdated? This changes the invoice_features tlv to bytes type. See eclair source (grep "invoiceFeatures"). https://github.com/ACINQ/eclair/blob/a4d66adce2ec180c94532d1d0014f86f6e74f607/eclair-core/src/main/scala/fr/acinq/eclair/wire/protocol/PaymentOnion.scala#L638
Update the trampoline payment logic in LNWallet to handle payments to/through blinded paths. This allows for bolt 12 trampoline payments. Also stops including a trampoline onion layer for the recipient of a legacy trampoline payment. A non-trampoline aware (legacy) receiver cannot read this onion and it is not required for Eclair compatibility anymore.
Co-Authored-By: f321x <f@f321x.com>
Co-Authored-By: f321x <f@f321x.com>
f321x
force-pushed
the
bolt12_2
branch
2 times, most recently
from
cc45ddc to
5419870
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #10110
Still WIP, I will cherry-pick commits into separate, focused PRs for review over time.