These were deprecated in v0.12.0, hence scheduled for removal next version anyway
(use local_fund_msat and remote_funds_msat).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since it's not spec-final yet (hell, it's not even properly specified
yet!) we need to put it behind an experimental flag.
Unfortunately, we don't have support for doing this in a plugin; a
plugin must present features before parsing options. So we need to do
it in core.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When you return an allocated pointer, you should always hand in the
context you want it allocated from. This is more explicit, because it may
really matter to the caller!
This also folds some simple operations, and avoids doing too much
variable assignment in the declarations themselves: some coding styles
prohibit such initializers, but that's a bit exteme.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And we should always represent them as is, not as optional: it's
possible in future we could *require* "WANT_PEER_BACKUP_STORAGE".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is needed for the next patch, which does this from the peer_connected hook!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: `sendcustommsg` can now be called by a plugin from within the `peer_connected` hook.
We keep the node_id, not a pointer to the peer.
This also means that it might have reconnected while we were in the hook, so make
sure we ignore the result if it's in state PEER_CONNECTED.
And remove the `tal_steal(peer, hook_payload)` which doesn't do anything: the
plugin_hook call steals hook_payload anyway!
Fixes: #5944
- Renamed zerod_channel_ids to temporary_channel_id
- Renamed witness_stack->witnesses
- Renamed witness_element->witness_elements
- open_channel2 now includes second commitment point
- accept_channel2 now includes second commitment point
Current commit on rfc branch 64f7f360b9f3c2664d078e2129cfe83098fc4617
Changelog-EXPERIMENTAL: Protocol: dual-funding spec changed in incompatible ways, won't work with old versions (but maybe soon with Eclair!!)
It's not likely but possible that the node's settings will shift btw a
start and an RBF; we persist the setting to the database so we don't
lose it.
Right now holding onto it forever is kind of extra but maybe we'll
reuse the setting for splices? idk.
Should this be a channel type??
`openchannel_init` takes a psbt, which we pipe over to dualopend
process.
If the peer requests that they'll only accept confirmed inputs, we need
to go validate those before we continue.
This wires up the harness for this (validation check yet tc)
technically we don't need this info after the channel opens, but for any
subsequent RBF (and maybe splice?) we need to remember what the
open/accept peer signaled
not amazing, since we'll probably call openchannel_update multiple
times per open, but this is the simplest way to confirm that we're
not sending unconfirmed outputs to peer.
