The signer may not be present at this time. If we want to keep the
check to protect against bit flips we should move it into `onchaind`
where it doesn't matter as much that the signer may be slow to
respond.
If we need to iterate forward to find a timestamp (only happens if we have gossip older than
2 hours), we didn't exit the loop, as it didn't actually move the offset.
Fixes: https://github.com/ElementsProject/lightning/issues/7462
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The latest draft allows these experimental ranges, which involves more
changes than I expected.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: offers: handle experimental ranges in offers/invoice_requests/invoices.
Turns out we set this to False instead of None, so new field get "deprecated": False.
When we actually deprecate one, we get the following error:
ValueError: Field Decode.offer_node_id changed `deprecated` annotation: v24.08 vs False
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Things are often equivalent but different types:
1. u8 arrays in libwally.
2. sha256
3. Secrets derived via sha256
4. txids
Rather than open-coding a BUILD_ASSERT & memcpy, create a macro to do it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was only ever expermental, so I don't feel bad about just removing it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: JSON-RPC: `sendonionmessage` (was experimental only, use `injectonionmessage`)
Changelog-Added: Protocol: pay can now pay to bolt12 invoices if entry to blinded hop is specified as a short_channel_id (rather than node id).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This also lets us test offers and invoices work if we are the start of
the blinded path.
Changelog-Added: offers: automatically add a blinded path from a peer if we have no public channels, so unannounced nodes can have offers too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use this for invoices published by unannounced nodes: want
something very similar for offers, so generalize and expose it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Ideally, we would be able to submit a payment exactly as an incoming
HTLC would, but our forwarding and decoding logic is currently very
much tied to the HTLC. It would be wonderful to detach that and
have an "injectonion" interface which was unwrapped like any other
(see "injectonionmessage") which would handle self-pay without any
special paths.
Since I'm not prepared to rewrite that all now, instead we use an
interface to decrypt the first hop if it's us, and use the remainder
of the blinded path.
Changelog-Fixed: plugins: pay can now pay a bolt12 invoice even if we, ourselves, are the head of the blinded path within it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For bolt12, we have blinded paths so we route to the head of the blinded
path, which may not be the same as the final payment destination.
This matters mainly for detecting self-pay.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We check out the master bolts branch, and that recently changed test vectors
causing our CI to change. We should test them against our current BOLTVERSION,
which is in .tmp.lightningrfc/
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We generate a reply path by simply reversing the outgoing path:
A->B->C gives reply path B->A
A->B gives reply path A
But if we are not a public node, we can't use ourselves as the first
entry of the reply path: this happens if we directly connect to the
head of a blinded path (as we now support).
In this case, give the entire path as a blinded path. We could do
this all the time, but there are some cases where nodes don't like
sending replies where the node itself is the head of the blinded
path (like CLN v24.05 or before!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only need a connection with a peer, not an actual channel. So
add all peers to the local gossmap.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we can specify a blinded path in an offer, we have to check they
used it (or didn't use it, if we didn't have one!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We iterate through the blinded paths until we can use one, and because we use
the modern code, we properly join paths if we need to route more than one hop
to reach the start of the blinded path.
Changelog-EXPERIMENTAL: fixed: fetchinvoice tries all blinded paths until one is usable, and handles case where we have to route more than one hop to reach the entry point.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
send_onion_reply() does that for us now, so we don't need to do it up-front.
Simplifies the code quite a bit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
