This caused a segmentation fault when calling `getcodexsecret` without
id.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Changelog-Fixed: Hsmtool: Fix segmentation fault when calling `getcodexsecret` without id.
This fixes a crash on startup of core-lightning where gevent could not
be imported. This happens before sys is imported and throws us into the
except clause which calls sys.
By importing it explicitly in the except clause we are not dependend of
the order of imports in the try bracket.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Changelog-Fixes: Plugin: clnrest crashed on startup when gevent was
missing.
Reported-by: Shahana Farooqui
Changelog-Fixed: JSON-RPC: Plugin notification `msat` fields in `invoice_payment` and `invoice_created` hooks now a number, not a string with "msat" suffix.
Changelog-Fixed: JSON-RPC: Plugin hook `payment` `msat` field is now a number, not a string with "msat" suffix.
Adds tests for when the connection fails during
1) splice tx_signature
2) splice commitment_signed
Fleshed out the reestablish flow for these two cases and implemented the fixes to make these reestablish flows work.
Part of this work required changing commit process for splices: Now we send a single commit_part for the splice where previously we sent all commits, and accordingly, we no longer revoke in response.
Changelog-Fixed: Implemented splicing restart logic for tx_signature and commitment_signed. Splice commitments are reworked in a manner incompatible with the last version.
Since these worked in v23.08, we can't just rename them. So if they are
used and unclaimed, we should rename them internally (if they're claimed,
it's probably clightning-rest, and we should *NOT* touch them!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: Plugins: `clnrest` parameters `rest-port`, `rest-protocol`, `rest-host` and `rest-certs`: prefix `cln` to them
Add a version bump for clnrest and the main poetry.lock to the makefile
and update the release checklist to include the new target.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This will allow users to use clnrest with c-lightning-REST without conflicts.
It was required for applications to have enough time for migrating from c-lightning-REST to clnrest.
Changelog-Changed:
config option `rest-certs` changed to `clnrest-certs`
config option `rest-protocol` changed to `clnrest-protocol`
config option `rest-host` changed to `clnrest-host`
config option `rest-port` changed to `clnrest-port`
config option `rest-cors-origins` changed to `clnrest-cors-origins`
config option `rest-csp` changed to `clnrest-csp`
We have a global JSON encoder hack, which means that any field ending in msat gets special treatment (so we can safely talk to lightningd, even if a field expects satoshi amounts, we are explicit). However, requests uses the JSON parser and DOES NOT want this conversion when sending it out as an HTTP response!
The simplest local fix we could find was Shahana's suggestion to iterate and covert away from Millisatoshi(): the reverse of what our JSON encoder does.
Fixes: https://github.com/ElementsProject/lightning/issues/6848
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It already throws an exception or error, or decodes the JSON response:
we can simply pass it through.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- cln-grpc certificate reuse
- new certificate generation
- `GET` and `POST` requests
- websocket server
- config options and HTTP headers
Link to #6436.
We need to upgrade the rust version of the ubuntu docker images as
time-core v0.1.2 needs a version newer than 1.67.0
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The fedora image installs a setuptools version that can not be upgraded
via pip. A fix is to remove the files manually and reinstall it via pip.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Code using `CI_SERVER` was added recently to track something. It
attempts to short-cut if `CI_SERVER` is not set, but on gitlab it
is set to `yes`. https://docs.gitlab.com/ee/ci/variables/
Instead use `CI_SERVER_URL`, maybe that is what is intended?
If we disconnect, we lose the open_attempt record. Which is fine, but we
should prevent the user from starting another RBF if the last one isn't
done yet!
Originally the accepter waited for the peer to send us their commitment
sigs before we send ours; this changes things so that the accepter
sends their commitment sigs ASAP.
This test fails: when cln is not the channel initiator, it waits for the other node to send commit_sig before sending its own commit_sig. There is no reason to do that, both nodes should send commit_sig immediately after exchanging tx_complete? Otherwise it's a missed opportunity to finalize the channel creation on reconnection, because in that case cln hasn't saved the channel and fails it on reconnection.
Reported-By: @t-bast
When we got our peer's sigs, if we were the remote, we would re-notify
the plugin, which in turn would re-send the tx-sigs to use.
In the case of CLN, we'd then
- break, because we'd re-forward the sigs to the `openchannel` plugin,
which was then in the wrong state (MULTIFUNDCHANNEL_SIGNED)
spenderp: plugins/spender/openchannel.c:598: json_peer_sigs: Assertion `dest->state == MULTIFUNDCHANNEL_SECURED' failed.
spenderp: FATAL SIGNAL 6 (version 5880d59-modded)
In the case of eclair, they'd just see our 2nd TX_SIGS message and
@t-bast would complain:
> This test works, with one minor issue: on reconnection, cln sends its tx_signatures twice (duplicate?).
This commit does two things:
- has the openchannel / spender plugin log a broken instead of
crashing when the state is not what we're expecting
- stops us from calling the `funder` plugin if this is a
replay/second receipt of commit-sigs.
Here we conform to the specification, which requires that we handle
next-funding-id in a specific way.
Note that we were already sending it, but now we actually correctly
handle its presence.
Changelog-Changed: Spec: dual-funding now follows the next-funding-id rules.
In the case where you're echoing back a tx-abort, just let it through.
Not doing this causes problems in the case where your node has forgotten
about an in-progress open.
This fixes the following problem:
- you send a tx-abort (even tho you have marked tx-sigs as received)
- peer echos it back (we echo back tx-aborts always)
- you throw an error because you're already in a tx-abort unallowed
state
In this commit, we allow for echos to come thru no matter our current state and
this fixes things/makes them work as expected.
If you get the right series of disconnects, it's possible for your peer
to send you a tx-sigs even though the current state of the channel open
is that you've seen the funding open on chain (your channel_ready[LOCAL]
= true)
In this case, if we haven't marked that we've seen the tx sigs yet,
we go ahead and mark them as seen and just ignore this tx-sigs msg.
If we get a commitment-signed message from a peer, outside of a normal
flow, process it!
We're about to send these during reconnect, so we need to be able to
handle them!
We're going to need to reuse this for reconnect; make the method
standalone in that it can figure out what to send to HSMD independent of
where it's located in the setup call flow.
We need to keep track of if we've gotten the last negotiation's
commitment sigs, for reconnect logic (helps us know what messages to
send in the reconnect case)
If an openchannel_update fails (due to disconnect etc) it's possible
that it could 'resolve' itself later due to the auto reconnect logic
If you call an openchannel_update and we've already got an inflight
record saved, go ahead and return the info from the inflight (including
info about whether or not the commitments are secured.)
This makes openchannel_update a bit more 'robust'/idempotent, in that
you can make repeat calls to it after the channel is inflight and get
the info you need back to continue (call openchannel_signed)
Changelog-Changed: RPC: `openchannel_update` will now echo back a result if there's a matching inflight record for this open.
Since we can now get a COMMITMENT_SIGNED message due to a reconnect,
in addition to the 'inline' open process, it's possible that we might
have cleaned up / lost the open_attempt object.
This is fine, we have (almost) all the data we need to round this off
successfully/send out a notice.
Note that the only exception is the `close_to` data is lost/forgotten in
the case of a restart; this is largely fine.
