With recent changes, particularly using postgres, we can finish the HTLC before
we force close, so the test fails. Insert an explicit hangup here so we reliably
get the result we expect:
```
@pytest.mark.parametrize("anchors", [False, True])
@unittest.skipIf(TEST_NETWORK != 'regtest', 'elementsd anchors not supportd')
def test_anchorspend_using_to_remote(node_factory, bitcoind, anchors):
"""Make sure we can use `to_remote` output of previous close to spend anchor"""
# Try with old output from both anchor and non-anchor channel.
l4_opts = {}
if anchors is False:
l4_opts['dev-force-features'] = "-23"
l1, l2, l3, l4 = node_factory.get_nodes(4, opts=[{},
{},
{'disconnect': ['-WIRE_UPDATE_FULFILL_HTLC']},
l4_opts])
# Give l2 some funds, from a to-remote output. It will have to spend
# this to use anchor.
node_factory.join_nodes([l4, l2])
# l4 unilaterally closes, l2 gets to-remote with its output.
l4.rpc.pay(l2.rpc.invoice(100000000, 'test', 'test')['bolt11'])
> wait_for(lambda: only_one(l4.rpc.listpeerchannels()['channels'])['htlcs'] != [])
tests/test_closing.py:4183:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
success = <function test_anchorspend_using_to_remote.<locals>.<lambda> at 0x7f8293e7fe20>
timeout = 180
def wait_for(success, timeout=TIMEOUT):
start_time = time.time()
interval = 0.25
while not success():
time_left = start_time + timeout - time.time()
if time_left <= 0:
> raise ValueError("Timeout while waiting for {}".format(success))
E ValueError: Timeout while waiting for <function test_anchorspend_using_to_remote.<locals>.<lambda> at 0x7f8293e7fe20>
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also gets some new timemono helpers, but we don't use them (yet).
Changelog-Fixed: Compilation on FreeBSD.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Closes: https://github.com/ElementsProject/lightning/issues/7758
Apparently clboss gives us \u UTF codes. We don't support that (use UTF-8 directly)
```
126 ../sysdeps/x86_64/multiarch/strlen-vec.S: No such file or directory.
(gdb) bt
label=label@entry=0x63e2f9604db9 "char *[]") at ccan/ccan/tal/str/str.c:137
complete=complete@entry=0x7ffe9090b0f6, destroyed=destroyed@entry=0x7ffe9090b0f7) at lightningd/plugin.c:773
```
Reported-by: Ken Sedgwick
Fixes: #8338
Changelog-None: broken in this release
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Checking a signature is a CPU-intensive operation that should be performed only
if gossmap doesn't already have the channel announcement in question and we're
not already checking for the announcement's UTxO.
Changelog-Fixed: `gossipd` doesn't waste CPU cycles checking signatures on channel announcements that are already known
Issue: https://github.com/ElementsProject/lightning/issues/7972
Ubuntu 20.04 reached its end-of-life (EOL) on April 15, 2025, and GitHub Actions subsequently removed the Ubuntu 20.04 LTS runner. As a result, we must upgrade all workflow runners to at least Ubuntu 22.04. Currently, this update has only been applied to pypi.yml for core-lightning.
Changelog-None.
The reproducible build is currently failing on Ubuntu Noble, causing the daily `Repro Build Nightly` GitHub action to fail and triggering email notifications.
This update resolves the issue by adjusting the default sqlite3 version and checksums to match the packages now available in Noble, allowing the image to build successfully.
Changelog-None.
We asserted that a node would be connected, but now we always call the
chanbackup peer_connected hook, it might not be that fast:
```
2025-05-17T08:37:58.7193306Z def test_funding_fail(node_factory, bitcoind):
...
2025-05-17T08:37:58.7204037Z # Restart l2 without ridiculous locktime.
2025-05-17T08:37:58.7204546Z del l2.daemon.opts['watchtime-blocks']
2025-05-17T08:37:58.7204990Z l2.restart()
2025-05-17T08:37:58.7206578Z l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
2025-05-17T08:37:58.7207072Z
2025-05-17T08:37:58.7207522Z # We don't have enough left to cover fees if we try to spend it all.
2025-05-17T08:37:58.7208203Z with pytest.raises(RpcError, match=r'not afford'):
2025-05-17T08:37:58.7208761Z l1.rpc.fundchannel(l2.info['id'], funds)
2025-05-17T08:37:58.7209203Z
2025-05-17T08:37:58.7209598Z # Should still be connected (we didn't contact the peer)
2025-05-17T08:37:58.7210243Z assert only_one(l1.rpc.listpeers()['peers'])['connected']
2025-05-17T08:37:58.7210875Z l2.daemon.wait_for_log('Handed peer, entering loop')
2025-05-17T08:37:58.7211439Z > assert only_one(l2.rpc.listpeers()['peers'])['connected']
2025-05-17T08:37:58.7211912Z E assert False
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It can definitely happen (it's not dead yet):
```
2025-05-17T08:44:48.9829150Z lightningd-2 2025-05-17T08:36:43.597Z **BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#3: gossipd gave channel_update in CGOSSIP_CHANNEL_ANNOUNCED_DYING? update=01027cf5d46590c45eb608a7e07a7b123c998ac12a655ce11004c9d9bb59f83698e8760d7b992df0dcf925f6732503de55d596aadaa35f0a8837cee58e0769172d2a06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00006f00000100006828493f010200060000000000000000000000010000000a000000003b023380
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We picked one node and iterated. This means we would only sent to 1,
not 2 nodes if we picked the last (common if there were only a few
peers). But it also means we would generally send to the same pair of
nodes, which isn't great for redundancy.
Rework to be more random.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we've make it only on existing channels, and not have to call
listdatastore every time, that means we can safely turn it on by
default.
Changelog-Added: Protocol: we now offer peer storage to any peers who create a channel.
Changelog-Deprecated: Config: `--experimental-peer-storage` (it's now the default).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When peer backup is enabled by default, it puts things in the datastore, breaking
this assumption. Narrow the test to examine the specific funder directory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They will in fact get truncated, and never restore. Large nodes should be using some real
backup strategy!
For this reason, we split "peer_backup" support into send vs store support, so we can
turn off send of our own without disabling storing/sending theirs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We already get the connected hook, so in there we can add to a hash
table of suitable peers. Rather than subscribe to disconnection, we
simply remove the peer if a sendcustommsg fails.
This does make after_send_scb_single() a bit more complex, since it
needs this specific node_id: we use a `struct info` per node and a
pointer to a shared "idx" reference counter.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By keeping a local hash table, we won't have to look up every time.
We still write to the datastore when it changes, and we need to
initialize it at plugin start.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Eclair only sets `batch_size` and `funding_txid` when its a batch larger than 1.
Adjust how we send and what we expect to receive to match this.
Changelog-None
And we timeout in:
l2.wait_for_channel_onchain(l1.info['id'])
Because the unilateral wins. This is because we tell closingd to
negotiate with a min feerate of 3750, but when it does and we check it,
our min has jumped, lightningd rejects it:
... That's below our min XXX for weight 772 at feerate 7000
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The spec used to say you had to wait for channel to be ready, *and* 6
depth before exchanging signatures. Now the 6 depth requirement is only
on the actual announcing of the channel: you can send sigs any time.
This means our state machine goes from:
NOT_USABLE -> NOT_DEEP_ENOUGH -> NEED_PEER_SIGS -> ANNOUNCED
to:
NOT_USABLE -> NEED_PEER_SIGS -> NOT_DEEP_ENOUGH -> ANNOUNCED
However, this revealed that our state machine is insufficient, so
rework it to be more general and understandable. In particular,
check for unexpected state transitions, and thus document them.
Note that cg->sent_sigs replaces channel->replied_to_announcement_sigs,
too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: We now exchange `announcement_signatures` as soon as we're ready, rather than waiting for 6 blocks (as per recent BOLT update)
They can all call get_block_height(); the extra argument confused me and
I thought they were called before the block height was actually updated.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want a more fine-grained approach, so we now have:
1. update_channel_update() - returns true if it changed.
2. channel_should_enable() - should this channel be marked enabled.
3. arm_refresh_timer() - start a refresh timer for the channel_update.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This could always happen, but now we're more correct about send it, it's
a possible race that I've seen in CI.
We can never get a PONG (that's now handled by connectd directly), but we
can definitely see this:
```
2025-05-15T02:29:14.7403081Z # Even with onchain anchor channel, it still keeps reserve (just in case!).
2025-05-15T02:29:14.7403766Z > l1.rpc.close(l2.info['id'])
2025-05-15T02:29:14.7404069Z
2025-05-15T02:29:14.7404248Z tests/test_opening.py:2536:
...
2025-05-15T02:29:14.7413090Z > return self.sock.recv(length)
2025-05-15T02:29:14.7413353Z E Failed: Timeout >1800.0s
...
2025-05-15T02:29:14.8097229Z lightningd-1 2025-05-15T01:50:59.538Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-closingd-chan#1: billboard perm: Expected closing_signed: 0103fad81b49d5e367cd785e3088b9acf356a7984a17a1ccda86d09da41438840b08000067000001000078c3314666731e339c0b8434f7824797a084ed7ca3655991a672da068e2c44cb53b57b53a296c133bc879109a8931dc31e6913a4bda3d58559b99b95663e6d52679cabaccc6e39dbd95a4dac90e75a258893c3aa3f733d1b8890174d5ddea8003cadffe557773c54d2c07ca1d535c4bf85885f879ae466c16a516e8ffcfec174
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Calling the funding tx an anchor is pre-spec terminology, which is now
confusing; let's rename the variable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When the command string run through $(call VERBOSE,…) contains a single-quote
character followed by shell metacharacters, the shell executing the VERBOSE
template's $(ECHO) command will attempt to interpret those metacharacters. This
could be disastrous, such as if someone were to put in a Makefile recipe:
$(call VERBOSE, , $(ECHO) 'Will not `rm -rf ~`')
When run with V=1, which causes VERBOSE to be defined as…
VERBOSE = $(ECHO) '$(2)'; $(2)
…Make would evaluate the above call into:
echo 'echo 'Will not `rm -rf ~`''; echo 'Will not `rm -rf ~`'
And oops, there goes the neighborhood.
The real-world motivating case for this fix is the sed call in the recipe for
doc/index.rst in doc/Makefile. It contains a sed expression enclosed in single
quotes, containing parentheses. When run through VERBOSE with V=1, the single
quotes around the sed expression actually escape _out_ of the single-quoted
string that is intended to be the whole command line, and you get:
/bin/sh: -c: line 1: syntax error near unexpected token `('
The fix is for VERBOSE to escape any single quotes embedded in the command line
argument when echoing it:
VERBOSE = $(ECHO) '$(subst ','\'',$(2))'; $(2)
Note that this is still wrong, as it will not do the right thing if $(2) happens
to begin with a hyphen, but I didn't want to introduce a new "PRINTF" variable
(or do something unsavory like calling cat with a here-doc) to squash a bug that
currently has no known manifestations.
Changelog-None
Lowdown requires a blank line before all preformatted blocks, or it doesn't
recognize them. `tools/md2man.sh` contained some ad-hoc efforts at fixing up
some locations where these required blank lines are absent from the output of
`tools/fromschema.py`, but it missed some. Instead of playing Whack-a-Mole, use
a blanket sed expression to ensure that a blank line precedes _every_ opening
```.
`esc_underscores(…)` in `tools/fromschema.py` did not work correctly on strings
containing an odd number of backticks, notably the ``` delimiters surrounding
preformatted text blocks. Specifically, it was dropping the last backtick since
none of the alternatives in the regex matched it. Add a new alternative that
matches a whole preformatted block as a single unit.
`output_member(…)` in `tools/fromschema.py` was passing each line of a member's
description through `esc_underscores(…)` individually, but that breaks
preformatted text blocks that are naturally multi-line and leads to mistakenly
escaping underscores inside such blocks. Rewrite the code to make use of the
`outputs(…)` utility function that joins all the provided lines together before
passing the whole text through `esc_underscores(…)`.
Drive-by fix a couple of flubbed preformatted blocks in schemas.
[ Added shellcheck suppression for md2man.sh --RR ]
Changelog-None
If `wally_psbt_extract` fails the function returns early leaking psbt, if it was `taken()`.
Throw it on tmpctx so its not leaked in this case.
Changelog-None
Fix a typo where the commit sig message ordering was not handled correctly for the first element.
We need to use msg_batch[0] to get the first post-sorted result instead of the original msg.
Changelog-None
It would be wrong to omit those prior to the last, and I want to see
what test this was supposedly breaking...
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Previously, the code utilized JSON-encoded text to pass log messages to the
log_() function, resulting in new lines being printed to the log as '\n'. This
commit addresses this issue by unescaping and splitting the log message into
lines, with each non-empty line being logged separately.
It is deemed acceptable to pass non-printable characters to log_() since they
are replaced with "?" in the logv() function, invoked by log_(). Therefore,
leaving lines JSON unescaped is permissible.
It's important to note that only the last log_() call may have call_notifier
set to true. This adjustment is crucial to prevent Python tracebacks complaining
about a broken pipe after lightningd exits.
Fix https://github.com/ElementsProject/lightning/issues/4912
For reference, the log of lightningd failing without a backend:
./lightningd/lightningd
2024-02-08T20:33:17.642Z INFO lightningd: v23.11-257-g968d6d6-modded
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'
2024-02-08T20:33:18.227Z **BROKEN** plugin-bcli: Could not connect to bitcoind using bitcoin-cli. Is bitcoind running?
2024-02-08T20:33:18.227Z **BROKEN** plugin-bcli: Make sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.
2024-02-08T20:33:18.227Z **BROKEN** plugin-bcli: You can verify that your Bitcoin Core installation is ready for use by running:
2024-02-08T20:33:18.227Z **BROKEN** plugin-bcli: $ bitcoin-cli echo 'hello world'
2024-02-08T20:33:18.227Z INFO plugin-bcli: Killing plugin: exited before we sent init
The Bitcoin backend died.
Changelog-Changed: Plugins: log messages containing \n are now split into multiple log lines, for neatness, and " is no longer turned into \".
This updates all reckless-installed plugins with `reckless update` or
update individual plugins by passing the plugin names as arguments.
The metadata stored with the installed plugin is used to find the
plugin from the appropriate source (the same source is used as when
originally installed.)
Changelog-Added: Reckless: `reckless update` updates all reckless-installed plugins.
This allows installing a local plugin directly without having
to modify reckless sources.
Changelog-changed: Reckless can be passed a local file or directory for installation.
channeld complains if it sees blocks going backwards, but that's
actually expected: allow those log messages:
```
2025-05-13T10:28:56.3283346Z _______________ ERROR at teardown of test_v2_replay_bookkeeping ________________
...
2025-05-13T10:28:56.3301378Z request.node.has_errors = True
2025-05-13T10:28:56.3301833Z > raise ValueError(str(errors))
2025-05-13T10:28:56.3302268Z E ValueError:
2025-05-13T10:28:56.3303425Z E Node errors:
2025-05-13T10:28:56.3303923Z E - lightningd-1: had BROKEN messages
2025-05-13T10:28:56.3304404Z E Global errors:
...
2025-05-13T10:28:56.4619742Z lightningd-1 2025-05-13T10:24:38.112Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#2: current blockheight 109 less than last 111
2025-05-13T10:28:56.4620188Z lightningd-2 2025-05-13T10:24:38.112Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: peer_in WIRE_SHUTDOWN
2025-05-13T10:28:56.4620600Z lightningd-1 2025-05-13T10:24:38.112Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#2: Trying commit
2025-05-13T10:28:56.4621119Z lightningd-2 2025-05-13T10:24:38.112Z INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CHANNELD_NORMAL to CHANNELD_SHUTTING_DOWN
2025-05-13T10:28:56.4621623Z lightningd-1 2025-05-13T10:24:38.112Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#2: current blockheight 109 less than last 111
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to wait for exiting startup mode *before* closing channel, so it doesn't ignore
the disconnection of l3, otherwise we don't get a disabled update, and timeout waiting
at line 330:
wait_for(lambda: not l1.is_channel_active(chanid2))
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
2025-05-12T04:37:57.4824338Z else:
2025-05-12T04:37:57.4824626Z # It will forget the older one.
2025-05-12T04:37:57.4825508Z > l2.daemon.wait_for_log(r"UNUSUAL {}-chan#1: Forgetting channel: It has been {} blocks without the funding transaction ".format(l1.info['id'], blocks + 1))
```
This fails because l3 can still transmit, so the second channel can confirm in time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We may introduce high capacity channels in askrene to represent problems
with multiple destinations (eg. multiple blinded paths) or to solve
self-payments. The integer computation of the deliverable amount through
these channels (I tested this with a channel with 21M bitcoin) would
fail due to an integer overflow in the function `amount_msat_sub_fee`,
21M BTC = 21 x 10^17 msat, which overflows u64 integers when multiplied
by 10^6. We have fixed `amount_msat_sub_fee` operations, so that it
doesn't overflow.
Changelog-Fixed: askrene: fixed routing in high capacity channels.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Change order of operations to ensure that askrene-inform-channel with
inform=constrained computes the correct upper bound on the liquidity:
upperBound = reserves + amount - 1
With the previous order of operations in the case amount=0 we would get:
upperBound = reserves
instead of
upperBound = reserves - 1
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: sendonion: a new paramter total_amount_msat to make MPP payments with sendpay and sendonion compatible.
[ Reordered to put new parameter at the end --RR ]
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
In some cases the CI is so quick and / or slow that the mempool doesn’t have the transaction by the time we’re looking for it.
Move the mempool check into a wait_for.
We do this by adding a specific txid the tx_abort applies to and performing checks based on that.
If the txid is NULL or unrecognized than no inflights are dropped from DB. If we recognize it than we do the check to see if we signed it and, if not, we let lightningd remove it from DB.
New reestablish behvaior allows splices to resume on reestablish if only commit sigs were exchanged.
Update the `test_commit_crash_splice` to reflect this (and turn it back on).
A splice where reestablish happens at the right moment causes an infinite loop of announcement signatures being sent back and forth.
Limit the announcement sigs we send in response to announcement sigs to once per channel session.
ChangelogNone
Allow user’s to RBF existing splices. For now this is done by simple executing an additional splice command, in the future this will can also be done with dedicated RPCs.
Changelog-Added: Enabled the ability to RBF splices
The result of splice_signed can fail for many reasons that are non-critical (already in mempool for instance).
Don’t abort channels in this case as that causes a force close.
Other implementations are sending commit_sig batches in different orders. We add support for them being in any order by ordering the batch of messages after receiving them.
Changelog-Changed: Increase interop compatability by loosening requirement that commitment signed messages be received in a particular order and sorting them internally.
The value of `our_funds` inlightningd is the funds added to the channel during creation. Splicing is a quasi-creation event. This change makes our pending funds be considered funding funds at the moment of splice confirmation.
Changelog-None
`bitcoin_tx_with_psbt` would somewhat opaquely steal the passed `psbt` value.
This caused a bug where code made a `bitcoin_tx` using a psbt without realizing the value was stolen. Because the resulting `bitcoin_tx` was placed in tmpctx it was not immediately clear that using `psbt` afterwards was an error until the tmpctx was cleared — creating a valgrind backtrace far from the actual issue.
Switching to the routine to using TAKES and adding documentation in the header, makes it explicitly clear which operation the user is doing — helping prevent future regressions of this kind.
Changelog-None
PSBT changeset routines were using linearize_output which mutated the memory of the objects it was comparing.
This commit fixes that and also cleans up the memory usage to be more clear and more guarentee there is no memory corruption.
Changelog-None
Check that the peer sent the correct txid in their `splice_locked` message.
We have to check this later on in `check_mutal_splice_locked` so we store the value in `splice_state`
A new case where `splice_locked` must be sent again on reestablish.
This handles the case where `splice_locked` did not complete locally or remotely and must be resumed.
Interop testing with Eclair revealed an issue with remote funding key rotation.
This searches for the funding output using the rotated remote funding pubkey instead of the furrent funding pubkey.
Also update the variable name to be more clear which this represents.
Changelog-Changed: Interop fixes for compatability with Eclair
Add preapprove_check capabilities:
WIRE_HSMD_PREAPPROVE_INCOICE_CHECK and
WIRE_HSMD_PREAPPROVE_KEYSEND_CHECK to the capabilities array
if dev_no_preapprove_check is not set.
Do not assume those occupy the last two slots in the array.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
signmessagewithkey: allows to sign a message with a key associated with
one bitcoin address in our wallet.
Changelog-Added: add a new rpc command signmessagewithkey to sign input messages with keys from our wallet.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: HSMD: add new wire API to sign messages with bitcoin wallet keys according to BIP137.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Make sure we are sending bogus channel reestablish after recovering from
emergency.recover file and peer storage backup.
Key Changes:
- Add wait_for_log() with appropriate debug statements
Unfortunately LND does not force close the channels on receiving an error,
they blame us for this behaviour (abb1e3463f/htlcswitch/link.go (L2119))
To fix this we will send them a Bogus Channel Reestablish with 0 commitment_number and invalid last_per_commit_secret.
Key Changes:
- In connect_activate_subd, if we detect a stub channel, we serialize and send a bogus channel_reestablish message.
Changelog-Fixed: Fixing LND's non responsive behaviour on receiving an error.
Suggested-by: @NicolasDorier
Closes: https://github.com/ElementsProject/lightning/issues/8078
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: we no longer try asking for blocks from bitcoind's peers if they don't store blocks.
We can fail the fundchannel because of a reconnect race: funder tells
us to reconnect so fast that we are still cleaning up from last time.
We deliberately defer clean up, to give the subds a chance to process any
final messages. However, on reconnection we force them to exit immediately:
but this causes new `connect` commands to see the exit and fail.
The workaround is to do this cleanup when a `connect` command is
issued (as well as the current case, which covers an automatic
reconnection or an incoming reconnection)
```
2025-05-09T00:40:37.1769508Z def test_reconnect_signed(node_factory):
2025-05-09T00:40:37.1770273Z # This will fail *after* both sides consider channel opening.
2025-05-09T00:40:37.1770850Z disconnects = ['<WIRE_FUNDING_SIGNED']
2025-05-09T00:40:37.1771298Z if EXPERIMENTAL_DUAL_FUND:
2025-05-09T00:40:37.1771735Z disconnects = ['<WIRE_COMMITMENT_SIGNED']
2025-05-09T00:40:37.1772155Z
2025-05-09T00:40:37.1772598Z l1 = node_factory.get_node(may_reconnect=True, disconnect=disconnects)
2025-05-09T00:40:37.1773210Z l2 = node_factory.get_node(may_reconnect=True)
2025-05-09T00:40:37.1773632Z
2025-05-09T00:40:37.1773917Z l1.fundwallet(2000000)
2025-05-09T00:40:37.1774268Z
2025-05-09T00:40:37.1774611Z l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
2025-05-09T00:40:37.1775151Z > l1.rpc.fundchannel(l2.info['id'], CHANNEL_SIZE)
2025-05-09T00:40:37.1775388Z
2025-05-09T00:40:37.1775485Z tests/test_connection.py:667:
...
2025-05-09T00:40:37.1799527Z > raise RpcError(method, payload, resp['error'])
2025-05-09T00:40:37.1800993Z E pyln.client.lightning.RpcError: RPC call failed: method: fundchannel, payload: {'id': '022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59', 'amount': 50000, 'announce': True}, error: {'code': -1, 'message': 'Disconnected', 'data': {'id': '022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59', 'method': 'openchannel_update'}}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We cannot add new parameters in the middle, since we accept parameters by JSON
array as well as by dicts. In fact, this broke tests, but due to unrelated
breakage in the GitHub "Automerge" functionality, it got applied as
556e38c838 ("askrene-bias-channel: bias call add
up.").
Also add tests, and a better Changelog line.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `askrene-bias-channel` now has a `relative` option to add, rather than replace, a channel bias.
We need to make sure the close tx is generated where we expect, so the following code
doesn't wait foreverL
```
2025-05-08T04:31:31.1071194Z > assert l2.rpc.wait('htlcs', 'deleted', 3)['deleted'] == 5
2025-05-08T04:31:31.1071518Z
2025-05-08T04:31:31.1071645Z tests/test_misc.py:3398:
...
2025-05-08T04:31:31.1079841Z E Failed: Timeout >1800.0s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't care about data persistence, and this suppresses all sync calls (speeding
sqlite3 specifically).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This significantly slows down the cycle when we have flakes (it's good if
the tree is completely broken though!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This speeds logging slightly, but most of the time is actually
spent in fflush() (which we need).
Result (10 runs, eatmydata):
FAILED tests/test_connection.py::test_bench - assert 24.086638-25.347475(24.6901+/-0.4) == 0
This is an 8% performance improvement (over the entire series), which is not bad.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we don't have to iterate through all plugins, making
our "do we even have to construct this notification" optimization
much more efficient.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If nobody is subscribed, have notify_start return NULL and the caller
can skip serialization. This is particularly useful for the "log"
notification which can get called a lot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our CORK logic was wrong, and it's better to use Nagle anyway:
we disable Nagle just before sending timing-critical messages.
Time for 100 (failed) payments:
Before:
148.8573575
After:
10.7356977
Note this revealed a timing problem in test_reject_invalid_payload: we would
miss the cause of the sendonion failure, and waitsendpay would be called
*after* it had failed, so simply returns "Payment failure reason unknown".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: Removed 200ms latency from sending commit/revoke messages.
We need to make sure the lease starts a the block we expect:
```
# Note that l3 has the whole lease delay (minus blocks already mined)
_, _, l3blocks = l3.wait_for_onchaind_tx('OUR_DELAYED_RETURN_TO_WALLET',
'OUR_UNILATERAL/DELAYED_OUTPUT_TO_US')
> assert l3blocks == 4032 - 6 - 2 - 1
E assert 4022 == (((4032 - 6) - 2) - 1)
tests/test_closing.py:985: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can fail to connect because l3 connects to l2 at the same time l2 connects to l3:
```
# The plugin in l2 fixes up the connection, so this works!
> l1.rpc.fetchinvoice(offer['bolt12'])
tests/test_connection.py:4792:
...
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: fetchinvoice, payload: {'offer': 'lno1qgsqvgnwgcg35z6ee2h3yczraddm72xrfua9uve2rlrm9deu7xyfzrcgqgqjczs7w3jhxazldahxjmmwd4jhxumpvaj47en0wfmkzunytanxz6tvzcssxhftzxfdlwsnfcgw2sy8t5mxa0ytcdfat2nkdwqvpy9nnsa9mzza'}, error: {'code': 1005, 'message': 'Timeout waiting for response'}
```
From logs:
```
lightningd-2 2025-05-07T21:20:54.367Z DEBUG 035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d-connectd: peer_out WIRE_INIT
lightningd-2 2025-05-07T21:20:54.367Z DEBUG 035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d-connectd: Connect IN
``
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Presumably we want to wait for htlcs to be all resolved here. With the speedup,
this failed under Postgres:
```
> wait_for(lambda: only_one(l2.rpc.listpeerchannels(l3.info['id'])['channels'])['htlcs'] != [])
tests/test_closing.py:4191:
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once we speed things up, this can receive COMMITMENT_SIGNED, and hence succeed. Let's
drop on receive, not send!
```
2025-05-06T06:07:51.5997333Z # Peers try RBF, break on initial COMMITMENT_SIGNED
2025-05-06T06:07:51.5997855Z bump = l1.rpc.openchannel_bump(chan_id, chan_amount, initpsbt['psbt'])
2025-05-06T06:07:51.5998214Z > with pytest.raises(RpcError):
2025-05-06T06:07:51.5998542Z E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once we speed things up, we can *receive* commitment_signed before we disconnect
due to sending ours: in this case, we *will* have a scratch tx.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
DNS seeds have been down/offline for a while, and this code (which
blocks!) has been a source of trouble. We should probably use a
canned set of "known nodes" if we want to bootstrap.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: we no longer use DNS seeds for peer lookup fallbacks.
Fixes: https://github.com/ElementsProject/lightning/issues/7913
From grubles' logs:
```
2025-01-06T15:30:31.449Z DEBUG lightningd: attempting connection to 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923 for additional gossip
2025-01-06T15:30:31.449Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Adding 0 addresses to important peer
2025-01-06T15:30:31.449Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:31.449Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:32.037Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:32.037Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:32.428Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:32.428Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:32.680Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:32.681Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:33.468Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:33.469Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:33.471Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:33.471Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:33.935Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:33.935Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:34.125Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:34.125Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:35.496Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:35.497Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:35.623Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:35.623Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:35.751Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:35.751Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
2025-01-06T15:30:35.892Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Failed connected out: Unable to connect, no address known for peer
2025-01-06T15:30:35.892Z DEBUG 035ca2fe4793a5e789ce846062eb4834f573c060d9200ce77544a29b48a0aa5923-connectd: Will try reconnect in 300 seconds
```
We promised to wait 300 seconds!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The channel bias feature is not being used yet by any plugin, so this
hopefully doesn't break any working code.
When askrene-bias-channel is called the bias quantity is added on top of
any previous biased already present on that channel instead of
overwriting it.
Changelog-Changed: askrene-bias-channel: bias call add up.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Reported-by: daywalker90
Changelog-Deprecated: JSON-RPC: channel_state_changed notification field `old_state` value "unknown" (it will be omitted, instead)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
fundwallet generates a block: if l2 sees one block and not the other, it can
consider the time on the first fundchannel to be one block earlier than expected:
```
2025-05-05T21:05:33.6260600Z E TimeoutError: Unable to find "[re.compile('UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#1: Forgetting channel: It has been 51 blocks without the funding transaction ')]" in logs.
...
2025-05-05T21:05:33.7179461Z lightningd-2 2025-05-05T20:44:26.141Z UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#1: Forgetting channel: It has been 52 blocks without the funding transaction 5a18d113f53df8b205ab679924babde4068f2d1876d34edc43701bf92b8ff13f getting deeply confirmed. We are fundee and can forget channel without loss of funds.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is inspired by a patch from @whitslack, which overlapped with this series.
Most importantly, there was only one call to bitcoin_tx_simple_input_weight(),
and it is better to be explicit with that one.
This also changes our funder calculation to assume our own input is taproot,
which it is likely to be given we've defaulted to taproot for outputs for
change addresses since 23.08.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
One in 256 times, we will grind a signature to 70 bytes (or shorter). This breaks
our feerate tests. Unfortunately the grinding is deterministic, so there doesn't
seem to be a way to avoid it. So we add a log message, and then we skip the
feerate test if it happens.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is legal! And we actually do this in tests, but we didn't check the psbt
was spendable (the next patch does, indirectly, by testing feerate):
```
# Discard prep4 and get all funds again
l1.rpc.txdiscard(prep5['txid'])
# You can have one which is all, but not two.
prep5 = l1.rpc.txprepare([{addr: Millisatoshi(amount * 3 * 1000)},
{addr: 'all'}])
# Feerate should be ~ as we asked for
> assert normal_feerate_perkw - 1 < feerate_from_psbt(bitcoind, l1, prep5['psbt']) < normal_feerate_perkw + 1
E AssertionError: assert (7500 - 1) < -1091803.9574935874
```
Changelog-Fixed: JSON-RPC: `txprepare` with `all` as well as one or more non-all amount fields now produces a valid PSBT.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we've fixed various underlying weight mis-estimation, we can do a few final tweaks and
test that anchors work as intended.
1. We assumed a p2wpkh output, but modern change is p2tr.
2. We handed `2` instead of `1` to bitcoin_tx_core_weight (which doesn't matter, but was weird).
3. Make change calculation clearer. I'm not sure the previous one was wrong, but it was harder
to understand.
4. Fix the test and make it clearly test that we are aiming for (and achieving) the right feerate.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: anchors' fees are now much closer to the feerate targets.
We need one byte for the number of witness elements. Some callers added it themselves,
but it's always needed. So document and fix the callers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't add the weight of the two sigs! The BOLT defines that to be a worst-case 73 byte sig,
but that turns out to be an overestimate (and this is not required for consensus) so we assume
everyone grinds.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use this for anchors, in which case we have a minimum value for
change. If we don't take this into account, we end up with a lower
feerate once we actually create the tx.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We previously treated it as a P2WPKH, which is wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: wallet: fees are much closer to target feerate when doing txprepare/fundchannel.
Due to a bug elsewhere I actually triggered this path, and it
broadcast the tx anyway, *then* closed the channel. We should abandon
the channel if we can, instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To actually evaluate spend cost, we need to know whether it's taproot or not.
Using an enum (rather than making callers examine the script) means we can
ensure all cases are handled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The renaming makes it clear that it's HSM specific.
And it has no pointers, so we can have an array instead of an array of pointers.
I tested this hadn't accidentally changed the wire format by disabling
version checks and using an old hsmd with the altered daemons and
running the test suite.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is such a simple struct that we can actually define it in csv.
This prevents us from accidentally breaking the ABI in future.
I tested this hadn't accidentally changed the wire format by disabling
version checks and using an old hsmd with the altered daemons and
running the test suite.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I'm about to update our utxo type, but Christian spotted that this is
part of the ABI for the hsm. So make that a private "hsm_utxo" type,
to insulate it from changes.
In particular, the HSM versions only contain the fields that the
hsm cares about, and the wire format is consistent (even though that
*did* include some of those fields, they are now dummies).
In the long term, this should be removed from the ABI: once we
no longer have "close_info" utxos, this information should already be
in the PSBT.
I tested this hadn't accidentally changed the wire format by disabling
version checks and using an old hsmd with the altered daemons and
running the test suite.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Not just the key index.
Also, remove FIXME: wallet_can_spend is no longer slow with lots of inputs!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're about to fix the feerate calculations in various places, and one
side effect is that we end up trying to add an empty anchor if none is
necessary (and failing, but we log a nasty message about it).
So don't do that, and fix the test which expected it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We actually need to mine another block, so that lightningd considers both
channels candidates for forgetting (and forgets the older one).
Reported-by: daywalker90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We say the offer amount arg can be either an `msat_or_any` or a `currency` string, but technically the order of evaluation is undefined, so it can check the other way, and it should not crash:
```
> offer = l3.rpc.offer(1000, 'test_pay_blindedpath_nodeaddr')
tests/test_pay.py:5692:
...
checker = <TypeChecker types={'array', 'bip340sig', 'boolean', 'currency', 'feerate', 'hash', 'hex', 'integer', 'msat', 'msat_or..._all', 'secret', 'short_channel_id', 'short_channel_id_dir', 'signature', 'string', 'txid', 'u16', 'u32', 'u64', 'u8'}>
instance = 1000
def is_currency(checker, instance):
"""currency including currency code"""
pattern = re.compile(r'^\d+(\.\d+)?[A-Z][A-Z][A-Z]$')
> if pattern.match(instance):
E TypeError: expected string or bytes-like object
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A log event LOG_TRACE submitted by a plugin was being logged as
**BROKEN** by lightningd before this commit.
Changelog-Fixed: plugins can now log events under the LOG_TRACE flag.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This broke my build machine, because lightningd --version was malformed
(I had no tags somehow in that branch).
I dived into the code to figure out what was wrong, and I was horrified.
1. STOP. Never write this much code.
2. You just need a NodeVersion class. That's it. No others.
3. Don't throw away the entire first part if it starts with 'v'. Just remove the v.
4. Handle untagged versions cleanly.
5. Always fail on invalid strings in the constructor, NOT on the first time you
use it.
I have rewritten it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids the docker image builders breaking with:
ERROR [linux/amd64 builder 15/17] RUN poetry export -o requirements.txt --without-hashes
0.780 pyproject.toml changed significantly since poetry.lock was last generated. Run Resolving dependencies... to fix the lock file.
This occurred when the default installation version changed underneath us.
Changelog-None
Implements the LSPS0 service plugin for core lightning
Changelog-Added: lsps-plugin: lsps0 service support
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Adds an async safe JSON-RPC V2 client for a generic transport layer. The
transport layer we will use later on are BOLT8 lightning messages.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
fundwallet() actually mines a block, putting our count out. If we see
both blocks at once, we will say "52" blocks instead of "51":
```
2025-05-02T05:28:40.5315155Z have_forgotten = l2.daemon.is_in_log(
2025-05-02T05:28:40.5315650Z r"UNUSUAL {}-chan#1: Forgetting channel: It has been 51 blocks without the funding transaction ".format(l1.info['id'])
2025-05-02T05:28:40.5316105Z )
2025-05-02T05:28:40.5316263Z
2025-05-02T05:28:40.5316417Z if dopay:
2025-05-02T05:28:40.5316616Z assert not have_forgotten
2025-05-02T05:28:40.5317056Z assert set([c['peer_id'] for c in l2.rpc.listpeerchannels()["channels"]]) == set([l1.info['id'], l3.info['id']])
2025-05-02T05:28:40.5317477Z else:
2025-05-02T05:28:40.5317662Z > assert have_forgotten
2025-05-02T05:28:40.5317887Z E assert None
```
```
0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#1: Forgetting channel: It has been 52 blocks without the funding transaction 0bb0579df6b1d983dda49dad47513afc71696c9d5bea3c8b955ba4b76bb053de getting deeply confirmed. We are fundee and can forget channel without loss of funds.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were supposed to put the sqlite db in a different directory, but
the test was wrong! So occasionally we would crash with:
```
Failed to commit DB transaction: Failed to commit a transaction: disk I/O error
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We try to do a JSON response if Python is not present, but it assumes sed. We should cleanly
exit on errors.
Before:
```
$ PATH=/tmp ./plugins/wss-proxy/wss-proxy
Something
./plugins/wss-proxy/wss-proxy: 12: sed: not found
{"jsonrpc":"2.0","id":,"result":{"disable":"No python3 binary found"}}
```
After:
```
$ PATH=/tmp ./plugins/wss-proxy/wss-proxy
something
./plugins/wss-proxy/wss-proxy: 12: sed: not found
```
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This finally happened on my local build machine, so I tracked it down using
py-spy, `apt-get install python3-dbg` and `py-local`.
Turns out the dev-memleak command was hanging, and the processes were stuck in
SIGSTOP. There are only two places we send that, and sure enough, this was
the test which was running at the time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
plugin_log inside after_send_scb_single was logging after sending peer storage
to each peer which could lead to spam in logs for big nodes, hence we should reduce
the log level to log_trace for it.
Changelog-Fixed: Suppress logs from chanbackup
This may be useful for their recovery, though they should see the spend onchain.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Protocol: We now reply to `channel_reestablish` even on long-closed channels.
This was always false. peer_start_channeld was called in various places
with the argument "NULL" instead of "false", which unfortunately compilers
didn't complain about :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Michael of Boltz told me this long ago, that when fees spiked some of their clients' opens got stuck. After two weeks their node forgot them, and when fees came back down the opens still failed. Unfortunately, I can't see an issue for this!
We can give some grace: we don't want to waste too many resources, but 100 channels is nothing.
The test needs to be adjusted to have *two* slow open channels, now.
Changelog-Changed: Protocol: we won't forget still-opening channels after 2016 blocks, unless there are more than 100.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're going to start loading them into memory for nicer responses if
people try to reestablish closed channels, but we don't care about ones
which were never actually opened. We could add a new state, but easier
to simply remove them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We are supposed to allocate of the ctx we're passed, not tmpctx.
Doesn't matter for now, because we don't use this result with anything which outlives tmpctx,
but we're going to:
```
==47574==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040005a8f38 at pc 0x55d3c584d252 bp 0x7ffddfb1b090 sp 0x7ffddfb1b088
READ of size 8 at 0x6040005a8f38 thread T0
#0 0x55d3c584d251 in json_add_closed_channel /home/runner/work/lightning/lightning/lightningd/closed_channel.c:27:3
#1 0x55d3c584ca5a in json_listclosedchannels /home/runner/work/lightning/lightning/lightningd/closed_channel.c:118:3
#2 0x55d3c58c0cbe in command_exec /home/runner/work/lightning/lightning/lightningd/jsonrpc.c:808:8
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Note that documentation says invoice expiries can batch, but that's no
longer true, so delete it. Usually, we miss a number because the
change is too fast.
This adds the wait interface, but it doesn't actually fire until the next
commit, which wires it into the db code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `wait` now supports the `htlcs` (`listhtlcs`) subsystem.
We're not going to increment one at a time for bulk deletion of htlcs
when a channel closes. There could be millions of HTLCs!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It makes the schema simpler, and indeed, expressable by GRPC.
Changelog-Added: JSON-RPC: `wait` now has separate `invoices`, `forwards` and `sendpays` objects for each subsystem.
Changelog-Deprecated: JSON-RPC: `wait` reply `details` object: use subsytem specific object instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The last argument is a pointer, but we were handing `false`. Which, for
terrible historic reasons, gets treated as NULL.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Requested-by: @whitslack
Closes: https://github.com/ElementsProject/lightning/issues/8233
Changelog-Added: JSON-RPC: `listpeerchannels` now has a `short_channel_id` parameter for just listing a specific channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
notleak() doesn't work for lightningd since the first span is created before
memleak (or anything else!) is initialized, so we have to mark it manually.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This doesn't happen very often, but can with autoclean.
However, we rarely traverse to the end, since we always expect to find
what we're looking for, and we fill from the front. So even a large
array (unless it's used) is fine.
Subtle: when we injected a parent, we used "active_spans" as the (arbitrary)
key. That can now change with reallocation, and so if that memory were reused
we could have a key clash. So we use "&active_spans" which doesn't change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't ever actually close the remote span (we don't have its key,
after all), and we keep a pointer to the parent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is much faster to give 64 bits of data, and we don't need
cryptographic randomness.
This brings us back to 413ns per trace.
Before:
real 0m5.819000-6.472000(6.2064+/-0.26)s
user 0m3.779000-4.101000(3.956+/-0.12)s
sys 0m2.040000-2.431000(2.2496+/-0.15)s
After:
real 0m3.981000-4.247000(4.1276+/-0.11)s
user 0m3.979000-4.245000(4.126+/-0.11)s
sys 0m0.000000-0.002000(0.001+/-0.00063)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightingd: trimmed overhead of tracing infrastructure.
There's an EBPF limit anyway, so stick with a 512-byte buffer.
This brings us back to 621ns per trace:
Before:
real 0m13.441000-14.592000(14.2686+/-0.43)s
user 0m11.265000-12.289000(11.9626+/-0.37)s
sys 0m2.175000-2.381000(2.3048+/-0.072)s
After:
real 0m5.819000-6.472000(6.2064+/-0.26)s
user 0m3.779000-4.101000(3.956+/-0.12)s
sys 0m2.040000-2.431000(2.2496+/-0.15)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Avoids allocations. Also assume that name and value parameters
outlive the trace span, so don't copy.
Before:
real 0m16.421000-18.407000(17.8128+/-0.72)s
user 0m14.242000-16.041000(15.5382+/-0.67)s
sys 0m2.179000-2.363000(2.273+/-0.061)s
After:
real 0m13.441000-14.592000(14.2686+/-0.43)s
user 0m11.265000-12.289000(11.9626+/-0.37)s
sys 0m2.175000-2.381000(2.3048+/-0.072)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. trace_span_start() is always called with a string literal, so
no copy needed (and we can use a macro to enforce this).
2. trace_span_tag() name and value are always longer-lived than
the span, so no need to copy these either.
Before:
real 0m18.524000-19.100000(18.7674+/-0.21)s
user 0m16.171000-16.833000(16.424+/-0.26)s
sys 0m2.259000-2.400000(2.337+/-0.059)s
After:
real 0m16.421000-18.407000(17.8128+/-0.72)s
user 0m14.242000-16.041000(15.5382+/-0.67)s
sys 0m2.179000-2.363000(2.273+/-0.061)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Testing parenting handling revealed several issues:
1. By calling "trace_span_start" when CLN_TRACEPARENT is set produces a bogus
entry, for which the span_id is overwritten so we never end it.
2. We don't need to close the remote parent when we close the first child: in
fact, this causes the remaining traces to be detached from the parent!
3. Suspension should return current to the parent, not to NULL.
Now the traces balance as we expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I added this debugging because the next test revealed a mismatch, so
I wanted to see where it was happening.
The comment in lightningd suggests it's possible, but I can't see any
code which suspends in the lightningd io_loop, so I cannot see how
this is triggered.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
With an average runtime of 18.7674, this implies 1876ns
per trace, which is far in excess of the 370ns claimed in
doc/developers-guide/tracing-cln-performance.md.
We also add a tag in there, so we measure that!
Results on my laptop:
real 0m18.524000-19.100000(18.7674+/-0.21)s
user 0m16.171000-16.833000(16.424+/-0.26)s
sys 0m2.259000-2.400000(2.337+/-0.059)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Introduced the use of UPDATE FROM syntax in SQLite queries,
which is not supported in versions prior to 3.33.0.
This causes issues on systems with older SQLite versions,
as reported in issue #8231. Rewrite the query in
migrate_convert_old_channel_keyidx() to use a subquery
with IN clause instead of UPDATE FROM, ensuring compatibility with
older SQLite versions.
Changelog-Fixed: db: replace UPDATE FROM syntax for SQLite compat
Fixes 68f3649d6b
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
```
cargo build --quiet --example cln-plugin-startup
error: failed to run custom build command for `cln-grpc v0.4.0 (/home/runner/work/lightning/lightning/cln-grpc)`
Caused by:
process didn't exit successfully: `/home/runner/work/lightning/lightning/target/debug/build/cln-grpc-1c0900b8d6f448d4/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-changed=proto/node.proto
cargo:rerun-if-changed=proto
--- stderr
thread 'main' panicked at cln-grpc/build.rs:7:10:
called `Result::unwrap()` on an `Err` value: Custom { kind: NotFound, error: "Could not find `protoc`. If `protoc` is installed, try setting the `PROTOC` environment variable to the path of the `protoc` binary. Try installing `protobuf-compiler` or `protobuf` using your package manager. It is also available at https://github.com/protocolbuffers/protobuf/releases For more information: https://docs.rs/prost-build/#sourcing-protoc" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
gmake: *** [cln-rpc/Makefile:15: target/debug/examples/cln-plugin-startup] Error 101
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
fatal: detected dubious ownership in repository at '/home/runner/work/lightning/lightning/external/libwally-core'
To add an exception for this directory, call:
git config --global --add safe.directory /home/runner/work/lightning/lightning/external/libwally-core
Reinitializing submodules src/secp256k1 ...
fatal: detected dubious ownership in repository at '/home/runner/work/lightning/lightning/external/libwally-core'
To add an exception for this directory, call:
git config --global --add safe.directory /home/runner/work/lightning/lightning/external/libwally-core
fatal: detected dubious ownership in repository at '/home/runner/work/lightning/lightning/external/libwally-core'
To add an exception for this directory, call:
git config --global --add safe.directory /home/runner/work/lightning/lightning/external/libwally-core
gmake: *** [external/Makefile:65: submodcheck] Error 128
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
| -- Found Python: /tmp/tmpyjjd1wyq/.venv/bin/python (found suitable version "3.11.11", minimum required is "3") found components: Interpreter Development.Module Development.SABIModule
| CMake Error at /tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/cmake/data/share/cmake-4.0/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
| Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
| Call Stack (most recent call first):
| /tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/cmake/data/share/cmake-4.0/Modules/FindPackageHandleStandardArgs.cmake:591 (_FPHSA_FAILURE_MESSAGE)
| /tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/cmake/data/share/cmake-4.0/Modules/FindPkgConfig.cmake:110 (find_package_handle_standard_args)
| CMakeLists.txt:35 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
| Traceback (most recent call last):
| File "/root/.local/lib/python3.10/site-packages/pyproject_hooks/_in_process/_in_process.py", line 389, in <module>
| main()
| File "/root/.local/lib/python3.10/site-packages/pyproject_hooks/_in_process/_in_process.py", line 373, in main
| json_out["return_val"] = hook(**hook_input["kwargs"])
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "/root/.local/lib/python3.10/site-packages/pyproject_hooks/_in_process/_in_process.py", line 280, in build_wheel
| return _build_backend().build_wheel(
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/hatchling/build.py", line 58, in build_wheel
| return os.path.basename(next(builder.build(directory=wheel_directory, versions=['standard'])))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/hatchling/builders/plugin/interface.py", line 147, in build
| build_hook.initialize(version, build_data)
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/scikit_build_core/hatch/plugin.py", line 125, in initialize
| self._initialize(build_data=build_data)
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/scikit_build_core/hatch/plugin.py", line 228, in _initialize
| builder.configure(
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/scikit_build_core/builder/builder.py", line 283, in configure
| self.config.configure(
| File "/tmp/tmpyjjd1wyq/.venv/lib/python3.11/site-packages/scikit_build_core/cmake.py", line 254, in configure
| raise FailedLiveProcessError(msg) from None
| scikit_build_core.errors.FailedLiveProcessError: CMake configuration failed
Note: This error originates from the build backend, and is likely not a problem with poetry but one of the following issues with coincurve (20.0.0)
- not supporting PEP 517 builds
- not specifying PEP 517 build requirements correctly
- the build requirements are incompatible with your operating system or Python version
- the build requirements are missing system dependencies (eg: compilers, libraries, headers).
You can verify this by running pip wheel --no-cache-dir --use-pep517 "coincurve (==20.0.0)".
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It didn't work, and it was downloading the Linux binary anyway!
```
2025-04-11 02:37:12 (1.61 MB/s) - ‘bitcoin-27.1-x86_64-linux-gnu.tar.gz’ saved [48920073/48920073]
tar: Error opening archive: Failed to open 'bitcoin-27.1-x86_64-linux-gnu.tar.bz2'
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
12 MiB to be downloaded.
[1/1] Fetching pkg-2.1.0.pkg: .......... done
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.21.3 to 2.1.0...
[1/1] Extracting pkg-2.1.0: .......... done
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'python38' have been found in the repositories
Error: The process '/usr/bin/bash' failed with exit code 1
```
Changelog-None: CI only
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Services that want to wrap the server implementation will need
access to the `NotificationStream` struct in order to pass
the stream through.
Changelog-Added: `cln-grpc` Exposed NotificationStream in the server module
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
def test_pay(node_factory):
> l1, l2 = node_factory.line_graph(2)
...
FAILED tests/test_pay.py::test_pay - OSError: AF_UNIX path too long
Changelog-None: symlink the socket to a tempfile which has a shorter path
Signed-off-by: Lakshya Singh <lakshay.singh1108@gmail.com>
get_channel_scid() returns the *first* channel, and we want all the channels.
So they may not actually be all visible in gossip.
```
@unittest.skipIf(TEST_NETWORK == 'liquid-regtest', "broken for some reason")
def test_hardmpp2(node_factory, bitcoind):
"""Credits to @daywalker90 for this test case."""
opts = {"disable-mpp": None, "fee-base": 0, "fee-per-satoshi": 10}
l1, l2, l3 = node_factory.get_nodes(3, opts=opts)
start_channels(
[
(l1, l2, 100_000),
(l1, l2, 200_000),
(l1, l2, 300_000),
(l1, l2, 400_000),
(l2, l3, 100_000),
(l2, l3, 200_000),
(l2, l3, 300_000),
(l2, l3, 600_000),
]
)
# FIXME: changing the last channel from 600k to 400k will fail the test due
# to l2 not accepting to forward any amount above 200k with error:
# CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED, still investigating
inv = l3.rpc.invoice("800000sat", "inv", "description")
> l1.rpc.call("renepay", {"invstring": inv["bolt11"]})
tests/test_renepay.py:797:
...
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: renepay, payload: {'invstring': 'lnbcrt8m1pnl3zfksp54n6vhkrcj0nkn2uqhf232v62539048u2ree4g9ssytm47gasgctspp58twj5xf4h57s4h0rhy55p5q6nry36glummjexsf4lc446je7y27qdqjv3jhxcmjd9c8g6t0dcxqyjw5qcqp9rzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqzqqqqqqqqqqqqqqqzsqqcrzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqpcqqqqqqqqqqqqqqzsqqcrzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqqgqqqqqqqqqqqqqqzsqqcrzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqpqqqqqqqqqqqqqqqzsqqc9qxpqysgqtgxcneu0u7xvetgh2kqmey86jssweneat5vx3fppuaphl9v9jweqa2ymczg9klau9jmsm6pm7m3cd28pggp7avuukjqxg63wy2vuvtcpggz4vt'}, error: {'code': 205, 'message': "minflow couldn't find a feasible flow: failed to find a feasible flow: find_admissible_path failed"}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The handshake targets were based on a false premise: that it is
impossible for any fuzzer to generate valid Act 1 or 2 packets. Niklas
Gogge proved this premise incorrect using AFL++ with the CMPLOG feature,
which enabled AFL++ to generate such valid packets.
We modify the targets to allow the scenario where the fuzzer finds these
valid packets and add the inputs AFL++ found to the corpus.
The cryptofuzz target was based on a false premise: that it is
impossible for any fuzzer to generate a valid ciphertext+MAC for the
decrypt function. Niklas Gogge proved this premise incorrect using AFL++
with the CMPLOG feature, which enabled AFL++ to generate such valid
messages.
We remove the assertions requiring decryption to fail and add the inputs
AFL++ found to the corpus.
BIP-141 specifies that a witness program must be between 2 and 40 bytes in
length. In our fallback address parsing, we were already checking the upper
bound, but missing the lower bound check. This commit adds validation to
ensure fallback address witness programs are at least 2 bytes long, bringing
our implementation in line with the spec and other implementations like
rust-lightning.
Changelog-Fixed: Enforced minimum witness program length of 2 bytes for
fallback addresses to comply with BIP-141 and prevent invalid decodings.
Also removes usage of pip due to this error that crops up on newer
versions of Ubuntu:
```
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.12/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
```
I've been recommending installing Poetry from the official
installer for the past several months and it always works.
Changelog-None
The workflow fails to trigger manually after recreating the release tag. It should support re-running even if the tag was previously deleted and recreated.
Changelog-None.
This happens with autoclean, which does a datastore request then frees
the parent command without waiting for a response (see clean_finished).
This leaks a trace, and causes a crash if the pointer is later reused.
My solution is to create a trace variant which declares the trace key
to be a tal ptr and then we can clean up in the destructor if this happens.
This fixes the issue for me.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: autoclean: fixed occasional crash when tracepoints compiled in.
This can happen with 24.11 and later. We scan back to exposed channel
opens, or that release.
The BROKEN log messages cause some tests to fail, so we fix those.
Fixes: https://github.com/ElementsProject/lightning/issues/8169
Changelog-Fixed: wallet: rescan for missing close outputs (can happen if peer doesn't support option_shutdown_anysegwit)
When we make mocks (which the next patch will do), these names cause a warning:
```
wallet/test/run-db.c:32:64: error: declaration of ‘bitcoind’ shadows a parameter [-Werror=shadow=compatible-local]
32 | void (*cb)(struct bitcoind *bitcoind UNNEEDED,
wallet/test/run-db.c:30:53: note: shadowed declaration is here
30 | struct bitcoind *bitcoind UNNEEDED,
wallet/test/run-db.c:33:51: error: declaration of ‘height’ shadows a parameter [-Werror=shadow=compatible-local]
33 | u32 height UNNEEDED,
wallet/test/run-db.c:31:40: note: shadowed declaration is here
31 | u32 height UNNEEDED,
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a bit more work to watch multiple addresses, but that's a small
price to pay for each channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We select the close key index at opening time, but the non-DF code didn't correctly register the
address as possibly used for P2WPKH for older nodes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: wallet: we could miss our own returned outputs on mutual closes if peer doesn't support option_shutdown_anysegwit (you will still need to rescan after update, if this happened to you!)
Reported-by: Grubles
1. Peer has to not support option_shutdown_anysegwit.
2. We have to restart between opening and closing the channel.
3. We won't see the to-us output, since it's p2wpkh not p2tr.
This bug was introduced in 24.11.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We pre-close incoming under some circumstances, so this does happen (it
didn't when this code was written). Don't walk all the HTLCs complaining
about them in this case, and don't freak out.
Changelog-Fixed: lightningd: incorrect spamming of log and potential crash on testnet case of duplicate HTLCs and slow closing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8176
It's not the *outgoing* HTLC which sets the deadline, it's the incoming.
Reported-by: @whitslack
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: Egregious anchor fee paid for unilateral close txs due to HTLC timeouts; it's not as urgent as our code made out!
chanbackup with many peers can do more than 128 concurrent rpc commands.
autoclean is the other plugin which can do many requests at once, so I
expect a similar issue there.
I tested this by rebuilding with `MAX_ACTIVE_SPANS` 1, which autoclean
tests triggered immediately.
The real fix is probably to use a hash table with a large initial size.
```
Mar 24 06:30:45 mlbb2 sh[28000]: chanbackup: common/trace.c:190: trace_span_slot: Assertion `s' failed.
Mar 24 06:30:45 mlbb2 sh[28000]: chanbackup: FATAL SIGNAL 6 (version v25.02)
Mar 24 06:30:45 mlbb2 sh[28000]: 0x5575232bac4f send_backtrace
Mar 24 06:30:45 mlbb2 sh[28000]: common/daemon.c:33
Mar 24 06:30:45 mlbb2 sh[28000]: 0x5575232baceb crashdump
Mar 24 06:30:45 mlbb2 sh[28000]: common/daemon.c:78
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958cd851f ???
Mar 24 06:30:45 mlbb2 sh[28000]: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958d2c9fc __pthread_kill_implementation
Mar 24 06:30:45 mlbb2 sh[28000]: ./nptl/pthread_kill.c:44
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958d2c9fc __pthread_kill_internal
Mar 24 06:30:45 mlbb2 sh[28000]: ./nptl/pthread_kill.c:78
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958d2c9fc __GI___pthread_kill
Mar 24 06:30:45 mlbb2 sh[28000]: ./nptl/pthread_kill.c:89
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958cd8475 __GI_raise
Mar 24 06:30:45 mlbb2 sh[28000]: ../sysdeps/posix/raise.c:26
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958cbe7f2 __GI_abort
Mar 24 06:30:45 mlbb2 sh[28000]: ./stdlib/abort.c:79
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958cbe71a __assert_fail_base
Mar 24 06:30:45 mlbb2 sh[28000]: ./assert/assert.c:94
Mar 24 06:30:45 mlbb2 sh[28000]: 0x7f2958ccfe95 __GI___assert_fail
Mar 24 06:30:45 mlbb2 sh[28000]: ./assert/assert.c:103
Mar 24 06:30:45 mlbb2 sh[28000]: 0x5575232ab7fa trace_span_slot
Mar 24 06:30:45 mlbb2 sh[28000]: common/trace.c:190
Mar 24 06:30:45 mlbb2 sh[28000]: 0x5575232abc9f trace_span_start
Mar 24 06:30:45 mlbb2 sh[28000]: common/trace.c:267
Mar 24 06:30:45 mlbb2 sh[28000]: 0x5575232a7c34 send_outreq
Mar 24 06:30:45 mlbb2 sh[28000]: plugins/libplugin.c:1112
```
Changelog-Fixed: autoclean/chanbackup: fixed tracepoint crash on large number of requests.
Fixes: https://github.com/ElementsProject/lightning/issues/8177
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We handed NULL as the logcb, resulting in a very uninformative crash:
```
2025-03-14T03:46:36.447Z INFO lightningd: Server started with public key 03d67f36c4f81789e2fe425028bacc96b199813eae426c517f589a45f1136c1fe5, alias Jubilee (color #dc42f4) and lightningd v25.02
topology: FATAL SIGNAL 11 (version v25.02)
0x560037f64aad send_backtrace
common/daemon.c:33
0x560037f64b49 crashdump
common/daemon.c:78
0x7f6c41ff351f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x0 ???
???:0
```
Changelog-Fixed: `topology` crash on invoice creation if a peer had a really high feerate.
Fixes: https://github.com/ElementsProject/lightning/issues/8156
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By limiting the commits that we look at to the changes since `master` we
can incrementally pull files under the coverage of these lints and checks.
Changelog-None: Not applicable, this is DX
We reconnect from l3->l2, but l2 is also trying to reconnect and
we can race:
```
# Now try when l3 uses scid for entry point of blinded path.
l3.stop()
l3.daemon.opts['dev-invoice-bpath-scid'] = None
l3.start()
> l3.rpc.connect(l2.info['id'], 'localhost', l2.port)
tests/test_pay.py:5667:
...
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: connect, payload: {'id': '022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59', 'host': 'localhost', 'port': 33557}, error: {'code': 402, 'message': 'disconnected during connection'}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By submitting them all at once, rather than serially, we should *definitely* hit the
ratelimit. We can also reduce the timeout (from 60 seconds) to speed the test up.
```
@pytest.mark.slow_test
def test_onionmessage_ratelimit(node_factory):
l1, l2 = node_factory.line_graph(2, fundchannel=False,
opts={'allow_warning': True})
offer = l2.rpc.call('offer', {'amount': '2msat',
'description': 'simple test'})
# Hopefully we can do this fast enough to reach ratelimit!
> with pytest.raises(RpcError, match="Timeout waiting for response"):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_pay.py:5825: Failed
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We play with directory permissions, but sqlites needs that, and sometimes (due to a timer, perhaps?)
it gets really upset about it:
```
lightningd-1 2025-03-16T23:29:58.506Z INFO lightningd: Server started with public key 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518, alias JUNIORBEAM-f91eb11-modded (color #0266e4) and lightningd f91eb11-modded
lightningd-1 2025-03-16T23:29:58.617Z DEBUG lightningd: Adding block 101: 55af171ade598f8c4f9a494eaaffe6b9f5ea64c7b0f3b273694148adf7ad7385
lightningd-1 2025-03-16T23:29:58.752Z TRACE lightningd: Calling rpc_command hook of plugin cln-xpay
lightningd-1 2025-03-16T23:29:58.764Z TRACE lightningd: Plugin cln-xpay returned from rpc_command hook call
lightningd-1 2025-03-16T23:29:58.784Z TRACE lightningd: Calling rpc_command hook of plugin cln-xpay
lightningd-1 2025-03-16T23:29:58.840Z TRACE lightningd: Plugin cln-xpay returned from rpc_command hook call
lightningd-1 2025-03-16T23:29:58.854Z TRACE lightningd: Calling rpc_command hook of plugin cln-xpay
lightningd-1 2025-03-16T23:29:58.865Z DEBUG gossipd: REPLY WIRE_GOSSIPD_NEW_BLOCKHEIGHT_REPLY with 0 fds
lightningd-1 2025-03-16T23:29:58.901Z **BROKEN** lightningd: Error executing statement: db/exec.c:108: UPDATE vars SET intval = intval + 1 WHERE name = 'data_version' AND intval = ?: attempt to write a readonly database
lightningd-1 2025-03-16T23:29:58.916Z **BROKEN** lightningd: Error executing statement: db/exec.c:108: UPDATE vars SET intval = intval + 1 WHERE name = 'data_version' AND intval = ?: attempt to write a readonly database
lightningd-1 2025-03-16T23:29:58.941Z **BROKEN** lightningd: FATAL SIGNAL 6 (version f91eb11-modded)
{'github_repository': 'ElementsProject/lightning', 'github_sha': 'f91eb118388dc1455c67d16079168fd0267ba248', 'github_ref': 'refs/pull/8112/merge', 'github_ref_name': 'HEAD', 'github_run_id': 13888173501, 'github_head_ref': 'flake-memleak', 'github_run_number': 12573, 'github_base_ref': 'master', 'github_run_attempt': '1', 'testname': 'test_setconfig_access', 'start_time': 1742167762, 'end_time': 1742167800, 'outcome': 'fail'}
----------------------------- Captured stderr call -----------------------------
Error executing statement: db/exec.c:108: UPDATE vars SET intval = intval + 1 WHERE name = 'data_version' AND intval = ?: attempt to write a readonly database
lightningd: FATAL SIGNAL 6 (version f91eb11-modded)
Log dumped in /tmp/lightning-crash.log.20250316232958
Lost connection to the RPC socket.Lost connection to the RPC socket.
=========================== short test summary info ============================
FAILED tests/test_misc.py::test_setconfig_access - AssertionError: Regex pattern did not match.
Regex: 'Cannot write to config file /tmp/ltests-22a5dz1j/test_setconfig_access_1/lightning-1/regtest/config'
Input: "RPC call failed: method: check, payload: {'command_to_check': 'setconfig', 'config': 'min-capacity-sat', 'val': 1000000}, error: Connection to RPC server lost."
ERROR tests/test_misc.py::test_setconfig_access - ValueError:
Node errors:
- lightningd-1: had BROKEN messages
- lightningd-1: Node exited with return code -6
```
So we move the db file for sqlite.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Enabling the cache makes signing significantly faster for segwit inputs,
particularly taproot which was designed with caching in mind.
Changelog-None
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>
Modified by Rusty:
- Simplify (we only need to suppress l1's txs, since it opens)
- Use synchronize_blockheight instead of log messages to ensure l2 has processed the block
- Use listpeerchannels instead of log messages for balance (should be more robust against changes)
- Open-code assertions for better debugging if they're wrong.
Since we included the spec for it, this is a good time to implement
it.
I also asked chatgpt to write some unit tests. I had to mangle them a
bit, but it probably saved me a few minutes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Unfortunately a spec typo means the data fields are missing (PR pending),
so we still patch those in.
The message "your_peer_storage" got renamed to "peer_storage_retrieval",
and the option "want_peer_backup_storage" was removed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `experimental-peer-storage` now only advertizes feature 43, not 41.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: RPC `listchannels` no longer includes private local channels (deprecated v23.08, disabled by default in v24.11).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: plugins which didn't accept string JSON RPC fields (deprecated v23.08, disabled by default in v24.11).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: allowing 0/1 instead of false/true for plugin options (deprecated v23.08, disabled by default in v24.11).
Changelog-Removed: --bind-addr and --addr on onion addresses and local sockets (deprecated v23.08, disabled by default in v24.11).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: connection/disconnection/block_added notification raw fields (deprecated v23.08, disabled by default in v24.11).
We haven't printed this since v24.08.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: listconfigs raw listing (deprecated v23.08, disabled by default in v24.11).
We now have to explicitly enable various deprecated commando commands, and now
when deprecations are disabled, we honour missing MPP option in bolt12 invoices.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we update the CLN_NEXT_VERSION, these will only be available with --i-promise-to-fix-broken-api-user.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In d18f564324 "pytest: stop using
deprecated commando_rune commands." we stopped using deprecated commands in these tests,
but we didn't remove the 'allow-deprecated-apis' flag.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
_in_ versions complain if used, _out_ don't (since we don't know if they are
going to use it). This was the wrong choice, and thus causes a BROKEN log
message when we update CLN_NEXT_VERSION.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The current docker build failed with Error `1.082 pyproject.toml changed significantly since poetry.lock was last generated. Run `poetry lock` to fix the lock file.`. Adding `poetry lock` command before `poetry export` will regenerate the lock file.
Changelog-None.
Really, any peer without a live channel is a bad prospect.
This requires us to wire the "enabled" flag through listincoming:
fortunately that's an internal, undocumented interface, so we don't
have a schema change.
Changelog-Fixed: Offline peers no longer selected for blinded paths..
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8127
This can happen if a descendent tx has no witness and we don't tell the main daemon
in time that we're not iterested.
Fixes: https://github.com/ElementsProject/lightning/issues/8133
Changelog-Fixed: lightningd: onchaind crash when seeing unrelated txs (usually when catching up with old closes)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In 6e4ff6a7d2 ("offers: add a blinded path
if we have no advertized address") we were overzealous, and set blinded
paths not just for offers and invoicerequests, but for invoices themselves.
This has revealed various interop issues (which is great, but not good
for our users!) so we should disable that. It also reduces the reliability
of payments in general.
Changelog-None: fixes previously overzealous addition
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Some enums, structs, functions in pyln-grpc-proto/cln-grpc/cln-rpc
have been slightly renamed so they follow grpc and rust's naming convention
We added twice, which caused spurious failures in real-world cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: https://github.com/hMsats
Fixes: https://github.com/ElementsProject/lightning/issues/8119
Changelog-Fixed: `xpay` would double the CLTV values in blinded paths, sometimes causing spurious failures.
Use larger CLTVs and we see the failure from l3, complaining the CLTV is outside
the amount in the payment_constraint field, like:
```
Failing HTLC because of an invalid payload (TLV 10 pos 104): cltv_expiry 609 > payment_constraint 376
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The old blindedpay fields would have an entry per hop, but that was changed
to a single per-path entry. The devtools hadn't caught up.
Similarly, it didn't like descriptionless offer fields in invreqs and invoices.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This corner case started triggering on my machine with latest Bitcoind.
This test sabotages the closing negotiation, and as a result l1
doesn't see l2's CLOSING_SIGNED. l2 is happy, however, and it is in
CLOSINGD_COMPLETE. When l1 reconnects, it gets an error, and this causes
it to drop the unilateral tx to chain.
This unilateral tx from l1 replaces or races the mutual close tx from
l2, causing a unilateral close, which breaks our test.
Though this is a corner case, it's much friendlier to allow the
closing negotiation again until we actually see the close onchain.
This fixes the tests here, too.
```
def test_closing_negotiation_reconnect(node_factory, bitcoind):
disconnects = ['-WIRE_CLOSING_SIGNED',
'+WIRE_CLOSING_SIGNED']
l1, l2 = node_factory.line_graph(2, opts=[{'disconnect': disconnects,
'may_reconnect': True},
{'may_reconnect': True}])
l1.pay(l2, 200000000)
assert bitcoind.rpc.getmempoolinfo()['size'] == 0
l1.rpc.close(l2.info['id'])
l1.daemon.wait_for_log(r'State changed from CHANNELD_NORMAL to CHANNELD_SHUTTING_DOWN')
l2.daemon.wait_for_log(r'State changed from CHANNELD_NORMAL to CHANNELD_SHUTTING_DOWN')
# Now verify that the closing tx is in the mempool.
bitcoind.generate_block(6, wait_for_mempool=1)
sync_blockheight(bitcoind, [l1, l2])
for n in [l1, l2]:
# Ensure we actually got a mutual close.
> n.daemon.wait_for_log(r'Resolved FUNDING_TRANSACTION/FUNDING_OUTPUT by MUTUAL_CLOSE')
tests/test_closing.py:275:
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: We now renegotiate an interrupted close, even if we don't need it, instead of sending an error.
This is a bit too much boilerplate for these, which mainly do the same
thing.
We add annotaitons to new_peer_fd so the compiler knows that it cannot
return NULL, otherwise with -O3 we get:
```
lightningd/peer_control.c: In function ‘peer_connected_hook_final’:
lightningd/peer_control.c:1388:28: error: ‘error’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1388 | take(towire_connectd_peer_send_msg(NULL, &channel->peer->id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lightningd/peer_control.c:1313:19: note: ‘error’ was declared here
1313 | const u8 *error;
| ^~~~~
lightningd/peer_control.c: In function ‘peer_spoke’:
lightningd/peer_control.c:1999:28: error: ‘error’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1999 | take(towire_connectd_peer_send_msg(NULL, &peer->id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:311: lightningd/peer_control.o] Error 1
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The vast majority of incoming channel updates seem to be cut due
to age, which results in noisy logs. Similarly, the chanbackup
logging verbosity might better match the equivalent actions in
channeld, which are at the debug level.
Fixes: #8058
Changelog-None: introduced in 25.02
If the nSequence in the tx it produces is not at least the value we
test in the script, the tx will always fail:
```
error code: -26\nerror message:\nmandatory-script-verify-flag-failed (Locktime requirement not satisfied)
```
If we have a lease, the nSequence is max(lease-time-remaining,
to-self-delay), so have onchaind tell lightningd the correct nSequence.
Fixes: https://github.com/ElementsProject/lightning/issues/7460
Reported-by: https://github.com/pabpas
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: Correctly collect our own (delayed) funds if we have a unilateral close when we are still offering a lease.
current height + to_self_delay[LOCAL] is correct normally, but if we
have an outstanding lease it's longer. Not a big issue, because
lightningd will retry until its spendable, but wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What we expect to happen:
1. l3, which unilaterally closed, waits 4032 blocks (minus those mined) before
trying to send get its "to_local" funds back.
2. This should then succeed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There are other ways we can disable it, of course (e.g full path name)
but this is the most obvious.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is neater than appending to some random file: we only do that once
if there's no "include" line to include a ".setconfig" file.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `setconfig` now has a `transient` flag which means it won't rewrite your config file.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The chanbackup plugin should update emergency.recover every time we
receive a new commitment secret.
Additionally, chanbackup should be able to serialize both the new
SCB format and the legacy format.
Key Changes:
- Added a commitment_revocation plugin hook to update emergency.recover whenever a new revocation secret is received.
- Implemented support for the new emergency.recover format while maintaining compatibility with the legacy format.
This function enables direct persistence of shachain data, ensuring all relevant information is saved upon retrieval.
Key Changes:
- Adds 'wallet_stub_shachain_init' function to store a retrieved shachain in the database.
- Saves initial metadata ('min_index' and 'num_valid') to the 'shachains' table.
- Iterates through known shachain secrets, adding each entry to 'shachain_known' with position, index, and hash.
These fields enhance 'stub_chan' to make channels which are capable to
create penalty transaction in case the peer broadcasts an old revoked state.
Key Changes:
- Added new params to stub_chan() to accomodate shachain, basepoints, opener, and remote_to_self_delay
- Check if any field is NULL inside scb_chan->tlvs and assign them appropriately
We define a new subtype 'modern_scb_chan' and a new tlvtype 'scb_tlvs' which includes
all the relevant information to create a penalty transaction when the peer tries to cheat.
Key Changes:
- Rename the old format to 'legacy_scb_chan' and define a new type 'modern_scb_chan'
- Include TLVs to 'modern_scb_chan'
- Create a new msgtype 'static_chan_backup_with_tlvs'
- Modify 'struct channel' to include 'struct modern_scb_chan'
- Add these two types to 'varsize_types' in generate.py
This change allows adding a length prefix to a serialized TLV. It will
be particularly useful for serializing all 'scb_chan' entries in
the 'emergency.recover' file.
Key Changes:
- Removed the need to loop in towire_tlv and fromwire_tlv, so the if conditions have been modified accordingly.
- During serialization, the length of the TLV is calculated before appending it, and it is stored in a temporary variable.
- For fromwire_tlv, only a simple length adjustment is required, and no loop is needed here either.
This change will allow subtypes in wiregen files to have tlvstreams.
Shifting tlv structs above subtypes in header_template is done to prevent
forward declaration.
Since generate-wire prepends 'tlv_' in tlvname, we
have to modify fromwire_subtype_field and towire_subtype_field in
impl_template to accommodate this.
Changelog-Added: This PR would turn our peers into watchtower and enable SCB to create penalty txn.
The parameter max_htlc_value_in_flight_msat stablished by peers on
channel opening (BOLT02) can now be retrived from the
gossmods_from_listpeerchannels API.
Adapted the corresponding callback functions in renepay and askrene to
take into account that value as a constraint to the value we can send
through a channel.
Changelog-Add: fetch max_htlc_value_in_flight_msat from gossmods_listpeerchannels API
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: JSON-RPC: `listpeerchannels` new output fields `their_max_total_htlc_out_msat` and `our_max_total_htlc_out_msat` as the value of `max_htlc_value_in_flight` (as of BOLT02) set by the local and remote nodes on channel creation.
Changelog-Deprecated: JSON-RPC: `listpeerchannels` value `max_total_htlc_in_msat`: use `our_max_total_htlc_out_msat` instead to follow spec naming convention.
Otherwise, deprecating a field causes SELECT * to fail:
```
> l1.rpc.sql(f"SELECT * FROM peerchannels;")
...
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: sql, payload: ('SELECT * FROM peerchannels;',), error: {'code': -1, 'message': 'query failed with access to peerchannels.max_total_htlc_in_msat is prohibited (Deprecated column table peerchannels.max_total_htlc_in_msat)'}
```
So if they use a wildcard, allow access: though "SELECT *" is fraught,
"COUNT(*)" is perfectly legit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The `enableoffer` JSON schema is present, but it is not included in the `GENERATE_MARKDOWN` list within the Makefile. This resulted into missing `.7` and `.7.md` files, leading to missing manpage and the documentation portal page.
Changelog-None.
Eduardo points out that payment_failed kind of over-promises: it may
actually not fail the payment now (with slow mode).
It's more an indiciation that we're not trying any more payment parts,
so rename it to payment_give_up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can create this scenario by having one path force close. We take
the opportunity to log this, even in non-slow-mode, since it's interesting
(not our bug, but someone just lost money!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This was requested by Michael of Boltz; it's mainly useful if you plan to
try failed payments on a *different* node. In that case, there's a
theoretical possibility that slow parts of this payment could combine with
that from a different node and overpay.
We don't allow this from the same node, already.
Changelog-Added: xpay: `xpay-slow-mode` makes xpay wait for all parts of a payment to complete before returning success or failure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Don't rely on the current attempt, make caller calculate total.
2. Save preimage inside attempt, for slow mode.
3. Hoist it higher in the file.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When tests CI on occur the version number has the following shape "1a86e50-modded".
We will always assume this is the latest version to make the version
checks pass
The fixtures in `tests/fixtures.py` modifies the path to
`lightningd/lightningd`.
I've adapted `pyln-testing` to accept an executable in the constructor.
This approach is more transparant and allows us to use the executable
path to query the version in the constructor.
Christian reported that this flag doesn't work on restart.
Indeed, it made us attempt *transient* rather than *persistent*
connections, but we still told connectd to connect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: connectd: `dev-no-reconnect-private` is respected on restart.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: lightning-cli: `help` messages using new-lines is now printed properly, enhancing readability and consistency.
Changelog-Changed: Interpret \n as the line separator in plugins to enhance the readability of lightning-cli help.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
[ Modified to use \n not | --RR ]
The `doc` variable was being initialised and processed but not used anywhere.
Changelog-None
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
Don't print unnecessary log entries every time we receive an rpc_command
hook event. Only log when `pay` is called.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Following 6e4ff6a, nodes now check for their public address and
generate a blinded path for invoices if the address is not advertized.
This breaks several of the tests where the blinded path is expected
to have the entrypoint be the node itself.
Changelog-None
When we merged blinded paths for nodes with no address
(6e4ff6a7d2), this test
broke. We need to prevent that, otherwise:
```
> assert ret['successful_parts'] == 2
E assert 1 == 2
tests/test_xpay.py:677: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It wasn't documented, and hopefully nobody was using it.
Changelog-Fixed: `decode` for bolt12 invoices "features" field renamed to "invoice_features" (as documentation said)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Turns out we weren't wiring them through! And libplugin wasn't reading them anyway.
Changelog-Fixed: lightningd: tell plugins our bolt12 features (so our bolt12 invoices explicitly allow MPP).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is deeply annoying, and we may have to support this properly
(using a separate algorithm entirely) if other implementations don't
fix their crap.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: xpay: suppress multi-part payment if invoice doesn't allow it (please, fix your nodes!)
This is an inefficient hack. Can you tell I really didn't want to
implement this? MPP was finalized in 2018 FFS.
We do this by adding another "auto" layer, which removes all too-small
channels, and then makes our MPP node pile all the funds into the largest
channel it chooses.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, if the total amount we're sending is less than the minimum amount
the channel insists on, we can eliminate it.
This fixes the problem that we're really trying to send a de-minumus
amount (rather than the more obscure case where we divide the amount
and then it is below the minimum).
After trying several other approaches, this was by far the cleanest!
Reported-by: https://github.com/JssDWt
Fixes: https://github.com/ElementsProject/lightning/issues/8045
Changelog-Fixed: xpay: don't simply give up if our total amount is less than htlc_minimum_msat on some channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Suggested-by: Matt Corallo
Fixes: https://github.com/ElementsProject/lightning/issues/7806
Changelog-Changed: Offers: we will use a blinded path if we have no advertized address (so payers wouldn't be able to connect directly).
I should have done this immediately after last release :(.
This turns various things off by default, even if deprecated APIs are enabled.
We remove the test of the to-be-removed params.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: Config: `rest-port`, `rest-protocol`, `rest-host` and `rest-certs` disabled by default (use clnrest-*, or `i-promise-to-fix-broken-api-user=rest-port.clnrest-prefix` etc and PLEASE REPORT if you need this!)
Changelog-Deprecated: Config: `max-locktime-blocks` disabled by default (use `i-promise-to-fix-broken-api-user=max-locktime-blocks` and PLEASE REPORT if you need this!)
These are about to start logging warnings, so use modern versions for tests
which aren't explicitly about testing obsolete ones.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This happened in CI:
```
algrind error file: valgrind-errors.16800
==16800== Thread 4 tokio-runtime-w:
==16800== Conditional jump or move depends on uninitialised value(s)
==16800== at 0x2466BF: _ZN175_$LT$axum..middleware..from_fn..FromFn$LT$F$C$S$C$I$C$$LP$T1$C$T2$C$T3$RP$$GT$$u20$as$u20$tower_service..Service$LT$http..request..Request$LT$axum_core..body..Body$GT$$GT$$GT$4call28_$u7b$$u7b$closure$u7d$$u7d$17h4cc36de5dd56d9feE.llvm.119371497468325184 (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x57BFFA: <axum::middleware::from_fn::ResponseFuture as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x37312B: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372D8D: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372F59: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x373A88: <tower::util::map_response::MapResponseFuture<F,N> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x32100D: <tower::util::oneshot::Oneshot<S,Req> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x38E326: _ZN91_$LT$axum..routing..route..RouteFuture$LT$E$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h3f11114fc5dd51f8E.llvm.194396656150191000 (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372315: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372C05: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x371A15: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x373A48: <tower::util::map_response::MapResponseFuture<F,N> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800==
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Searches the first unused groupid and uses that number for the current
payment attempt.
We previously used the highest value of used groupid + 1, which breaks
in a few corner cases.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Change functions json_pay and json_paystatus to json_renepay
and json_renepaystatus to match the conventional naming.
This is helpful for grep searches.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
On lookup, we update the htable if any new addresses have been added.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: startup time vastly improved for large nodes with pending closes and many bitcoin addresses.
It was long obsoleted, and never appears in the DB, but we do still have
to handle old ones in the code.
We removed it from the enum in
f342630b92 (v24.02) after deprecating it
in 23.02.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From Whitslack's "startup takes 15 minutes" bug report, we can see
that wallet_can_spend is extremely slow. We exacerbate this by setting a large
bip32_max_index:
```
91.29% 0.02% lightningd lightningd [.] wallet_can_spend
|
--91.27%--wallet_can_spend
|
|--47.81%--scriptpubkey_p2tr_derkey
| |
| |--42.80%--scriptpubkey_p2tr
...
|--42.16%--bip32_key_from_parent
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In a previous [commit](https://github.com/ElementsProject/lightning/pull/8065/commits), I mistakenly removed the `lightning-` replacement logic from the base name also. This commit restores that functionality to re-enable schema checks.
Changelog-None.
When paying with injectpaymentonion we need to manually decode the error
from the onion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Always use a fake destination node, the self-payments are no longer a
corner case for the routing problem in this way. Also it is ok for
get_routes to return routes with zero length.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Use injectpaymentonion for payments with |routes|=0,
ie. self-payments and blinded paths where our node is
the first node in the blinded path.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Collect the shared secrets when making a payment request.
We would need this if we use injectpaymentonion instead of sendonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Refactor create_onion function, now we could use the same function to
build onions for sendonion and injectpaymentonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
sendonion RPC does not allow to set the total amount in lightningd's
wallet, therefore it mixing sendpay and sendonion payment parts would
not work. That means for the time being we cannot complete a payment
initialized with sendpay until we add a total_amount parameter to
sendonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Fix error handling since we moved from sendpay to sendonion rpc.
With sendonion once a route fails we don't get the scid and node_id that
failed along the route, so we have to deduce those from our own internal
data.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Use renesendpay to send the payment allowing to pay to BOLT12 invoices
from a higher level interface.
Changelog-Add: renepay: Add support for BOLT12 payments
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changing route.amount to route.amount_deliver
for clarity. This variable hold the value that
the route delivers to destination.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Add an rpc to renepay that is similar to sendpay that
handles BOLT11 and BOLT12 payments.
This is not the most elegant solution but it is a workaround
until we implement it into lightningd which has more development
friction.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
[Added version tag into documentation, to show it was added in 25.02 --RR]
Changelog-Added: Plugins: new nofitications `plugin_stopped` and `plugin_started`
Otherwise it appears to be a leak:
==612637== 11,264 bytes in 1 blocks are still reachable in loss record 1 of 1
==612637== at 0x484D953: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==612637== by 0x1301F2: trace_init (trace.c:153)
==612637== by 0x13065D: trace_span_start (trace.c:263)
==612637== by 0x173968: db_open_ (utils.c:367)
==612637== by 0x17AE43: create_test_wallet (run-wallet.c:1313)
==612637== by 0x17C726: test_shachain_crud (run-wallet.c:1548)
==612637== by 0x18300E: main (run-wallet.c:2329)
Changelog-None
In the time it takes connectd to flush the log message for
, gossipd can already have
the announcement sent.
lightningd-1 2025-02-11T15:26:06.745Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_in WIRE_ANNOUNCEMENT_SIGNATURES
lightningd-2 2025-02-11T15:26:06.887Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#1: peer_in WIRE_ANNOUNCEMENT_SIGNATURES
lightningd-1 2025-02-11T15:26:06.897Z TRACE gossipd: Received node_announcement for node 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518
lightningd-1 2025-02-11T15:26:06.915Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_out WIRE_ANNOUNCEMENT_SIGNATURES
Changelog-None
Reported by Grubles on ARM64:
```
VALGRIND=1 valgrind -q --error-exitcode=7 --track-origins=yes --leak-check=full --show-reachable=yes --errors-for-leak-kinds=all common/test/run-tal_arr_randomize > /dev/null
==151138== Source and destination overlap in memcpy(0x4d69f08, 0x4d69f08, 8)
==151138== at 0x48CB68C: __GI_memcpy (vg_replace_strmem.c:1147)
==151138== by 0x41B50B: tal_arr_randomize_ (pseudorand.c:84)
==151138== by 0x41BB07: main (run-tal_arr_randomize.c:166)
==151138==
make: *** [Makefile:750: unittest/common/test/run-tal_arr_randomize] Error 7
```
It is correct: you can't overlap src and dst in memcpy. It *probably* works in
this case, but it's undefined!
Fixes: https://github.com/ElementsProject/lightning/issues/7030
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After analyzing various weird cases where we ended up with duplicate
gossip_store entries, it could be explained by us not fully processing
the gossip store.
It's not clear that my assumptions that we would always see our own writes
are true: technically this may require an fsync(). So we now add the
check, and do an fsync and try again.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: gossipd: more sanity checks that we are correctly updating the gossip_store file.
We had at least one report of overwriting the gossip_store file at
offset 1. Make sure this doesn't happen.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's actually the only one that uses it. We also tweak the way
gossip_store handles failure: gossmap_manage now tells it when to
reset the corrupted store.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Instead of making a copy.
To measure the performance impact, I timed
tests/test_askrene.py::test_real_biases on my laptop.
No checksum check: 194.52s
Copying for checksum check: 202.81s
Zero-copy checksum check: 194.40s
But these numbers proved noisy. Still, doesn't hurt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We assume if it's incorrect, we simply need to wait. If this proves incorrect,
we will see a stream of BROKEN log messages.
To measure the performance impact, I timed
tests/test_askrene.py::test_real_biases on my laptop.
Before: 194.52s
After: 202.81s
So it's marginal.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
While this shouldn't happen, it does (pending other fixes), and we stop reading the
gossip store until next time. The result is partial gossip, demonstrated beautifully
by NicolasDorier's report:
```
lightning_gossipd: gossmap: redundant channel_announce for 864063x1306x1, offsets 1272259 and 1784859!"
```
Gossipd stalld there and don't make more progress. So gossipd itself
doesn't see the entire gossip_store.
Then things get really batshit:
```
2025-02-04T05:53:28.582Z DEBUG gossipd: Store compact time: 1429910 msec
```
This took 1429 seconds to process. Why?
Because it hasn't been processing the gossip store fully, gossipd kept adding "new" records to the end:
```
2025-02-04T05:53:28.583Z DEBUG gossipd: gossip_store: Read 62716143/1739952/5158256/0 cannounce/cupdate/nannounce/delete from store in 31634458462 bytes, now 31634458440 bytes (populated=true)
```
It has 31GB of gossip in there! No wonder it took so long...
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8035
Changelog-Fixed: gossipd: corruption in the gossip_store could cause ever-longer startup times and no gossip updates.
Default goes to stderr for LOG_UNUSUAL and higher.
We have to whitelist more cases in map_catchup so we don't spam the logs
with perfectly-expected (but ignored) messages though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only use it in one place, and that was simply to share an fd between
gossipd writing and gossipd reading, which may be causing our zfs problem
anyway.
In fact, it fixes a race if we don't have HAVE_PWRITEV.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have a report of this happening under ZFS. We cannot do much if
this really is a problem where we can't read back what we write, but
this avoids the immediate crash.
Fixes: https://github.com/ElementsProject/lightning/issues/7971
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: gossmap: occasional crash (at least on ZFS) reading gossip_store.
In 4e7ba96729 (ightningd: don't kill onchaind
if we are forcing a disconnect.) actually was something which happened
in our generate examples script.
This updates that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
plugins/Makefile has target/${RUST_PROFILE}/cln-grpc depend on the
generated files via $(MSGGEN_GENALL), but cln-rpc/Makefile adds to
that variable, so needs to be included first.
Here's an example build error:
```
Combining schemas from /home/rusty/lightning-ltest/doc/schemas into /home/rusty/lightning-ltest/contrib/msggen/msggen/schema.json
Created /home/rusty/lightning-ltest/contrib/msggen/msggen/schema.json from 2 files
error: failed to run custom build command for `cln-grpc v0.3.0 (/home/rusty/lightning-ltest/cln-grpc)`
Caused by:
process didn't exit successfully: `/home/rusty/lightning-ltest/target/debug/build/cln-grpc-95489e3ba33c0ab3/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-changed=proto/node.proto
cargo:rerun-if-changed=proto
--- stderr
thread 'main' panicked at cln-grpc/build.rs:7:10:
called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: node.proto:134:52: \"AskreneageResponse\" is not defined.\nnode.proto:135:23: \"GetroutesRequest\" is not defined.\nnode.proto:135:50: \"GetroutesResponse\" is not defined.\nnode.proto:136:32: \"AskrenedisablenodeRequest\" is not defined.\nnode.proto:136:68: \"AskrenedisablenodeResponse\" is not defined.\nnode.proto:137:34: \"AskreneinformchannelRequest\" is not defined.\nnode.proto:137:72: \"AskreneinformchannelResponse\" is not defined.\nnode.proto:138:34: \"AskrenecreatechannelRequest\" is not defined.\nnode.proto:138:72: \"AskrenecreatechannelResponse\" is not defined.\nnode.proto:139:34: \"AskreneupdatechannelRequest\" is not defined.\nnode.proto:139:72: \"AskreneupdatechannelResponse\" is not defined.\nnode.proto:140:32: \"AskrenebiaschannelRequest\" is not defined.\nnode.proto:140:68: \"AskrenebiaschannelResponse\" is not defined.\nnode.proto:141:37: \"AskrenelistreservationsRequest\" is not defined.\nnode.proto:141:78: \"AskrenelistreservationsResponse\" is not defined.\nnode.proto:142:32: \"InjectpaymentonionRequest\" is not defined.\nnode.proto:142:68: \"InjectpaymentonionResponse\" is not defined.\nnode.proto:143:18: \"XpayRequest\" is not defined.\nnode.proto:143:40: \"XpayResponse\" is not defined.\nnode.proto:145:33: \"StreamBlockAddedRequest\" is not defined.\nnode.proto:145:74: \"BlockAddedNotification\" is not defined.\nnode.proto:146:40: \"StreamChannelOpenFailedRequest\" is not defined.\nnode.proto:146:88: \"ChannelOpenFailedNotification\" is not defined.\nnode.proto:147:36: \"StreamChannelOpenedRequest\" is not defined.\nnode.proto:147:80: \"ChannelOpenedNotification\" is not defined.\nnode.proto:148:30: \"StreamConnectRequest\" is not defined.\nnode.proto:148:68: \"PeerConnectNotification\" is not defined.\nnode.proto:149:32: \"StreamCustomMsgRequest\" is not defined.\nnode.proto:149:72: \"CustomMsgNotification\" is not defined.\n" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
make: *** [plugins/Makefile:305: target/debug/cln-grpc] Error 101
make: *** Waiting for unfinished jobs....
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't update this when we extended the timeout to 120 seconds in
ee3133f198 ("lightningd: increase
startup time for plugins to 120 seconds.")
```
def test_failing_plugins(directory):
fail_plugins = [
os.path.join(os.getcwd(), 'contrib/plugins/fail/failtimeout.py'),
os.path.join(os.getcwd(), 'contrib/plugins/fail/doesnotexist.py'),
]
for p in fail_plugins:
> with pytest.raises(subprocess.CalledProcessError):
E Failed: DID NOT RAISE <class 'subprocess.CalledProcessError'>
tests/test_plugin.py:420: Failed
----------------------------- Captured stdout call -----------------------------
{'github_repository': 'ElementsProject/lightning', 'github_sha': '83dca18c5e9610bfaac766f957387b9a1ec48f50', 'github_ref': 'refs/pull/7887/merge', 'github_ref_name': 'HEAD', 'github_run_id': 13253210143, 'github_head_ref': 'guilt/bolt-updates-after-24.11', 'github_run_number': 12237, 'github_base_ref': 'master', 'github_run_attempt': '2', 'testname': 'test_failing_plugins', 'start_time': 1739239278, 'end_time': 1739239340, 'outcome': 'fail'}
=========================== short test summary info ============================
FAILED tests/test_plugin.py::test_failing_plugins - Failed: DID NOT RAISE <class 'subprocess.CalledProcessError'>
============= 1 failed, 80 passed, 2 skipped in 855.37s (0:14:15) ==============
```
We can actually delete it before counters are updated:
```
wait_for(lambda: len(l3.rpc.listinvoices()['invoices']) == 2)
> assert l3.rpc.autoclean_status()['autoclean']['expiredinvoices']['cleaned'] == 3
E assert 1 == 3
tests/test_plugin.py:3266: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We thought it was a good idea to terminate channel subds, but we included onchaind as well!
```
2025-01-29T21:31:46.053Z UNUSUAL 03…00-channeld-chan#255683: Adding HTLC 1737 too slow: killing connection
2025-01-29T21:31:46.053Z INFO 03…00-chan#255683: Peer transient failure in CHANNELD_NORMAL: Adding HTLC timed out: killed connection
2025-01-29T21:31:46.053Z DEBUG 03…00-channeld-chan#255683: Status closed, but not exited. Killing
2025-01-29T21:31:46.054Z DEBUG 03…00-chan#255683: Failing HTLC 1738 due to peer death
2025-01-29T21:31:46.058Z DEBUG 03…00-chan#255683: Failing HTLC 1737 due to peer death
2025-01-29T21:31:46.058Z DEBUG 03…00-chan#255673: Forcing disconnect due to One channel had an error
2025-01-29T21:31:46.059Z DEBUG 03…00-onchaind-chan#255673: Status closed, but not exited. Killing
2025-01-29T21:31:46.093Z DEBUG 03…00-connectd: disconnect_peer
2025-01-29T21:31:46.093Z DEBUG 03…00-lightningd: peer_disconnect_done
```
Reported-by: @whitslack
Fixes: https://github.com/ElementsProject/lightning/issues/8055
Changelog-Fixed: onchaind: don't die if we fail an unrelated channel with the same peer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Raspberry Pi, with bitcoind running and full gossip topology may actually hit
this, and we have a report in practice.
Note that the comment is wrong, so fix that too.
Fixes: https://github.com/ElementsProject/lightning/issues/7724
Reported-by: m-schmoock
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently, pyln tests fail if the `lightning-` prefix is removed from schema/*.json files. In this release, we will update pyln to remove its reliance on this prefix, and in the next release, we will remove the prefixes from the files as well.
Changelog-None.
Test flake where the balance for lightning-2 went negative
```
> assert account_balance(l2, channel_id) == 0
tests/test_closing.py:1314:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tests/utils.py:183: in account_balance
m_sum -= Millisatoshi(m['debit_msat'])
contrib/pyln-client/pyln/client/lightning.py:193: in __sub__
return Millisatoshi(int(self) - int(other))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = -10000msat, v = -10000
```
Led me to look into this test. lightning-2 should go negative since we
roll back the amounts it's received by going to a prior database state.
Rather than trying to do the right thing with obviously broken node
records, instead we just stop trying to account for them correctly
(impossible).
I also noticed that the anchor tests were failing the utxo output
matchup, which we should be asserting on it. The HTLC RBF that our
anchor code creates was causing an issue by creating another wallet
deposit utxo under the HTLC output. We now optionally add this utxo
in the case that anchors are turned on.
Changelog-None: Fix test flake
It's really hard to tell what on earth went wrong when a coin movement
check fails, since we dont' return good error info.
Here we replace almost every `assert` with a proper check + error with
message to help make debugging easier.
cc @rustyrussell
Changelog-None: improve failure messages
If a user tries to do a splice without signing their inputs we now provide them with a nice error message and cancel the RPC since that wouldn’t be productive for the user anyway.
We also add a helpful message if they do the opposite — try to sign a PSBT where they did not add any inputs.
Changelog-Changed: Update prevents users from trying to splice unsigned PSBTs — protecting against potential issues.
Sure, we have to convert to and from the db set-of-pairs, but that's far simpler
than dealing with the current structure now we want to add code to *remove* from
the blacklist.
Changelog-Changed: JSON-RPC: `blacklistrune` no longer supports of runes over id 100,000,000.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This migration was introduced in dccbccf8f2 (pre 23.08), so the only way they
would need this is if they migration straight from 23.05 to 25.02. And then
the solution is to migration to a prior one first, but I'll bet good money
we never, ever see this message:
Commando runes still present? Migration removed in v25.02: call Rusty!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When building from a release zipfile and there is no `git` present, the version number lacks a ‘v’.
This triggers db.c to fail it’s `is_released_version` check, which fails because the version not start with a ‘v’ — thereby the database upgrade is rejected.
Issue reported by TonyV on Discord:
“Hey guys, I just upgraded to the latest release and am now getting
```
Refusing to irreversibly upgrade db from version 219 to 261 in non-final version 24.11.1 (use --database-upgrade=true to override)
```
I have the db backed up... but am I good to make those changes without breaking my channels?”
Changelog-Changed: Fix for people upgrading using source release zip packages.
test_closing_different_fees fails:
```
2024-10-14T08:43:30.2733614Z
2024-10-14T08:43:30.2734133Z # Now wait for them all to hit normal state, do payments
2024-10-14T08:43:30.2735205Z > l1.daemon.wait_for_logs(['update for channel .* now ACTIVE'] * num_peers
2024-10-14T08:43:30.2736233Z + ['to CHANNELD_NORMAL'] * num_peers)
2024-10-14T08:43:30.2736725Z
2024-10-14T08:43:30.2736903Z tests/test_closing.py:230:
...
2024-10-14T08:43:30.2761325Z E TimeoutError: Unable to find "[re.compile('update for channel .* now ACTIVE')]" in logs.
```
For some reason one of the channel_update injections does *not* evoke this message
from gossipd...
Changelog-None: debug!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Moved the `Usage` section further down in `createrune` and `commando-rune` for improved UX.
- Added a new example for creating a rune with `read-only` restrictions, extending it to allow only payments of `less than 100,000 sats per day` using the `pay` or `xpay` methods.
- Adjusted formatting by appending an extra space after the `dependentUpon` condition, fixing `[*start* [*end*]][*relist*]` to `[*start* [*end*]] [*relist*]`.
- Relocated `Examples` from the expandable section to a standard heading, as examples are now already placed at the end of the page.
Changelog-None.
After merging the Rust-based `clnrest` plugin into the master, all three reproducible build scripts failed with the following error:
```
error: package `socketioxide v0.15.1` cannot be built because it requires rustc 1.75.0 or newer, while the currently active rustc version is 1.73.0
Either upgrade to rustc 1.75.0 or newer, or use
cargo update -p socketioxide@0.15.1 --precise ver
where `ver` is the latest version of `socketioxide` supporting rustc 1.73.0
make: *** [plugins/Makefile:304: target/release/clnrest] Error 101
```
To resolve this, we can either downgrade `socketioxide` to `v0.11.1`, which is compatible with `Rust >=v1.67` OR Upgrade Rust to `v1.75`.
Since the latest Rust version is `1.84`, upgrading to `1.75` seems like a reasonable choice, as it is already 13 months old.
Changelog-None.
If you re-run a node several times, the log file fills with info from
previous runs. To avoid looking at old logs, only parse the most recent
run's logs when looking for the magic CLN rest startup/deactivated
strings
Changelog-Fixed: startup-regtest.sh now only inspects the most recent run's logs for the active status of the clnrest plugin
We used to not print what happened with an HTLC in the `pay`
plugin. This meant that to follow the HTLCs we'd have to map the `pay`
HTLCs to the `lightningd` HTLCs, and then trace that. BY having `pay`
print the outcome as it sees it, we can make that tracking much
simpler, even allowing for tooling to do it for us.
Changelog-None This is a log-only change
Adding the newly introduced RPCs, `editdescriptionbyoutpoint` and `editdescriptionbypaymentid`, to the `Makefile` for generating the corresponding `.md` files required for the documentation portal.
Changelog-None.
I'm not sure why this happens, and suspect it is caused by an issue elsewhere, so
add some verbose debugging, don't crash.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8017
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `xpay` will refuse to make a 0msat payment (0msat invoice, partial payment, or manually-set on amountless invoice).
Fixes: https://github.com/ElementsProject/lightning/issues/8016
We have CI runs which timeout (after 2 hours). It's not clear why,
but we can at least eliminate CLN lockups as the answer.
Since pytest disabled the --timeout option on test shutdown, we could be
seeing an issue on stopping taking a long time?
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we get "lucky" then commit tx will have short sig, one less weight (1 in 256 chance):
```
@unittest.skipIf(TEST_NETWORK != 'regtest', 'elementsd anchors not supportd')
def test_onchain_slow_anchor(node_factory, bitcoind):
"""We still use anchors for non-critical closes"""
l1, l2 = node_factory.line_graph(2)
# Don't let l1 succeed in sending commit tx
def censoring_sendrawtx(r):
return {'id': r['id'], 'result': {}}
l1.daemon.rpcproxy.mock_rpc('sendrawtransaction', censoring_sendrawtx)
close_start_depth = bitcoind.rpc.getblockchaininfo()['blocks']
# Make l1 close unilaterally.
l1.rpc.disconnect(l2.info['id'], force=True)
l1.rpc.close(l2.info['id'], unilateraltimeout=1)
# We will have a super-low-prio anchor spend.
l1.daemon.wait_for_log(r"Low-priority anchorspend aiming for block {} \(feerate 253\)".format(close_start_depth + 2016))
# Restart with reduced block time.
l1.stop()
l1.daemon.opts['dev-low-prio-anchor-blocks'] = 20
l1.start()
l1.daemon.wait_for_log("Low-priority anchorspend aiming for block {}".format(close_start_depth + 20))
l1.daemon.wait_for_log("Anchorspend for local commit tx")
# Won't go under 12 blocks though.
# Make sure it sees all these blocks at once, to avoid test flakes!
l1.stop()
bitcoind.generate_block(7)
l1.start()
height = bitcoind.rpc.getblockchaininfo()['blocks']
l1.daemon.wait_for_log(r"Low-priority anchorspend aiming for block {} \(feerate 7458\)".format(height + 13))
> l1.daemon.wait_for_log(r"Anchorspend for local commit tx fee 12335sat \(w=714\), commit_tx fee 4545sat \(w=768\): package feerate 11390 perkw")
```
Here's the log we *did* get:
```
2025-01-25T08:46:40.9399213Z lightningd-1 2025-01-25T08:40:06.312Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Anchorspend for local commit tx fee 12328sat (w=714), commit_tx fee 4545sat (w=767): package feerate 11392 perkw
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Doesn't always die messily, it seems?
```
@unittest.skipIf(TEST_NETWORK != 'regtest', 'elementsd doesnt yet support PSBT features we need')
@pytest.mark.openchannel('v2')
def test_rbf_reconnect_tx_construct(node_factory, bitcoind, chainparams):
disconnects = ['=WIRE_TX_ADD_INPUT', # Initial funding succeeds
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'+WIRE_TX_COMPLETE',
'-WIRE_COMMITMENT_SIGNED',
'+WIRE_COMMITMENT_SIGNED']
l1, l2 = node_factory.get_nodes(2,
opts=[{'disconnect': disconnects,
'may_reconnect': True,
'dev-no-reconnect': None},
{'may_reconnect': True,
'dev-no-reconnect': None,
'broken_log': 'dualopend daemon died before signed PSBT returned'}])
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
amount = 2**24
chan_amount = 100000
bitcoind.rpc.sendtoaddress(l1.rpc.newaddr()['bech32'], amount / 10**8 + 0.01)
bitcoind.generate_block(1)
# Wait for it to arrive.
wait_for(lambda: len(l1.rpc.listfunds()['outputs']) > 0)
res = l1.rpc.fundchannel(l2.info['id'], chan_amount)
chan_id = res['channel_id']
vins = bitcoind.rpc.decoderawtransaction(res['tx'])['vin']
assert(only_one(vins))
prev_utxos = ["{}:{}".format(vins[0]['txid'], vins[0]['vout'])]
# Check that we're waiting for lockin
l1.daemon.wait_for_log(' to DUALOPEND_AWAITING_LOCKIN')
# rbf the lease with a higher amount
rate = int(find_next_feerate(l1, l2)[:-5])
# We 4x the feerate to beat the min-relay fee
next_feerate = '{}perkw'.format(rate * 4)
# Initiate an RBF
startweight = 42 + 172 # base weight, funding output
initpsbt = l1.rpc.utxopsbt(chan_amount, next_feerate, startweight,
prev_utxos, reservedok=True,
excess_as_change=True)
# Run through TX_ADD wires
for d in disconnects[1:-4]:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
with pytest.raises(RpcError):
l1.rpc.openchannel_bump(chan_id, chan_amount, initpsbt['psbt'])
wait_for(lambda: l1.rpc.getpeer(l2.info['id'])['connected'] is False)
# The first TX_COMPLETE breaks
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
bump = l1.rpc.openchannel_bump(chan_id, chan_amount, initpsbt['psbt'])
with pytest.raises(RpcError):
update = l1.rpc.openchannel_update(chan_id, bump['psbt'])
wait_for(lambda: l1.rpc.getpeer(l2.info['id'])['connected'] is False)
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
# l1 should remember, l2 has forgotten
# l2 should send tx-abort, to reset
l2.daemon.wait_for_log(r'tx-abort: Sent next_funding_txid .* doesn\'t match ours .*')
l1.daemon.wait_for_log(r'Cleaned up incomplete inflight')
# abort doesn't cause a disconnect
assert l1.rpc.getpeer(l2.info['id'])['connected']
# The next TX_COMPLETE break (both remember) + they break on the
# COMMITMENT_SIGNED during the reconnect
bump = l1.rpc.openchannel_bump(chan_id, chan_amount, initpsbt['psbt'])
with pytest.raises(RpcError):
update = l1.rpc.openchannel_update(chan_id, bump['psbt'])
wait_for(lambda: l1.rpc.getpeer(l2.info['id'])['connected'] is False)
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
l2.daemon.wait_for_logs([r'Got dualopend reestablish',
r'No commitment, not sending our sigs'])
l1.daemon.wait_for_logs([r'Got dualopend reestablish',
r'No commitment, not sending our sigs',
r'dev_disconnect: -WIRE_COMMITMENT_SIGNED',
'peer_disconnect_done'])
assert not l1.rpc.getpeer(l2.info['id'])['connected']
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
# COMMITMENT_SIGNED disconnects *during* the reconnect
# We can't bump because the last negotiation is in the wrong state
with pytest.raises(RpcError, match=r'Funding sigs for this channel not secured'):
l1.rpc.openchannel_bump(chan_id, chan_amount, initpsbt['psbt'])
# l2 reconnects, but doesn't have l1's commitment
> l2.daemon.wait_for_logs([r'Got dualopend reestablish',
r'No commitment, not sending our sigs',
# This is a BROKEN log, it's expected!
r'dualopend daemon died before signed PSBT returned'])
tests/test_opening.py:944:
...
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('dualopend daemon died before signed PSBT returned')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By having gossipwith filter out messages we don't want, we can get the counts of
expected messages correct, and not hit errors like this:
```
def test_gossip_throttle(node_factory, bitcoind, chainparams):
"""Make some gossip, test it gets throttled"""
l1, l2, l3, l4 = node_factory.line_graph(4, wait_for_announce=True,
opts=[{}, {}, {}, {'dev-throttle-gossip': None}])
# We expect: self-advertizement (3 messages for l1 and l4) plus
# 4 node announcements, 3 channel announcements and 6 channel updates.
# We also expect it to send a timestamp filter message.
# (We won't take long enough to get a ping!)
expected = 4 + 4 + 3 + 6 + 1
# l1 is unlimited
start_fast = time.time()
out1 = subprocess.run(['devtools/gossipwith',
'--all-gossip',
'--hex',
'--network={}'.format(TEST_NETWORK),
'--max-messages={}'.format(expected),
'{}@localhost:{}'.format(l1.info['id'], l1.port)],
check=True,
timeout=TIMEOUT, stdout=subprocess.PIPE).stdout.split()
time_fast = time.time() - start_fast
assert time_fast < 2
# Remove timestamp filter, since timestamp will change!
out1 = [m for m in out1 if not m.startswith(b'0109')]
# l4 is throttled
start_slow = time.time()
out2 = subprocess.run(['devtools/gossipwith',
'--all-gossip',
'--hex',
'--network={}'.format(TEST_NETWORK),
'--max-messages={}'.format(expected),
'{}@localhost:{}'.format(l4.info['id'], l4.port)],
check=True,
timeout=TIMEOUT, stdout=subprocess.PIPE).stdout.split()
time_slow = time.time() - start_slow
assert time_slow > 3
# Remove timestamp filter, since timestamp will change!
out2 = [m for m in out2 if not m.startswith(b'0109')]
# Contents should be identical (once uniquified, since each
# doubles-up on its own gossip)
> assert set(out1) == set(out2)
E AssertionError: assert {b'010054b1907bdf639c9060e0fa4bca02419c46f75a99f0908b87a2e09711d5d031ba76b8fd07acc8be1b2fac9e31efb808e5d362c32ef4665...
E Extra items in the left set:
E b'01010ad5be8b9ba029245c2ae2d667af7ead7c0129c479c7fd7145a9b65931e90222082e6e4ab37ef60ebd10f1493d73e8bf7a40c4ae5f7d87cc...8488830b60f7e744ed9235eb0b1ba93283b315c035180266e44a554e494f524245414d2d333930353033622d6d6f64646564000000000000000000'
E Extra items in the right set:
E b'01079f87eb580b9e5f11dc211e9fb66abb3699999044f8fe146801162393364286c6000000010000006c010101'
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
So not every message type counts: this is useful when we want to get a specific number
of a specific type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This caused a "flake" in testing, because it's wrong:
```
_____________________________ test_gossip_pruning ______________________________
[gw2] linux -- Python 3.10.16 /home/runner/.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.10/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f0267530490>
bitcoind = <pyln.testing.utils.BitcoinD object at 0x7f0267532b30>
def test_gossip_pruning(node_factory, bitcoind):
""" Create channel and see it being updated in time before pruning
"""
l1, l2, l3 = node_factory.get_nodes(3, opts={'dev-fast-gossip-prune': None,
'allow_bad_gossip': True,
'autoconnect-seeker-peers': 0})
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
l2.rpc.connect(l3.info['id'], 'localhost', l3.port)
scid1, _ = l1.fundchannel(l2, 10**6)
scid2, _ = l2.fundchannel(l3, 10**6)
mine_funding_to_announce(bitcoind, [l1, l2, l3])
wait_for(lambda: l1.rpc.listchannels(source=l1.info['id'])['channels'] != [])
l1_initial_cupdate_timestamp = only_one(l1.rpc.listchannels(source=l1.info['id'])['channels'])['last_update']
# Get timestamps of initial updates, so we can ensure they change.
# Channels should be activated locally
> wait_for(lambda: [c['active'] for c in l1.rpc.listchannels()['channels']] == [True] * 4)
```
Here you can see it has pruned:
```
lightningd-1 2025-01-24T07:39:40.873Z DEBUG gossipd: Pruning channel 105x1x0 from network view (ages 1737704380 and 0)
...
lightningd-1 2025-01-24T07:39:50.941Z UNUSUAL lightningd: Bad gossip order: could not find channel 105x1x0 for peer's channel update
```
Changelog-Fixed: Protocol: we were overzealous in pruning channels if we hadn't seen one side's gossip update yet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can be a bit early in our assertion:
```
@unittest.skipIf(os.getenv('TEST_DB_PROVIDER', 'sqlite3') != 'sqlite3', "sqlite3-specific DB manip")
def test_reconnect_remote_sends_no_sigs(node_factory):
"""We re-announce, even when remote node doesn't send its announcement_signatures on reconnect.
"""
l1, l2 = node_factory.line_graph(2, wait_for_announce=True, opts={'may_reconnect': True,
'dev-no-reconnect': None})
# Wipe l2's gossip_store
l2.stop()
gs_path = os.path.join(l2.daemon.lightning_dir, TEST_NETWORK, 'gossip_store')
os.unlink(gs_path)
l2.start()
# l2 will now uses (REMOTE's) announcement_signatures it has stored
wait_for(lambda: l2.rpc.listchannels()['channels'] != [])
# Remove remote signatures from l1 so it asks for them (and delete gossip store)
l1.db_manip("UPDATE channels SET remote_ann_node_sig=NULL, remote_ann_bitcoin_sig=NULL")
gs_path = os.path.join(l1.daemon.lightning_dir, TEST_NETWORK, 'gossip_store')
os.unlink(gs_path)
l1.restart()
l1.connect(l2)
l1needle = l1.daemon.logsearch_start
l2needle = l2.daemon.logsearch_start
# l1 asks once, l2 replies once.
# Make sure we get all the msgs!
time.sleep(5)
l1.daemon.wait_for_log('peer_out WIRE_ANNOUNCEMENT_SIGNATURES')
l2.daemon.wait_for_log('peer_out WIRE_ANNOUNCEMENT_SIGNATURES')
l1msgs = [l.split()[4] for l in l1.daemon.logs[l1needle:] if 'WIRE_ANNOUNCEMENT_SIGNATURES' in l]
> assert l1msgs == ['peer_out', 'peer_in']
E AssertionError: assert ['peer_out'] == ['peer_out', 'peer_in']
E Right contains one more item: 'peer_in'
E Full diff:
E - ['peer_out', 'peer_in']
E + ['peer_out']
```
```
lightningd-2 2025-01-24T05:53:22.862Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_out WIRE_ANNOUNCEMENT_SIGNATURES
lightningd-1 2025-01-24T05:53:22.864Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_in WIRE_ANNOUNCEMENT_SIGNATURES
lightningd-1 2025-01-24T05:53:22.885Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: channel_gossip: received announcement sigs for 103x1x0 (we have 103x1x0)
{'github_repository': 'ElementsProject/lightning', 'github_sha': 'e9d36f2b8ecd45882753cbe062c355e40bc7109c', 'github_ref': 'refs/pull/8027/merge', 'github_ref_name': 'HEAD', 'github_run_id': 12943530601, 'github_head_ref':
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sometimes they connect too fast, so we don't get a chance to ratelimit all of them:
```
def test_connect_ratelimit(node_factory, bitcoind):
"""l1 has 5 peers, restarts, make sure we limit"""
nodes = node_factory.get_nodes(6,
opts=[{'dev-limit-connections-inflight': None, 'may_reconnect': True}] + [{'may_reconnect': True}] * 5)
l1 = nodes[0]
nodes = nodes[1:]
addr = l1.rpc.newaddr()['bech32']
for n in nodes:
bitcoind.rpc.sendtoaddress(addr, (FUNDAMOUNT + 1000000) / 10**8)
bitcoind.generate_block(1, wait_for_mempool=len(nodes))
sync_blockheight(bitcoind, [l1])
for n in nodes:
l1.rpc.connect(n.info['id'], 'localhost', n.port)
l1.rpc.fundchannel(n.info['id'], FUNDAMOUNT)
# Make sure all channels are established and announced.
bitcoind.generate_block(6, wait_for_mempool=len(nodes))
wait_for(lambda: len(l1.rpc.listchannels()['channels']) == len(nodes) * 2)
assert not l1.daemon.is_in_log('Unblocking for')
l1.restart()
# The first will be ok, but others should block and be unblocked.
> l1.daemon.wait_for_logs((['Unblocking for ']
+ ['Too many connections, waiting'])
* (len(nodes) - 1))
tests/test_connection.py:4721:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <pyln.testing.utils.LightningD object at 0x7f6e288a3a60>
regexs = ['Unblocking for ', 'Too many connections, waiting', 'Unblocking for ', 'Too many connections, waiting', 'Unblocking for ', 'Too many connections, waiting', ...]
timeout = 180
def wait_for_logs(self, regexs, timeout=TIMEOUT):
"""Look for `regexs` in the logs.
The logs contain tailed stdout of the process. We look for each regex
in `regexs`, starting from `logsearch_start` which normally is the
position of the last found entry of a previous wait-for logs call.
The ordering inside `regexs` doesn't matter.
We fail if the timeout is exceeded or if the underlying process
exits before all the `regexs` were found.
If timeout is None, no time-out is applied.
"""
logging.debug("Waiting for {} in the logs".format(regexs))
exs = [re.compile(r) for r in regexs]
start_time = time.time()
while True:
if self.logsearch_start >= len(self.logs):
if not self.logs_catchup():
time.sleep(0.25)
if timeout is not None and time.time() > start_time + timeout:
print("Time-out: can't find {} in logs".format(exs))
for r in exs:
if self.is_in_log(r):
print("({} was previously in logs!)".format(r))
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('Unblocking for '), re.compile('Too many connections, waiting')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
____________________ ERROR at teardown of test_xpay_maxfee _____________________
...
# Format a nice list of everything that went wrong and raise an exception
request.node.has_errors = True
> raise ValueError(str(errors))
E ValueError:
E Node errors:
E - lightningd-1: Node exited with return code 1
E Global errors:
```
And:
```
@unittest.skipIf(TEST_NETWORK != 'regtest', 'too dusty on elements')
def test_xpay_maxfee(node_factory, bitcoind, chainparams):
"""Test which shows that we don't excees maxfee"""
outfile = tempfile.NamedTemporaryFile(prefix='gossip-store-')
subprocess.check_output(['devtools/gossmap-compress',
'decompress',
'--node-map=3301=022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59',
'tests/data/gossip-store-2024-09-22.compressed',
outfile.name]).decode('utf-8').splitlines()
AMOUNT = 100_000_000
# l2 will warn l1 about its invalid gossip: ignore.
# We throttle l1's gossip to avoid massive log spam.
> l1, l2 = node_factory.line_graph(2,
# This is in sats, so 1000x amount we send.
fundamount=AMOUNT,
opts=[{'gossip_store_file': outfile.name,
'subdaemon': 'channeld:../tests/plugins/channeld_fakenet',
'allow_warning': True,
'dev-throttle-gossip': None},
{'allow_bad_gossip': True}])
tests/test_xpay.py:509:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
contrib/pyln-testing/pyln/testing/utils.py:1720: in line_graph
nodes = self.get_nodes(num_nodes, opts=opts)
contrib/pyln-testing/pyln/testing/utils.py:1602: in get_nodes
return [j.result() for j in jobs]
contrib/pyln-testing/pyln/testing/utils.py:1602: in <listcomp>
return [j.result() for j in jobs]
/opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/concurrent/futures/_base.py:458: in result
return self.__get_result()
/opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/concurrent/futures/_base.py:403: in __get_result
raise self._exception
/opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/concurrent/futures/thread.py:58: in run
result = self.fn(*self.args, **self.kwargs)
contrib/pyln-testing/pyln/testing/utils.py:1653: in get_node
node.start(wait_for_bitcoind_sync)
contrib/pyln-testing/pyln/testing/utils.py:1015: in start
self.daemon.start(stderr_redir=stderr_redir)
contrib/pyln-testing/pyln/testing/utils.py:671: in start
self.wait_for_log("Server started with public key")
contrib/pyln-testing/pyln/testing/utils.py:355: in wait_for_log
return self.wait_for_logs([regex], timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <pyln.testing.utils.LightningD object at 0x7f27ab586c20>
regexs = ['Server started with public key'], timeout = 180
def wait_for_logs(self, regexs, timeout=TIMEOUT):
"""Look for `regexs` in the logs.
The logs contain tailed stdout of the process. We look for each regex
in `regexs`, starting from `logsearch_start` which normally is the
position of the last found entry of a previous wait-for logs call.
The ordering inside `regexs` doesn't matter.
We fail if the timeout is exceeded or if the underlying process
exits before all the `regexs` were found.
If timeout is None, no time-out is applied.
"""
logging.debug("Waiting for {} in the logs".format(regexs))
exs = [re.compile(r) for r in regexs]
start_time = time.time()
while True:
if self.logsearch_start >= len(self.logs):
if not self.logs_catchup():
time.sleep(0.25)
if timeout is not None and time.time() > start_time + timeout:
print("Time-out: can't find {} in logs".format(exs))
for r in exs:
if self.is_in_log(r):
print("({} was previously in logs!)".format(r))
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('Server started with public key')]" in logs.
```
gossipd (and other plugins) simply take too long to digest the gossmap under valgrind.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I'd been resisting this, but some tests really do want "hang up after
*receiving* this", and it's more reliable than getting the peer to
"hang up afer *sending* this" which seems not always work.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pyln logger's configuration was unexpectedly being overwritten by the root logger during the autogenerated examples test, complicating error debugging.
We resolved this by introducing a pytest fixture to reapply the logger configuration before the tests executes.
Changelog-None.
Fixes: https://github.com/ElementsProject/lightning/issues/8023
Currently on I see link failures like the following:
```bash
./configure
<snip>
checking for libsodium with IETF chacha20 variants... yes
<snip>
ar libccan.a
ld ccan/ccan/cdump/tools/cdump-enumstr
ld: library 'sodium' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
The configure check passes under Clang here.
Changelog-Fixed: build: fix linking against libsodium on macOS.
The current check fails when building with newer GCC, i.e:
```bash
error: ‘crypto_secretstream_xchacha20poly1305_init_push’ reading 32 bytes from a region of size 3 [-Werror=stringop-overread]
12 | crypto_secretstream_xchacha20poly1305_init_push(&crypto_state, header,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13 | data);
```
This inadvertently results in the release binaries for Ubuntu 22.04 &
24.04, not having a runtime libsodium dependency, but instead using the
bundled lib.
It's not clear to me this is actually enough to fix (all) the release builds,
as the build containers need to have `libsodium-dev`, not just `libsodium`
in them, and it's not clear to me which packages are actually present
looking at the repro build scripts.
Changelog-Fixed: build: libsodium configure check fixed to work with newer GCC.
The updated API requires typed htables to explicitly state whether they
allow duplicates: for most cases we don't, but we've had issues in the
past.
This is a big patch, but mainly mechanical.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I wanted to make sure we didn't have a bug in our htable routine,
so I wrote this test. We don't, but leave it in.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Install `poetry-plugin-export` as a separate step.
- Remove `--no-update` option from `poetry lock` as it's now default behavior.
- Add `poetry lock` to the command chain after removing cln-rest and wss-proxy.
https://github.com/python-poetry/poetry/releases/tag/2.0.0
Undertaken to upgrade QEMU to 7.2. Also upgrades Python to 3.11
implicitly and migrates Python dependency management to virtual environments.
Changelog-Changed: Released Docker images are now based on Debian Bookworm
This doesn't do anything, because it's trying to create a symlink for a
verison that doesn't exist. The version installed via brew is 0.22.5.
In any case, on any recent macOS system, this should not be necessary.
Changelog-None.
Poetry will no longer include the `poetry-plugin-export` plugin by default, which is essential for exporting dependencies. So, we now need to install it explicitly.
Keep a proper cache of all possible ones. I think this may be the
timeout problem: according to the logs, channeld_fakenet stops responding
and thus HTLCs eventually time out.
```
```
2024-12-16T23:16:16.4874420Z lightningd-1 2024-12-16T22:45:14.068Z UNUSUAL 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: Adding HTLC 18446744073709551615 too slow: killing connection
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can get the reply_short_channel_ids_end in the messages when
we make a query:
```
2024-11-29T07:39:28.8550652Z time_fast = time.time() - start_fast
2024-11-29T07:39:28.8551067Z assert time_fast < 2
2024-11-29T07:39:28.8551487Z out3 = [m for m in out3 if not m.startswith(b'0109')]
2024-11-29T07:39:28.8552158Z > assert set(out1) == set(out3)
...
2024-11-29T07:39:28.8675516Z E Extra items in the right set:
2024-11-29T07:39:28.8675887Z E b'010606226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f01'
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This should help us fix the flakes. Dealing with them was a major
headache at the end of the last release (and they covered up real bugs!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cut & paste from the forwarding code, where we don't let onions use the
unannounced scids. Obviously local commands can use them.
Reported-by: @michael1011
Changelog-Fixed: JSON-RPC: xpay now works through unannounced channels.
Note that the slight code reorder changes the JSON order, which is generally
undefined, but our doc checker is very strict!
Changelog-Changed: `xpay` now gives the same JSON success return as documented by `pay` when `xpay-handle-pay` is set.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/7923
maxfeepercent is use by Zeus, so let's make that work.
maxfee is more precise, so it's the only xpay option (maxfee was added
to pay later).
[ Fix to ppm logic by Lagrang3, thanks! --RR ]
Fixes: https://github.com/ElementsProject/lightning/issues/7926
Changelog-Changed: JSON-RPC: With `xpay-handle-pay` set, xpay will now be used even if `pay` uses maxfeeprecent or exemptfee parameters (e.g. Zeus)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means that it gets shown in listsendpays: omitting this broke spark, apparently!
Changelog-Changed: `xpay` now populates more fields, so `listsendpays` and `listpays` show `destination` and `amount_msat` fields for xpay payments.
Fixes: https://github.com/ElementsProject/lightning/issues/7881
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If they give us the invstring, we can at least set who signed the invoice. Of course,
it might not be a real node_id (with blinded paths).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This appears in listsendpays / listpays, and is useful information (if we know!).
This doesn't fix old payments, but means that xpay can use this for new payments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I used an unknown arg and it didn't complain. injectpaymentonion's schema predated
the sweep which fixed up use of "additionalProperties".
Indeed, we were missing some properties!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There was a wrong assumption that the number of bytes read
by `cli_read` would get us for each correctly read token
two extra CR characters. As a matter of fact one could read
enough characters to parse the first token, but the two
extra CR characters are not guaranteed.
```
==143570== Memcheck, a memory error detector
==143570== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==143570== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==143570== Command: /home/lagrange/BACKUP/l4-appdata/github/lagrang3/lightning/cli/lightning-cli --lightning-dir=/tmp/askrene_benchmark/lightning -k getroutes source=032ed0d87ba2bd68e3a386717cf2faaae4fa6d6da247986b1997113930e4f841d5 destination=03b2f16bf472dd03c55c2ce9910aab717321db4489cd87df5225adadb08031da4b amount_msat=100000sat final_cltv=6 layers=[] maxfee_msat=500sat
==143570==
==143570== Invalid read of size 1
==143570== at 0x484A430: memmove (vg_replace_strmem.c:1382)
==143570== by 0x10C3D2: main (lightning-cli.c:871)
==143570== Address 0x4a62f80 is 0 bytes after a block of size 1,040 alloc'd
==143570== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==143570== by 0x11402E: allocate (tal.c:256)
==143570== by 0x11471E: tal_alloc_ (tal.c:473)
==143570== by 0x1147EA: tal_alloc_arr_ (tal.c:517)
==143570== by 0x10C206: main (lightning-cli.c:816)
==143570==
==143570== Invalid read of size 1
==143570== at 0x484A43D: memmove (vg_replace_strmem.c:1382)
==143570== by 0x10C3D2: main (lightning-cli.c:871)
==143570== Address 0x4a62f81 is 1 bytes after a block of size 1,040 alloc'd
==143570== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==143570== by 0x11402E: allocate (tal.c:256)
==143570== by 0x11471E: tal_alloc_ (tal.c:473)
==143570== by 0x1147EA: tal_alloc_arr_ (tal.c:517)
==143570== by 0x10C206: main (lightning-cli.c:816)
==143570==
==143570== Invalid write of size 1
==143570== at 0x484A433: memmove (vg_replace_strmem.c:1382)
==143570== by 0x10C3D2: main (lightning-cli.c:871)
==143570== Address 0x4a62f80 is 0 bytes after a block of size 1,040 alloc'd
==143570== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==143570== by 0x11402E: allocate (tal.c:256)
==143570== by 0x11471E: tal_alloc_ (tal.c:473)
==143570== by 0x1147EA: tal_alloc_arr_ (tal.c:517)
==143570== by 0x10C206: main (lightning-cli.c:816)
```
Changelog-Fixed: lightning-cli: fix "malformed response" bug
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We ratelimited DEBUG messages, but that can be annoying and cause us to miss things.
We demoted the worst offenders in the last release, to TRACE level.
Now, only log trace if it's wanted, and never suppress DEBUG.
Changelog-Changed: Logging: we no longer suppress DEBUG messages from subdaemons.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/7917
header sys/errno.h gets re-directed to errno.h leading to warning and
then failure so instead directly referencing the header
Changelog-None: change header
Signed-off-by: Lakshya Singh <lakshay.singh1108@gmail.com>
We are checking if `txw->depth` is `-1` and then print it, when we
clearly want `depth` instead.
Changelog-Fixed logs: When printing depths some unsigned numbers could overflow
It's actually tested by fetchinvoice, but doing an explicit test in Python
allows for schema checking!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: `injectonionmessage` API simplified and documented.
It's undocumented and only used in one place, so we can change it (it
was new in 24.08).
We really want to be able to just handle a raw onionmessage: this allows
oblivious sending of messages, but also, in combination with the coming
onionmessage_forward_fail notification, allows us to connect then
reinject.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Clarify that the ability to reproducibly build a piece of software has
nothing to do with being a maintainer.
Minor typo/grammar fixes.
Changelog-None.
See: https://github.com/ElementsProject/lightning/issues/7899
A node with 23 connections gets far too many debug messages.
Changelog-Fixed: `gossipd` now does logging at trace, not debug level.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Removed branch testing as it is not required. Point releases will trigger the event due to `tag` push even when it is not from master branch.
- Added version in inputs for testing
- Added missing `inputs` tag
Changelog-None.
It's freaking people out when they see things like:
```
2024-11-11T05:26:41.281Z DEBUG ...53c-connectd: peer_out INVALID 22859
```
Fixes: https://github.com/ElementsProject/lightning/issues/7802
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: connectd: log unknown messages as "UNKNOWN" not "INVALID" to avoid freaking people out.
We were handing "maxfee" to every getroutes call, even if we had already
used some of the fees.
Reported-by: @daywalker90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: xpay is new this release.
In fact, there are several places where we try to decode old invoices,
and they should all work. The only place we should enforce expiration is
when we're going to pay.
This also revealed that xpay wasn't checking bolt11 expiries!
Reported-by: hMsats
Fixes: https://github.com/ElementsProject/lightning/issues/7869
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `decode` refused to decode expired bolt12 invoices.
```
error[E0277]: the trait bound `cln_rpc::model::requests::AskrenereserveRequest: From<pb::AskrenereserveRequest>` is not satisfied
--> cln-grpc/src/server.rs:3994:56
|
3994 | let req: requests::AskrenereserveRequest = req.into();
| ^^^^ the trait `From<pb::AskrenereserveRequest>` is not implemented for `cln_rpc::model::requests::AskrenereserveRequest`, which is required by `pb::AskrenereserveRequest: Into<_>`
|
= note: required for `pb::AskrenereserveRequest` to implement `Into<cln_rpc::model::requests::AskrenereserveRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskreneageRequest: From<pb::AskreneageRequest>` is not satisfied
--> cln-grpc/src/server.rs:4026:52
|
4026 | let req: requests::AskreneageRequest = req.into();
| ^^^^ the trait `From<pb::AskreneageRequest>` is not implemented for `cln_rpc::model::requests::AskreneageRequest`, which is required by `pb::AskreneageRequest: Into<_>`
|
= note: required for `pb::AskreneageRequest` to implement `Into<cln_rpc::model::requests::AskreneageRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::GetroutesRequest: From<pb::GetroutesRequest>` is not satisfied
--> cln-grpc/src/server.rs:4058:51
|
4058 | let req: requests::GetroutesRequest = req.into();
| ^^^^ the trait `From<pb::GetroutesRequest>` is not implemented for `cln_rpc::model::requests::GetroutesRequest`, which is required by `pb::GetroutesRequest: Into<_>`
|
= note: required for `pb::GetroutesRequest` to implement `Into<cln_rpc::model::requests::GetroutesRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskrenedisablenodeRequest: From<pb::AskrenedisablenodeRequest>` is not satisfied
--> cln-grpc/src/server.rs:4090:60
|
4090 | let req: requests::AskrenedisablenodeRequest = req.into();
| ^^^^ the trait `From<pb::AskrenedisablenodeRequest>` is not implemented for `cln_rpc::model::requests::AskrenedisablenodeRequest`, which is required by `pb::AskrenedisablenodeRequest: Into<_>`
|
= note: required for `pb::AskrenedisablenodeRequest` to implement `Into<cln_rpc::model::requests::AskrenedisablenodeRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskreneinformchannelRequest: From<pb::AskreneinformchannelRequest>` is not satisfied
--> cln-grpc/src/server.rs:4122:62
|
4122 | let req: requests::AskreneinformchannelRequest = req.into();
| ^^^^ the trait `From<pb::AskreneinformchannelRequest>` is not implemented for `cln_rpc::model::requests::AskreneinformchannelRequest`, which is required by `pb::AskreneinformchannelRequest: Into<_>`
|
= note: required for `pb::AskreneinformchannelRequest` to implement `Into<cln_rpc::model::requests::AskreneinformchannelRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskrenecreatechannelRequest: From<pb::AskrenecreatechannelRequest>` is not satisfied
--> cln-grpc/src/server.rs:4154:62
|
4154 | let req: requests::AskrenecreatechannelRequest = req.into();
| ^^^^ the trait `From<pb::AskrenecreatechannelRequest>` is not implemented for `cln_rpc::model::requests::AskrenecreatechannelRequest`, which is required by `pb::AskrenecreatechannelRequest: Into<_>`
|
= note: required for `pb::AskrenecreatechannelRequest` to implement `Into<cln_rpc::model::requests::AskrenecreatechannelRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskreneupdatechannelRequest: From<pb::AskreneupdatechannelRequest>` is not satisfied
--> cln-grpc/src/server.rs:4186:62
|
4186 | let req: requests::AskreneupdatechannelRequest = req.into();
| ^^^^ the trait `From<pb::AskreneupdatechannelRequest>` is not implemented for `cln_rpc::model::requests::AskreneupdatechannelRequest`, which is required by `pb::AskreneupdatechannelRequest: Into<_>`
|
= note: required for `pb::AskreneupdatechannelRequest` to implement `Into<cln_rpc::model::requests::AskreneupdatechannelRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskrenebiaschannelRequest: From<pb::AskrenebiaschannelRequest>` is not satisfied
--> cln-grpc/src/server.rs:4218:60
|
4218 | let req: requests::AskrenebiaschannelRequest = req.into();
| ^^^^ the trait `From<pb::AskrenebiaschannelRequest>` is not implemented for `cln_rpc::model::requests::AskrenebiaschannelRequest`, which is required by `pb::AskrenebiaschannelRequest: Into<_>`
|
= note: required for `pb::AskrenebiaschannelRequest` to implement `Into<cln_rpc::model::requests::AskrenebiaschannelRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::AskrenelistreservationsRequest: From<pb::AskrenelistreservationsRequest>` is not satisfied
--> cln-grpc/src/server.rs:4250:65
|
4250 | let req: requests::AskrenelistreservationsRequest = req.into();
| ^^^^ the trait `From<pb::AskrenelistreservationsRequest>` is not implemented for `cln_rpc::model::requests::AskrenelistreservationsRequest`, which is required by `pb::AskrenelistreservationsRequest: Into<_>`
|
= note: required for `pb::AskrenelistreservationsRequest` to implement `Into<cln_rpc::model::requests::AskrenelistreservationsRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::InjectpaymentonionRequest: From<pb::InjectpaymentonionRequest>` is not satisfied
--> cln-grpc/src/server.rs:4282:60
|
4282 | let req: requests::InjectpaymentonionRequest = req.into();
| ^^^^ the trait `From<pb::InjectpaymentonionRequest>` is not implemented for `cln_rpc::model::requests::InjectpaymentonionRequest`, which is required by `pb::InjectpaymentonionRequest: Into<_>`
|
= note: required for `pb::InjectpaymentonionRequest` to implement `Into<cln_rpc::model::requests::InjectpaymentonionRequest>`
error[E0277]: the trait bound `cln_rpc::model::requests::XpayRequest: From<pb::XpayRequest>` is not satisfied
--> cln-grpc/src/server.rs:4314:46
|
4314 | let req: requests::XpayRequest = req.into();
| ^^^^ the trait `From<pb::XpayRequest>` is not implemented for `cln_rpc::model::requests::XpayRequest`, which is required by `pb::XpayRequest: Into<_>`
|
= note: required for `pb::XpayRequest` to implement `Into<cln_rpc::model::requests::XpayRequest>`
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Testing autoconnect in --offline mode, the autoconnect never functions
if the seeker has not gotten out of the startup state. This commit
overloads the counter to start the autoconnect
attempt on the second round through the seeker_check.
Changelog-None
```
Program received signal SIGSEGV, Segmentation fault.
0x000000001014e9d8 in io_set_finish_ (conn=0x0, finish=0x0, arg=0x0) at ccan/ccan/io/io.c:137
137 conn->finish = finish;
(gdb) bt
incoming=true) at connectd/connectd.c:394
```
Fixes: #7871
Reported-by: grubles
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: broken in this release
A side-effect of having grpc start by default. Annoyingly, if it
can't bind it simply exits, with no message, so I had to guess what
was happening.
Reported-by: @daywalker90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Run with environment variable `GENERATE_EXAMPLES`
- Update cln version in getinfo example on `make update-versions`
- Added two `dev` configs, dev-no-plugin-checksum and dev-no-version-checks, to match CI listconfigs
- Changed commando rpc example from `getinfo` to `newaddr` to avoid unneccessary file updates for future builds
- Stabilized `bkpr-editdescriptionbyoutpoint`, `listclosedchannels` and `listaddresses` examples
Large nodes were not always getting their own channel gossip out
reliably. The number of peers we spam our own channel gossip to
is limited to save large nodes on startup, but this should be
relaxed slightly to ensure propagation.
Changelog-Fixed: Own-channel gossip is broadcast to more peers on connect.
Using jsonrpc_request_sync, layers are loaded before we finish init,
so we never can be asked to create a layer before we've loaded it
(xpay creates a layer immediately on startup).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: persistent layers new this release.
Create lower-level versions of routines to create biases, layers,
constraints, etc and only save the ones called from the public APIs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: persistent layers were only added in this release
They're not always 34 (aka '"'). This is a side-effect of ids
changing from u64 to strings quite a while ago.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: we now create a low-priority (2016 down to 12 blocks fee target) anchor for low-fee unilateral closes even if there's no urgency.
We're going to call this twice. But this patch also takes care
that a failed attempt to create an anchor doesn't alter other
variables!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. merge_deadlines can't really fail.
2. We don't care about incoming HTLCs with no preimage.
3. Debug print anchor points as soon as we calc them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cleans up the API: we have two functions now, one which is explicitly for
"I'm failing this because I saw this tx onchain".
Now we can correctly report the tx which closed the channel (previously
we would always report our own tx(s)!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `close` now correctly reports the txid of the remote onchain unilateral tx if it races with a peer close.
Changelog-Fixed: Protocol: we no longer try to spend anchors if a commitment tx is already mined (reported by @niftynei).
Fixes: #7526
The seeker can send a full gossip query, which means the ping doesn't happen
(it needs 14-45 seconds of quiet!).
We disable the gossip_queries feature, so it doesn't ask.
```
def test_ping_timeout(node_factory):
# Disconnects after this, but doesn't know it.
l1_disconnects = ['xWIRE_PING']
l1, l2 = node_factory.get_nodes(2, opts=[{'dev-no-reconnect': None,
'disconnect': l1_disconnects},
{'dev-no-ping-timer': None}])
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
# This can take 10 seconds (dev-fast-gossip means timer fires every 5 seconds)
l1.daemon.wait_for_log('seeker: startup peer finished', timeout=15)
# Ping timers runs at 15-45 seconds, *but* only fires if also 60 seconds
# after previous traffic.
> l1.daemon.wait_for_log('dev_disconnect: xWIRE_PING', timeout=60 + 45 + 5)
tests/test_connection.py:4194:
...
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('dev_disconnect: xWIRE_PING')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We wait until a connection fails, or a subd is connected to the peer,
before letting another one through. This should prevent us from
overwhelming lightningd on large nodes, but unlike the previous back-off,
it's based on how fast lightningd is, not an arbitrary time.
We also let one through each second, in case we're connecting to many,
but not doing anything but gossip (e.g. 100 explicit connect
commands).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Reconnecting to peers at startup should be significantly faster (dependent on machine speed).
Rather than have lightningd call us repeatedly to try to connect, have
it tell us what peers are transient and aren't, and connectd will
automatically try to maintain that connection.
There's a new "downgrade_peer" message to tell it a peer is now
transient: to make it non-transient we simply tell connectd to
connect as a non-transient.
The first time, I missed that dual_open_control does its own state
transitions :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: `connectd` now handles maintaining/reconnecting to important peers, and we remember the last successful address we connected to.
This is more useful than the last address, which may be it connecting
to us. And use it when we restore it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we connected out, remember that address. We always remember the last
address, but that may be an incoming address. This is explicitly the last
outgoing address which worked.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're going to use this to ask if there are any channels which make it
important to reconnect to the peer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In fact, only 951 of 17419 (5%) of node announcements are missing an address
(and gossipd doesn't know if we can connect to Tor addresses anyway) so
just check it *has* a node_announcement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Let lightningd feed us hints to try first, but we can extract the
addresses from node_announcement messages ourselves.
(Lightningd used to ask gossipd on our behalf: this is far simpler!)
One side effect of this is that we don't hand back address hints given to us
by lightningd: it would use these again for reconnecting. This is breaks
test_sendpay_grouping, so we disable it temporarily.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It turns out that under some circumstances we end up clearing the
pointee of `current` but not the pointer. Thus when we select the next
slot we can end up reusing the same slot, making it its own parent.
We forcefull break these cycles by enforcing that `current` should
never be returned and be set as its own parent.
Changelog-None
Trace spans form a tree, but we don't actually check that the
structure doesn't break. Breakage can for example come if we use the
same key accidentally, making a new span its own ancestor.
We have the space in memory set aside anyway, so let's just copy the
`trace_id` into the span itself, rather than resolving the `root` at
time of emission.
This was a bit harder to identify: during an `io_loop` run we suspend
the current span before handing over to `io_loop`, and later when a callback
is called we resume the span again. Depending on how we return from
the `io_loop` instance that is used to drive the startup, we either
have resumed the last span, or we don't. Since we start a span before
`io_loop` and want it to be emitted afterwards, we need to take care
of the case where we returned from a callback that did not resume, and
therefore the current context is empty.
Making `trace_span_resume` idempotent means we can just resume it
manually.
Ideally we'd push the suspend / resume logic down into `io_loop`
itself, and then we'd have just one place. Maybe suspend and resume
callbacks that can be configured in `io_loop`?
After adding the DB query instrumentation we ran into a couple of
issues, with spans not being resumed correctly, and it was rather hard
to identify the problem. This adds debug statements so we can trace
the tracing (traception if you will).
Changelog-None
lightningd/test/run-find_my_abspath.c includes ../lightningd.c, which includes
header_versions_gen.h, a generated header file.
lightningd/Makefile correctly declares that lightningd/lightningd.o depends on
header_versions_gen.h, but lightningd/test/Makefile lacks any such declaration
regarding lightningd/test/run-find_my_abspath.c, which leads to build failure:
In file included from lightningd/test/run-find_my_abspath.c:5:
lightningd/test/../lightningd.c:64:10: fatal error: header_versions_gen.h: No such file or directory
64 | #include <header_versions_gen.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
Declare the missing dependency in lightningd/test/Makefile so that Make will
ensure that header_versions_gen.h is generated before it attempts to build
lightningd/test/run-find_my_abspath.o.
Changelog-None
Due to Darwin-arm64 conditional setting of `CPPFLAGS`, the subsequent
`CPPFLAGS +=` is resolved earlier on ARM macOS which results in empty
paths being used.
Changelog-None
If the first one doesn't use the entire timeout, the second might need longer
(I used TIMEOUT=10 normally):
```
FAILED tests/test_gossip.py::test_gossip_pruning - TimeoutError: Unable to find "[re.compile('Pruning channel 103x1x0 from network view')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
pay does this, xpay does not. Which means if a block comes in (or you're behind),
you get gratuitous failures:
```
def test_xpay_simple(node_factory):
l1, l2, l3, l4 = node_factory.get_nodes(4, opts={'may_reconnect': True})
node_factory.join_nodes([l1, l2, l3], wait_for_announce=True)
node_factory.join_nodes([l3, l4], announce_channels=False)
# BOLT 11, direct peer
b11 = l2.rpc.invoice('10000msat', 'test_xpay_simple', 'test_xpay_simple bolt11')['bolt11']
> ret = l1.rpc.xpay(b11)
tests/test_xpay.py:148:
...
if not isinstance(resp, dict):
raise TypeError("Malformed response, response is not a dictionary %s." % resp)
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: xpay, payload: ('lnbcrt100n1pn5qu7csp53rp0mfwtfsyyy8gzsggepnxgslyalwvz3jkg9ptmqq452ln2nmgqpp58ak9nmfz9l93r0fpm266ewyjrhurhatrs05nda0r03p82cykp0vsdp9w3jhxazl0pcxz72lwd5k6urvv5sxymmvwscnzxqyjw5qcqp99qxpqysgqa798258yppu2tlfj8herr3zuz0zgux79zvtx6z57cmfzs2wdesmr4nvnkcmyssyu6k64ud54eg0v45c3mcw342jj6uy7tu202p6klrcp6ljc9w',), error: {'code': 203, 'message': "Destination said it doesn't know invoice: incorrect_or_unknown_payment_details"}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: xpay is new this release.
24.05 and before requires a "description" field. We should not have removed it here
until that was EOL!
Changelog-Fixed: pyln-client: plugins now compatible with CLN <= 24.05 (broken in 24.08)
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't want to to refresh the gossmap internally: this could invalidate the
gossmap held by the current callers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This does not validate a node announcement and address, but it
does select a node at random from the gossmap and asks lightningd
to attempt a connection to it.
Gossipd uses this to ask lightningd -> connectd to initiate
a connection to a new gossip peer. This can be used when
there are insufficient peers already connected to gossip with.
Changelog-Changed: Gossipd can now request connections to additional nodes for improved gossip sync
We can get more gossip_filter messages now. And we can also go over max-messages,
so increase that too.
```
del tally['query_short_channel_ids']
del tally['query_channel_range']
del tally['ping']
> assert tally == {'channel_announce': 1,
'channel_update': 3,
'node_announce': 1,
'gossip_filter': 1}
E AssertionError: assert {'channel_ann..._announce': 1} == {'channel_ann..._announce': 1}
E Omitting 2 identical items, use -vv to show
E Differing items:
E {'gossip_filter': 2} != {'gossip_filter': 1}
E {'channel_update': 2} != {'channel_update': 3}
E Full diff:
E {
E 'channel_announce': 1,...
E
E ...Full output truncated (10 lines hidden), use '-vv' to show
tests/test_gossip.py:2326: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We actually mine *300* blocks, not 200, and if timing is right l1
can have mined the txid before mine_txid_or_rbf() checks the mempool:
```
def test_onchaind_replay(node_factory, bitcoind):
disconnects = ['+WIRE_REVOKE_AND_ACK', 'permfail']
# Feerates identical so we don't get gratuitous commit to update them
l1, l2 = node_factory.line_graph(2, opts=[{'watchtime-blocks': 201, 'cltv-delta': 101,
'disconnect': disconnects,
'feerates': (7500, 7500, 7500, 7500)},
{'watchtime-blocks': 201, 'cltv-delta': 101}],
wait_for_announce=True)
inv = l2.rpc.invoice(10**8, 'onchaind_replay', 'desc')
rhash = inv['payment_hash']
routestep = {
'amount_msat': 10**8 - 1,
'id': l2.info['id'],
'delay': 101,
'channel': first_scid(l1, l2)
}
l1.rpc.sendpay([routestep], rhash, payment_secret=inv['payment_secret'])
l1.daemon.wait_for_log('sendrawtx exit 0')
bitcoind.generate_block(1, wait_for_mempool=1)
# Wait for nodes to notice the failure, this seach needle is after the
# DB commit so we're sure the tx entries in onchaindtxs have been added
l1.daemon.wait_for_log("Deleting channel .* due to the funding outpoint being spent")
l2.daemon.wait_for_log("Deleting channel .* due to the funding outpoint being spent")
# We should at least have the init tx now
assert len(l1.db_query("SELECT * FROM channeltxs;")) > 0
assert len(l2.db_query("SELECT * FROM channeltxs;")) > 0
# Generate some blocks so we restart the onchaind from DB (we rescan
# last_height - 100)
bitcoind.generate_block(100)
sync_blockheight(bitcoind, [l1, l2])
# l1 should still have a running onchaind
assert len(l1.db_query("SELECT * FROM channeltxs;")) > 0
l2.rpc.stop()
l1.restart()
# Can't wait for it, it's after the "Server started" wait in restart()
assert l1.daemon.is_in_log(r'Restarting onchaind \(ONCHAIN\): closed in block 109')
# l1 should still notice that the funding was spent and that we should react to it
_, txid, blocks = l1.wait_for_onchaind_tx('OUR_DELAYED_RETURN_TO_WALLET',
'OUR_UNILATERAL/DELAYED_OUTPUT_TO_US')
assert blocks == 200
bitcoind.generate_block(200)
# Could be RBF!
> l1.mine_txid_or_rbf(txid)
tests/test_closing.py:1864:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
contrib/pyln-testing/pyln/testing/utils.py:1375: in mine_txid_or_rbf
wait_for(lambda: rbf_or_txid_broadcast(txids))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
success = <function LightningNode.mine_txid_or_rbf.<locals>.<lambda> at 0x7f9b129c4550>
timeout = 180
def wait_for(success, timeout=TIMEOUT):
start_time = time.time()
interval = 0.25
while not success():
time_left = start_time + timeout - time.time()
if time_left <= 0:
> raise ValueError("Timeout while waiting for {}".format(success))
E ValueError: Timeout while waiting for <function LightningNode.mine_txid_or_rbf.<locals>.<lambda> at 0x7f9b129c4550>
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The test program has a leak, so address sanitizer complains and makes it
"fail" the zlib detection test!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can fix the median calc by removing the (unused) reverse edges.
Also analyze the failure case in test_real_data: it's a real edge case, so
hardcode that one as "ok".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The ratio of the median of the fees and probability cost is overall not
a bad factor to combine these two features. This is what the
test_real_data shows.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The fee_fallback test would fail after fixing the computation of the
median. Now by we can restore it by making the probability cost factor
1000x higher than the ratio of the median. This shows how hard it is to
combine fee and probability costs and why is the current approach so
fragile.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Rusty: "We don't generally use NDEBUG in our code"
Instead use a compile time flag ASKRENE_UNITTEST to make checks on unit
tests that we don't normally need on release code.
Changelog-none
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
- use graph_max_num_arcs/nodes instead of tal_count in bound checks,
- don't use ccan/lqueue, use instead a minimalistic queue
implementation with an array,
- add missing const qualifiers to temporary tal allocators,
- check preconditions with assert,
- remove inline specifier for static functions,
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The calculation of the median values of probability and fee cost in the
linear approximation had a bug by counting on non-existing arcs.
Changelog-none: askrene: fix the median
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We use an arc "array" in the graph structure, but not all arc indexes
correspond to real topological arcs. We must be careful when iterating
through all arcs, and check if they are enabled before making operations
on them.
Changelog-None: askrene: fix bug, not all arcs exists
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Add a new function to compute a MCF using a more general description of
the problem. I call it mcf_refinement because it can start with a
feasible flow (though this is not necessary) and adapt it to achieve
optimality.
Changelog-None: askrene: add a MCF refinement
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
It is just a copy-paste of "dijkstra" but the name
implies what it actually is. Not an implementation of minimum cost path
Dijkstra algorithm, but a helper data structure.
I keep the old "dijkstra.h/c" files for the moment to avoid breaking the
current code.
Changelog-EXPERIMENTAL: askrene: add priorityqueue
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
While we have (I hope!) fixed the underlying sync problem, this can still happen with
older gossip. So now we tell it the channel is dead, so it won't happen more than once.
Fixes: #7703
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can help us backfill any missing gossip if our current
peers haven't been the most reliable.
Changelog-Changed: Gossipd requests a full sync from a random peer every hour.
Based on gossip sync data from random network peers, listening to only 5
peers will not reliably catch all gossip traffic. For now, add extra
redundancy.
Allows our peer to change their funding pub key during a splice.
Changelog-Changed: Support added for peers that wish to rotate their funding pubkey during a splice.
Set the remote funding pubkey on both lightningd and channeld when mutual splice lock is achieved.
This will be needed once rotating funding keys is enabled during splicing
Changelog-None.
As per eclair spec proposal.
1) A renaming to `funding_txid`
2) Adding of `batch_size` to indicate how many commitment_signed msgs are expected.
Changelog-None
In anticipation of adding support for rotating funding pubkeys during a splice, `channel_txs` is updated to support specifying these manually instead of using the channel’s funding pubkeys.
Changelog-None
Channeld stores its own cache of `inflight` and that needs to have a copy of `remote_funding` as well.
Since copying a secp256k1 pubkey isn’t documented and `copy_inflight` isn’t used anyway — we’re dropping `copy_inflight`.
Changelog-None
It is possible for prevtx to be larger than max packet size, so for shared outputs (currently only the funding tx) we add support for sending the `txid` only across the wire and filling in the prevtx locally.
Changelog-None
Enable storing the remote funding pubkey in DB if the channel peer decides to change it during splicing. It needs to be in DB incase of restarts mid-splice.
Changelog-None
Added and updated error messages when splicing to make it more clear to the user why a splice is failing.
Changelog-Changed: Improved error messaging for splice commands.
As we can see from the previous test, l3 tells us why it rejected the payment:
```
lightningd-3 2024-11-19T03:56:27.151Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Failing HTLC because of an invalid payload (TLV 10 pos 104): cltv_expiry 136 > payment_constraint 130
```
It turns out, we were not updating the block height in the plugin!
Without this, when we create a (non-dummy) blinded path we set a
too-low CLTV restriction, and it doesn't work after a few blocks!
Note we were actually triggering this error in the xpay tests!
Reported-by: Vincenzo Palazzo
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Offers: Receiving bolt12 payments where we have no public channels would fail a few blocks after startup.
Don't reply with update_fail_malformed_htlc, even though WIRE_INVALID_ONION_BLINDING
has BADONION set. Fail it with a normal error message.
This fixes a known FIXME.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: entry to blinded paths return more useful errors (e.g if it's the final node, you get a real error, otherwise you get invalid_onion_blinding).
Payer metadata is a field that controls the payer ID
provided during the fetchinvoice process.
There are use cases where this is highly useful, such as
proving that the payer has paid for the correct item.
Imagine visiting a merchant's website to pay for multiple offers, where
one of these offers is a default offer (with no description and no set amount).
In this scenario, the merchant could claim not to have received
payment for a specific item. Since the same offer may be used to
fetch invoices for different products, there needs to be a way to
identify which product the invoice corresponds to.
With this commit, it will be possible to inject payer metadata,
which helps solve the issue described above.
For example, possible payer metadata could be `to_hex(b"{payer_node_id}.{product_id}.{created_at}")`.
Changelog-Added: JSON-RPC: `fetchinvoice` allows setting invreq_metadata via `payer_metadata` parameter.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We actually pruned before we got all the channels. Extend the pruning time,
which unfortunately makes the test slower.
```
2024-11-18T02:13:11.7013278Z node_factory = <pyln.testing.utils.NodeFactory object at 0x7ff72969e820>
2024-11-18T02:13:11.7014386Z bitcoind = <pyln.testing.utils.BitcoinD object at 0x7ff72968fe20>
2024-11-18T02:13:11.7014996Z
2024-11-18T02:13:11.7015271Z def test_gossip_pruning(node_factory, bitcoind):
2024-11-18T02:13:11.7016222Z """ Create channel and see it being updated in time before pruning
2024-11-18T02:13:11.7017037Z """
2024-11-18T02:13:11.7017871Z l1, l2, l3 = node_factory.get_nodes(3, opts={'dev-fast-gossip-prune': None,
2024-11-18T02:13:11.7018971Z 'allow_bad_gossip': True})
2024-11-18T02:13:11.7019634Z
2024-11-18T02:13:11.7020236Z l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
2024-11-18T02:13:11.7021153Z l2.rpc.connect(l3.info['id'], 'localhost', l3.port)
2024-11-18T02:13:11.7021806Z
2024-11-18T02:13:11.7022226Z scid1, _ = l1.fundchannel(l2, 10**6)
2024-11-18T02:13:11.7022886Z scid2, _ = l2.fundchannel(l3, 10**6)
2024-11-18T02:13:11.7023458Z
2024-11-18T02:13:11.7023907Z mine_funding_to_announce(bitcoind, [l1, l2, l3])
2024-11-18T02:13:11.7025183Z l1_initial_cupdate_timestamp = only_one(l1.rpc.listchannels(source=l1.info['id'])['channels'])['last_update']
2024-11-18T02:13:11.7026179Z
2024-11-18T02:13:11.7027358Z # Get timestamps of initial updates, so we can ensure they change.
2024-11-18T02:13:11.7028171Z # Channels should be activated locally
2024-11-18T02:13:11.7029326Z > wait_for(lambda: [c['active'] for c in l1.rpc.listchannels()['channels']] == [True] * 4)
```
We can see in logs, it actually started pruning already:
```
2024-11-18T02:13:11.9622477Z lightningd-1 2024-11-18T01:52:03.570Z DEBUG gossipd: Pruning channel 105x1x0 from network view (ages 1731894723 and 0)
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sometimes l1 ratelimits before l2, and l2 receives the warning message, not l1:
```
> assert l1.daemon.is_in_log('WARNING: Ratelimited onion_message: exceeded one per 250msec')
E AssertionError: assert None
E + where None = <bound method TailableProc.is_in_log of <pyln.testing.utils.LightningD object at 0x7f13435f45b0>>('WARNING: Ratelimited onion_message: exceeded one per 250msec')
E + where <bound method TailableProc.is_in_log of <pyln.testing.utils.LightningD object at 0x7f13435f45b0>> = <pyln.testing.utils.LightningD object at 0x7f13435f45b0>.is_in_log
E + where <pyln.testing.utils.LightningD object at 0x7f13435f45b0> = <fixtures.LightningNode object at 0x7f13435cbb80>.daemon
...
lightningd-1 2024-11-19T00:45:43.721Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_in WIRE_ONION_MESSAGE
lightningd-1 2024-11-19T00:45:43.721Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_out WIRE_WARNING
lightningd-2 2024-11-19T00:45:43.722Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_out WIRE_ONION_MESSAGE
lightningd-2 2024-11-19T00:45:43.722Z DEBUG connectd: REPLY WIRE_CONNECTD_INJECT_ONIONMSG_REPLY with 0 fds
lightningd-2 2024-11-19T00:45:43.722Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_in WIRE_WARNING
lightningd-2 2024-11-19T00:45:43.722Z INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Received WIRE_WARNING: WARNING: Ratelimited onion_message: exceeded one per 250msec
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I can't reproduce this, but CI did (with Elements):
```
[gw3] linux -- Python 3.8.18 /home/runner/.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7fd0e20f57f0>
bitcoind = <pyln.testing.utils.ElementsD object at 0x7fd0e307dbe0>
executor = <concurrent.futures.thread.ThreadPoolExecutor object at 0x7fd0e307da30>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
def test_lightningd_still_loading(node_factory, bitcoind, executor):
"""Test that we recognize we haven't got all blocks from bitcoind"""
mock_release = Event()
# This is slow enough that we're going to notice.
def mock_getblock(r):
conf_file = os.path.join(bitcoind.bitcoin_dir, 'bitcoin.conf')
brpc = RawProxy(btc_conf_file=conf_file)
if r['params'][0] == slow_blockid:
mock_release.wait(TIMEOUT)
return {
"result": brpc._call(r['method'], *r['params']),
"error": None,
"id": r['id']
}
# Start it, establish channel, get extra funds.
l1, l2, l3 = node_factory.get_nodes(3, opts=[{'may_reconnect': True,
'wait_for_bitcoind_sync': False},
{'may_reconnect': True,
'wait_for_bitcoind_sync': False},
{}])
node_factory.join_nodes([l1, l2])
# Balance l1<->l2 channel
l1.pay(l2, 10**9 // 2)
l1.stop()
# Now make sure l2 is behind.
bitcoind.generate_block(2)
# Make sure l2/l3 are synced
sync_blockheight(bitcoind, [l2, l3])
# Make it slow grabbing the final block.
slow_blockid = bitcoind.rpc.getblockhash(bitcoind.rpc.getblockcount())
l1.daemon.rpcproxy.mock_rpc('getblock', mock_getblock)
l1.start(wait_for_bitcoind_sync=False)
# It will warn about being out-of-sync.
assert 'warning_bitcoind_sync' not in l1.rpc.getinfo()
assert 'warning_lightningd_sync' in l1.rpc.getinfo()
# Make sure it's connected to l2 (otherwise we get TEMPORARY_CHANNEL_FAILURE)
wait_for(lambda: only_one(l1.rpc.listpeers(l2.info['id'])['peers'])['connected'])
# Payments will succced.
l1.pay(l2, 1000)
> assert l1.daemon.is_in_log(r"Sending HTLC while still syncing with bitcoin network \(104 vs 105\)")
E AssertionError: assert None
E + where None = <bound method TailableProc.is_in_log of <pyln.testing.utils.LightningD object at 0x7fd0e20f9fa0>>('Sending HTLC while still syncing with bitcoin network \\(104 vs 105\\)')
E + where <bound method TailableProc.is_in_log of <pyln.testing.utils.LightningD object at 0x7fd0e20f9fa0>> = <pyln.testing.utils.LightningD object at 0x7fd0e20f9fa0>.is_in_log
E + where <pyln.testing.utils.LightningD object at 0x7fd0e20f9fa0> = <fixtures.LightningNode object at 0x7fd0e20f59d0>.daemon
```
What was in logs was:
```
lightningd-1 2024-11-18T05:33:50.634Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Sending HTLC while still syncing with bitcoin network (103 vs 105)
```
Implying that l1 was an extra block behind.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to wait for *l2* to see the channel in CHANNELD_NORMAL,
otherwise the array here is empty:
```
chan = only_one([c for c in l1.rpc.listpeerchannels(l2.info['id'])['channels'] if c['state'] == 'CHANNELD_NORMAL'])
amount = chan['funding']['local_funds_msat']
assert amount > Millisatoshi(str((1 << 24) - 1) + "sat")
# We should know we can spend that much!
spendable = chan['spendable_msat']
assert spendable > Millisatoshi(str((1 << 24) - 1) + "sat")
# So should peer.
> chan = only_one([c for c in l2.rpc.listpeerchannels(l1.info['id'])['channels'] if c['state'] == 'CHANNELD_NORMAL'])
tests/test_connection.py:3552:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
arr = []
def only_one(arr):
"""Many JSON RPC calls return an array; often we only expect a single entry
"""
> assert len(arr) == 1
E AssertionError
```
The old `long_description` was removed and deprecated a while ago
without adding a proper replacement for plugin developers.
The getmanifest JSON that was to be used for that only knows `name` and `usage`.
This PR adds an optional `description` parameter that will be filled
with the methods docstring `__doc__` (if set).
Example:
@p.method("example")
def some_method(...)
"""some description"""
...
Changelog-Add: optional description paramter to Plugin.Method
Commit 531845971c broke the build without
SQLite because this code:
new = tal_fmt(NULL, template,
IF_SQLITE3(sqlite3_libversion_number()));
preprocesses into:
new = tal_fmt(NULL, template,
);
which has a syntax error. Fix it by moving the comma into the macro
argument.
Fixes: 531845971c
Changelog-None
This is required for VLS which wants to know (and potentially decline) invoices
we're trying to pay.
As a nice side effect, our "check" command for xpay now does much more thorough
checking of arguments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As the first user of a persistent layer, this tripped tests which
assumed the datastore would be empty!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are automatically marked "important", in the sense that we won't startup
if they are not working, but this wasn't meant to disallow stopping them.
Changelog-Changed: JSON-RPC: built-in plugins can now be stopped using "plugin stop".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Note: won't work with grpc (or probably other tools), since the output
is different. But good for testing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Config: option `xpay-handle-pay` can be used to call xpay when pay is used in many cases (but output is different from pay!)
Because we initalized plugin->io_rpc_conn *after* calling plugin->init,
send_outreq would do a (harmless, in our case) wakeup on an uninitialized address:
```
==1164079== Conditional jump or move depends on uninitialised value(s)
==1164079== at 0x1628FC: backend_wake (poll.c:227)
==1164079== by 0x160B98: io_wake (io.c:384)
==1164079== by 0x1160A8: ld_rpc_send (libplugin.c:255)
==1164079== by 0x1187E0: send_outreq (libplugin.c:1099)
==1164079== by 0x115041: init (xpay.c:1620)
```
Solution is simple: set plugin->io_rpc_conn to NULL, and don't wake it in this case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
fail->msg can be NULL for local failures (the error message itself is more informative
in this case). Use the generic "something went wrong" message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Both for HTLC txs and the to-self outputs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Wallet: Taproot addresses are used for unilateral-close change addresses.
It only works on BOLT11, and has long been replaced by the more
generic "decode".
Removing it will stop the confusion!
(Note: documentation claims it was introduced in 23.08, but that was
wrong, as it's been in CLN since the beginning).
[ Fixup from: niftynei <niftynei@gmail.com> ]
Fixes: https://github.com/ElementsProject/lightning/issues/6419
Changelog-Deprecated: JSON-RPC: `decodepay`: use `decode`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fails when l3 doesn't know address for l1, to connect to it:
```
2024-11-16T04:45:42.2243366Z lightningd-3 2024-11-16T04:35:10.582Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: peer_in WIRE_ONION_MESSAGE
2024-11-16T04:45:42.2244342Z lightningd-3 2024-11-16T04:35:10.582Z DEBUG lightningd: Got onionmsg reply_path
2024-11-16T04:45:42.2245398Z lightningd-3 2024-11-16T04:35:10.582Z DEBUG plugin-offers: Note: disallowing deprecated onion_message_recv.blinding
2024-11-16T04:45:42.2246408Z lightningd-3 2024-11-16T04:35:10.586Z UNUSUAL plugin-offers: No incoming channel for 5msat, so no blinded path
2024-11-16T04:45:42.2247289Z lightningd-3 2024-11-16T04:35:10.605Z DEBUG hsmd: Client: Received message 25 from client
2024-11-16T04:45:42.2248372Z lightningd-3 2024-11-16T04:35:10.606Z DEBUG plugin-offers: connecting directly to 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518
2024-11-16T04:45:42.2249451Z lightningd-3 2024-11-16T04:35:10.606Z DEBUG gossipd: REPLY WIRE_GOSSIPD_GET_ADDRS_REPLY with 0 fds
2024-11-16T04:45:42.2250743Z lightningd-3 2024-11-16T04:35:10.607Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Failed connected out: Unable to connect, no address known for peer
```
This is because the test which was supposed to wait for addresses is
wrong: it passes when l3 knows nothing! (`all([])` == `True`)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Couldn't figure out why hsmtool.proc.wait(WAIT_TIMEOUT) returns 1?
hsmtool doesn't ever seem to exit status 1!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Looking at the logs (and comparing a successful run), it seems the connect happens before
the connect_stream is ready, so we miss it:
```
________________________ test_grpc_connect_notification ________________________
[gw7] linux -- Python 3.8.18 /home/runner/.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7fb08bb969d0>
def test_grpc_connect_notification(node_factory):
l1, l2 = node_factory.get_nodes(2)
# Test the connect notification
connect_stream = l1.grpc.SubscribeConnect(clnpb.StreamConnectRequest())
l2.connect(l1)
> for connect_event in connect_stream:
tests/test_cln_rs.py:425:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../../../.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/lib/python3.8/site-packages/grpc/_channel.py:543: in __next__
return self._next()
../../../.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/lib/python3.8/site-packages/grpc/_channel.py:960: in _next
_common.wait(self._state.condition.wait, _response_ready)
../../../.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/lib/python3.8/site-packages/grpc/_common.py:156: in wait
_wait_once(wait_fn, MAXIMUM_WAIT_TIMEOUT, spin_cb)
../../../.cache/pypoetry/virtualenvs/cln-meta-project-AqJ9wMix-py3.8/lib/python3.8/site-packages/grpc/_common.py:116: in _wait_once
wait_fn(timeout=timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <Condition(<unlocked _thread.RLock object owner=0 count=0 at 0x7fb089730f00>, 0)>
timeout = 0.1
def wait(self, timeout=None):
"""Wait until notified or until a timeout occurs.
If the calling thread has not acquired the lock when this method is
called, a RuntimeError is raised.
This method releases the underlying lock, and then blocks until it is
awakened by a notify() or notify_all() call for the same condition
variable in another thread, or until the optional timeout occurs. Once
awakened or timed out, it re-acquires the lock and returns.
When the timeout argument is present and not None, it should be a
floating point number specifying a timeout for the operation in seconds
(or fractions thereof).
When the underlying lock is an RLock, it is not released using its
release() method, since this may not actually unlock the lock when it
was acquired multiple times recursively. Instead, an internal interface
of the RLock class is used, which really unlocks it even when it has
been recursively acquired several times. Another internal interface is
then used to restore the recursion level when the lock is reacquired.
"""
if not self._is_owned():
raise RuntimeError("cannot wait on un-acquired lock")
waiter = _allocate_lock()
waiter.acquire()
self._waiters.append(waiter)
saved_state = self._release_save()
gotit = False
try: # restore state no matter what (e.g., KeyboardInterrupt)
if timeout is None:
waiter.acquire()
gotit = True
else:
if timeout > 0:
> gotit = waiter.acquire(True, timeout)
E Failed: Timeout >1200.0s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since wait_for_onchaind_tx doesn't actually wait for the call to bitcoind to
return, we have a race in checking if the txid is in the mempool. Fix this
by making wait_for_onchaind_tx actually wait for the response (except for delayed txs!).
```
2024-11-15T07:15:22.0836959Z def test_htlc_in_timeout(node_factory, bitcoind, executor):
2024-11-15T07:15:22.0837722Z """Test that we drop onchain if the peer doesn't accept fulfilled HTLC"""
2024-11-15T07:15:22.0838208Z
2024-11-15T07:15:22.0838585Z # HTLC 1->2, 1 fails after 2 has sent committed the fulfill
2024-11-15T07:15:22.0839137Z disconnects = ['-WIRE_REVOKE_AND_ACK*2']
2024-11-15T07:15:22.0839741Z # Feerates identical so we don't get gratuitous commit to update them
2024-11-15T07:15:22.0840304Z l1 = node_factory.get_node(disconnect=disconnects,
2024-11-15T07:15:22.0840839Z options={'dev-no-reconnect': None},
2024-11-15T07:15:22.0841285Z feerates=(7500, 7500, 7500, 7500))
2024-11-15T07:15:22.0841673Z l2 = node_factory.get_node()
2024-11-15T07:15:22.0842278Z # Give it some sats for anchor spend!
2024-11-15T07:15:22.0842679Z l2.fundwallet(25000, mine_block=False)
2024-11-15T07:15:22.0843013Z
2024-11-15T07:15:22.0843342Z l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
2024-11-15T07:15:22.0843753Z chanid, _ = l1.fundchannel(l2, 10**6)
2024-11-15T07:15:22.0844058Z
2024-11-15T07:15:22.0844291Z sync_blockheight(bitcoind, [l1, l2])
2024-11-15T07:15:22.0844606Z
2024-11-15T07:15:22.0844958Z amt = 200000000
2024-11-15T07:15:22.0845713Z inv = l2.rpc.invoice(amt, 'test_htlc_in_timeout', 'desc')['bolt11']
2024-11-15T07:15:22.0846612Z assert only_one(l2.rpc.listinvoices('test_htlc_in_timeout')['invoices'])['status'] == 'unpaid'
2024-11-15T07:15:22.0847141Z
2024-11-15T07:15:22.0847430Z executor.submit(l1.dev_pay, inv, dev_use_shadow=False)
2024-11-15T07:15:22.0847805Z
2024-11-15T07:15:22.0848041Z # l1 will disconnect and not reconnect.
2024-11-15T07:15:22.0848660Z l1.daemon.wait_for_log('dev_disconnect: -WIRE_REVOKE_AND_ACK')
2024-11-15T07:15:22.0850393Z
2024-11-15T07:15:22.0851297Z # Deadline HTLC expiry minus 1/2 cltv-expiry delta (rounded up) (== cltv - 3). cltv is 5+1.
2024-11-15T07:15:22.0852146Z # shadow route can add extra blocks!
2024-11-15T07:15:22.0852622Z status = only_one(l1.rpc.call('paystatus')['pay'])
2024-11-15T07:15:22.0853044Z if 'shadow' in status:
2024-11-15T07:15:22.0853861Z shadowlen = 6 * status['shadow'].count('Added 6 cltv delay for shadow')
2024-11-15T07:15:22.0854325Z else:
2024-11-15T07:15:22.0854547Z shadowlen = 0
2024-11-15T07:15:22.0854845Z bitcoind.generate_block(2 + shadowlen)
2024-11-15T07:15:22.0855292Z assert not l2.daemon.is_in_log('hit deadline')
2024-11-15T07:15:22.0855669Z bitcoind.generate_block(1)
2024-11-15T07:15:22.0855950Z
2024-11-15T07:15:22.0856406Z l2.daemon.wait_for_log('Fulfilled HTLC 0 SENT_REMOVE_COMMIT cltv .* hit deadline')
2024-11-15T07:15:22.0856997Z l2.daemon.wait_for_log('sendrawtx exit 0')
2024-11-15T07:15:22.0857360Z l2.bitcoin.generate_block(1)
2024-11-15T07:15:22.0857741Z l2.daemon.wait_for_log(' to ONCHAIN')
2024-11-15T07:15:22.0858137Z l1.daemon.wait_for_log(' to ONCHAIN')
2024-11-15T07:15:22.0858644Z
2024-11-15T07:15:22.0859068Z # L2 will collect HTLC (iff no shadow route)
2024-11-15T07:15:22.0859741Z _, txid, blocks = l2.wait_for_onchaind_tx('OUR_HTLC_SUCCESS_TX',
2024-11-15T07:15:22.0860287Z 'OUR_UNILATERAL/THEIR_HTLC')
2024-11-15T07:15:22.0860662Z assert blocks == 0
2024-11-15T07:15:22.0860908Z
2024-11-15T07:15:22.0861262Z # If we try to reuse the same output as we used for the anchor spend, then
2024-11-15T07:15:22.0861951Z # bitcoind can reject it. In that case we'll try again after we get change
2024-11-15T07:15:22.0862433Z # from anchor spend.
2024-11-15T07:15:22.0862768Z if txid not in bitcoind.rpc.getrawmempool():
2024-11-15T07:15:22.0863354Z bitcoind.generate_block(1)
2024-11-15T07:15:22.0863735Z > bitcoind.generate_block(1, wait_for_mempool=1)
2024-11-15T07:15:22.0864019Z
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Because it wasn't in ALL_OBJS. Copy the Makefile pattern!
```
Submodule 'src/secp256k1' (https://github.com/ElementsProject/secp256k1-zkp.git) registered for path 'external/libwally-core/src/secp256k1'
Cloning into '/home/runner/work/lightning/lightning/external/libwally-core/src/secp256k1'...
cc tests/plugins/channeld_fakenet.c
In file included from ./bitcoin/script.h:4,
from tests/plugins/channeld_fakenet.c:14:
./bitcoin/signature.h:6:10: fatal error: secp256k1.h: No such file or directory
6 | #include <secp256k1.h>
| ^~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:301: tests/plugins/channeld_fakenet.o] Error 1
make: *** Waiting for unfinished jobs....
Submodule path 'external/libwally-core/src/secp256k1': checked out
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There's a known issue with hsm passwords and valgrind:
```
write_all(master_fd, (password + '\n').encode("utf-8"))
> l1.daemon.wait_for_log("Server started with public key")
tests/test_plugin.py:4526:
...
if self.is_in_log(r):
print("({} was previously in logs!)".format(r))
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('Server started with public key')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Based on the patch by bstin <barry.github@capsmx.com>, which added a separate command,
this simply extends "generatehsm" to allow more options.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: hsmtool: generatehsm can run non-interactive, taking options on the cmdline.
The `send_outreq` function is a good place to suspend and resume
traces, since these are usually the places where we hand off control
back to the `io_loop`. This assumes that we do not continue doing
heavy liftin after we have queued an `outreq` call, but that is most
likely the case anyway. This frees us from having to track suspensions
whenever we call the RPC from a plugin.
Christian noted that if we don't do this we could flood onchaind with messages:
particularly in Greenlight where the HSM (remote) may delay indefinitely, so
onchaind doesn't process messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means it always tells us explicitly whether to keep watching or not,
and we know it's processed it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This may help the cases we see where gossipd doesn't realize channels
are closed (because of shutdown before it processed the closing).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: `gossipd` will no longer miss some channel closes on restart.
And we hook in the replay watch code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: `onchaind` can miss conclusion of final txs in some cases, will now replay independently.
We start by telling onchaind about the funding spend, and anything
which spends it, and it tells us the txids it *doesn't* want to watch
any more. We're going to use a separate set of watches for the replay
case: this implements that code.
Once we're caught up, we convert any remaining watches to normal ones
to follow future blocks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And use it for `exposesecret-passphrase`. This is probably overly
cautious, but it makes me feel a little better that we won't leak it
to someone with read-only access.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Being able to back up the hsm_secret is critical, but you cannot do
this through a UI, because of course we do not allow such access.
People have lost funds because they didn't back up.
This allows access to the hsm_secret if you use a password set in the
config file. (If it's not set, the command does not work). This is a
compromise, of course.
Changelog-Added: `exposesecret` command for encouraging hsm_secret backups.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. It's called listpays not listpay.
2. "index" does NOT have a default value (it must be specified if limit or start are used)
3. Note that limit and start have effects on accuracy, since we combine records.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we don't consume *all* the CPU.
Changelog-Fixed: Plugins: `autoclean` is now gentler on the node when doing giant cleans.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
On a large node, especially with postgres, this causes every other command
to take 30 seconds plus. The first, obvious, step is to reduce how many
commands we will do at once.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Given an {outpoint}, sets the description on the matching outpoint (if exists).
Note that if no outpoint exists in bookkeeper, will return an empty list
Changleog-Added: PLUGINS: bookkeeper has a new RPC `bkrp-editdescriptionbyoutpoint` which will set/update a description for an outpoint creation event.
This takes an {payment_id} and {description}.
It looks for all chain + channel events that match
that {payment_id} and updates the description for those events.
We return all the updated events. If no events are updated, an empty
list is returned.
Changelog-Added: PLUGINS: bookkeeper has a new RPC `bkpr-editdescriptionbypaymentid` which will update the description for any event with matching payment_id
The fee maximum is used to issue a warning to the user their feerate is high in case they accidentally make a large donation to miners.
During python testing the feerates are high on purpose so we raise the warning level to at least the penality feerate.
The command called “splice” can take a json payload or a ‘splice script’, process it into a list of ‘actions’ and then execute those actions.
These actions include or will include everything you would want to do with a splice:
* Splice into a channel
* Splice out of a channel
* Fund from wallet
* Deposit to wallet
* Send funds to bitcoin address
Changelog-Added: A new magic “splice” command is added that can take a ‘splice script’ or json payload and perform any complex splice across multiple channels merging the result into a single transaction. Some features are disabled and will be added in time.
When set this flag tells addpsbtoutput to add the intiator serial_id to the added output.
Changelog-Changed: addpsbtoutput now allows serial_id to be set while adding which is needed for splicing and dual.
This is the sister command of addpsbtoutput.
Adds inputs equal to or greater than the amount requests, reservers them, and reports important information back out to the user.
Changelog-Added: New low-level RPC command addpsbtinput to fund PSBTs directly and help with complex splices & dual-opens.
The ability to stfu channels in bulk is required to do complex multi channel operations. When stfu’ing in this manner, the available funds at the moment of stfu is returned to the user.
In order to cancel the stfu we also add a bulk tx_abort command.
Changelog-Added: `stfu_channels` and `abort_channels` are added for bulk multi-channel splice commands. These allow the user to pause (and resume) multiple channels in place.
On certain well timed restarts we lose their siganture from memory and don’t receive it from them. In these cases we can extract it from the PSBT directly.
This is needed to all multi-channel splices. When channeld can return the signatures to the user (based on signing order precedent), it now does from splice_update.
Additionally, we move sending of the initial psbt from splice_init down to splice_update. This is also necessary for correct psbt diff detection during multi-channel splices.
Changelog-Changed: splice_update can in some cases now return the remotely partiall signed psbt to the user, if so `signtures_secured` will be true.
`splice_signed` now searchs the PSBT for channel ids
Changelog-Changed: `splice_signed` parameters are switched in order to make `channel_id` an optional parameter, enabling multi-splice-signatures.
A routine for getting a signature back out of an input’s list of pending signatures via pubkey search.
This is needed for certain kinds of restarts as we lose our peer’s signature from memory but a copy is kept in the PSBT.
New compiler for splice scripts that parses splice scripts, validates them, converts them to json and back again.
Changelog-Added: Splice script parser — takes a custom splice query language to bundle multiple complex splices into a single task in a simple way.
This does not mean it won't change, just that it will be backwards compatible.
Changelog-Added: Plugins: `askrene` which provides `getroutes` and a complete API for adding information in layers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets you place annotated biases on channels, to influence routing.
Uses include avoiding TOR nodes, slow channels or other local preferences.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: askrene is new anyway.
On `dev-memleak`, if someone is using rpc_command_hook, we'll call
it when the hook returns. But it will see these contexts as a leak.
So attach them to tmpctx (which is excluded from leak detection).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without knowing what method was called, we can't have useful general logging
methods, so go through the pain of adding "const char *method" everywhere,
and add:
1. ignore_and_complete - we're done when jsonrpc returned
2. log_broken_and_complete - we're done, but emit BROKEN log.
3. plugin_broken_cb - if this happens, fail the plugin.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we used to allow cmd to be NULL, we had to hand the plugin
everywhere. We no longer do.
1. Various jsonrpc_ functions no longer need the plugin arg.
2. send_outreq no longer needs a plugin arg.
3. The init function takes a command, not a plugin.
4. Remove command_deprecated_in_nocmd_ok.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were dereferencing the first character of the id, (always '"') which meant
everything was id 34.
Before:
plugin-pay: cmd 34 partid 5
After:
cmd pytest:pay#62/cln:pay#105 partid 0
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: `pay`: debug logging now uses correct JSON ids.
This means we replace p->cmd with an auxillary command after we've
finished, so we have a valid command to use.
It also means we weave `struct command_result` returns back through
all the callers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This does not code changes, but makes the next changes easier.
We short-cut the "we are a child" case and de-indent the main
cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is cleaner: everything can now be associated with a command
context.
You're supposed to eventually dispose of it using timer_complete().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sometimes we want to clean up *after* a command has completed, but
we're moving to a model where all libplugin operations require a
`struct command`. This adds `aux_command` to create an
independent-lifetime command with the same id.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I started getting "WIRE_TEMPORARY_CHANNEL_FAILURE: Too many HTLCs" after
two hundred xpay attempts.
This was nice (it found some bugs in injectpaymentonion's handling of
local errors, and in xpay's reporting), but shouldn't happen.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Start with a random capacity (linear prob), and remember in-progess
payments so we can simulate them using capacity properly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Note the impedence mismatch between sendpay and getroutes: we have to shift
amounts and delays by 1.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our gossmap_store uncompresser generates nodeids with well-known
privkeys, so we can decrypt and respond to HTLCs sent to such nodes.
By replacing channeld with a fake, we can connect a node to another
node, but then once the channel is established, allow payments to be
sent into the generated network, and respond appropriately.
This minimal version handles MPP timeouts, but doesn't insert any
delays or runtime capacity for channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: Testing only
secp256k1_ctx is used by pubkey_from_node_id. Don't try to pick and
choose where to initialize secp256k1_ctx, just always do it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If you change branches and have a generated .md file, index.rst
will pick it up. Use the Makefile variable, not the contents of
the filesystem!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This remove an unnecessary check for existing description field if the
description_hash is provided in the invoice. The bolt11_decode function
already checks the description against the hash if both are provided.
Changelog-Fix: renepay: allow to pay BOLT11 invoices with description_hash, the description field is made optional
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Now pay learns, it sometimes learns not to try again:
```
> assert(len(l1.rpc.listpays()['pays']) == 2)
E AssertionError: assert 1 == 2
E + where 1 = len([{'amount_sent_msat': 0, 'bolt11': 'lnbcrt1pnjj7mysp5tfx8n6nyx7ehszgqn7gqm2r6n079p22u2yddtg797ka3pa9557tspp5f89z6genjqrl3knymvav9ajwcxrm5w7arxux06rrhjux88derjyqdq8v3jhxccxqyjw5qcqp9rzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqqsqqqqqqqqpqqqqqzsqqc9qxpqysgqcuyr7qlyctf9w96fqg4wetqt7t5v938dagmv0r777n902utjufujzjxl3289r97yngft966zly3ehxfp469dh3lq0hkv6r684snvunqppuyvsl', 'created_at': 1730771812, 'destination': '035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d', ...}])
tests/test_pay.py:5147: AssertionError
```
We fix this by creating a fresh channel, so it will try.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can see peer_in before the state changes:
```
l3.daemon.wait_for_log("peer_in WIRE_ERROR")
> assert only_one(l3.rpc.listpeerchannels(l2.info['id'])['channels'])['state'] == 'AWAITING_UNILATERAL'
E AssertionError: assert 'CHANNELD_NORMAL' == 'AWAITING_UNILATERAL'
E - AWAITING_UNILATERAL
E + CHANNELD_NORMAL
```
From the logs, there is 0.2 seconds between them:
```
lightningd-3 2024-11-05T01:58:41.695Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_in WIRE_ERROR
lightningd-3 2024-11-05T01:58:41.726Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: billboard perm: Received ERROR channel cecf36a62a09d4f1bdb42aa61d0770964bf3b245b8943a3e5b86dafc572f63d1: Forcibly closed by `close` command timeout
lightningd-3 2024-11-05T01:58:41.745Z UNUSUAL 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Peer permanent failure in CHANNELD_NORMAL: channeld: received ERROR channel cecf36a62a09d4f1bdb42aa61d0770964bf3b245b8943a3e5b86dafc572f63d1: Forcibly closed by `close` command timeout (reason=protocol)
lightningd-3 2024-11-05T01:58:41.890Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: We have 3 anchor points to use
lightningd-3 2024-11-05T01:58:41.897Z DEBUG lightningd: Broadcasting txid ff2f44b37d96a81fcaa2a4b11746a06be70f3f800fbce941e61a47abb61f70c0
lightningd-3 2024-11-05T01:58:41.901Z DEBUG lightningd: sendrawtransaction: 02000000000101cecf36a62a09d4f1bdb42aa61d0770964bf3b245b8943a3e5b86dafc572f63d1000000000096b64c80044a01000000000000220020525df7a97bd0506c9ec41ee4e5f095e6e5316db01846a0a687404628017e88494a010000000000002200206db2ec9041ba3ccb6309dcad26015f32637e6869be09d3c3d3a1cb1439296f0b400d030000000000220020c2468acf761754e2533fcb13235326d1f1173b697b132048d6409be7818ed9a96a1f0c0000000000220020b1b561b95c1bccd50fb21bd417a95cabbc3efc351b1353063fe5e9f185d21c8a0400473044022036ab981a2642527c2019a4d15847f6b2fb1d0b92f1a2faff463ab109ed70c4d002205eeb0fcd610a9dba477ee7d66f02d0384080383fbb003d4ee423bdae0970b0430147304402202f7de3481ce00478e539cd9d6bac95ec3c80ec906c46ad2561118dca321b1458022048efd1aa04ff5fafbb99d14f7c9671072b035cbd2c031547793eb0cb6a62302d0147522102d595ae92b3544c3250fb772f214ad8d4c51425033740a5bcc357190add6d7e7a2102d6063d022691b2490ab454dee73a57c6ff5d308352b461ece69f3c284f2c241252ae6e14d920
lightningd-3 2024-11-05T01:58:41.907Z INFO 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: State changed from CHANNELD_NORMAL to AWAITING_UNILATERAL
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The original complaint which caused my investigation was the 100% CPU
consumption of connectd, which we traced to the queue to gossipd.
However, the issue is not really connectd's overproduction, but
gossipd's underconsumption, probably caused by its own queueing issues
with the trace messages to lightningd, which the prior patch fixed.
Nonetheless, gossipd *can* get busy, and if we were to ask multiple
nodes for full gossip, we could see a few hundred thousand messages
come it at once. Hence I'm increasing the warning limit to 250,000
messages.
This commit is also where we attach the Changelog message, even
though it's really "common/msg_queue: use membuf for greater efficiency."
and "gossipd: fix excessive msg_queue length from status_trace()" which
solved the problem.
Here's the backtrace from a previous debug patch:
```
lightning_connectd: msg_queue length excessive (version v24.08.1-17-ga780ad4-modded)
0x5580534051f0 send_backtrace
common/daemon.c:33
0x55805340bd5b do_enqueue
common/msg_queue.c:66
0x55805340bde5 msg_enqueue
common/msg_queue.c:82
0x5580534057ce daemon_conn_send
common/daemon_conn.c:161
0x5580533fe3ff handle_gossip_in
connectd/multiplex.c:624
0x5580533ff23b handle_message_locally
connectd/multiplex.c:763
0x5580533ff2d6 read_body_from_peer_done
connectd/multiplex.c:1112
```
Reported-by: https://github.com/JssDWt
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: `connectd` and `gossipd` message queues are much more efficient.
When this (very spammy) "handle_recv_gossip" message was changed
from debug to trace, the suppression code wasn't updated: we suppress
overly active debug messages, but not trace messages.
This is the backtrace from an earlier version of the "too large queue"
patch:
```
lightning_gossipd: msg_queue length excessive (version v24.08.1-17-ga780ad4-modded)
0x557e521e833f send_backtrace
common/daemon.c:33
0x557e521eefb9 do_enqueue
common/msg_queue.c:66
0x557e521ef043 msg_enqueue
common/msg_queue.c:82
0x557e521e891d daemon_conn_send
common/daemon_conn.c:161
0x557e521f14f0 status_send
common/status.c:90
0x557e521f1804 status_vfmt
common/status.c:169
0x557e521f1433 status_fmt
common/status.c:180
0x557e521de7c6 handle_recv_gossip
gossipd/gossipd.c:206
0x557e521de9f5 connectd_req
gossipd/gossipd.c:307
0x557e521e862d handle_read
common/daemon_conn.c:35
```
Without this, we have hardly any enforcement. This is why the schema
mistake fixed in the previous patches weren't spotted immediately.
The hard work was done by:
```
$ for f in lightning-*.json; do grep -v '^ "additionalProperties": false,' $f | bagto $f; done
$ for f in lightning-*.json; do sed 's/"properties": {/"additionalProperties": false, "properties": {/' $f | bagto $f; done
$ make fmt-schemas
```
Then checking where 'additionalProperties: true' had been turned to
false (we deliberately use it in some places where there are if
statements in the schema, or occasionally where there can be arbitrary
fields).
[Including doc/rpc-schema-draft.json update by Shahana]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows the next patch (which makes the schemas stricter) to not
break our tests.
We add some missing fields (including dev fields, but they're empty and hidden),
and add a few minor clarifications and a spelling fix. Most of these are new
schemas for this release, so no mention in Changelog.
Here is the difference in the man pages:
--- doc/lightning-askrene-inform-channel.7.md.old 2024-10-29 17:33:07.714521584 +1030
+++ doc/lightning-askrene-inform-channel.7.md 2024-10-29 17:42:37.434280109 +1030
@@ -24,6 +24,8 @@
- **short\_channel\_id\_dir** (short\_channel\_id\_dir): The short channel id and direction
+- **layer** (string): The name of the layer to apply this change to.
+- **timestamp** (u64): The UNIX timestamp when this constraint was created.
- **maximum\_msat** (msat, optional): The maximum value which this channel could pass.
--- doc/lightning-askrene-listlayers.7.md.old 2024-10-29 17:33:07.716521571 +1030
+++ doc/lightning-askrene-listlayers.7.md 2024-10-29 17:42:37.424280316 +1030
@@ -29,13 +29,16 @@
- **channel\_updates** (array of objects):
+ - **short\_channel\_id\_dir** (short\_channel\_id\_dir): The short channel id and direction this update applies to.
+ - **enabled** (boolean, optional): True if this can be used, false otherwise.
- **htlc\_minimum\_msat** (msat, optional): The minimum value allowed in this direction.
- **htlc\_maximum\_msat** (msat, optional): The maximum value allowed in this direction.
- **fee\_base\_msat** (msat, optional): The base fee to apply to use the channel in this direction.
- **fee\_proportional\_millionths** (u32, optional): The proportional fee (in parts per million) to apply to use the channel in this direction.
- - **delay** (u16, optional): The CLTV delay required for this direction.
+ - **cltv\_expiry\_delta** (u16, optional): The CLTV delay required for this direction.
- **constraints** (array of objects):
- **short\_channel\_id\_dir** (short\_channel\_id\_dir): The short channel id and direction
+ - **timestamp** (u64, optional): The UNIX timestamp when this constraint was created.
- **maximum\_msat** (msat, optional): The maximum value which this channel could pass.
--- doc/lightning-askrene-listreservations.7.md.old 2024-10-29 17:33:07.719521550 +1030
+++ doc/lightning-askrene-listreservations.7.md 2024-10-29 17:42:37.428280233 +1030
@@ -16,7 +16,7 @@
-On success, an object containing **layers** is returned. It is an array of objects, where each object contains:
+On success, an object containing **reservations** is returned. It is an array of objects, where each object contains:
--- doc/lightning-autoclean-status.7.md.old 2024-10-29 17:33:07.732521462 +1030
+++ doc/lightning-autoclean-status.7.md 2024-10-29 17:42:37.441279965 +1030
@@ -9,7 +9,7 @@
-The **autoclean-status** RPC command tells you about the status of the autclean plugin, optionally for only one subsystem.
+The **autoclean-status** RPC command tells you about the status of the autoclean plugin, optionally for only one subsystem.
--- doc/lightning-renepay.7.md.old 2024-10-29 17:33:07.927520140 +1030
+++ doc/lightning-renepay.7.md 2024-10-29 17:42:37.996268504 +1030
@@ -58,6 +58,9 @@
- **status** (string) (one of "complete", "pending", "failed"): Status of payment.
+- **bolt11** (string, optional): The bolt11 invoice paid. *(added v23.08)*
+- **bolt12** (string, optional): The bolt12 invoice paid. *(added v23.08)*
+- **groupid** (u64, optional): The groupid used for these payment parts (as can be seen in listsendpays) *(added v23.08)*
- **destination** (pubkey, optional): The final destination of the payment.
--- doc/lightning-sendonion.7.md.old 2024-10-29 17:33:07.937520073 +1030
+++ doc/lightning-sendonion.7.md 2024-10-29 17:42:37.957269309 +1030
@@ -22,7 +22,7 @@
-- **first\_hop** (object): Instructs Core Lightning which peer to send the onion to. It is a JSON dictionary that corresponds to the first element of the route array returned by *getroute*.:
+- **first\_hop** (object): Instructs Core Lightning which peer to send the onion to. It is a JSON dictionary that corresponds to the first element of the route array returned by *getroute* (so fields not mentioned here are ignored).:
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `renepay` return fields documented in schema (`bolt11`, `bolt12` and `groupid`)
This is like `sendonion` but unwraps the onion as the first hop,
avoiding nasty special cases for blinded paths which start with this
node, and also self-pay.
Tests split into multiple ones after Christian's review.
Changelog-Added: JSON-RPC: `injectpaymentonion` for initiating an HTLC like a peer would do.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Don't assume we have an outgoing HTLC at this level.
Note that previously we didn't save the failed onion unless it was
unparsable: we keep that both for space savings and because our
`waitsendpay` logic assumes that when it fetches from the db if
there's a failonion it was unparsable!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This message is supposed to include the msat amount received. But this is
obviously per-HTLC, and we hacked it to use the value for the first one.
And we add logging whenever we fail an HTLC set, since we removed logging
by not calling failmsg_incorrect_or_unknown() (which, now, no longer needs
to log).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Removes the `COMPAT_V070` functionality for `listfowards`.
Changelog-Changed: The `listforwards` command will now return a value
of 0 for `received_time` for very old forward attempts.
Changelog-Fixed: The documentation version was calculated as `pre-v24.08` for point releases like v24.08.1` also because `CLN_NEXT_VERSION` has not been included in the point release branches. Updating the script to build documentation on new tags and change the version to `pre-cln-next-version` for non-tagged commits.
Changelog-Added: JSON-RPC: `decode` now used modern BOLT 4 language for blinded paths, `first_path_key`.
Changelog-Deprecated: JSON-RPC: `decode` `blinding` in blinded path: use `first_path_key`.
Changelog-Added: Plugins: `onion_message_recv` and `onion_message_recv_secret` hooks now used modern BOLT 4 language for blinded paths, `first_path_key`.
Changelog-Deprecated: JSON-RPC: `onion_message_recv` and `onion_message_recv_secret` hooks `blinding` in blinded path: use `first_path_key`.
No code changes, just catching up with the BOLT changes which rework our
blinded path terminology (for the better!).
Another patch will sweep the rest of our internal names, this tries only to
make things compile and fix up the BOLT quotes.
1. Inside payload: current_blinding_point -> current_path_key
2. Inside update_add_htlc TLV: blinding_point -> blinded_path
3. Inside blinded_path: blinding -> first_path_key
4. Inside onion_message: blinding -> path_key.
5. Inside encrypted_data_tlv: next_blinding_override -> next_path_key_override
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is obsolete (since modern onions) and so removed from spec.
We should not set it, and don't need to handle it specially.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we should support it by default.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Protocol: `option_quiesce` enabled by default.
Changelog-Deprecated: Config: --experimental-quiesce: it's now the default.
We build with this: it changes the blinded_path field to sciddir_or_pubkey.
But it wasn't committed, so if someone rebuilt the wire files they'd be wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we know the total reservations on each hop, we can more easily
determine probabilities than using flowset_probability() which has to
replicate this collision detection.
We leave both in place for now, to check. The results are not
identical, due to slightly different calculation methods.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were trying to get the max capacity of a flow to see if we could add some
more sats, and hit an assertion:
tests/test_askrene.py:707:
```
DEBUG plugin-cln-askrene: notify msg info: Flow reduced to deliver 88070161msat not 90008000msat, because 107x1x0/1 has remaining capacity 88071042msat
DEBUG plugin-cln-askrene: notify msg info: Flow reduced to deliver 284138158msat not 284787000msat, because 108x1x0/1 has remaining capacity 284141000msat
**BROKEN** plugin-cln-askrene: Flow delivers 129565000msat but max only 56506138msat
INFO plugin-cln-askrene: Killing plugin: exited during normal operation
```
We need to *unreserve* our flow before asking for max capacity. We were
also missing a few less important cases where we altered flows without altering
the reservation, so fix those too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I noticed that increasing mu a little bit sometimes made a big difference,
because by completely ignoring fees we were choosing the worst of two channels
in some cases.
Start at 1% fees; this saves a lot on initial fees in this test!
Here's the new stats on mu levels:
96 mu=1
90 mu=10
41 mu=20
30 mu=30
24 mu=40
19 mu=50
22 mu=60
8 mu=70
95 mu=80
19 mu=90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `askrene` is now better at finding low-fee paths.
While the `k=8` value worked for the current main network tests with the
amounts in those tests, it wasn't robust across a wider range of values
(as demonstrated when other test changes broke tests!).
Time to do this properly: calculate the ratio at the time we combine them,
using median values.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Even after the previous fix, we still occasionally increase fees when my increases.
This is due to the difference between MCF's linear fees, and actual fees, and
is unavoidable, but add a check if it somehow happens.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I noticed this in the logs:
plugin-cln-askrene: notify msg unusual: The flows had a fee of 151950msat, greater than max of 53697msat, retrying with mu of 10%...
plugin-cln-askrene: notify msg unusual: The flows had a fee of 220126msat, greater than max of 53697msat, retrying with mu of 20%...
We would expect increasing mu to *reduce* the fee!
Turns out that our linear fee is a bad terrible approximation, because I
was using base_fee_penalty of 10.0.
|
| / __ <- real fee, with base: fee = base + propfee * amount.
| / __/
| _//
| __/
| __/_/
|/ _/
| _/ <- linearized fee: fee = linear * amount
|/
+-----------------------------------
These cross over where linear = propfee + base / amount. Assume we split the
payment into 10 parts, this implies that the base_fee_penalty should be 10 / amount
(this gives a slight penalty to the normal case, but that's ok).
This gives better results, too: we get down to 650099 sats in fees, vs 801613
before.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
During "test_real_data", then only successes with reduced fees were 92 on "mu=10", and only
1 on "mu=30": the rest went to mu=100 and failed.
I tried numerous approaches, and in the end, opted for the simplest:
The typical range of probability costs looks likes:
min = 0, max = 924196240, mean = 10509.4, stddev = 1.9e+06
The typical range of linear fee costs looks like:
min = 0, max = 101000000, mean = 81894.6, stddev = 2.6e+06
This implies a k factor of 8 makes the two comparable.
This makes the two numbers comparable, and thus makes "mu" much more
effective. Here are the number of different mu values we succeeded at:
87 mu=0
90 mu=10
42 mu=20
24 mu=30
17 mu=40
19 mu=50
19 mu=60
11 mu=70
95 mu=80
19 mu=90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The current prob_cost_factor setting does not seem to make mu very
effective, in fact, it gives strange results:
plugin-cln-askrene: notify msg unusual: The flows had a fee of 151950msat, greater than max of 53697msat, retrying with mu of 10%...
plugin-cln-askrene: notify msg unusual: The flows had a fee of 220126msat, greater than max of 53697msat, retrying with mu of 20%...
We would expect increasing mu to *reduce* the fee!
As a first step, simplify (it can't be infinite, and the -1 are weird).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We ask it again, but reduce fees by 1msat from the previous answer.
This is really nasty, as it frequently exercises the case where we
only go over fee when we do the refinement step.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I tested with a really large gossmap (hacked to be 4GB), and when we
keep retrying to minimize cost (calling minflow 11 times), and we
don't free tmpctx.
Due to an issue with how gossmap estimates the index sizes, we ended
up running out of memory. This fixes it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Flow cycles can occur if we have arc zero arc costs.
The previous path construction from the flow in the network assumed the
absence of such cycles and would enter an infinite loop if it hit one.
With his patch wee add cycle detection and removal during the path
construction phase.
Reported-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-EXPERIMENTAL: `askrene` infinite loop fixed
This happens in the coming "real network" test!
We add fees and hit htlc_max, but don't have another flow to add to.
Rather than MCF again, we split the flow into two.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The fp16_t values are approximations (overestimate for htlc_max,
underestimate for htlc_min), so in the refinement step we should use
the exact values.
This also fixes a logic bug: flow_remaining_capacity returned the
total capacity, not the additional capacity!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `askrene` now honors exact htlc_maximum_msat limits.
In particular, this lets you find the exact htlc_maximum_msat/htlc_minimum_msat
values.
This means we actually create real channel_updates for local mods, which
requires a second "local" scratch region.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `getroutes` now applies `auto.sourcefree` layer in the order specified, so doesn't alter channels changed in later layers.
Rather than adding to the gossmap modifications directly, populate
the layer and have the normal layer application logic do it.
This is consistent when we query layers in the next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And unify logging for better debugging.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: `askrene` now has better logging, gives notifications of progress.
The "init_cupdate" message is for gossipd to tell lightningd about our *own* latest
channel_update messages, not the remote ones! The "remote_channel_update" message
is for messages from the peer.
This appeared as an occasional BROKEN message in CI:
```
**BROKEN** 035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d-chan#4: gossipd gave us channel_update for channel in gossip_state CGOSSIP_NEED_PEER_SIGS
```
Where we had sent (and not received) announcement_signatures, and restarted: the peer had meanwhile
sent us their channel_announcement and channel_update.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: we could get confused on restart and not re-transmit our own channel_updates.
tmpctx may not get cleaned immediately, so the timeout (a child of
the struct early_peer at this point) can still outlast the conn.
Do the clearer thing, and explicitly free the timeout.
Changelog-Fixed: connectd: crash on erroneous timeout.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Whenever we build without `make clean` first, this file gets
overwritten. It asks the user for input because it is not run with
`-f`. This causes the build to hang until the user inputs `y`.
Here is an example build:
```
$ make -j7 && sudo make install
CC: cc -DCLN_NEXT_VERSION="v24.08" -DPKGLIBEXECDIR="/usr/local/libexec/c-lightning" -DBINDIR="/usr/local/bin" -DPLUGINDIR="/usr/local/libexec/c-lightning/plugins" -DCCAN_TAL_NEVER_RETURN_NULL=1 -Wall -Wundef -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wold-style-definition -Werror -Wno-maybe-uninitialized -Wshadow=local -std=gnu11 -g -fstack-protector-strong -Og -I ccan -I external/libwally-core/include/ -I external/libwally-core/src/secp256k1/include/ -I external/jsmn/ -I external/libbacktrace/ -I external/gheap/ -I external/build-x86_64-linux-gnu/libbacktrace-build -I external/libsodium/src/libsodium/include -I external/libsodium/src/libsodium/include/sodium -I external/build-x86_64-linux-gnu/libsodium-build/src/libsodium/include -I . -I/usr/local/include -I/usr/include/postgresql -DSHACHAIN_BITS=48 -DJSMN_PARENT_LINKS -DCOMPAT_V052=1 -DCOMPAT_V060=1 -DCOMPAT_V061=1 -DCOMPAT_V062=1 -DCOMPAT_V070=1 -DCOMPAT_V072=1 -DCOMPAT_V073=1 -DCOMPAT_V080=1 -DCOMPAT_V081=1 -DCOMPAT_V082=1 -DCOMPAT_V090=1 -DCOMPAT_V0100=1 -DCOMPAT_V0121=1 -c -o
LD: cc -Og config.vars -Lexternal/build-x86_64-linux-gnu -lwallycore -lsecp256k1 -ljsmn -lbacktrace -lsodium -L/usr/local/include -lm -lsqlite3 -L/usr/lib/x86_64-linux-gnu -lpq -o
mv: replace 'tools/headerversions', overriding mode 0755 (rwxr-xr-x)? cc lightningd/test/run-check_node_announcement.c
cc lightningd/test/run-find_my_abspath.c
cc lightningd/test/run-invoice-select-inchan.c
cc lightningd/test/run-jsonrpc.c
cc lightningd/test/run-log_filter.c
cc lightningd/test/run-log-pruning.c
cc lightningd/test/run-shuffle_fds.c
ld lightningd/test/run-find_my_abspath
ld lightningd/test/run-log-pruning
ld lightningd/test/run-check_node_announcement
ld lightningd/test/run-log_filter
ld lightningd/test/run-jsonrpc
ld lightningd/test/run-shuffle_fds
ld lightningd/test/run-invoice-select-inchan
^Cmake: *** [tools/Makefile:16: tools/headerversions] Interrupt
```
One workaround is to just know that you need to enter `y` here.
But the best solution is probably to update the Makefile like so.
Changelog-None
Multiple places in the pay lifecycle depend on mods to be set. By
setting the mods directly after the first listpeerchannels call,
subsequent calls to listpeerchannels are avoided.
Changelog-Fixed: pay-plugin: only call listpeerchannels once during a
payment lifecycle.
Since we don't compact the gossmap on the fly (FIXME!) we can
easily surpass 4GB in the gossmap, and 32 bit offsets are not
sufficient.
I'm a bit surprised we don't crash immediately, but we've definitely
seen issues.
Changelog-Fixed: gossipd: crash errors with large gossip_store (>4MB) growth on longer-running nodes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For nodes with many channels this is a tremendous improvement in pay
performance. PR #7611 improves payment performance from 15 seconds to
13.5 seconds on one of our nodes. This commit improves payment
performance from 13.5 seconds to 5.7 seconds.
Changelog-Fixed: Improved pathfinding speed for large nodes.
This minimizes the need to convert back and forth from and to sat
values, and it also removes a new instance of sats in the public
interface (`channel_hints`).
Suggested-By: Rusty Russell <@rustyrussell>
We were ignoring more reliable information because of the
stricter-is-better logic. This meant that we were also ignoring local
channel information, despite knowing better.
By simplifying the logic to pick the one with the newer timestamp we
ensure that later observations always trump earlier ones. There is a
bit of interplay between the relaxation of the constraints updating
the timestamp, and comparing to real observation timestamps, but that
should not impact us for local channels.
It was failing because the channel_hint from one attempt would prevent
us from retrying. By changing the amounts so that the channel_hints do
not concern them (value smaller than estimate) we can make things work
as before again.
A failing payment would doom all subsequent ones. Now we step down the
amount a single satoshi so any prior channel_hints do not doom the
payment outright.
Changelog-None
We were using `channel_hint` to temporarily tweak the graph inside of
a payment. However, these ad-hoc `channel_hints` are stickier than
their predecessors, in that they outlive the payment attempt itself,
and interfere with later ones.
Changelog-Changed: pay: Discarding an overly long or expensive route does not blocklist channels anymore.
If we have a large channel, fail to send through a small amount, and
then add a `channel_hint`, then it can happen that the call to
`channel_hint_set_update` is already late enough that it refills the
1msat we removed from the attempted amount, thus making the edge we
just excluded eligible again, which can lead into an infinite loop.
We slow down the updating of the channel_hints to once every
hysteresis timeout. This allows us to set tight constraints, while not
incurring in the accidental relaxation issue.
We need to know the overall channel capacity, i.e., the amount_msat
that the channel was funded with, in order to relax the channel_hint
to refill over time.
When cln is run without deprecated apis, the `listchannels` call would
still query `listpeerchannels`, even though it wouldn't use the result.
This adds unnecessary time to the call. Especially in case the node has
many channels. This commit skips the listpeerchannels call in case the
outcome won't be used.
Changelog-Fixed: Improve listchannels performance
1. describe_disabled should point out if node itself is disabled.
2. Hoist constraint check for neater if branching.
3. Use amount_msat_max/min for greater clarity.
4. Simply disable channels, don't zero htlc_min/max when node disabled.
I also fixed the diagnostic of htlc_max correctly, which removes a FIXME.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The code is a bit too complex for gcc to track it:
```
In file included from ccan/ccan/tal/str/str.h:7,
from plugins/askrene/askrene.c:11:
plugins/askrene/askrene.c: In function ‘do_getroutes’:
ccan/ccan/tal/tal.h:324:23: error: ‘routes’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
324 | #define tal_count(p) (tal_bytelen(p) / sizeof(*p))
| ^~~~~~~~~~~
plugins/askrene/askrene.c:476:24: note: ‘routes’ was declared here
476 | struct route **routes;
| ^~~~~~
plugins/askrene/askrene.c:475:29: error: ‘amounts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
475 | struct amount_msat *amounts;
| ^~~~~~~
plugins/askrene/askrene.c:488:69: error: ‘probability’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
488 | json_add_u64(response, "probability_ppm", (u64)(probability * 1000000));
| ~~~~~~~~~~~~~^~~~~~~~~~
cc plugins/askrene/dijkstra.c
cc1: all warnings being treated as errors
```
On my local machine, it also warns in param_dev_channel, so I fixed that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This turns out to be critical for users: also stops them from
bothering us when their node is offline or has insufficient capacity!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Lagrang3 points out it's less useful (when we time them out), and probably
a premature optimization anyway.
Suggested-by: Lagrang3 <lagrang3@protonmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows for explicit partial updates to channels (e.g. just change
fees, or just disable) without haveing to set the other fields.
This generalizes askrene-disable-channel, which is removed.
We also take the chance to use the proper BOLT 7 terms in the API:
- htlc_minimum_msat
- htlc_maximum_msat
- cltv_expiry_delta
- fee_base_msat
- fee_proportional_millionths
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was weird not to have a capacity associated with localmods channels, and
fixing it has some very nice side effects.
Now the gossmap_chan_get_capacity() call never fails (we prevented reading
of channels from gossmap in the partially-written case already), so we
make it return the capacity. We do this in msat, because that's what
all the callers want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is actually what we want in several places: to only override one or
two fields in a channel_update.
We add a gossmap_local_setchan() with a similar API to the old
gossmap_local_updatechan(), for the case where we want to set every
field.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Lagrang3 points out that if we hit a maximum, we should take into account
the reserve. This is true, but it's hard for the caller to do, so change
the API to be slightly higher level.
Tell "inform" what happened, and it adjust the constraints appropriately.
This makes the least assumptions possible (a reserve does *not* mean that
the capacity was actually used at that time).
We also add a mode to say "this succeeded": for now this does nothing,
but it could reduce both min/max capacities, and add capacity in the
other direction. This is useful for future payments, but not as useful
for the current one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I got confused, as we had a struct containing two arrays. Simply expose the
reserve_hop struct and use arrays directly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's generally better to be explicit with these things: currently typos
would be ignored. But it's also much easier to clean up entire layers
as we use them for temporary (per-payment) effects.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We allow adding them, but crash when we remove the localmods. Yet
this could theoretically happen if a channel we modified was removed
from the gossmap, anyway.
Reported-by: Lagrang3 <lagrang3@protonmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I like the clarity, but this is a hot path. Fortunately these arrays
have very well defined lengths.
Before: 5.81 seconds
After: 1.06 seconds
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only ever visit each node once, so we can just use an array. This
avoids calling tal() all the time, which is *especially* slow when we're
memory tracking.
I had an old canned gossmap which I benchmarked for these (and in
particular one node was unreachable, and that was slow):
Before: 17.27 seconds
After: 5.80 seconds
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows tools to validate that it is accessing the correct hsm_secret for this node!
This is extremely important for backups: if they are using VLS, they need to back *that*
up instead, for example.
Changelog-Added: `hsmtool`: `getnodeid` command derives the node id from the hsm_secret, to verify it's the correct secret.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We bump the version to minor version 0.2 to allow ourselves to bump on
patch level when we need to fix a bug or update a dependency.
Changelog-Changed: Plugins: `cln-grpc` Upgrade tonic version and
introduce new versioning scheme.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Tonic had some breaking changes since 0.8. We want to be closer to newer
versions for downstream consumers to be able to benefit from changes in tonic.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The `anchors/even` channel type was missing from the grpc bindings.
It is now the default channel type, so `fundchannel` over grpc fails
with:
```
Failed to deserialize response : unknown variant `anchors/even`,
expected one of `static_remotekey/even`, `anchor_outputs/even`,
`anchors_zero_fee_htlc_tx/even`, `scid_alias/even`, `zeroconf/even`
```
Changelog-Changed: Channel type `anchors/even` was added
to the grpc bindings.
This name is clearer than the old one.
And since the struct contains a string, it's more natural for the
struct to be the tal parent of the string so it's a real object. This means
we need an array of pointers, so each struct can be its own tal object.
wallet_state_change_get is hoisted higher in the code and made static.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And instead of loading them in listpeerchannels, use them. This means
listpeerchannels no longer touches the db.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSONRPC: `listpeerchannels` (and thus, pay) sped up on very large nodes.
Indirection via a string and an enum is just adding confusion here.
And move the `struct channel_stats` into channel.h.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids a db lookup on every iteration of listpeerchannels, which
can be slow on large nodes (Postgres, I assume).
We can now simply add the fields we want to channel load, and remove
wallet_channel_stats_load entirely.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
askrene.c was getting quite long, and this is self-contained.
The only code change is a convenience accessor for the per-htlc-cost
hash table.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
"spendable" is for a single HTLC: if we own the channel, this amount
decreases with every HTLC, as we have to pay fees. We have access to this since
we call listpeerchannels anyway, so we can calculate the additional costs and
use it in the refining phase.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't actually hit the htlc_max cases, since the flow code already
constrains us to that.
And handling htlc_min is better done in the caller, where diagnostics
are better (basically, we should eliminate them, and if that means no
route, give a clear error message).
And the refinement step can handle any extra millisats from rounding.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the root cause of the problem worked around in 50949b7b9c
"askrene: hack in some padding so we don't overflow capacities."
When adding fees to flows, we didn't recheck the boundary conditions: in
renepay this is done by routebuilder.
Fortunately, we can use our "reservations" infrastructure to temporarily
use capacity as we process flows, so we handle the cases where they are
not independent correclty.
My assumption is that the resulting errors are small, so we divide
them between the remaining flows based on highest-to-least
probability.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Simply calculate it when we need it, which means we don't have to keep it
up-to-date as we tweak the flow.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than making the callers do this, make the invoice decoder perform
the various sanity checks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had a workaround for channels added by "auto.local", but instead we
should make it work properly.
I didn't do this before because we can't manipulate the localmods while
they're applied, but it's simple to do it in two stages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Not quite the same, as it doesn't have the "auto.local" layer, but it exhibits
the same problem if we revert the fix for test_live_spendable.
And it's much faster!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I used `amount_msat_eq(x, AMOUNT_MSAT(0))` because I forgot this
function existed. I probably missed it because the name is surprising,
so add "is" in there to make it clear it's a boolean function.
You'll note almost all the places which did use it are Eduardo's and
Lisa's code, so maybe it's just me.
Fix up a few places which I could use it, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If I put in X, how much can I get out after fees are subtracted?
This was inspired by Eduardo's channel_maximum_forward in renepay, which
is basically the same thing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This was incorrect once we stopped removing old payments on failure,
which was the reason we had to remove the HTLCs.
It also removed by partid, which is wrong since it should have done
old_payment->partid and old_payment->groupid!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Removes CI value error for Broken logs
- Fixes CI errors due to deprecated listconfigs 'important-plugins'
- Removed listchannels deprecated local test
Changelog-None.
Thanks to Michael Schmook for the excellent bug report.
Fixes: https://github.com/ElementsProject/lightning/issues/7671
Changelog-Fixed: lightningd: no longer crash if a plugin dies during lightningd startup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In commit 60e1532dd8 (released in crate 0.1.8), which switched the
logging framework to tracing-subscriber, the default log level filter
was (accidentally) set to ERROR and above, instead of INFO and above.
Change this back to INFO as it was before. It can still be overridden
with CLN_PLUGIN_LOG.
Follows the example in https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#method.from_envCloses#7658.
Changelog-Fixed: cln-plugin: Change default log level filter back to INFO
It's an output field (which we don't complain about), not an input field!
Fixes: https://github.com/ElementsProject/lightning/issues/7652
Changelog-Fixed: Logging: removed bogus "**BROKEN** plugin-topology: DEPRECATED API USED: listchannels.include_private" message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For BOLT12 invoices, the "description" is field missing in the invoice
responses. Update the schemas accordingly:
- `doc/schemas/lightning-waitanyinvoice.json`
- `doc/schemas/lightning-waitinvoice.json`
Also commit the generated msggen, cln-grpc, cln-rpc and pyln-grpc-proto files.
Changelog-Fixed: schemas: Make description in `Wait(any)invoiceResponse` optional to handle BOLT12
Our low-level ccan/io IO routines return three values:
-1: error.
0: call me again, I'm not finished.
1: I'm done, go onto the next thing.
In the last release, we tweaked the sematics of "-1": we now opportunistically
call a routine which returns 0 once more, in case there's more data. We use errno to
distinguish between "EAGAIN" which means there wasn't any data, and real errors.
However, if the underlying read() returns 0 (which it does when the peer has closed
the other end) the value of errno is UNDEFINED. If it happens to be EAGAIN, we will
call it again, rather than closing. This causes us to spin: in particular people reported
hsmd consuming 100% of CPU.
The ccan/io read code handled this by setting errno to 0 in this case, but our own
wire low-level routines *did not*.
Fixes: https://github.com/ElementsProject/lightning/issues/7655
Changelog-Fixed: Fixed intermittant bug where hsmd (particularly, but also lightningd) could use 100% CPU.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we pull and old channel from the database, it might not.
Fixes: https://github.com/ElementsProject/lightning/issues/7645
Changelog-Fixes: lightningd: crash when starting channeld for older channel with no local alias.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Lightningd should log if a builtin plugin fails to start instead of
silently skip over it.
Changelog-Add: log message if builtin plugin fails to start.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
send_tlvs is NULL if no special features are supported, and peer
sets `next_to_send` anyway:
```
0x5ed1c6719538 peer_reconnect
channeld/channeld.c:5205
0x5ed1c6719dab init_channel
channeld/channeld.c:5959
0x5ed1c6719f04 main
channeld/channeld.c:6005
```
Backport: v24.08
Fixes: https://github.com/ElementsProject/lightning/issues/7486
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Updated `release-checklist` with new GitHub actions for Docker and PyPI publishing.
- Updated `repro` with information about the `cl-repro.sh` script.
Changelog-None.
Running `git describe` in local setup correctly identifies the tag available on the tag. But `docker buildx` via actions does not identify it without `--tags` param.
Reference Issue: https://github.com/ElementsProject/lightning/issues/7626
Changelog-Fixed: Docker image created via github actions correctly reads the tag available on the HEAD.
Python was installing `pyln-client` directly from the server for testplugpass plugin. This commit is updating the requirements.txt file to install pyln-client with absolute local path.
Commit a1fdeee76b "Makefile: clean up install path handling."
broke the ability to configure with one path and then run in a
different path. Turns out people actually do this! So, we have
to use relative paths, compared to our existing binary.
And we can't use path_rel, because that requires that the path
exist (thanks @Lagrang3!).
Fixes: https://github.com/ElementsProject/lightning/issues/7595
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Of course, we still will, since spendable is for a single HTLC, but
this also shows why we should treat *minimum* as the incorrect answer
if they cross, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/7563
It seems we didn't handle it correctly: we need to cap the first
segment as well as the others, as far as I can tell.
Also, it can be less than the maximum capacity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Conversion is lossy, and we don't want to spend more than the channel,
so it's conservative to round down here.
This doesn't actually help our test though!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Based on great test case from https://github.com/daywalker90
```
E AssertionError: assert {'107x2x0/1': 'Path total 285720859 > spendable 285718000', '108x1x0/1': 'Path total 384721849 > spendable 384718000'} == {}
E Left contains 2 more items:
E {'107x2x0/1': 'Path total 285720859 > spendable 285718000',
E '108x1x0/1': 'Path total 384721849 > spendable 384718000'}
E Full diff:
E {
E - ,
E + '107x2x0/1': 'Path total 285720859 > spendable 285718000',
E + '108x1x0/1': 'Path total 384721849 > spendable 384718000',
E }
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- **Poetry Issue:** The Docker build for `linux/arm/v7` failed in recent RC releases on the Poetry installation step in the `builder-python` stage. This issue occurred because the `builder-python` stage builds on target's arch but poetry was unable to install on arm/v7 without rust >= v1.56.1.
- **Solution:** Instead of installing poetry on the `builder-python` stage, we leveraged the existing multi-arch `builder` stage, which already had Poetry. Now, we export the dependencies from `pyproject.toml` to `requirements.txt` within the `builder` stage and then copy `requirements.txt` to the `builder-python` stage for pip installation.
- **Cryptography installation Issue:** python installations for `pyln-proto` started failing due to Cryptography upgrade from v41 to v42 (#7475). It is because now Cryptography needs cargo/rust also.
- **Solution:** Installing cargo in `builder-python` stage also.
- **Configure Prefix Issue:** Previously, we used `RUN ./configure --prefix=/tmp/lightning_install --enable-static` in the `builder` image and then copied `/tmp/lightning_install` from the `builder` stage to `/usr/local` in the `final` stage. However, this approach is now causing errors due to missing binaries/plugins at their default locations.
- **Solution:** We are now configuring the installation to use the default location (`/usr/local`). To prevent the local image size from increasing by up to 87MB, instead of copying the entire `/usr/local/` directory, we are explicitly copying only the core lightning binaries.
Changelog-Fixed: Fixes failing Docker build for `arm32` arch.
- Temporarily adding `rc` tag trigger for testing `Build and push multi-platform docker images` action flow before the final release.
- Added some variable inputs for testing like repo, platforms, etc.
- Added more logs for future debugging.
You need to know it to make an onion, and in theory if we decided to
fuzz it could be different for different paths.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Channel filter must apply to the modified gossmap+localmods,
otherwise we disable local channels with htlcmax=0.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Add a little bit of uncertainty to the local channels to avoid
consuming precisely all spendable_msat on our side, which leads to
temporary channel failure if the spendable_msat changes during the
course of the payment.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Refresh gossmap once before we read the routehints.
Make sure that if channels in the routehints are public,
we retrieve their capacities from gossip.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
- add more checks
- add more error messages
- compute probabilities without fees during MCF
- compute probabilities with fees during get_routes
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
In theory we should not have htlc_total<=known_max.
But for some strange race condition we do sometimes.
Until we find a solution to ensure the correct state
of the uncertainty network we remove the assertion.
Thanks to signed arithmetic and MIN guards, the rest
of the code in linearize_channel can handle the
weird cases with known_max<htlc_total.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The probability for a success forward of x amount on a channel is now
computed as:
P_success(x) = b * P_rene(x)
where P_rene(x) is the probability distribution proposed by Rene
Pickhardt with a uniform distribution on the known liquidity of the
channel and 'b' is a new parameter we add in this PR, by the name of
"base probability". The "base probability" represents the probability
for a channel in the network choosen at random to be able to forward at
least 1msat, ie. of being alive, non-depleted and with at least one HTLC
slot. We don't know the value of 'b', but for the moment we assume that
it is 0.98 and use that as default.
As a consequence the probability cost becomes non-linear and non-convex
because of the additional constant term:
Cost(x) = - log P_success(x)
= - log b - - log P_rene(x)
= - log b + Cost_rene(x)
We currently don't handle well base fees and neither this additional
"base probability" but we can as a first approximation linearize the
cost function in this way:
Cost_linear(x) = (- log b)*x + Cost_rene_linear(x)
Changelog-Added: renepay: Add a dev parameter to renepay that represents
a constant probability of availability for all channels in the network.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Commit 901342b50d ("pyln-testing: require
explicit pattern for BROKEN messages.") changed to a manual scan of
logs rather than using is_in_log, so it needs to manually refresh,
otherwise we miss final log messages.
This causes us to often miss memleak messages, which are printed
only in the exit path!
Reported-by: Lagrang3
Fixes: https://github.com/ElementsProject/lightning/issues/7565
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Mainly, it just causes complaints if we're running a lightningd which is installed
(in which case, my_path is not stolen, unlike running locally installed).
Reported-by: daywalker90
Fixes: https://github.com/ElementsProject/lightning/issues/7569
Changelog-None: regression this release
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our hash tables allow duplicate keys, and we use that in a few places.
However, the get() function only returns the first, so it's not a good
idea with such hash tables.
Another patch fixes this at a deeper level (using different hash table
types depending on whether this table can have duplicates), but this
is the minimal fix for existing code.
This may be the cause behind us occasionally missing onchain events:
Fixes: https://github.com/ElementsProject/lightning/issues/7460
Fixes: https://github.com/ElementsProject/lightning/issues/7377
Fixes: https://github.com/ElementsProject/lightning/issues/7118
Fixes: https://github.com/ElementsProject/lightning/issues/6951
This fixes them in future: fixing them now will require something else.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: occasionally we could miss transaction outputs (not telling gossipd, or even onchaind)
msggen cannot handle the complex type in renepay-exclude,
therefore I added a rule override for it, just like pay-exclude.
```
msggen cln-grpc/proto/node.proto
Traceback (most recent call last):
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/__main__.py", line 131, in <module>
main()
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/__main__.py", line 115, in main
run()
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/__main__.py", line 72, in run
service = load_jsonrpc_service(
^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/utils/utils.py", line 241, in load_jsonrpc_service
methods = [load_jsonrpc_method(name) for name in grpc_method_names]
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/utils/utils.py", line 209, in load_jsonrpc_method
request = CompositeField.from_js(schema["methods"][rpc_name]['request'], path=name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/model.py", line 297, in from_js
field = ArrayField.from_js(fpath, ftype)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/model.py", line 464, in from_js
itemtype = UnionField.from_js(child_js, path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/devel/cvs/lightning/contrib/msggen/msggen/model.py", line 393, in from_js
itemtype = PrimitiveField(
^^^^^^^^^^^^^^^
TypeError: PrimitiveField.__init__() missing 2 required positional arguments: 'added' and 'deprecated'
```
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-EXPERIMENTAL: renepay: add cli option "exclude" to manually disable channels and nodes.
We add a channel filtering paymod that disables channels that have very
low max_htlc. It can be expanded to consider other properties as well,
for instance high base fee, low capacity or high latency.
Changelog-Added: renepay: prune the network by disabling channels we
don't like, eg. very low max_htlc.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Expecting to have more than just a bunch of disabled channels if we
prune the lightning network heavily I am changing the internal data
structure of disabledmap from a simple array to a hashtable.
Have a finer control over disabled channels by targeting
short_channel_id_dir instead of short_channel_id,
ie. we can disable a single direction of a channel.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
If the rpc plugin is run while an older version of reckless is found on
PATH, it produces an error:
2024-08-01T18:32:00.849Z DEBUG plugin-recklessrpc: reckless-stderr:usage: reckless [-h] [-d RECKLESS_DIR] [-l LIGHTNING] [-c CONF] [-r] [--network NETWORK] [-v]
{install,uninstall,search,enable,disable,source,help} ...
reckless: error: unrecognized arguments: --json
Catch this and don't try to parse the output as json.
This allows generic subcommands to be passed to reckless-rpc along with
the target to search/install/etc.. These commands are unvalidated so
far and may crash the reckless process.
Changelog-Added: reckless-rpc plugin: issue commands to reckless over rpc.
This is actually totally fair, and LND, which does not support it without an option, rejects.
Thanks to Vincenzo and roasbeef for debugging this for me!
Fixes: https://github.com/ElementsProject/lightning/issues/7221
Changelog-Fixed: Protocol: we can now open unannounced channels with LND nodes again.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The documentation and the implementation of inform-channel have
different orders for the arguments minimum_msat and maximum_msat.
We change the order in the documentation to match that of the
implementation: minimum_msat comes before maximum_msat.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Often I find this in the logs:
DEBUG plugin-cln-renepay: gossmap ignored 94692259263600 channel updates
Apparently gossmap_refresh does not initialize the input variable num_channel_updates_rejected.
Fix this by explicitely initializing it before calling gossmap_refresh.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
routefail object allocation was linked to route,
we had a crash of the plugin with the following error:
0x561f424fc07a send_backtrace
common/daemon.c:33
0x561f424fc102 crashdump
common/daemon.c:75
0x7f5b0e7dc04f ???
???:0
0x7f5b0e82ae2c ???
???:0
0x7f5b0e7dbfb1 ???
???:0
0x7f5b0e7c6471 ???
???:0
0x561f4252581f call_error
ccan/ccan/tal/tal.c:95
0x561f425258c8 check_bounds
ccan/ccan/tal/tal.c:169
0x561f425258f9 to_tal_hdr
ccan/ccan/tal/tal.c:179
0x561f42526283 tal_free
ccan/ccan/tal/tal.c:525
0x561f424e5379 routefail_end
plugins/renepay/routefail.c:52
0x561f424e557b handle_failure
plugins/renepay/routefail.c:431
apparently there was a race condition for which the route was first
freed before we arrived to routefail_end where we manually free
routefail. I don't see how this could have happened, but anyways
this subtle bug can be avoided by linking the routefail to the payment.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Fixed: renepay: finalized routes have to be processed and
determine the payment status even after the payment goes into the
background (no current command active). Not doing so leads to finalized
routes getting stuck in the payment internal data structure and their
associated HTLCs in the uncertainty network don't get released.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We rather have a payment hash table to look up payments based on the
payment hash than having a list.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Use success_data_from_listsendpays to check if there are "complete"
sendpays instead of imposing the presence of "complete" sendpays as a
precondition for success_data_from_listsendpays.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Simply move the "computed routes" array from the payment to the
routetracker. It makes sense to put all temporary stages of routing into
a single data structure: the routetracker.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
There were some dummy rpc calls to waitblockheight in the payment workflow
to allow the function stack to clear. But it is better if some steps in
the payment are executed "atomically" to avoid strange race conditions.
For example: all steps between getting pending sendpays, computing new
routes and sending those routes.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
It feels unsafe to rely on the internal state of the plugin's database
to tell how many pending sendpays there are for the current payment.
The safest way is to assume lightningd knows and thus use listsendpay
before computing routes.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
- remove payment pointer from routetracker, fetch payment if necessary
from payment_hash;
- "have results" condition as a function call to routetracker.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The time of decay "TIMER_FORGET_SEC" was set to 1 hour,
which is very low, it would make the plugin try depleted channels after
just a couple of seconds for very small amounts.
I set it to 1 week ~ 6e5 seconds.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
When you have *lots* of events in your bkpr database looking up a
specific event via calling bkpr-listaccountevents and using jq or
grep to filter gets very slow (and wasteful of CPU and disk resources).
This commit adds the paremeter payment_id to the call to filter for a
specific payment id via a where clause in the request to the database of bkpr.
Changelog-Added: Plugins: Add payment_id parameter to bkpr-listaccountevents to filter events.
When a peer connects, we always send all our own gossip (even if they
had set the timestamp filters to filter it out). But we weren't
forcing it out to them when it changed, so this logic only applied to
unstable or frequently-restarting nodes.
So now, we tell all the peers whenever we tell gossipd about our new
gossip.
Fixes: #7276
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: We now send current peers our changed gossip (even if they set timestamp_filter otherwise), not just on reconnect.
We didn't actually check that we *send* the refreshed gossip, just
that we print the message saying we're going to.
So check that everyone received updated gossip when this happens.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sometimes, for various reasons, a user disables an offer
and then wants to re-enable it. This should be allowed because,
from the CLN point of view, it is just an internal state.
If a user has constraints on the description of the invoice
because they are using services that link some sort of user ID
to an offer, it is important for the user to be able to re-enable the
offer, not create a new one. Creating a new offer would
require a different description.
Link: https://github.com/ElementsProject/lightning/issues/7360
Co-Developed-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
I will commit doc/schemas/lightning-*.json files separately to keep this commit easier to review.
- test-autogenerate-rpc-examples updates all example request & responses in doc/schemas/lightning-*.json files.
- Updated tools/fromschema.py to accommodate the sql JSON example requirement where it does not accept -o in the query but shell does (for queries containing the = sign).
Changelog-None.
Bitcoind's web server has a default of 4 threads, with queue depth 16 and it fails rather than queue beyond that.
Increasing thread count to 20 for running >10 lightning test nodes simultaneously.
1) We can't simply cast away const to manipulate a string, the compiler can assume
we don't. The type must be made non-const.
2) cisspace() is nicer to use than isspace() (no cast required!)
3) Simply place a NUL terminator instead of using memmove to set it.
4) Use cast_const to add const to char **, where necessary.
5) Add Changelog line, for CHANGELOG.md
Changelog-Fixed: Config: whitespace at the end of (most) options is now ignored, not complained about.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Did a sweep to find any others, give this from sanitizer:
```
2024-08-09T18:06:45.1729472Z plugins/bkpr/recorder.c:2057:23: runtime error: load of value 190, which is not a valid value for type 'bool'
2024-08-09T18:06:45.1729877Z SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior plugins/bkpr/recorder.c:2057:23 in
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Valgrind found this. I think two PRs were added in parallel, which is why we
only found it after merge:
```
2024-08-09T01:57:23.7375752Z ==34263== Uninitialised byte(s) found during client check request
2024-08-09T01:57:23.7376275Z ==34263== at 0x172405: memcheck_ (mem.h:247)
2024-08-09T01:57:23.7376661Z ==34263== by 0x172585: db_bind_int (bindings.c:49)
2024-08-09T01:57:23.7377086Z ==34263== by 0x126233: log_chain_event (recorder.c:2057)
2024-08-09T01:57:23.7377544Z ==34263== by 0x11BF8B: json_utxo_deposit (bookkeeper.c:1735)
2024-08-09T01:57:23.7378207Z ==34263== by 0x12BED3: ld_command_handle (libplugin.c:1847)
2024-08-09T01:57:23.7378674Z ==34263== by 0x12C649: ld_read_json_one (libplugin.c:1998)
2024-08-09T01:57:23.7379114Z ==34263== by 0x12C780: ld_read_json (libplugin.c:2018)
2024-08-09T01:57:23.7379534Z ==34263== by 0x2990CB: next_plan (io.c:60)
2024-08-09T01:57:23.7379881Z ==34263== by 0x299D21: do_plan (io.c:422)
2024-08-09T01:57:23.7380230Z ==34263== by 0x299D88: io_ready (io.c:439)
2024-08-09T01:57:23.7380585Z ==34263== by 0x29C1BC: io_loop (poll.c:455)
2024-08-09T01:57:23.7380980Z ==34263== by 0x12D439: plugin_main (libplugin.c:2230)
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When renepay starts, one of the first operations it does is to check for
pending sendpays for the same invoice. Those are added up to an internal
database to keep track of. Also the amount they deliver to the
destination is computed so that the current payment rpc call would try
to complete the payment for whatever amount remains to pay.
For an incomplete payment after calling the RPC renepay I found this in
the logs:
2024-05-22T19:44:19.853Z DEBUG plugin-cln-renepay: There are pending sendpays to this invoice. groupid = 6 delivering = 0msat, last_partid = 10
Where delivering should be the sum of the amounts delivered by pending routes.
The `pay` plugin, as well as other plugins making use of the tree-pay
executor, will now emit their observations as they see them. The
notifications are sent on the `channel_hint_updated` topic, and any
subscriber will get them.
We also added a `timestamp` to the `struct channel_hint`, as these
observations now outlive the `pay` call, and have to be attenuated /
relaxed as they age, until we can eliminate them completely (when the
restriction is equal to the structural information gathered from the
gossip).
Changelog-Added: pay: Payments now emit `channel_hint_updated` notification to share inferred balances and observations across multiple payments.
It might be nice to let the bookkeeper keep track of external accounts
as well as the internal onchain wallet? To this end, we add some new
custom notifications, which the bookkeeper will ingest and add to its
ledger.
Suggested-By: @chrisguida
Changelog-Added: PLUGINS: `bookkeeper` now listens for two custom events: `utxo_deposit` and `utxo_spend`. This allows for 3rd party plugins to send onchain coin events to the `bookkeeper`. See the new plugins/bkpr/README.md for details on how these work!
We used to always target `now() + 300`, which ends up never really
confirming, as the fee estimate bumps into the min-relay-fee
limit. With this commit we set an absolute target of 2 weeks, and a
linear fee rampup, until we are at T-2h, at which point we just stick
with the estimate, and try with this increased feerate to try and get
the sweep confirmed.
This ought to make RBF transactions much more efficient for closing
channels.
Changelog-Fixed onchaind: The sweep deadline for to_us outputs would be reset on each restart of the subdaemon. Now the deadline is absolute in terms of the close height.
We do some fancy accounting for channel closures; since we're tagging
splice txs as closes we need to mark them as splices so we can treat them
as any other 'normal' on chain event.
We weren't properly notifying that a channel output has been spent in
the case of it being spent in a splice. This fixes the notification side
of the equation, however there's still some issues remaining for the
bookkeeper side (to come).
Changelog-Fixed: We now send a `coin_movement` notification for splice confirmations of channel funding outpoint spends.
Changelog-Added: pay: The pay plugin now checks whether we have enough spendable capacity before computing a route, returning a clear error message if we don't
This allows us to directly returnan error code based on where we
decided to abort, rather than attemtping to infer it from the parts.
Changelog-Added: pay: The pay plugin now returns better error codes
Also redirect config creation prompts to stderr in order to not interfere
with json output on stdout.
Changelog-Added: reckless provides json output with option flag -j/--json
This follows the same structure that enables python virtual environments:
reckless/
<plugin_name>/
<symlink to compiled bin>
source/
<clone of original source plugin dir>/
Changelog-Added: Reckless: added the ability to install rust plugins.
We had some weird code to try to do relative paths. Instead, use absolute
ones and keep life simple. Also rename "daemon_dir" to the clearer
"subdaemon_dir" as that's what it's used for.
We now need special magic to do "installcheck", which is a bit awkward,
but at least it's contained.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This populates information on both topology (i.e. unannounced channels) and capacity for the local node using `listpeerchannels`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This marks all channels around the source node as free (no delay, no fee). This is normally what we want, if we are calculating a path for ourselves.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In general, we should be using tmpctx unless there's a specific reason not to.
It's clear, and simplifies the code somewhat.
If tmpctx is not cleaned often enough, we can look at a per-MCF context, but this
seems like premature optimization.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We let the caller choose mu, and iterate if necessary: it can also
check its limits for fees, etc. Rationalize it to 0-100 inclusive for
human consumption.
This means we don't loop internally, and in fact there's only one
failure mode: we cannot find enough capacity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't know anything about most channels, so we create an array of
fp16_t containing them. We zero out ones where we do know something,
and use the previous code as the slow path.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we never have to look up a local channel when asked the capacity.
We mark these dummy constraints with an MAX timestamp.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We apply all the gossmods for the layers they specified, and create a
naive routine to give the capacity of a channel given those layers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They tell us what paths they're using, so we can adjust capacity estimates
accordingly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'reserve-fixup.patch':
fixup! askrene: reservation implementation.
These are the repositories of all information.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'layers-fixup.patch':
fixup! askrene: add layers infrastructure.
This avoids globals (and means memleak traverses the variables!): we
only change over the test plugin though, to avoid unnecessary churn.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This simplifies the callers significantly: all channel_announcements now
have an amount, so gossmap_chan_get_capacity() only fails on a local
modification.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we actually check the other fields too, as per BOLT!
Reported-by: https://github.com/hMsatsFixes: #7513
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This helps code using generate_gossip_store() too, since it can map its identifiers
to the nodeids which were used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
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>
And make it use inject_onionmessage. This means we have to be more careful
in createinvoice_done where we had a payload field allocated off tmpctx.
The new code correctly handles the case where we find a path (not just
a peer!) to the start of a blinded path, and need to join the paths.
It worked before if we had to connect directly, just not in the case
where we actually found a usable route of more than 1 hop.
Changelog-EXPERIMENTAL: fixed: onionmessage replies now work even if we need to route to the start of the blinded reply path.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This will obsolete the existing calls to RPC "sendonionmessage", but
we transition by introducing it separately. It's designed to work with
the common/onion_message routines and "injectonionmessage".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is complicated, and I needed to write it down. All the current routines
are spread through the code, and I wanted it all in one place.
This implementation also support *joining* two paths together, which we
previously didn't.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We already parse some fields, so hand them directly rather than
having fetchinvoice behave as if it's a raw hook.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means only a single gossmap, and they already share the fetchinvoice-noconnect option
and autoconnect code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Plugins: the `fetchinvoice` plugin has been combined into the `offers` plugin.
The *schemas* were added in v24.05, but the actual fields are much older. Unfortunately,
fixing this required a manual edit of the .msggen.json file, as msggen won't let the
added version change (for good reason).
Versions when these notifications were originally added:
connect: v0.6.3
channel_opened: v0.7.2.1:
channel_state_changed: v0.9.1
channel_open_failed: v0.9.3
block_added: v22.11
custommsg: v24.02
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Making sure that we are able to fetch the invoice
from an offer without description
E pyln.client.lightning.RpcError: RPC call failed: method:
offer, payload: {'amount': '2msat'}, error: {'code': -32602, 'message':
'bolt12: Offer does not contain a description: invalid token
\'"lno1qgsqvgnwgcg35z6ee2h3yczraddm72xrfua9uve2rlrm9deu7xyfzrcgqyppvggz953rvg9rtxj8lalh43z8epwydjfrmffn3y3p5qz5cywpu09rr4vs"\''}
Link: https://github.com/ElementsProject/lightning/issues/7405
Link: https://github.com/ElementsProject/lightning/issues/7404
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Changelog-Added: Protocol: onion messages are now supported by default.
Changelog-Deprecated: Config: the --experimental-onion-messages option is ignored (on by default).
However fast we can handle them, it's antisocial to allow others to
make us spam the rest of the network.
Changelog-Protocol: onion messages: we limit incoming to 4 per second, allowing a little burst.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is now permitted in the offers PR, so we should support it. But
we can't just look up in the gossmap, since the "short_channel_id"
could be an alias. So we get lightningd to tell us all scid->peer
mappings, and look up in that.
Changelog-Added: Protocol: onion messages can now be forwarded by short_channel_id.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we set them (i.e. at lockin), when we fire up channeld (for
aliases, which we create at channel init, but aren't really useful
until we have finished channel opening), and at startup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Unlike "sendonionmessage" which instructs us to send to a peer, this
process it locally (presumably, it contains the next hop). This is
useful because it allows us to process an onion message which starts
with us (a legal case for a blinded path supplied by someone else!).
It also opens the door to bolt12 self-pay.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Allows for caller to log, but more importantly, when we add a command to
inject onion messages, allows for us to capture the error.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For some reason CI now hits a race where it tries to analyze a still-being-generated file:
```
tools/headerversions.c:52:30: error: syntax error [syntaxError]
new = tal_fmt(NULL, template,
^
make: *** [Makefile:552: check-cppcheck] Error 123
```
Restrict it to real source files instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A bit tricky, since we get more than one message at a time. However,
this just means we go over quota for a bit, and will get caught when
those are sent (we do this for a single message already, so it's not
that much worse).
Note: this not only limits sending, but it limits the actuall query
processing, which is nice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This basically means moving the code from gossipd to connectd to handle
these queries.
This will get connectd have finer control over ratelimiting them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This was removed from the spec on Apr 25, 2022. We stopped ever sending them
in 0.12.0 (2022-08-23). Now we remove receive support.
Changelog-Protocol: Removed support for zlib-compressed short-channel-ids in query responses.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is more efficient in a few ways:
1. It's trivial to get to the end of the gossip_store, we don't have
to iterate.
2. It tends to be mmaped so we don't have to call pread().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently stream gossip as fast as we can, even if they start at
timestamp 0. Instead, use a simple token bucket filter and only let
them have 1MB per second (500 bytes per second for testing).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Protocol: connectd: we now throttle outgoing gossip at 1MB/second per peer.
We never call `listconfigs` in our tests with `experimental-offers` enabled,
so we didn't notice that the schema is wrong: it does not expect the
"plugin" field in 'fetchinvoice-noconnect'.
The next patch folds the fetchinvoice plugin into the offers plugin,
which is enabled even if `experimental-offers` isn't (for `decode`),
so we notice it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Document and enforce the --experimental-anchors deprecation, which was somehow missed in v24.02
Changelog-Deprecated: Config: the --experimental-anchors option is ignored (on by default since v24.02).
Only sphinx internally uses the hmac field: it's actually a general descriptor
of onion contents, which we can use elsewhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't use the payment_secret in bolt12, but in onion_decode() we
do put the path_secret (if of correct length) into payment_secret. Not
realizing this confused me, so document that, and make sure we insist
on it being present for bolt12.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This was when we handled pre-TLV onions where the first byte was 0. We haven't
done that for a while: you can tell, because process_onionpacket doesn't use
the parameter at all!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can't happen because we go the self-pay path in this case, but
once we fix that for bolt12, this can be reached.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were getting the following message in test_feerate_stress:
```
2024-07-08T02:15:45.5663941Z lightningd-2 2024-07-08T02:13:45.696Z **BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Peer did not close, forcing close
```
I can reproduce it locally if I run the test enough, and finally found
the issue by printing the status of the fd when we time it out (using
routines from connectd.c).
The peer fd alternates between reading and writing. When we go to
discard it, we wake the write queue, so write_to_peer() get called.
It won't shutdown the socket if there are still subds attached, and
will wait again for a read.
The last subd exit has to also wake the write queue if we're draining,
so it can do the io_sock_shutdown. Otherwise, we hit the timeout,
causing the message above.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Theoretical only, but we could leak an fd if we closed a conn before
the fd was sent. This doesn't happen in our current codebase because
we only hand fds to connectd, which only closes at shutdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only hand fds to connectd for now, so this doesn't happen (we don't
destroy that queue except on shutdown). But it's still a potential issue.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If the peer sends you their signatures before we return from the *first*
openchannel_update then the state would still be in
MULTIFUNDCHANNEL_STARTED (not UPDATED) and we'd incorrectly switch the
state to MULTIFUNDCHANNEL_SIGNED, which would plunge us headfirst into
`check_sigs_ready`.
However the `mfc->txid` hadn't been set yet, so we'd crash when trying
to confirm that we've got sigs for the correct txid. Oops.
To fix this, we simply invert the check such that the *only* state that
will move into SIGNED is SECURED
Interestingly, this patch and the last take my total test time on my
build machine down by about 10%. From 403.93s (0:06:43) to 366.64s (0:06:06)
though there were some unrelated errors.
Changelog-Changed: connectd: I/O optimizations to significantly speed up larger nodes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A fairly simple change: ccan/io will now call the underlying I/O
routines repeatedly until they indicate they are unfinished, *or* fail
with EAGAIN. This should make a significant difference to large
nodes, which currently spend far too much time calling poll() to
discover a single fd is still writable (mainly, for streaming gossip).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: connectd: now should use far less CPU on large nodes.
common/version.o depends on common/version_gen.h explicitly already,
and header_versions_gen.h is only used by lightningd, so we can make
that dependency explicit.
This means when version changes (i.e. different git commit) we only
relink, not recompile.
Before:
```
real 0m6.578s
user 0m14.705s
sys 0m13.621s
```
After:
```
real 0m2.098s
user 0m6.763s
sys 0m4.844s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This slows compilation somewhat when we make small changes (e.g. making the tree dirty).
Instead, simply mark them as "pre-XXX" or "XXX".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Their dependencies seem correct, so we shouldn't have to build them every time.
Before:
```shell
$ time make -s
real 0m5.183s
user 0m5.134s
sys 0m11.715s
```
After:
```shell
$ time make -s
real 0m0.784s
user 0m0.775s
sys 0m1.159s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The file `cln-rpc/src/notifications.rs` is generated by `msggen`.
The `Makefile` has tooling to update the file when needed
- `make check-gen-updated` should error if file isn't properly updated
- `make gen` updates the file
This comit fixes both behaviors mentioned above.
As suggested by @cdecker, I compared `poetry show --tree` results from before/after `cd plugins/clnrest/ && poetry export --output requirements.txt && pip install -r requirements.txt` to check for any significant difference. There is no difference in the tree.
But poetry export removed coincurve & other dependencies from clnrest's requirements.txt.
Changelog-None.
clnrest installation instruction on the markdown tries to install `flask_restx` not `flask-restx`.
Reference: clnrest plugin complains of flask_restx missing (#7383)
Changelog-None.
Documents which are deleted from lightning schema were still listed on readme server.
This script was adding or updating the list but delete action was missing.
Changelog-None.
Shahana decided this was the optimal UX path, though I insisted that we still
report the actual problem directly when in dev mode, as a compromise.
Suggested-by: https://github.com/Amperstrand
Changelog-Changed: JSON-RPC: Do not return the contents of invalid parameters in error messages, refer to logs (use 'check' to get full error messages)
Fixes: https://github.com/ElementsProject/lightning/issues/7338
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It doesn't actually log, just gets the `struct logger`, so this name is better.
We're also going to implement command_log() as an actual logging
function in next commit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
2024-06-24T05:09:32.5233603Z assert l1.rpc.listfunds()["channels"][0]["state"] == "ONCHAIN"
2024-06-24T05:09:32.5234187Z > assert l2.rpc.listfunds()["channels"][0]["state"] == "ONCHAIN"
2024-06-24T05:09:32.5234917Z E AssertionError: assert 'FUNDING_SPEND_SEEN' == 'ONCHAIN'
2024-06-24T05:09:32.5235464Z E - ONCHAIN
2024-06-24T05:09:32.5235773Z E + FUNDING_SPEND_SEEN
2024-06-24T05:09:32.5236096Z
2024-06-24T05:09:32.5236242Z tests/test_misc.py:2907: AssertionError
```
It's possible that l2 hasn't seen the onchain tx yet. What we really want to do is
wait for it, then test that l1 really can spend the output it has recovered.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
2024-06-24T05:14:14.9939033Z > l1.rpc.call('dev-feerate', [l2.info['id'], rate - 5])
2024-06-24T05:14:14.9939354Z
2024-06-24T05:14:14.9939466Z tests/test_connection.py:3439:
...
2024-06-24T05:14:14.9967617Z > raise RpcError(method, payload, resp['error'])
2024-06-24T05:14:14.9968833Z E pyln.client.lightning.RpcError: RPC call failed: method: dev-feerate, payload: ['022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59', 2290], error: {'code': -1, 'message': 'Peer bad state'}
```
The disconnect can actually take a while: wait for both sides to
believe they're reconnected. Also wait a little to make sure the
feerate change doesn't create a bad signature.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
lightningd-3 penalizes lightningd-2 but then it can see the preimage for the HTLC which
has already been timed out:
```
2024-06-24T02:41:29.4633900Z lightningd-3 2024-06-24T02:33:54.073Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-onchaind-chan#1: HTLC already resolved by THEIR_HTLC_TIMEOUT_TO_THEM when we found preimage
```
This is fair: the test deliberately takes l3 offline for long enough
that the HTLC can get timed out.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Found by very slow CI: the two io_breaks() can combine into one, so we
block waiting for the second initialization which never happens.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
checkchain_timer is run by chaintopology, so why have the pointer in
bitcoind?
And since we free the timers, we don't need them to self-disable by
checking the stopped flag.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Handling half in main() and half here was a mess. And the name
"max_blockheight" was poor: it was the max in the db, or UINT32_MAX,
but then we changed it depending on what height we wanted to start at.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/6924
Changelog-Changed: lightningd: we wait for bitcoind if it has somehow gone backwards (as long as header height is still ok).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The current code is confusing: there are polling loops, but we wait for
them to run once.
Be explicit: make the calls once, then start the loops in begin_topology.
This removes various chain_topology struct members which only exist for
startup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Example usage has been either merged with examples or usage keys. This heading was not required separately.
This PR edits & rearranges Examples, Example Notifications and Example Usage data.
Changelog-None.
- Added missing Example Notifications Heading
- Renamed `example_json_notifications` to `example_notifications`
- Moved `example_notifications` to the end of the page
- Changed ALL `doc/schemas/lightning-*.json` file's `json_example` to `examples`
- Change the heading from example to examples
- Bring shell command before the json command
- Move Example to the end of the page
- Remove horizontal line from Example
I was trying to debug a node with several multiplexed channels, and
was finding it a bit difficult to determine which channel index
matches which result of `listpeerchannels` as well as figuring out
what their status was. This just prints the status in string format
when loading the channel from the DB.
Changelog-Changed: wallet: The channel status is printed when loading it from the DB
[ Fix not to include 'value' and 'default' (if None) in getmanifest response --RR ]
[ Fix to support [] operator for existing plugins (including our test ones!) --RR ]
I was looking into using the `threading.Condition` but since we're
already rather heavily using callbacks, this allows us to stay
single-threaded, and not having to completely hook the `setconfig`
function.
Changelog-Added: pyln-client: Added a notification mechanism for config changes
We didn't actually *change* the value you'd see, when we got a setconfig call!
Changelog-Added: pyln-client: implement setconfig hook for plugins so you can see changes in `dynamic` options.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can filter down to only the list* fields we need. In the case of a
node with 1M forwards, this reduces listforwards time from 5 seconds
to 4 seconds. It will also reduce memory consumption.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There are really three subsystems: invoices, forwards and sendpays,
each of which has two variants we care about (successes and failures).
If we split the code that way, we can extract the core differences in
each of these cases and share most of the logic.
It's a bit awkward to iterate over each "subsystem" in the JSON
parameter sense, so we have some iteration code to do that where we
need to.
The result is going to be much easier to paginate!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're about to make this a more complex struct, so introducing a
new_clean_info() function unifies the code paths.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From test_penalty_htlc_tx_timeout[False] flake (with keys replaced by l2 and l5, for clarity)
```
lightningd-3 2024-06-04T04:34:00.942Z UNUSUAL l2-chan#1: Peer permanent failure in CHANNELD_NORMAL: Funding transaction spent
lightningd-3 2024-06-04T04:34:01.570Z UNUSUAL l5-chan#3: Peer permanent failure in CHANNELD_NORMAL: Funding transaction spent
lightningd-3 2024-06-04T04:34:01.655Z UNUSUAL l5-chan#3: Abandoning unresolved onchain HTLC at block 132 (expired at 125) to avoid peer closing incoming HTLC at block 131
lightningd-3 2024-06-04T04:34:02.802Z **BROKEN** l5-chan#3: FUNDS LOSS of 50000000msat: peer took funds onchain before we could time out the HTLC, but we abandoned incoming HTLC to save the incoming channel
```
So, we were already closing l2, no reason to abandon it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2923 lines of output? Even with warnings-only, it's 59 lines, so only
enable that with `make V=1`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
v4.0 no longer works for me (see below, and widely reported elsewhere).
v5.0 doesn't understand f strings, and creates a flood of complaints.
v6.0 requires python >= 3.8.1, so we need to update that.
v7.0 is the latest, but why push it.
```
make check-python-flake8
Traceback (most recent call last):
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/bin/flake8", line 8, in <module>
sys.exit(main())
^^^^^^
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/main/cli.py", line 22, in main
app.run(argv)
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/main/application.py", line 375, in run
self._run(argv)
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/main/application.py", line 363, in _run
self.initialize(argv)
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/main/application.py", line 343, in initialize
self.find_plugins(config_finder)
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/main/application.py", line 157, in find_plugins
self.check_plugins = plugin_manager.Checkers(local_plugins.extension)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/plugins/manager.py", line 363, in __init__
self.manager = PluginManager(
^^^^^^^^^^^^^^
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/plugins/manager.py", line 243, in __init__
self._load_entrypoint_plugins()
File "/home/rusty/.cache/pypoetry/virtualenvs/cln-meta-project-BgKQHyxC-py3.12/lib/python3.12/site-packages/flake8/plugins/manager.py", line 261, in _load_entrypoint_plugins
eps = importlib_metadata.entry_points().get(self.namespace, ())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'EntryPoints' object has no attribute 'get'
make: *** [Makefile:535: check-python-flake8] Error 1
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This PR is adding github action for auto Docker releases. This will streamline Docker image builds & releases for enhanced efficiency, reliability, and consistency in managing Docker-based deployments.
The build & release event will be triggered:
- On any new tag creation without rc suffix.
- Manually for testing purposes.
Changelog-None.
This update will add lightning-cli examples and make examples heading collapsible.
- The JSON EXAMPLES heading is collapsible now
- Examples in lightning-cli format also
- manpage examples have better formatting
Changelog-None.
We could get the current key from the reestablish message even if we'd
lost our db, but there are very few of these channels left: we upgraded to use them
in the 2019-01-09 release.
We will eventually remove support altogether, but this is a nice removal of
some ugly code for something which "never happens".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Everyone understands gossip_queries now, but peers leave it unset to indicate
they have nothing useful to say.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have assumed this for a long time, so nothing changes.
Confusingly, this BOLT commit also cleaned up one reamining `option_anchors_zero_fee_htlc_tx`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a difficult transition for us: this string appears in channel
types. We make the transition now in the understanding that it will
be more difficult in future.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: JSON-RPC: `listpeers` `features` array string "option_anchors_zero_fee_htlc_tx": use "option_anchors" (spec renamed it).
Changelog-Added: JSON-RPC: `listpeers` `features` array string uses "option_anchors" for feature 22/23, following renaming in BOLT 9.
Changelog-Changed: JSON-RPC: `listclosedchannels`, `listpeerchannels`, `openchannel_update`, `openchannel_init`, `fundchannel`, `fundchannel_start` and `multifundchannel`: `channel_type` array `names` now contains "anchors" instead of "anchors_zero_fee_htlc_tx".
Changelog-Changed: lightningd: `--list-features-only` now lists "option_anchors" instead of "option_anchors_zero_fee_htlc_tx".
These were removed from the spec.
We still support existing ones, though we were the only implementation
which ever did, and only in experimental mode, so we should be able to
upgrade them and avoid a forced close, with a bit of engineering...
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We still support *existing* channels. Just not new ones (before they could,
in theory, explicitly ask for one).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Just use substrings not regexes, since we have more complex characters now LaTeX
is entering the spec!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we do have to set the network correctly though,
and also we can get query messages from lightningd which we have to filter.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since `poetry=1.8.0` there is a non-package mode. This can be used to
create `pyproject.toml` files that are only used to track dependencies.
Performing `poetry install` in the project-root with a recent version of `poetry`
is currently generating a warning which will become an error in the
future.
Setting `package-mode=false` makes this error go away.
A side-effect is that the `name`, `version` and `description` in the
`pyproject.toml`-file will be ignored. Keeping the parameters in the
`pyproject.toml` file ensures it will still work for developers who are
using `poetry<1.8.0`.
We documented them as deprecated in v23.08 but unintentionally didn't deprecate them in the code. Thus we are starting their actual deprecation cycle from v24.08 release.
Updating removal version for commands `commando-rune`, `commando-listrunes`, and `commando-blacklist`
Changelog-None.
We do this with typesafe_cb and it's so useful I'm not going to remove it. But clang 18 complains:
```
ccan/ccan/tal/tal.c:246:6: runtime error: call to function destroy_conn_close_fd through pointer to incorrect function type 'void (*)(void *)'
/home/rusty/devel/cvs/lightning/ccan/ccan/io/poll.c:251: note: destroy_conn_close_fd defined here
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Somehow, this documentation got lost during the Great Rewrite, so
restore that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: JSON-RPC: `offer` removed `@` prefix support from `recurrence_base` (use `recurrence_start_any_period` set to `false`)
Changelog-Removed: Plugins: `estimatefees` returning feerates by name (e.g. "opening"); deprecated in v23.05.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Issue: Docker images for v24.05 were built on clean lightning directory and the published image should be running on v24.05 but it is running as v24.05-modded.
Root cause: Dockerfile builder was running different versions of grpcio-tools and protobuf. It resulted in auto generated update of contrib/pyln-grpc-proto/pyln/grpc/node_pb2.py and contrib/pyln-grpc-proto/pyln/grpc/primitive_pb2.py files.
Solution: Run `poetry install` before make in the dockerfile's builder stage to ensure that the grpcio-tools and protobuf versions are the same.
References:
https://github.com/ElementsProject/lightning/issues/7370#issuecomment-2152952820https://github.com/ElementsProject/lightning/pull/7376#issuecomment-2161102381
Changelog-None.
1. Plugin things should all be prefixed by `Plugins:` then the name of the plugin altered.
2. New config options should always be named in CHANGELOG.md!
3. Unify groups of changes into a single line, in this case, GRPC.
4. Command, plugin and option names are in backticks.
5. Offers changes are still under EXPERIMENTAL.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This PR will help in publishing CLN reproducible binaries for Ubuntu v24.04 (noble).
Please note that I adjusted Dockerfiles for focal and jammy also to keep the base image creation script same for all three images. The step update was required because `noble` only runs with ubuntu:noble setup.
Changelog-None.
We do this by literally creating the modern-style TLV, and pretending we found it in the onion.
This isolates us from messing with any callers, who don't even know.
Co-programmed-with: Alex Myers <alex@endothermic.dev>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/7347
Changelog-Fixed: Protocol: forward legacy non-TLV onions which we removed in 22.11 and spec itself in Feb 2022. Still sent by LND nodes who haven't seen our node_announcement.
This fails, because l2 can't decode the onion:
```
lightningd-2 2024-05-28T21:43:35.137Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#1: Rejecting their htlc 0 since onion is unprocessable WIRE_INVALID_ONION_HMAC ss=4202c24ea44d9029a2ea3abb24cded51da93164f8bb5cddce9cc824af9945435
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to fire up channeld to send this, but:
1. That's silly, we have all the information to make it ourselves.
2. We didn't do it if there was an error on the channel, which as of 24.02
there always is!
3. When it did work, running channeld *stops* onchaind, indefinitely slowing recovery.
Fixes: https://github.com/Blockstream/greenlight/issues/433
Changelog-Fixed: Protocol: we once again send CHANNEL_REESTABLISH responses on closing channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fedora image building by build-release.sh currently throws error ` git: command not found`.
Fixed it by adding git in the Dockerfile and loading the image in the script.
Changelog-None.
This seems to be happening to some people, so don't panic. Unfortunately we don't have
a good error callback here, so msg to stderr.
Fixes: https://github.com/ElementsProject/lightning/issues/7249
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only write these in two places: one where we get a message from lightningd about
our own channel, and one where we get a reply from lightningd about a txout check.
The former case we explicitly check that we don't already have it in gossmap, so
add checks to the latter case, and give verbose detail if it's found.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
LDK will pick the *upper* limit (see: https://github.com/lightningdevkit/rust-lightning/issues/3014)!
It should not do this, but since you can set a manual range for mutual close, it's probably better to disable this option for close, as it's even more dangerous than documented.
Changelog-Changed: config/JSON: --ignore-fee-limits / setchannel ignorefeelimits no longer applies to mutual close.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/7242
Thought it's intuitive, it's not documented to, and LDK's current behavior makes it quite dangerous to do so.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is violate what the docs of getchainfo is telling us that the
last_block_height is a u64.
```
2024-05-17T09:53:23.464Z **BROKEN** plugin-offers: Got error reply to getchaininfo: '{\"error\":{\"code\":-1,\"data\":null,\"message\":\"invalid type: string \\\"0\\\", expected u64\"},\"id\":\"init/offers:getchaininfo#1\",\"jsonrpc\":\"2.0\"}\n\n'
2024-05-17T09:53:23.496Z INFO plugin-offers: Killing plugin: exited before replying to init
2024-05-17T09:53:23.496Z **BROKEN** plugin-offers: Plugin marked as important, shutting down lightningd!
2024-05-17T09:53:23.496Z DEBUG lightningd: io_break: lightningd_exit
2024-05-17T09:53:23.496Z **BROKEN** plugin-topology: Reading JSON input: Connection reset by peer
2024-05-17T09:53:23.504Z INFO plugin-topology: Killing plugin: exited before replying to init
2024-05-17T09:53:23.504Z **BROKEN** plugin-topology: Plugin marked as important, shutting down lightningd!
2024-05-17T09:53:23.504Z DEBUG lightningd: io_break: lightningd_exit
2024-05-17T09:53:23.504Z DEBUG plugin-bookkeeper: Setting up database at sqlite3://accounts.sqlite3
2024-05-17T09:53:23.504Z DEBUG connectd: REPLY WIRE_CONNECTD_START_SHUTDOWN_REPLY with 0 fds
2024-05-17T09:53:23.504Z DEBUG lightningd: io_break: connectd_start_shutdown_reply
```
Fixing the following crash
```
Got error reply to getchaininfo: '{"error":{"code":-1,"data":null,"message":"invalid type: string \"0\", expected u64"},"id":"init/offers:getchaininfo#1","jsonrpc":"2.0"}
'lightningd: lightningd already running? Error locking PID file: Resource temporarily unavailable
```
Fixes: 847208f5d8
Changelog-None: offer: fix type to the getchaininfo rpc
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This is on me, and the last height is optional, and not required,
because sometimes you do not want wait the sync of the blockchain
but just get the information of the current status.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Issue: rpc documentation on the readme server is not being updated.
It is an extension of PR #7326 to fix runtime error from github actions.
Changelog-None.
Issue: rpc documentation on the readme server is not being updated.
Updating the path from `doc/**.md` to `doc/schemas/lightning-*.json` for triggering the action because all `doc/*.7.md` files are fully generated by the `tools/fromschema.py` now.
Added manual trigger event for readme's documentation update.
Changelog-None.
Add a test that checks `get_route` and `uncertainty_update` behaviour's
handling of missing channel capacities.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
`bech32_charset_rev` is only 128 bytes in size but the `c < 0 || c > 128` check allows for `c` to be equal to 128 which would be out-of-bounds. Fix this off-by-one bug by changing the check to `c >= 128`.
```
plugins/renepay/mods.c: In function 'payment_continue':
plugins/renepay/mods.c:63:7: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
63 | (u64)payment_virtual_program[payment->exec_state++];
| ^
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now that our rpc documenation is generated from schema, we need to build
the docs before trying to update the rdme contents. The goal is to fix
the following issue with the rdme-rpc-sync workflow:
Run python .github/scripts/sync-rpc-cmds.py
lightning-addgossip lightning-addgossip.7.md
Traceback (most recent call last):
File .github/scripts/sync-rpc-cmds.py, line 92, in <module>
main()
File .github/scripts/sync-rpc-cmds.py, line 82, in main
with open(doc/ + file) as f:
FileNotFoundError: [Errno 2] No such file or directory: 'doc/lightning-addgossip.7.md'
Currently make a plugin that do reportings of logs on
a services like graphana is not possible. So this commit
include the possibility to write a plugin that do the report
of this analisys.
Changelog-Added: core: notify plugins when a log line is emitted.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
When running `make check-python` we'll expclicitly include
`pyln-grpc-proto` in the `PYTHONPATH`.
This ensures we always run the tests using the version installed in
`./contrib/pyln-grpc-proto`
In rust enum are expected to be CamelCase.
However, we are generating enum's using CAPITAL_SNAKE_CASE.
This generates a warning and breaks CI.
See `cln_rpc::notifications::ConnectAddressType::LOCAL_SOCKET`
The schema in the docs for the `ConnectNotification` was faulty.
I've already fix this in https://github.com/ElementsProject/lightning/pull/7085
The new schema is
```
{
"connect" : {
"address" : {
"address" : "127.0.0.1",
"port" : 38012,
"type" : "ipv4"
},
"direction" : "in",
"id" : "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59"
}
}
```
The `address` in the `connect` field will be encoded in protobuf as
`ConnectAddress`. However, this collides with the `ConnectAddress` that
is defined in the `connect` rpc-method.
This commit
- Updates the schema in `doc/schemas/notification/connect.json`
- Changes `msggen` to include an override to `PeerConnect` for any
notification typename that starts with `Connect`
Both have an `address` field which is a composite type. This results in
naming collisions
schema's: Updated schema for connect-notification
schema for connect notification + overrides
Override ConnectAddress to `PeerConnectAddress` in protobuf
for notifications
I'm working to expose a stream of notifications over grpc.
This requries me to define structs that can be used to request
a stream of notifications.
These structs are all empty.
**Problem Description**
In previous commits I introduced some new fields to `msggen`.
One example is `CustomMsgResponse` in `cln-grpc/src/notification.rs`.
```rust
pub struct CustomMsgResponse {
#[serde(skip_serializing_if = "Option::is_none")]
pub peer_id: Option<PublicKey>,
#[serde(skip_serializing_if = "Option::is_none")]
pub payload: Option<String>,
}
```
The `peer_id` and `payload` are required parameters.
However, the generated code is still marking them as `Optional`.
This is a choice made by `msggen`. It does this because `payload` and
`peer_id` are recently added fields. By marking the field as optional
the language bindings would also work when used on an older version of
Core-Lightning.
In this scenario. Marking them as optional is overkill.
The `CustomMsgStruct` and `payload` field are created in the same
version of CoreLightning.
This commit solves this behavior.
In the next commit I'll change the behavior of `OptionalPatch`.
The changes require me to have access to the `parent` of a field.
Splitting it up in a separate commit makes it easier to review.
You can run `msggen` against this version and the previous `version`.
I've tested it. It returns exactly the same output.
In Core Lightning notifications are JSON-messages. This commit
introduces structs that can be used to parse the notification
messages.
Using `msggen` all required tructs are automatically generated
This means we can see the values in listconfigs, even if we haven't set
them yet.
In particular, we now see the following:
* autoclean-cycle.value_int=3600
* bitcoin-rpcclienttimeout.value_int=60
* bitcoin-retry-timeout.value_int=60
* funder-max-their-funding.value_str=4294967295sat
* funder-per-channel-min.value_str=10000sat
* funder-reserve-tank.value_str=0sat
* funder-fund-probability.value_int=100
Changelog-Changed: plugins: libplugin now shows plugin option default values (where they're non-trivial)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. sql's dev-sqlfilename should be registered as a dev option.
2. bcli's timeout is an integer, not a string.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The spec has moved a bit here: the `outgoing_cltv_value` in the final onion
is basically the blockheight now (plus the 1 block delta we give ourselves).
Also, we were doubling ours, since p->min_final_cltv_expiry was already set
to p->blindedpay->cltv_expiry_delta above.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without this, it was broken because our peer will no longer forward
via scids for private channels. We could use the scid alias, but the
node id is right at hand.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This demonstrates a number of issues reported by Carla: no surprise
since there was no test!
(We create a one-hop blinded path when we only have private channels).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently, anything which doesn't have a live channel is considered transient.
We free this first under stress, and also if they're still connecting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our fetchinvoice always creates a reply path which terminates at their peer,
so we need a dev overrride for that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can disable this with `fetchinvoice-noconnect`.
Changelog-EXPERIMENTAL: We will now reply to invoice_request messages even if reply path requires us to make an outgoing connection (LDK does this)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we don't find one searching from our random spot in the peer table,
we're supposed to wrap, not crash!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Previously, we only had a single python plugin `clnrest` and the instructions were embedded under other heading.
Adding a new heading for python plugins and their installation instructions will make it easier for users to locate them.
Changelog-None.
Changelog-Changed: hsmd: the hsmd now supports HSM_VERSION 6
This is actually optional, everything would be ok leaving native hsmd
support at HSM_VERSION 5 instead.
Changelog-None: channeld internal
This factoring makes it much clearer which callers only need the pubkey and
which only need the old_secret.
VLS has merged a workaround which prevents crashing when fetching a
per-commitment-point beyond the allowed range (the secret is just not
returned in this case.
https://gitlab.com/lightning-signer/validating-lightning-signer/-/merge_requests/643
In HSM_VERSION 6 the semantic is cleaned up; get_per_commitment_point
never returns a secret and safely be called on any commitment number.
The feerate security margin is a multiplicative factor applied to the
feerate of some transactions in order to guarantee that the
transaction remains publishable and has a sufficient chance of being
confirmed, that we can base some of our decisions on that.
The multiplicative factor is >=1 and was so far a constant 2. This
might have been sensible in the low-fee environment, where the fees
are expected to oscillate, and almost guaranteeing that we will
eventually have rising feerates but in high-fee environments that is
no longer the case, and the 100% margin that the multiplicator 2
brings is excessive. We therefore opt to start out with 100%, then
linearly interpolate up to a given maxfeerate (which does not have to
be a real feerate ever reached, it just indicates the feerate after
which we apply the constant 10% margin.
Fixes#6974Closes#6976
[Fixed up all the other changes required, including spendable calcualtion
comments and unit test and pytest tests --RR]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: offers: we now understand blinded paths which use a short-channel-id(+direction) as entry point.
We don't actually support it yet, but this threads through the type change,
puts it in "decode" etc.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And deprecate the --max-locktime-blocks which allows them to set it.
Hilariously, the spec misspells CLTV as CTLV at one point, so we work around it for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. onion-message
2. blinded-payments
3. route-blinding
4. channel-type
5. warnings.
Now they'll be checked correctly, and if the spec changes, we'll know
to reexamine this code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We expect:
UNUSUAL.*WARNING: we have 1 channels but can file descriptors limited to 65536
We get:
lightningd: WARNING: we have 1 channels but can file descriptors limited to 32768!
This is strange, since the first line is from Python's hard limit. Presumably something is restricting the fd limit of children
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They're cheap. The 2x channels heuristic is nice, but does assume
they restart every so often. If someone hits 64k connections I would
like to know anyway!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1024 is a common limit, and people are starting to hit that many channels, so we should increase it: twice the number of channels seems reasonable, though we only do this at restart time.
Changelog-Changed: lightningd: we now try to increase the number of file descriptors, if it's less than twice the number of channels at startup (and log if we cannot!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use a crude heuristic: if we were trying to contact them, it's a
"deliberate" connection, and should be preserved.
Changelog-Changed: connectd: prioritize peers with channels (and log!) if we run low on file descriptors.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I thought I was going to want to have a convenient way of counting
these, but it turns out unnecessary. Still, this is slightly more
efficient and simple, so I am including it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can happen if we're totally out of fds, but previously we gave
no log message indicating this!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The `chainlag` is defined as the positive difference between the
height of the last block processed by the node and the best height
known by the bitcoin backend. The chainlag is positive when we are
still catching up with the blockchain, and `0` otherwise.
The `chainlag` is used as an additional offset to the CLTV values when
sending payments, allowing payments to be sent even before the chain
sync completes.
Listpeerchannels would update the local channel information setting the
liquidity in the outgoing channel to known_min=known_max=capacity,
when in fact it should be known_min=known_max=spendable.
The route-builder checks the liquidity bounds of each route one at a
time. Every route that satisfy the contraints is recorded in the
uncertainty network and produces an HTLC burden on the channels it uses,
so that the following routes cannot count on the same liquidity twice.
Routes contain only routing information and the payment they're linked
to can be obtained through the payment_hash. We remove the dependency of
route building routines from the payment itself. In order to make
plain payment information available we define a payment_info structure.
- use switch case over all possible WIRE_* errors,
- remove the virtual machine for routefail, use a simple two step
solution: 1. update the gossip and 2. handle error cases
Using enum renepay_errorcode simplifies the low level API of chan_extra and flow.
We can extract information about the nature of a function call failure
from its return value.
Routefail consist mainly of an API `routefail_start` that handles the
failure of a forwarding request (encoded in a route). Internally there
is a routefail datastructure that goes through a series of execution
steps, eg. updating the gossmap, updating the uncertainty network, etc.
Routebuilder constitute the module that builds the routes we try in the
payment. The public API is simply `get_routes`, it replaces the similar
interface for pay_flows.
Add a new implementation of the payment state machine.
This is based in the `pay` plugin concept of payment modifiers,
but here we take it to the next level.
The payment goes through a virtual machine that includes calling
functions and evaluating conditions.
This is fixing a bug that @chrisguida reported,
when we notify a plugin we also notify a plugin
that it is in the middle of initialization.
So imagine the following use case:
- 1. Plugin A sends get manifest
- 2. cln makes a check and generates a warning
- 3. Plugin A is subscribed to the warning or * notification
- 4. Core Lightning gets upset because it receives a warning message but it was waiting for a init.
I think it is still a bug in how Core Lightning handles the init, but also I think we should communicate with the plugin only if it is initialized.
```
lightningd-1 2024-04-23T23:20:34.154Z DEBUG plugin-clnrest: Notification: {'warning': {'level': 'warn', 'time': '1713914433.818230531', 'timestamp': '2024-04-23T23:20:33.818Z', 'source': 'plugin-bookkeeper', 'log': \"topic 'utxo_deposit' is not a known notification topic\"}}
lightningd-1 2024-04-23T23:20:34.154Z DEBUG hsmd: new_client: 0
lightningd-1 2024-04-23T23:20:34.154Z **BROKEN** plugin-test_libplugin: Did not receive 'init' yet, but got 'warning' instead
lightningd-1 2024-04-23T23:20:34.155Z INFO plugin-test_libplugin: Killing plugin: exited before we sent init
lightningd-1 2024-04-23T23:20:34.155Z **BROKEN** plugin-test_libplugin: Plugin marked as important, shutting down lightningd!
lightningd-1 2024-04-23T23:20:34.155Z DEBUG lightningd: io_break: lightningd_exit
lightningd-1 2024-04-23T23:20:34.155Z DEBUG lightningd: io_loop: connectd_init
Time-out: can't find [re.compile('Server started with public key')] in logs
{'github_repository': 'ElementsProject/lightning', 'github_sha': '014c1eb383b0a65394cf166b3aa0174cf2077896', 'github_ref': 'refs/pull/7258/merge', 'github_ref_name': 'HEAD', 'github_run_id': 8808124001, 'github_head_ref': 'cguida/onchain_notif', 'github_run_number': 9395, 'github_base_ref': 'master', 'github_run_attempt': '1', 'testname': 'test_self_disable', 'start_time': 1713914432, 'end_time': 1713914612, 'outcome': 'fail'}
----------------------------- Captured stderr call -----------------------------
Did not receive 'init' yet, but got 'warning' insteadlightningd: lightningd/connect_control.c:767: connectd_init: Assertion `ret == ld->connectd' failed.
lightningd: FATAL SIGNAL 6 (version 014c1eb-modded)
0x555b1dc2d6f3 send_backtrace
common/daemon.c:33
0x555b1dc2d8de crashdump
common/daemon.c:75
0x7fda4584251f ???
???:0
0x7fda458969fc ???
???:0
0x7fda45842475 ???
???:0
0x7fda458287f2 ???
???:0
0x7fda4582871a ???
???:0
0x7fda45839e95 ???
???:0
0x555b1db98f8e connectd_init
lightningd/connect_control.c:767
0x555b1dbb0307 main
lightningd/lightningd.c:1249
0x7fda45829d8f ???
???:0
0x7fda45829e3f ???
???:0
0x555b1db6fd64 ???
???:0
0xffffffffffffffff ???
???:0
```
Reported-by: @chrisguida
Co-Developed-by: @chrisguida
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
These are very noisy at the debug level:
DEBUG lightningd: Calling rpc_command hook of plugin clboss
DEBUG lightningd: Plugin clboss returned from rpc_command hook call
As seen in https://github.com/ZmnSCPxj/clboss/issues/194
Temporary patch to avoid issue #6973
[ Add much more logging! --RR ]
Changelog-Fixed: lightningd: avoid crash on signing failure when trying to spend anchor outputs.
This didn't trigger the bug, but worth explicitly testing: we spend a
to-remote output from a previous unilateral close, to spend an anchor
on a current unilateral close.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`jq` is not available in the default repositories of the Ubuntu Focal image. To resolve this, adding the official jq package repository and then installing it.
Changelog-None.
We wire through --dev options into the hsmd, and test preapprove accept and deby
with both old and new protocols.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Apparently VLS actually does something when we preapprove: if caller is just
checking we want to tell it not to do that!
I put in a flag so we can test both old and new APIs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This should make VLS's life easier: they can ignore dev flags they
don't understand, but we will know their capabilites after init and so
know what they didn't understand (if required).
The only flag for now is a flag to force failure for "preapprove" calls.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we can check that the setconfig would actually parse. We do this
by handing NULL to the calback to indicate it's a test, which may not
work in general but works for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: `check` `setconfig` now checks that the new config setting would be valid.
We need to pass through setconfig in check mode, then we need to have libplugin
add (and use!) a `check_only` parameter to all option setting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `check` `setconfig` on plugin options can now check the config value would be accepted.
We don't thoroughly handle `check setconfig`: it would be good to
allow this to do further checking!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Plugins: Can now opt in to handle `check` command on their commands, for more thorough checking.
If this is set, instead of mangling the request in-place, we will hand
it through raw. Plugins will use this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to extend it to plugins, and we want it to be allowed to be async for more power,
so rather than not completing the cmd if we're checking, do it in command_check_done()
and call it.
This is cleaner than the special case we had before, and allows check to us all the
normal jsonrpc mechanisms, especially async requests (which we'll need if we want to
hand check requests to plugins!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 with -O3 gives:
```
In file included from plugins/renepay/test/../mcf.c:5,
from plugins/renepay/test/run-arc.c:13:
ccan/ccan/tal/str/str.h: In function ‘minflow’:
ccan/ccan/tal/str/str.h:43:9: error: ‘errmsg’ may be used uninitialized [-Werror=maybe-uninitialized]
43 | tal_fmt_(ctx, TAL_LABEL(char, "[]"), __VA_ARGS__)
| ^~~~~~~~
plugins/renepay/test/../mcf.c:1565:15: note: ‘errmsg’ was declared here
1565 | char *errmsg;
| ^~~~~~
cc1: all warnings being treated as errors
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without this, everything came out as level INFO.
Changelog-Fixed: pyln-client: Fix Plugin.notify_message() not to ignore `level` parameter.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This test reproduces a bug in the `cln-plugin`-crate.
Core Lightning supports a wildcard `*` that plugins can use to
subscribe to all notifications.
However, `cln-plugin` does not support this case.
It allows the developer to subscribe `*`.
But the plug-in crashes when the first notification is received
Creates an example package that subscribes to all notifications and logs
them. This is useful for testing the behavior of subscribing to "*".
I've also edited the Makefile to ensure that `make` builds the example
and that `make clean` removes the example
Uncommited channels are missing several fields which would normally be
populated by an active channel. This simply skips them for the purposes
of finding a route. The particular culprit was:
{
"peer_id": "038cd9f3679d5b39bb2105978467918d549572de472f07dd729e37c7a6377d41d5",
"peer_connected": true,
"state": "OPENINGD",
"owner": "lightning_openingd",
"opener": "local",
"to_us_msat": 8317559000,
"total_msat": 8317559000,
"features": [
"option_static_remotekey",
"option_anchors_zero_fee_htlc_tx"
]
}
Fixes#7197 - SEGV in direct_pay_listpeerchannels when field private missing
Changelog-Fixed: Fixed crash in pay plugin caused by parsing uncommitted dual open channels
- Updated config params and plugin
- Updated documentation
Changelog-Added: Added a new configuration for clnrest plugin to change the default Swagger UI path from `/` to custom url.
- Updated config params and plugin
- Updated documentation
Changelog-Added: Added a new configuration for clnrest plugin to change the default Swagger UI path from `/` to custom url.
Changelog-Changed: Plugins: bcli: Add a path that tries to fetch blocks
from a peer if we can not find them locally.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
`getblockfrompeer` was introduced in v23.0.0, we want to skip this path
if the version of bitcoind used is below that.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
In the case that we have peers left in the peers array and that we could
not find the block yet, we ask the next peer for the desired block.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We introduce the peers array that contains the known set of connected
peers for future reference in case that we couldn't find the block we
are looking for.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We move the `geblock` call into a separate function. This allows us to
call if from various places in the future.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This allows us to intercept getblock on a non 0 exit when the block was
not found. We fill this with something meaningull in future commits.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Not singular (though we used to have a listinvoice, removed in v0.6.1).
Reported-by: "Plant" via email
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than `allow_broken_log`, we have `broken_log` which is a regex
indicating what log lines are expected. This tightens our tests
significantly, as it will catch *unexpected* brokenness.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
an edge case like MultifundchannelChannel_idsChannel_type
was previously converted to MultifundchannelChannelIdschannelType
instead of the correct MultifundchannelChannelIdsChannelType
Apparently NixOS didn't have Python (sometimes!) so let's not assume.
By reusing the JSON "parsing" code from cowsay, we can self-disable
to handle this case.
Reported-by: Shahana Farooqui <shahana.farooqui@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `clnrest` now correctly self-disables if Python not present at all.
2024-04-12 10:32:32 +02:00
1036 changed files with 152792 additions and 72142 deletions
> 25.09 FREEZE July 28TH: Non-bugfix PRs not ready by this date will wait for 25.12.
>
> RC1 is scheduled on _August 11th_
>
> The final release is scheduled for September 1st.
## Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:
- [ ] The changelog has been updated in the relevant commit(s) according to the [guidelines](https://docs.corelightning.org/docs/coding-style-guidelines#changelog-entries-in-commit-messages).
- [ ] Tests have been added or modified to reflect the changes.
- [ ] Documentation has been reviewed and updated as needed.
- [ ] Related issues have been listed and linked, including any that this PR closes.
- Plugins: `chanbackup` turns our peers into watchtowers and enables SCB to create penalty txns. ([#7772])
- JSON-RPC: `fetchinvoice` BIP 353 name support (`bip353`). ([#7887])
- JSON-RPC: `blacklistrune` now has an option to un-blacklist (`relist`). ([#8037])
- JSON-RPC: `setconfig` now has a `transient` flag which means it won't rewrite your config file. ([#8095])
- Plugins: New nofitications `plugin_stopped` and `plugin_started`. ([#7508])
- xpay: `xpay-slow-mode` makes xpay wait for all parts of a payment to complete before returning success or failure. ([#8094])
- Plugins: `xpay` now supports a `maxdelay` parameter for better `xpay-handle-pay` compatibility. ([#7969])
- JSON-RPC: `listpeerchannels` new output fields `their_max_total_htlc_out_msat` and `our_max_total_htlc_out_msat` as the value of `max_htlc_value_in_flight` (as of BOLT02) set by the local and remote nodes on channel creation. ([#8084])
- Config: Added support for Bitcoin `testnet4`. ([#7894])
### Changed
- clnrest: clnrest is now a rust plugin. ([#7509])
- JSON-RPC: `blacklistrune` no longer supports of runes over id 100,000,000. ([#8037])
- Splicing: User is prevented from trying to splice unsigned PSBTs, protecting against potential issues. ([#8052])
- Splicing: Stricter tests for interop with Eclair. ([#8031])
- `xpay` now populates more fields, so `listsendpays` and `listpays` show `destination` and `amount_msat` fields for xpay payments. ([#7941])
- `xpay` now gives the same JSON success return as documented by `pay` when `xpay-handle-pay` is set. ([#7938])
- JSON-RPC: With `xpay-handle-pay` set, xpay will now be used even if `pay` uses maxfeeprecent or exemptfee parameters (e.g. Zeus.) ([#7942])
- Release: Docker images are now based on Debian Bookworm. ([#7921])
- lightning-cli: Plugin descriptions in `lightning-cli help` is now more readable with interpretation of \n characters. ([#8022])
- Release: Fixed version number and version check in source release zip packages. ([#8010])
- Logging: We no longer suppress DEBUG messages from subdaemons. ([#7935])
- lightning-cli: `help` messages using new-lines is now printed properly, enhancing readability and consistency. ([#8022])
- pyln-testing: pyln-testing is now compatible with older versions of Core Lightning. ([#7173])
### Deprecated
Note: You should always set `allow-deprecated-apis=false` to test for changes.
- JSON-RPC: `listpeerchannels` value `max_total_htlc_in_msat`: use `our_max_htlc_value_in_flight_msat` instead to follow spec naming convention. ([#8084])
- Config: `rest-port`, `rest-protocol`, `rest-host` and `rest-certs` disabled by default (use `clnrest-*`, or `i-promise-to-fix-broken-api-user=rest-port.clnrest-prefix` etc and PLEASE REPORT if you need this!) ([#8089])
- Config: `max-locktime-blocks` disabled by default (use `i-promise-to-fix-broken-api-user=max-locktime-blocks` and PLEASE REPORT if you need this!) ([#8089])
### Removed
### Fixed
- lightningd: Startup time vastly improved for large nodes with pending closes and many bitcoin addresses. ([#8019])
- renepay: No longer crashes on trying a payment after xpay. ([#7979])
- connectd: `dev-no-reconnect-private` is respected on restart. ([#8104])
- cln-grpc, clnrest: Errors that cause them to stop will now log correctly. ([#8085])
- Plugins: xpay doesn't simply give up if our total amount is less than `htlc_minimum_msat` on some channel. ([#8057])
- Plugins: xpay suppresses multi-part payment if an invoice doesn't allow it (please, fix your nodes!) ([#8059])
- JSON-RPC: xpay now works through unannounced channels. ([#7937])
- onchaind: Don't die if we fail an unrelated channel with the same peer. ([#8056])
- gossipd: More sanity checks that we are correctly updating the `gossip_store` file. ([#8053])
- gossipd: Corruption in the `gossip_store` no longer causes ever-longer startup times and no gossip updates. ([#8053])
- gossmap: Don't crash on ZFS while reading `gossip_store`. ([#8053])
## [24.11.1] - 2024-12-16: "The lightning-dev Mailing List II"
Minor fixes, particularly for xpay users.
### Changed
- JSON-RPC: `xpay` now gives the same JSON success return as documented by `pay` when `xpay-handle-pay` is set. ([#7938], [#7952])
- JSON-RPC: With `xpay-handle-pay` set, xpay will now be used even if `pay` uses maxfeeprecent or exemptfee parameters (e.g. Zeus) ([#7942])
- JSON-RPC: `xpay` now populates more fields, so `listsendpays` and `listpays` show `destination` and `amount_msat` fields for xpay payments. ([#7941])
- Logging: we no longer suppress DEBUG messages from subdaemons. ([#7935])
### Fixed
- JSON-RPC: xpay now works through unannounced channels. ([#7937])
## [24.11] - 2024-12-09: "The lightning-dev Mailing List"
This release named by Dusty Daemon.
### Added
- JSON-RPC: `listaddresses` to list issued addresses from the node. ([#7800])
- Config: `autoconnect-seeker-peers`, allowing seeker to reach out to new nodes for additional gossip (default: 10). ([#7798])
- Protocol: `option_quiesce` enabled by default. ([#7586])
- JSON-RPC: `fetchinvoice` allows setting invreq_metadata via `payer_metadata` parameter. ([#7786])
- hsmtool: generatehsm can run non-interactive, taking options on the cmdline. ([#7102])
- Plugins: `pay` now has tracing support for various payment steps. ([#7803])
- Plugins: new notification `onionmessage_forward_fail`.
- JSON-RPC: `exposesecret` command for encouraging hsm_secret backups. ([#7647])
- JSON-RPC: `listpays` has `index`, `start` and `limit` parameters for listing control. ([#7385])
- Plugins: bookkeeper has a new RPC `bkpr-editdescriptionbypaymentid` which will update the description for any event with matching payment_id ([#7604])
- Config: `grpc-host` option for grpc plugin ([#7479])
- JSON-RPC: A new magic `dev-splice` command is added that can take a ‘splice script’ or json payload and perform any complex splice across multiple channels merging the result into a single transaction. Some features are disabled and will be added in time. ([#6980])
- JSON-RPC: low-level RPC command `addpsbtinput` to fund PSBTs directly and help with complex splices & dual-opens. ([#6980])
- JSON-RPC: `stfu_channels` and `abort_channels` are added for bulk multi-channel splice commands. These allow the user to pause (and resume) multiple channels in place. ([#6980])
- JSON-RPC: `injectpaymentonion` for initiating an HTLC like a peer would do. ([#7749])
- Documentation: Example documentation on generating custom gRPC ([#7731])
- Installation: Nix users can now install CLN from the new flake. ([#7656])
- JSON-RPC: `decode` now used modern BOLT 4 language for blinded paths, `first_path_key`. ([#7586])
- Plugins: `onion_message_recv` and `onion_message_recv_secret` hooks now used modern BOLT 4 language for blinded paths, `first_path_key`. ([#7586])
- JSON-RPC: keysend `maxfee` parameter for consistency with pay. ([#7227]) ([#7653])
- `hsmtool`: `getnodeid` command derives the node id from the hsm_secret, to verify it's the correct secret. ([#7644])
### Changed
- Plugins: grpc now starts on port 9736 by default (localhost, see `grpc-host`) ([#7479])
- Config: bolt12 now enabled by default (finally!) ([#7833])
- Protocol: we now connect to additional nodes for improved gossip (see `autoconnect-seeker-peers`) ([#7798])
- Protocol: Own-channel gossip is broadcast to more peers (up to 50, not 5). ([#7873])
- Build: Added architecture identifier to Ubuntu release ([#7797])
- Logging: connectd now logs unknown messages as "UNKNOWN" not "INVALID" to avoid freaking people out. ([#7892])
- Protocol: we now create a low-priority (2016 down to 12 blocks fee target) anchor for low-fee unilateral closes even if there's no urgency. ([#7832])
- Protocol: splicing moved from test numbers to spec numbers. ([#7719])
- Protocol: Support added for peers that wish to rotate their funding pubkey during a splice. ([#7719])
- Startup: reconnecting to peers at startup should be significantly faster (dependent on machine speed). ([#7630])
- Protocol: we remember the last successful address we connected to for important peers. ([#7630])
- Protocol: Gossipd requests a full sync from a random peer every hour. ([#7768])
- JSON-RPC: `injectonionmessage` API simplified and documented.
- JSON-RPC: Improved error messaging for splice commands. ([#7719])
- JSON-RPC: built-in plugins can now be stopped using "plugin stop". ([#7799])
- Wallet: Taproot addresses are used for unilateral-close change addresses. ([#7800])
- JSON-RPC: `close` now outputs txs & txids of all closing transactions (splice candidates can cause there to be multiple). ([#7466])
- JSON-RPC: `splice_update` can in some cases now return the remotely partiall signed psbt to the user, if so `signtures_secured` will be true. ([#6980])
- JSON-RPC: `splice_signed` parameters are switched in order to make `channel_id` an optional parameter, enabling multi-splice-signatures. ([#6980])
- `pay`: Discarding an overly long or expensive route does not blocklist channels anymore. ([#7494])
- Plugins: `cln-grpc` Upgrade tonic version and ([#7598])
### Deprecated
Note: You should always set `allow-deprecated-apis=false` to test for changes.
- Config: `experimental-offers` (it's now the default). ([#7833])
- Config: `experimental-quiesce`: it's now the default. ([#7586])
- JSON-RPC: `close``tx` and `txid` field (use `txs` and `txids`) ([#7466])
- JSON-RPC: `decodepay`: use `decode`. ([#7551])
- JSON-RPC: `decode``blinding` in blinded path: use `first_path_key`. ([#7586])
- JSON-RPC: `onion_message_recv` and `onion_message_recv_secret` hooks `blinding` in blinded path: use `first_path_key`. ([#7586])
### Fixed
- JSON-RPC: `decode` refused to decode expired bolt12 invoices. ([#7890])
- JSON-RPC: `listforwards``received-time` is always present (it could be missing for ancient nodes, now it will be 0) ([#7744])
- Plugins: `cln-grpc` now understands channel type `anchors/even` ([#7628])
- Plugins: `cln-grpc` no longer logs a warning if a notification does not have a handler ([#7867])
- JSON-RPC: `close` now correctly reports the txid of the remote onchain unilateral tx if it races with a peer close. ([#7593])
- Protocol: we no longer try to spend anchors if a commitment tx is already mined (reported by @niftynei). ([#7593])
- pyln-client: plugins now compatible with CLN <= 24.05 (broken in 24.08) ([#7852])
- Protocol: Receiving bolt12 payments where we have no public channels would fail a few blocks after startup. ([#7839])
- Protocol: entry to blinded paths returns more useful errors (e.g if it's the final node, you get a real error, otherwise you get invalid_onion_blinding). ([#7839])
- build: fix overzealous warning from clang 19. ([#7829])
- `gossipd` will no longer miss some channel closes on restart. ([#7343])
- `onchaind` can miss conclusion of final txs in some cases, will now replay independently. ([#7343])
- Plugins: `autoclean` is now gentler on the node when doing giant cleans. ([#7805])
- Plugins: libplugin plugins can now intercept `rpc_command` hook without deadlocking. ([#7750])
- protocol: onion messages are now supported by default. ([#7455])
- protocol: onion messages can now be forwarded by short_channel_id. ([#7455])
- pay: The pay plugin now checks whether we have enough spendable capacity before computing a route, returning a clear error message if we don't ([#7418])
- pay: Payments now emit `channel_hint_updated` notification to share inferred balances and observations across multiple payments. ([#7487])
- pay: The pay plugin now returns better error codes ([#7418])
- reckless-rpc plugin: issue commands to reckless over rpc. ([#7506])
- reckless: accepts json array input for command targets ([#7484])
- reckless provides json output with option flag -j/--json ([#7484])
- reckless: added the ability to install rust plugins. ([#7484])
- JSON-RPC: `listpeers``features` array string uses "option_anchors" for feature 22/23, following renaming in BOLT 9. ([#7388])
- plugins: `bookkeeper` now listens for two custom events: `utxo_deposit` and `utxo_spend`. This allows for 3rd party plugins to send onchain coin events to the `bookkeeper`. See the new plugins/bkpr/README.md for details on how these work! ([#7258])
- plugins: Add payment_id parameter to bkpr-listaccountevents to filter events. ([#7536])
- cln-plugin: add multi options for String and i64 ([#7544])
- pyln-client: Added a notification mechanism for config changes ([#7289])
- pyln-client: implement setconfig hook for plugins so you can see changes in `dynamic` options. ([#7289])
- doc: all examples in the documentation are now generated from running the code, so they are current. ([#7457])
### Changed
- protocol: We now send current peers our changed gossip (even if they set timestamp_filter otherwise), not just on reconnect. ([#7554])
- protocol: we now always ask the first peer for all its gossip. ([#7512])
- connectd: I/O optimizations to significantly speed up larger nodes. ([#7365])
- plugins: the `fetchinvoice` plugin has been combined into the `offers` plugin. ([#7456])
- close: We no longer attempt to publish a unilateral close that'd fail anyway when we witness a close onchain. ([#7447])
- pay: Improved logging should facilitate debugging considerably. ([#7418])
- reckless: option flags are now position independent. ([#7484])
- plugins: now allows date and time sqlite functions. ([#7467])
- splice: added outnum of new funding output to splice_signed RPC command ([#7465])
- lightningd: we wait for bitcoind if it has somehow gone backwards (as long as header height is still ok). ([#7342])
- wallet: The channel status is printed when loading it from the DB ([#7354])
- JSON-RPC: `listclosedchannels`, `listpeerchannels`, `openchannel_update`, `openchannel_init`, `fundchannel`, `fundchannel_start` and `multifundchannel`: `channel_type` array `names` now contains "anchors" instead of "anchors_zero_fee_htlc_tx". ([#7388])
- JSON-RPC: Do not return the contents of invalid parameters in error messages, refer to logs (use 'check' to get full error messages) ([#7420])
- lightningd: `--list-features-only` now lists "option_anchors" instead of "option_anchors_zero_fee_htlc_tx". ([#7388])
- updated Bitcoin to v27.1 and Elements to v23.2.1 ([#7436])
- update libwally to 1.3.0 ([#7480])
### Deprecated
Note: You should always set `allow-deprecated-apis=false` to test for changes.
- offers: fixed: onionmessage replies now work even if we need to route to the start of the blinded reply path. ([#7456])
- offers: 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. ([#7456])
- renepay: prune the network by disabling channels we don't like, eg. very low max_htlc. ([#7403])
- renepay: fixed: un-reserve routes that have completed or failed ([#7357])
- renepay: Add a dev parameter representing a constant probability of availability for all channels in the network. ([#7540])
- renepay: add cli option "exclude" to manually disable channels and nodes. ([#7403])
## [24.05] - 2024-06-04: "The Infinitely Divisible Satoshi"
This release named by @daywalker90.
### Added
- JSON-RPC: `createrune` new restriction `pinv` to examine bolt11/bolt12 invoice fields (e.g. amount of invoice). ([#7165])
- Plugins: `cln-plugin` adds dynamic configs and a callback for changes ([#7293])
- JSON-RPC: `pay` has a new parameter `partial_msat` to only pay part of an invoice (someone else presumably will pay the rest at the same time!) ([#7145])
- JSON-RPC: `check``keysend` now checks with HSM that it will approve it. ([#7111])
- Plugins: Can now opt in to handle `check` command on their commands, for more thorough checking. ([#7111])
- JSON-RPC: `check``setconfig` now checks that the new config setting would be valid. ([#7111])
- JSON-RPC: `check``setconfig` on plugin options can now check the config value would be accepted. ([#7111])
- Plugins: `cln-grpc` adds notifications over the grpc interface. Configurable with config parameter `grpc-msg-buffer-size`. ([#7084])
- Plugins: Added `wss-proxy`, a WSS Proxy server with `wss-bind-addr` and `wss-certs` configurations. ([#7225])
- Runes: named parameters (e.g. `pnameamountmsat`) no longer need to remove underscores (i.e. `pnameamount_msat` now works as expected). ([#7124])
- lightningd: we now try to increase the number of file descriptors, if it's less than twice the number of channels at startup (and log if we cannot!). ([#7237])
- connectd: prioritize peers with channels (and log!) if we run low on file descriptors. ([#7237])
- lightningd: Processing blocks should now be faster ([#7101])
- Plugins: `cln-grpc` adds routes to `decode` and `decodepay` results ([#7317])
- hsmd: the hsmd now supports `HSM_VERSION 6` ([#7178])
- hsmd: `HSM_VERSION 6`: `get_per_commitment_point` does not imply index - 2 is revoked, makes it safe to call on any index. ([#7178])
- Documentation: Merged `example_json_request` and `example_json_response` in a single `json_examples` array to maintain the request and its corresponding response together. ([#7181])
- JSON-RPC: `stop` and `recover` now return a JSON object (not a raw string!) like every other command does. ([#6995])
- Plugins: `pay` payments are more robust for nodes that are currently syncing. ([#7190])
### Deprecated
Note: You should always set `allow-deprecated-apis=false` to test for changes.
### Removed
- Plugins: no longer allow missing `id` field in commando requests (deprecated v23.02, EOL v24.02) ([#7094])
- JSON-RPC: `createrune` restrictions as raw strings (use arrays) (deprecated v23.05, EOL 24.02). ([#7094])
- Plugins: `invoice_payment` and `htlc_accepted` hook `failure_code` response (deprecated v22.08 and v0.8, EOL v23.02) ([#7094])
### Fixed
- Plugins: `pay` now correctly estimates channel capacity ([#7188])
- lightningd: avoid crash on signing failure when trying to spend anchor outputs. ([#7291])
- Plugins: `renepay` fixed a race condition leading to a crash. ([#7125])
- JSON-RPC: `fundchannel_start` now disallows a non-zero `mindepth` parameter if you ask for a zeroconf `channel_type`. ([#7175])
- pyln-client: Fix Plugin.notify_message() not to ignore `level` parameter. ([#7287])
- JSON-RPC: `multifundchannel` with `all` as an amount works as expected. ([#7037])
- Plugins: `pay` crash fixed, caused by parsing uncommitted dual open channels ([#7235])
- Plugins: `clnrest` now correctly self-disables if Python not present at all. ([#7211])
- lightningd: slow memory leak when using plugin hooks fixed (introduced in v23.11) ([#7192])
- Plugins: `recovery` is less noisy. ([#7116])
- Plugins: `renepay` handles htlc_max correctly for local channels. ([#7159])
- Plugins: The recover plugin now avoids trying to recover closed channels. ([#7216])
- Gossmap: Avoid adding redundant channel announcements to the gossip_store. ([#7330])
- Protocol: forward legacy non-TLV onions which we removed in 22.11 and spec itself in Feb 2022. Still sent by LND nodes who haven't seen our node_announcement. ([#7352])
- Protocol: we once again send CHANNEL_REESTABLISH responses on closing channels. ([#7353])
- gossipd: Fixed a crash when processing pending node announcements. ([#7368])
### EXPERIMENTAL
- offers: We will now reply to invoice_request messages even if reply path requires us to make an outgoing connection (LDK does this) ([#7304])
- offers: we now understand blinded paths which use a short-channel-id(+direction) as entry point. ([#7212])
- offers: Fix blinded paths in invoices - use node_id and set final node's CLTV delta. ([#7311])
This implementation has been in production use on the Bitcoin mainnet since early 2018, with the launch of the [Blockstream Store][blockstream-store-blog].
We recommend getting started by experimenting on `testnet` (or `regtest`), but the implementation is considered stable and can be safely used on mainnet.
We recommend getting started by experimenting on `testnet` (`testnet4` or `regtest`), but the implementation is considered stable and can be safely used on mainnet.
## Reach Out to Us
Any help testing the implementation, reporting bugs, or helping with outstanding issues is very welcome.
Don't hesitate to reach out to us on IRC at [#lightning-dev @ libera.chat][irc1], [#c-lightning @ libera.chat][irc2], or on the implementation-specific mailing list [c-lightning@lists.ozlabs.org][ml1], or on the Lightning Network-wide mailing list [lightning-dev@lists.linuxfoundation.org][ml2], or on Discord [core-lightning][discord], or on Telegram [Core Lightning][telegram].
Don't hesitate to reach out to us on [Build-on-L2][bol2], or on the implementation-specific [mailing list][ml1], or on [CLN Discord][discord], or on [CLN Telegram][telegram], or on IRC at [dev][irc1]/[gen][irc2] channel.
## Getting Started
Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 22.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`).
Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 25.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`).
Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](#pruning) for more details.
### Installation
There are 4 supported installation options:
There are 3 supported installation options:
- Installation of a pre-compiled binary from the [release page][releases] on GitHub.
- Using one of the [provided docker images][dockerhub] on the Docker Hub.
@ -101,13 +106,10 @@ the lightning network.
There are also numerous plugins available for Core Lightning which add
capabilities: in particular there's a collection at: https://github.com/lightningd/plugins
Including [helpme][helpme-github] which guides you through setting up
your first channels and customizing your node.
For a less reckless experience, you can encrypt the HD wallet seed:
see [HD wallet encryption](#hd-wallet-encryption).
You can also chat to other users at [#c-lightning @ libera.chat][irc2];
You can also chat to other users at Discord [core-lightning][discord];
we are always happy to help you get started!
@ -123,11 +125,11 @@ lightning-cli newaddr
`lightningd` will register the funds once the transaction is confirmed.
You may need to generate a p2sh-segwit address if the faucet does not support bech32:
Alternatively you can generate a taproot address should your source of funds support it:
```bash
# Return a p2sh-segwit address
lightning-cli newaddr p2sh-segwit
# Return a taproot address
lightning-cli newaddr p2tr
```
Confirm `lightningd` got funds by:
@ -207,19 +209,24 @@ Developers wishing to contribute should start with the developer guide [here](do
@ -6,19 +6,30 @@ We have a 3 month release cycle, and the last two versions are supported.
## Reporting a Vulnerability
To report security issues send an email to rusty@rustcorp.com.au, or
security@blockstream.com (not for support).
To report security vulnerabilities, please send an email to one of the following addresses:
- `rusty@rustcorp.com.au`
- `security@blockstream.com`
Note: These email addresses are exclusively for vulnerability reporting.
For all other inquiries/communication, please refer to the [Reach Out to Us](https://github.com/ElementsProject/lightning?tab=readme-ov-file#reach-out-to-us) section in our README.
## Signatures For Releases
The following keys may be used to communicate sensitive information to
developers, and to validate signatures on releases:
You can import a key by running the following command with that individual’s fingerprint: `gpg --keyserver hkps://keys.openpgp.org --recv-keys "<fingerprint>"` Ensure that you put quotes around fingerprints containing spaces.
You can import a key by running the following command with that individual’s fingerprint:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.