Offers: bolt12 updated for latest draft. #5676

This makes us match eed2ab0c30ad7f93e3b2641ca9d7ade32f3d121d ("Use `invalid_onion_blinding` everywhere"). 1. Numerous typographical changes. 2. Make sure we *always* return WIRE_INVALID_ONION_BLINDING if we're in a blinded path. 3. Handle p->total_msat correctly (MPP payments). 4. Reorganize blinding handling just like spec order. Signed-off-by: Rusty Russell <[email protected]>

This current spec is not strict enough: we might complain that the next peer is not connected, for example, which leaks information. So return WIRE_INVALID_ONION_BLINDING even if we're the first hop on the path, to be safe. Signed-off-by: Rusty Russell <[email protected]>

In a blinded path, you can specify node_id instead of scid. Handle that case. Signed-off-by: Rusty Russell <[email protected]>

Some places (e.g. the pay plugin) only need to construct onions, not decode them. Signed-off-by: Rusty Russell <[email protected]>

We simply take the first one, and route to the start of that. Then we append the blinded path to the onion construction. Signed-off-by: Rusty Russell <[email protected]>

We actually want lightningd to create these, since it wants to put the path_id secret in the last element. So best API is actually a generic one, rather than separate APIs to create first and last ones. And really, the more explicit initialization makes the users clearer. Signed-off-by: Rusty Russell <[email protected]>

We had a scheme where lightningd itself would put a per-node secret in the blinded path, then we'd tell the caller when it was used. Then it simply checks the alias to determine if the correct path was used. But this doesn't work when we start to offer multiple blinded paths. So go for a far simpler scheme, where the secret is generated (and stored) by the caller, and hand it back to them. We keep the split "with secret" or "without secret" API, since I'm sure callers who don't care about the secret won't check that it doesn't exist! And without that, someone can use a blinded path for a different message and get a response which may reveal the node. Signed-off-by: Rusty Russell <[email protected]>

Instead of doing command_fail() in the else, do it immediately then unindent the normal path. No code changes. Signed-off-by: Rusty Russell <[email protected]>

We're going to mess with it in the next patch... Signed-off-by: Rusty Russell <[email protected]>

…e presented. The "path" is just a message to ourselves. This meets the minimal requirement for bolt12 invoices: that there be a blinded path (at least so we can use the path_id inside in place of "payment_secret"). We expose the method to make this path_id to a common routine: offers will need this for generating more sophisticated paths. Signed-off-by: Rusty Russell <[email protected]>

And check it in invoice.c, insead of a hack where we compare against invhash. Restore checking, too. Signed-off-by: Rusty Russell <[email protected]>

This is needed for offers to generate blinded paths. No documentation changes since listincoming is an undocumented internal hack interface which topology presents for production of routehints. Signed-off-by: Rusty Russell <[email protected]>

We need this to create the payment_constraints for an invoice blinded path. Signed-off-by: Rusty Russell <[email protected]>

It's just to a direct peer, and we only create one, but this is enough to test, and make payments to non-public nodes work. Signed-off-by: Rusty Russell <[email protected]>

The new spec removes the offer_id, in favor of mirroring all the fields. So we need a way of generating a convenient identifier to identify the offer, and this works. We also want to extract parts of streams elsewhere, so expose that. Signed-off-by: Rusty Russell <[email protected]>

…eqs. This is an important part of the coming spec: we mirror all fields, known and unknown. Signed-off-by: Rusty Russell <[email protected]>

The spec only specifies the mpp bit for invoices, but in general they are separate spaces. Signed-off-by: Rusty Russell <[email protected]>

This is in preparation for the spec update where the signature field does not even exist. Signed-off-by: Rusty Russell <[email protected]>

This has radically changed in the spec, so remove it now, and we'll reintroduce / rewrite it. Signed-off-by: Rusty Russell <[email protected]>

I know this is an unforgivably large diff, but the spec has changed so much that most of this amounts to a rewrite. Some points: * We no longer have "offer_id" fields, we generate that locally, as all offer fields are mirrored into invoice_request and then invoice. * Because of that mirroring, field names all have explicit offer/invreq/invoice prefixes. * The `refund_for` fields have been removed from spec: will re-add locally later. * quantity_min was removed, max == 0 now mean "must specify a quantity". * I have put recurrence fields back in locally. This brings us to 655df03d8729c0918bdacac99eb13fdb0ee93345 ("BOLT 12: add explicit invoice_node_id.") Signed-off-by: Rusty Russell <[email protected]>

This changed, by popular demands. Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

We no longer have to refer back to the offer for which we're making the invoice_request, or to the invoice_request we made for an invoice, as they are all mirrored (and we check!). It's clearer to simply look at the object directly. Signed-off-by: Rusty Russell <[email protected]>

…nstead of towire/fromwire hack. I forgot this existed! Signed-off-by: Rusty Russell <[email protected]>

This gives us a unique identifier, by which we can match an invoice to their invoice_request. Signed-off-by: Rusty Russell <[email protected]>

We no longer use offers for "I want to send you money", but we'll use invoice_requests directly. Create a new table for them, and associated functions. The "localofferid" for "pay" and "sendpay" is now "localinvreqid". This is an experimental-only option, so document the change under experimental only. Signed-off-by: Rusty Russell <[email protected]> Changelog-EXPERIMENTAL: JSON-RPC: `pay` and `sendpay` `localofferid` is now `localinvreqid`.

…invoicerequests/disableinvoicerequest This is how we put new invoice_requests into the db; this will be used by a new "invoicerequest" command which replaces "offerout". The API is now the same as the offers api. Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

No code changes. Signed-off-by: Rusty Russell <[email protected]>

And make errors gcc-style, so emacs can jump through the automatically. ``` In devtools/reduce-includes.sh line 21: echo -n "-$LINE" ^-- SC3037 (warning): In POSIX sh, echo flags are undefined. In devtools/reduce-includes.sh line 25: echo -n "." ^-- SC3037 (warning): In POSIX sh, echo flags are undefined. In tools/rel.sh line 6: prefix=$(printf '%s\n' "${from#$common}" | sed 's@[^/][^/]*@..@g') ^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns. Did you mean: prefix=$(printf '%s\n' "${from#"$common"}" | sed 's@[^/][^/]*@..@g') In tools/rel.sh line 7: printf '%s\n' "$prefix/${to#$common}" ^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns. Did you mean: printf '%s\n' "$prefix/${to#"$common"}" For more information: https://www.shellcheck.net/wiki/SC3037 -- In POSIX sh, echo flags are undef... https://www.shellcheck.net/wiki/SC2295 -- Expansions inside ${..} need to b... make: *** [Makefile:553: check-shellcheck] Error 123 ``` Signed-off-by: Rusty Russell <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Offers: bolt12 updated for latest draft. #5676

Offers: bolt12 updated for latest draft. #5676

Commits on Nov 9, 2022