Category, description and long description from `json_command` and `plugin_command` have been removed in favour of getting them from json schema. Reference PR: Add categories in RPC documentation #7485
Deprecating them in pyln-client as well. They will remove completely in future releases.
Changelog-Deprecated: pyln-client: category, description and long descriptions for RPC commands are deprecated now.
This is a hack, but we've had nodes missing gossip. LDK does this,
so until we get a better workaround, use this one.
Changelog-Changed: Protocol: we now always ask the first peer for all its gossip.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
> warnings.warn(f"Error reporting testrun: {e}: {e.read()}")
E AttributeError: 'URLError' object has no attribute 'read'
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In CI, this would sometimes fail: we would timeout waiting for the
fetchinvoice reply. Never happened locally, so was annoying to debug.
What happened was simple: we called injectonionmessage then when it
returned, put the "sent" object in the linked list so we could recognize
any reply onion messages.
However, we were getting that reply before the plugin processed the response
to injectonionmessage. This is possible because there are two fds for
plugins: one for it to receive notifications and hooks (like onion messages)
and one for normal RPC usage (like commands to inject onion messages).
The fix is simple: put in the list *before* calling JSON RPC.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We ask each channeld to report its leaks, and keep a refcount of how
many are outstanding. When the channeld replies, or dies, we decrement
the count in a destructor.
But if the last channeld we're waiting for dies, we can call the
destructor in an unexpected place, and thus run leak detection when
we were partway through some operation, which gives a false positive.
Here's a backtrace showing it:
```
0x5f93405897e3 send_backtrace
common/daemon.c:33
0x5f93405381cf finish_report
lightningd/memdump.c:139
0x5f93405382a0 leak_detect_req_done
lightningd/memdump.c:172
0x5f9340705c41 notify
ccan/ccan/tal/tal.c:243
0x5f9340705ca5 del_tree
ccan/ccan/tal/tal.c:437
0x5f9340705ce8 del_tree
ccan/ccan/tal/tal.c:447
0x5f93407061f3 tal_free
ccan/ccan/tal/tal.c:532
0x5f9340563f5a subd_release_channel
lightningd/subd.c:924
0x5f934050fb91 channel_set_owner
lightningd/channel.c:31
0x5f9340511b84 channel_err
lightningd/channel.c:1081
0x5f93405121a3 channel_fail_transient
lightningd/channel.c:1095
0x5f934054e547 peer_channels_cleanup
lightningd/peer_control.c:187
0x5f9340550411 peer_connected
lightningd/peer_control.c:1689
0x5f9340525101 connectd_msg
lightningd/connect_control.c:629
```
Instead, do the lightningd detection up-front, where it's in a
clean environment.
Reported-by: Shahana Farooqui
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
