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>
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>
This has the benefit of being shorter, as well as more reliable (you
will get a link error if we can't print it, not a runtime one!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Standardizes the is_xxx script function all take a script length, and changes
their first-level callers to pass it. This has several knock on benefits:
- We remove the repeated tal_count/tal_bytelen calls on the script, in
particular the redundant calls that result when we must check for multiple
types of script - which is almost all cases.
- We remove the dependency on the memory being tal-allocated (It is, in
all cases, but theres no reason we need to require that).
- We remove all cases where we create a copy of the script just to id it.
- We remove all allocations for non-interesting scripts while iterating block
txs in process_getfilteredblock_step1().
- We remove all allocations *including for potentially interesting scripts* in
topo_add_utxos().
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>
For example, lnprototest got the error 'You gave bad parameters: Did not support channel_type ' which doesn't make it clear that it's rejecting the empty channel type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're about to make static_remotekey compulsory, but we still want to
do tests for pre-existing channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And add request schemas for openchannel_init and fundchannel_start.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `fundchannel_start` and `openchannel_init` now take an optional `channel_type` parameter.
Rename the offending functions from wally_foo to cln_wally_foo.
For the sake of a minimal diff, only calls which conflict with wally
v1.0.0 have been changed. However it is bad form to use the wally_
function namespace; the remaining such calls should also be renamed.
Changelog-None
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>
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
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)
Here, we split up what was "commit_received" into two phases:
- commit-ready, where we're about to send our commitment tx to
peer
- commit-received, when we've gotten the commitment tx from our
peer
This lets us do the right thing (as far as the spec is concerned) with
returning the correct 'next_funding_txid' on reconnect (later commits).
Tihis commit is implementing a 2-phase commit between
the signer the node and the peer.
The main reason for this is that everybody must agree on the lock,
otherwise one of them will want N signatures (on the splice candidates),
and another will produce only 1 signature.
check_outpoint is the "prepare" for the signer, and lock_outpoint is the
"commit". if check_outpoint returns true, lock_outpoint must not fail.
Link: https://github.com/ElementsProject/lightning/issues/6722
Suggested-by: @devrandom
Co-Developed-by: Ken Sedgwick <ken@bonsai.com>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Originally VLS used hsmd_ready_channel as an early call during channel
setup, but later the BOLT-2 spec changed the name of funding_locked to channel_ready.
This is very confusing because the hsmd_ready_channel is not directly
related to the new channel_ready.
This commit is renaming the hsmd_ready_channel to hsmd_setup_channel.
Link: https://github.com/ElementsProject/lightning/issues/6717
Suggested-by: Ken Sedgwick
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We generalize the current df-only "aborted" flag (and invert it) to a
"disconnected" flag in the peer status message.
We convert it back to the aborted flag for now inside subd.c, but that's
next.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it easier to use outside simple subds, and now lightningd can
simply dump to log rather than returning JSON.
JSON formatting was a lot of work, and we only did it for lightningd, not for
subdaemons. Easier to use the logs in all cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were allowed to, but the spec removed that. So we handle warnings
differently from errors now.
This also means the LND "internal error" workaround is done in
lightningd (we still disconnect, but we don't want to close channel).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Protocol: we no longer disconnect every time we receive a warning message.
We determine whether they are allowed or not based on the hook return
value of `mindepth`. To do so we need to pass that value down to
`openingd` and verify that the `channel_type` and our permissions
match up.
Update the lightningd <-> channeld interface with lots of new commands to needed to facilitate spicing.
Implement the channeld splicing protocol leveraging the interactivetx protocol.
Implement lightningd’s channel_control to support channeld in its splicing efforts.
Changelog-Added: Added the features to enable splicing & resizing of active channels.
