-
Notifications
You must be signed in to change notification settings - Fork 3.4k
initial support bolt12 offers #10110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
accumulator
wants to merge
45
commits into
spesmilo:master
Choose a base branch
from
accumulator:bolt12
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
+3,311
−266
Conversation
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
f321x
reviewed
Oct 6, 2025
ecdsa
reviewed
Oct 6, 2025
ecdsa
reviewed
Oct 6, 2025
ecdsa
reviewed
Oct 6, 2025
fa47daa to
f10ae24
Compare
Member
|
I have pushed a new version of https://github.com/spesmilo/electrum/commits/test_blinded_payment_onion |
6c10962 to
e7765dd
Compare
310953d to
b34be45
Compare
…res.with_assumed()
This allows restricting blinded paths to channels that have sufficient receive capacity for payment. NOTE: this might have privacy issues, as this can be used to probe channel capacity. Maybe randomize leeway?
add invreq_metadata validation
add no-receive-capacity test
…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).
…out are ERROR state
… generated. add feature filter for blinded payment path peers do not check frozen setting for onion message channel peers improve docs
…n tlv_stream_name=='onionmsg_tlv'
consistently use invoice_from_payment_identifier()
store used path_ids for each invoice by payment_hash
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()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR contains initial support for BOLT12
offerpayment identifiers,invoiceby sendinginvoice_requestvia onion messageinvoiceandinvoice_errorresponsesinvoicebolt11data structures likeLnAddr, to minimize changes in payment sending code pathinvoicecurrently stored inInvoice.lightning_invoicewith a prefix, because adding a new field to an@attr.sobject is a PITA when switching branches, final storage location TBD.add_offer,get_offer,delete_offerandlist_offersfor managing offers.invoice_requestand replies withinvoiceif request can be matched with an offer.notes w.r.t current state:
pathininvoice_pathsis tried, iteration of multiplepathis TODOaddslog, making the wallet file non-backward compatible