This makes the pay helper function being able to route
a payment using the optional `route` paramter that defaults to `False`.
I added this, as some plugins maintained their own version of `pay` that
needed routed payment helper.
Changelog-None
During our development, we modified the way
we report backtraces.
On a minimal configuration in OpenBSD, it seems that we
no longer compile from commit a9f26b7d07 because
our conditional code is buggy.
With the following compiler
vultr# cc -v
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.3
Thread model: posix
InstalledDir: /usr/bin
We have the following error
cc common/channel_id.c
cc common/daemon.c
common/daemon.c:218:2: error: implicit declaration of function 'add_steal_notifiers' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
add_steal_notifiers(NULL);
^
1 error generated.
gmake: *** [Makefile:298: common/daemon.o] Error 1
Reported-by: @grubles
Fixes a9f26b7d07
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
As a node matures and is no longer new, it can take some time
to determine which version of `cln` it's running.
To address this, we now display the version earlier. This ensures
that even in the event of a crash, we're aware of the running version.
(cln-meta-project-py3.11) ➜ lightning git:(macros/log-version) ✗ ./lightningd/lightningd
2023-10-12T19:21:00.899Z INFO lightningd: v23.08.1-209-gae94be4-modded
2023-10-12T19:21:00.994Z INFO lightningd: Creating configuration directory /home/vincent/.lightning/bitcoin
2023-10-12T19:21:01.235Z INFO lightningd: Creating database
2023-10-12T19:21:01.279Z UNUSUAL hsmd: HSM: created new hsm_secret file
Could not connect to bitcoind using bitcoin-cli. Is bitcoind running?
Make sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.
You can verify that your Bitcoin Core installation is ready for use by running:
$ bitcoin-cli echo 'hello world'
2023-10-12T19:21:01.349Z **BROKEN** plugin-bcli: \nCould not connect to bitcoind using bitcoin-cli. Is bitcoind running?\n\nMake sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.\n\nYou can verify that your Bitcoin Core installation is ready for use by running:\n\n $ bitcoin-cli echo 'hello world'\n
2023-10-12T19:21:01.349Z INFO plugin-bcli: Killing plugin: exited before we sent init
The Bitcoin backend died.
Link: https://github.com/ElementsProject/lightning/issues/6374
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We update `test_grpc_no_auto_start` test to check that we do not
generate certificates when the cln-grpc plugin is not started.
This fails currently, so next commit fix it up.
Add test `test_rune_method_not_equal_and_method_empty` that reproduces
issue #6725.
This fails currently, so next commit fix it up.
Error:
```
> with pytest.raises(RpcError, match='Not permitted: method not present'):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_runes.py:605: Failed
```
Without `developer` option, after compiling CLN and sourcing
`contrib/startup_regtest.sh`, if we try to start 2 nodes on regtest
running the command `start_ln` we get the following error:
```
lightningd: Config file /tmp/l1-regtest/config line 6: dev-fast-gossip: requires --developer
...
lightningd: Config file /tmp/l2-regtest/config line 6: dev-fast-gossip: requires --developer
```
Changelog-None
The tests will wait until it's locally enabled, but it might not have
the update in the gossip store. So have renepay enhance its local
view even if it already knows about the channel (this is correct
anyway, it just isn't very important usually).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This breaks Dijkstra, which is presumably why it was actually
disabled. Remove the code altoghether, instead.
Changelog-Fixed: JSON-RPC: `getroute` now documents that it ignores `fuzzpercent`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In this case, we were allocating off NULL, which meant a leak:
```
MEMLEAK: 0x565086722e98
label=channeld/channeld.c:3433:struct inflight
backtrace:
ccan/ccan/tal/tal.c:477 (tal_alloc_)
channeld/channeld.c:3433 (inflights_new)
channeld/channeld.c:3573 (splice_accepter)
channeld/channeld.c:4145 (peer_in)
channeld/channeld.c:6051 (main)
parents:
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also added splice_out tests that use the new PSBT command.
ChangeLog-Added: New `addpsbtoutput` command for creating a PSBT that can receive funds to the on-chain wallet.
We show where the pointer was allocated, but it can be confusing if it
was later stolen onto another context. Save and report those too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it easier to use outside simple subds, and now lightningd can
simply dump to log rather than returning JSON.
JSON formatting was a lot of work, and we only did it for lightningd, not for
subdaemons. Easier to use the logs in all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't apply the inflight to the channel struct before asserting, so
we can break test_rbf_non_last_mined:
```
lightningd: lightningd/dual_open_control.c:981: dualopend_tell_depth: Assertion `bitcoin_txid_eq(&channel->funding.txid, txid)' failed.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: #6696
Changelog-Fixed: rune: use runes table `id` instead `runes_uniqueid` from `vars` because it returns incorrect unique id if rune/s migrated from datastore.
Removed `bin-` while copying Fedora sums from release captain's file. Sums are saved as `clightning-$VERSION-Fedora-28-amd64.tar.gz` not as `clightning-$VERSION-bin-Fedora-28-amd64.tar.gz`
Changelog-None.
Now we're not always using the same functions to watch during
dual-funding opening, we need to make sure we're watching the close
(in particular, df close before the opening is confirmed).
So, keep a pointer, and if it's not set in drop_to_chain, set it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used the original channel funding output number. I'm not sure if this
was true in the previous code, or a regression I introduced, but it
caused occasonal failures in test_splice_gossip!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use the *same* callback for the funding tx, as well as for inflight dual-funding txs, as well as inflight splice txs. This is deeply confusing!
Instead, use explicit cbs for splicing and df. Once they're locked in, use the normal callback.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We never do this, but we're about to (we always watch before
we broadcast a tx).
We use a `depth` member to avoid calling the callback multiple times
for the same event, but we initialize it to 0. This means if we
register a watch, and the first thing that happens is that it
reorganizes out, we *don't* make the callback.
Use an impossible value at initialization, instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The latter is used when we're put in the db, the former is the uncommitted state.
Currently dbid == 0 is used in addition to the state, which is unwieldy.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Experimental: JSON-RPC: added new dual-funding state `DUALOPEND_OPEN_COMMITTED`
This is the variant of DUALOPEND_OPEN_INIT which you see once
the channel is in the db: we'll be adding it next, but to reduce
clutter the docs are added as a separate commit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We usually hand times by copy, not by pointer (and if we did, they should
be const!). I noticed this particularly for the state changed code, but
it goes down to to json_add_timeiso, so I fixed that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We should use capability tests for states (can you add htlcs?) rather than vague
descriptions (are you closing?).
And as much as possible, use switch () statements to force us to think
about all the cases, especially when we add new states!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently it's half done in funding_depth_cb, and half in
channeld_tell_depth. It's very confusing as a result,
with splicing, dual-funding and zeroconf.
This does introduce a behaviour change: if a channel is NORMAL and
it gets reorganized, we force close (unless we were the one who funded
it, or it's zeroconf anyway). This is safer than continuing to use
the channel in this case!
Some tests are changed to zeroconf to make them work, but v2 doesn't
support zeroconf, so that's removed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
