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.
If the peer's disconnected but the caller sends us valid sigs for the
channel open, we should go ahead and store them to disk before we reject
the call based on the fact that the peer is disconnected.
This way if the peer reconnects later, the channel open will succeed
Changelog-Changed: RPC: `openchannel_signed` will now remember the details of a signed PSBT even if the peer is disconnected.
When we reconnect, if we get a note from the peer that they dont know
about a pending inflight, we need to be able to clean it up so we can
restart/re-negotiate a new RBF etc.
This adds a cleanup method to remove any inflights for a channel without
a last_tx (commitment tx)
We don't actually use this internal to this method? Weird.
Anyway, if we don't want/need it allow the caller to signal that by
passing in NULL, if desired.
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).
From the spec:
Once peers are ready to exchange commitment signatures, they must remember
the details of the funding transaction to allow resuming the signatures
exchange if a disconnection happens.
Basically this means we add channels to the database before we've gotten
commitments for them; it's nice that there's now a state for commitments
recevied but we now save the channel prior to that.
This commit makes it possible to track the pre-commit-rcvd but not quite
open-init state.
"Patrick, I'm sorry I doubted you."
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Config: `large-channels` is now the default, wumbology for all.
Adding a fee offset as the channel opener reduces the likelihood of a
disconnect by the peer do to slight variation in feerate calculation
between nodes.
Changelog-Fixed: Some peer disconnects due to update_fee disagreements are avoided.
We want to use this for boosting txs: either attaching fees to
zero-fee HTLCs, or making anchor transactions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- certificate generation
- config options validation
- log level from 'error' to 'info'
- sending method as None instead ""
- added `listclnrest-notifications` for websocket server rune method
Changelog-Fixed: websocket server notifications are available with
restriction of `readonly` runes
startup_regtest now checks if wallet directory exists before creating
the default wallet, then it will check if wallet is loaded before
attempting to load it. This prevents unnecessary errors during the
execution of this bash script.
[ Squashed fixup: `regtest: restore double quotes on PATH_TO_BITCOIN` -- RR ]
If we ever re-enabled a channel too fast, if we considered it spam it
wouldn't propagate. For the moment, consider our own updates to never
be spam.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This should only have an effect if someone queries, but in practice, peers actually
see the disabling of channels.
This is a workaround until we rework the code so gossipd doesn't generate these at all
any more.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This functionality already exists in the Python framework; this feature
enables it for Rust plugins as well.
Changelog-Added: cln-plugin: Implement send_custom_notification to allow sending custom notifications to other plugins.
