- certificate generation
- config options validation
- log level from 'error' to 'info'
- sending method as None instead ""
- added `listclnrest-notifications` for websocket server rune method
Changelog-Fixed: websocket server notifications are available with
restriction of `readonly` runes
startup_regtest now checks if wallet directory exists before creating
the default wallet, then it will check if wallet is loaded before
attempting to load it. This prevents unnecessary errors during the
execution of this bash script.
[ Squashed fixup: `regtest: restore double quotes on PATH_TO_BITCOIN` -- RR ]
If we ever re-enabled a channel too fast, if we considered it spam it
wouldn't propagate. For the moment, consider our own updates to never
be spam.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This should only have an effect if someone queries, but in practice, peers actually
see the disabling of channels.
This is a workaround until we rework the code so gossipd doesn't generate these at all
any more.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This functionality already exists in the Python framework; this feature
enables it for Rust plugins as well.
Changelog-Added: cln-plugin: Implement send_custom_notification to allow sending custom notifications to other plugins.
While running the integration testing in VLS we noted that there is a problem with the old_secret during that revoke and ack.
The built-in signer of core lightning return always the secret, but with a signer with more strict policies this can not be true.
In fact, the VLS return the old_secret only if it is the last tx candidate. So we should keep track of the old_secret during the recursion.
The current core is unsage because we can only revoke transaction M-1 once we have transaction M signed by the counterparty. If there is a splice candidate that is unsigned yet, and we revoke commitment transaction M-1 for it, and it gets into the blockchain, and the peer goes away, we can't force close anymore.
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: (null):0 ((null)) 0xffffffffffffffff
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: FATAL SIGNAL (version v23.08-64-gbffe599)
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: common/daemon.c:38 (send_backtrace) 0x55c4a2ebd97b
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: common/status.c:221 (status_failed) 0x55c4a2ecf0ae
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: common/subdaemon.c:18 (status_backtrace_exit) 0x55c4a2ecf42b
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: common/daemon.c:78 (crashdump) 0x55c4a2ebdb16
lightningd-1 2023-10-25T15:24:25.151Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x7f084e44251f
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:317 ((null)) 0x7f084e5a09cd
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: wire/towire.c:17 (towire) 0x55c4a2ed610e
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: bitcoin/privkey.c:33 (towire_secret) 0x55c4a2eea03b
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: wire/peer_wiregen.c:2737 (towire_revoke_and_ack) 0x55c4a2ee1d3d
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:1850 (make_revocation_msg_from_secret) 0x55c4a2e9d80e
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:1931 (send_revocation) 0x55c4a2e9de7a
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:2249 (handle_peer_commit_sig) 0x55c4a2e9f175
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:2880 (interactive_send_commitments) 0x55c4a2ea0c2e
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:3937 (splice_initiator_user_finalized) 0x55c4a2ea40ce
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:4011 (splice_initiator_user_update) 0x55c4a2ea44d4
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:5756 (req_in) 0x55c4a2ea8d9d
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: channeld/channeld.c:6151 (main) 0x55c4a2eaa3f8
lightningd-1 2023-10-25T15:24:25.152Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x7f084e429d8f
lightningd-1 2023-10-25T15:24:25.153Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: ../csu/libc-start.c:392 (__libc_start_main_impl) 0x7f084e429e3f
lightningd-1 2023-10-25T15:24:25.153Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: (null):0 ((null)) 0x55c4a2e98734
lightningd-1 2023-10-25T15:24:25.153Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: backtrace: (null):0 ((null)) 0xffffffffffffffff
lightningd-1 2023-10-25T15:24:25.153Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: STATUS_FAIL_INTERNAL_ERROR: FATAL SIGNAL
Reported-by: devrandom
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This table doesn't have `id`, except as the implicit one in Sqlite3,
so we need to add it for postgres.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
peer_htlcs has become a bit of a dumping ground: move listforwards
etc to its own file.
Also move `struct channel_info` from peer_htlcs.h to channel.h where
it more logically belongs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Looking through logs I was surprise to see:
```
lightningd-1 2023-10-26T03:42:36.824Z INFO lightningd: Sending 200000000msat over 1 hops to deliver 200000000msat
```
On a re-payment where we simply returned from sendpay immediately! Move that log to later.
We used to have "unsaved" payments: now we don't we can use
our normal "iterator" pattern rather than returning arrays.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It used to be used for both `sendpay` and `waitsendpay` but now it's
only for the latter, so the name is confusing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't write to db immediately, but waited until it the actual HTLC got
added (or failed). That way we didn't have a separate transaction to
write the payment into the db, but the complexity is not worth it: it
makes the next refactors harder, since we can't use the normal
iterator patterns like we do with the rest of the db (as we have to add
the unstored ones).
We might as well also make sendpay return immediately: we used to return
once the HTLC had been confirmed sent, since we entered it in the db
at that point, but we can keep it simple now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We generalize the invoice routine, though it's (known) buggy, so we have
to copy it. We rename the invoice routine to a more specific name though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Adding an index means:
1. Add the new subsystem, and new updated_index field to the db, and
create xxx_index_deleted/created/updated APIs.
2. Hook up these functions to the points they need to be called.
3. Add index, start and limit fields to the list command.
4. Add created_index and updated_index into the list command.
This does #1.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The log messages were changed but the test fields weren’t updated, resulting in some test flakiness. Being more explicit with the log message we’re looking for should help.
Changelog-None
This means refactoring out some of the generic anchor info, from the
per-commitment-tx info (we can have at least two, perhaps more with
splicing!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's going to want to remember these, in case it encounters peers'
commitment tx and needs to boost it with CPFP on the anchor.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
channel_txs was a thin wrapper around channel_splice_txs, but that's
just confusing. Rename channel_splice_txs to channel_txs, and just
call it everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We try to use anchors to CPFP our own commitment, but what if they
get there first? We also need to use anchors on the commitment
txs they broadcast.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
