Skip to content

Conversation

@accumulator
Copy link
Member

@accumulator accumulator commented Aug 7, 2025

This PR contains initial support for BOLT12

  • parses bolt12 offer payment identifiers,
  • requests bolt12 invoice by sending invoice_request via onion message
  • handles invoice and invoice_error responses
  • initial support for paying bolt12 invoice
    • currently 'abusing' bolt11 data structures like LnAddr, to minimize changes in payment sending code path
    • bolt12 invoice currently stored in Invoice.lightning_invoice with a prefix, because adding a new field to an @attr.s object is a PITA when switching branches, final storage location TBD.
  • CLI commands add_offer, get_offer, delete_offer and list_offers for managing offers.
  • handles incoming invoice_request and replies with invoice if request can be matched with an offer.
  • accepts incoming HTLCs with blinding
  • initial Qt GUI should be working for sending to offer
  • initial QML GUI should be working for sending to offer

notes w.r.t current state:

  • only first path in invoice_paths is tried, iteration of multiple path is TODO
  • needs gossip enabled, no support for trampoline routing yet.
  • expired offers are not automatically removed from the wallet db.
  • adds extra blinding field to HTLCs in adds log, making the wallet file non-backward compatible

@accumulator accumulator force-pushed the bolt12 branch 5 times, most recently from fa47daa to f10ae24 Compare October 8, 2025 13:52
@ecdsa
Copy link
Member

ecdsa commented Oct 12, 2025

I have pushed a new version of https://github.com/spesmilo/electrum/commits/test_blinded_payment_onion
This branch adds a unit test for the blinded payment onion creation test vector from the BOLT

@accumulator accumulator force-pushed the bolt12 branch 10 times, most recently from 6c10962 to e7765dd Compare November 12, 2025 11:16
@accumulator accumulator force-pushed the bolt12 branch 9 times, most recently from 310953d to b34be45 Compare November 18, 2025 12:14
accumulator and others added 29 commits December 15, 2025 16:09
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?
…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).
… generated.

add feature filter for blinded payment path peers
do not check frozen setting for onion message channel peers
improve docs
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants