This mistake was revealed when we start using experimental range for recurrence
(next commit).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The `invreq_recurrence_counter` clashes with the coming addition of
invreq_paths, so we might as well move them all to the new experimental
ranges.

Changelog-EXPERIMENTAL: Recurring offers had incompatible changes, won't work against older versions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…ecated.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is the blinded path for offerless invoice_requests.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is a good idea, but also specifically called out in the latest BOLT spec.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The latest spec allows this to be omitted iff there is a blinded path
and it would be made up anyway.

In that case, the key they will use to sign the invoice will be the final
blinded key in the path we use.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…rectly.

1. Missing offer_description iff offer_amount also missing.
2. Missing offer_issuer_id iff offer_paths is present.
3. Short channel id on introduction point.
4. Experimental range.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

invoice_path_id is actually a generic path_id thing, so rename it.

We're going to use the same scheme for path secrets and the tweak to
node_id when we create a fake pubkey for invoice_requests, so a new
header is appropriate.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

For now we only use a fake id for requesting invoices (as a payer_key), but we
will eventually use this generically, and we want plugins to be able to map them
too, so use the same scheme as path_id: a generated secret using the makesecret
API.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

… our key.

The current interface, if given a tweak, uses a *different secret key*
and tweaks it.  This was an early experiment: we will switch to using
a secret tweak for invoice_requests like we do for invoice path ids.

To make sure there's no funny business, *hsmd* hashes to form the
tweak (i.e. no zero tweaks!).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…ng invoices.

This is going to allow us to move it out from lightingd into plugin,
easily.  It's legal because the combination of offer id and label must
be unique (with recurrence, we use the same metadata anyay, since they
want to correlate with prior payments anyway).

We already broke recurrence in this PR, so we don't need another note to say
we're changing the key derivation.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

They can do it now: before it would have been awkward to look up previous
payments to match it up for recurring offers (which need to use the same
key, hence the same invreq_metadata).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…request`.

It's an internal difference, so doesn't actually break compatibility
(it would if we tried to prove we owned an old invoicerequest, but we
don't have infrastructure for that anyway).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…or createinvoicerequest.

It's an internal undocumented interface, which makes this change less painful.

We *do* check that the invreq_metadata maps to the given invreq_payer_id, which would
is required for us to sign it.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…necessary.

Changelog-EXPERIMENTAL: offers: `invoicerequest` will set a blinded path if we're an unannounced node.
Changelog-EXPERIMENTAL: offers: `sendinvoice` will use a blinded path in an invoice_request, if specified.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is a final sweep to match the current BOLT12 text:

	1563d13999d342680140c693de0b9d65aa522372 ("More bolt12 test vectors.")

Only two code changes, to change the order of checks to match the bolt,
and to give a warning on decode if a path is empty.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>