We take over the --bookkeeper-dir and --bookkeeper-db options, and
then if we can find the bookkeeper db we extract the records to
initialize our chain_moves and channel_moves tables.
Of course, bookkeeper now needs to not register those options.
When bookkeeper gets invoked the first time, it will reconstruct
everything from listchannelmoves and listcoinmoves. It cannot
preserve manually-added descriptions, so we put those in the datastore
for it ready to go.
Note that the order of onchain_fee changes slightly from the original.
But this is fine.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the moment, we'll continue to use bookkeeper to monitor the
notifications to insert these (we don't have the internal infrastructure
for that, and actually these commands are probably better than using
notifications).
We hoist param_outpoint() into common code, since there are already
two uses.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Only makes sense to wait on creation, since they neither are deleted
nor updated.
We also enhance the list commands to take the standard index options.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `wait`: new subsystems `chainmoves` and `channelmoves`.
This is where all the previous work pays off: we can access the coinmoves
in the db.
Changelog-Added: JSON-RPC: `listchainmoves` and `listchannelmoves` commands to access the audit log of coin movements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Iterating through every peer and channel every time can be very slow
for large nodes, when calling wallet_coinmoves_extract for listcoinmoves.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is mainly for the coming list commands, but it's just more
logical to have the common fields at the top.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We change notify_chain_mvt to wallet_save_chain_mvt, and
notify_channel_mvt to wallet_save_channel_mvt, which save to the db
and call the notifier themselves.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than forcing them to wrap their parameters in a "payload"
sub-object, copy in params directly. We include the "origin" field
one level up, if they care.
The next patch restores compatibility for the one place we currently use
them, which is the pay plugin.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: pyln-client: plugin custom notifications origins and payload (use parameters directly)
We always prefer to omit fields rather than use 'null' (or unknown!).
Note that before this, the schema was broken, so we have to put a special
exemption in for that case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids making an extra copy of the escaped string.
Note that jsonrpc_command_add() no longer accepts usage strings
containing invalid escape sequences. (Previously, it would quietly
accept such a string without unescaping anything.)
Changelog-None
An obvious omission!
Changelog-Added: Plugins: `openchannel` and `openchannel2` hooks now expose the `channel_type` field for the offered channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
bookkeeper used to generate these as channel events, now lightningd does.
We also add a "journal" event, which we will need later too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's always set, and in fact we assume it is (journal entries are not
internal to lightningd, so we won't see them in
lightningd/notification.c: that comment is misleading).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is not particularly relevant now (it's always the current time) but will be
useful when we implement the list commands.
Note that timestamp is set to be "u32" in various schemas. This will
only become a problem on Sun 07 Feb 2106 06:28:15 UTC. I apologize to
my grandchildren in advance.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're going to store them in the db this way, so I thought I'd see what it looks like if
we lift that interface all the way through.
We use a struct, so that types are checked strictly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we can keep a pointer to the channel directly, *or* a string.
This avoids gratuitous formatting (on creation) and lookups (later).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
More readable for me. Also, change order so we definitely break
compilation on all callers (putting enum before amount).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The part id is *only* unique within a group. The payment_hash / partid / groupid tuple is unique.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Plugins: `coin_movement` notification with `part_id` field now always has `group_id` field.
Rather than converting to a generic coin_mvt struct, use these directly in
the notification, which is more explicit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add serializing and deserializing of the extra tlvs to to the
htlc_accepted_hook to allow plugin users to replace the tlv stream that
is attached to the update_add_htlc message on forwards.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This appends the extra_tlvs to the internal channeld_offer_htlc wire
msg. We also recombine the extra_tlvs with the blinded path key for
forwarding htlcs.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We cannot use subd_req() here: replies will come out of order, and the
we should not simply assign the reponses in FIFO order.
Changelog-Fixed: lightningd: don't get confused with parallel ping commands.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This replaces the old "iterate through each peer, then each peer's channel" suboptimality.
A bit of care required that we don't expose scids if we're forwarding,
but that was already carefully handled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We allowed NULL for stub channels, but just don't put the stub scid
into the hash tables. This cleans up all the callers to make it
clear this is a non-optional parameter.
We opencode channel_set_random_local_alias, since there's only one caller now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: we now allow routing through old short-channel-ids once a splice is done (previously we would refuse, leading to a 6 block gap in service).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There can be any number of these, and it will be useful to allow
routing by older scids (when other nodes haven't seen our gossip, or
even before we *can* announce the new post-splice channel).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to use a check on the active psbt to see if our splice signature was in it — but now we need to generate the signature early.
So we have to add a field tracking if we’ve sent it and add it to the database, wire protocols, and inflight objects.
Prior to it being compulsory, these daemons would need a default value. Now it's
always required, it's clearer if it's always told.
There's no "default_channel_type" now everyone has to specify channel_type either,
so rename it to "desired_channel_type" and put it in lightningd specifically.
Note that the channel_type can have options added: either option_scid_alias or option_zeroconf.
This results in a slight behavior change: we will get type zeroconf even if we didn't ask for it, if they gave it to us.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: fundchannel / fundchannel_start returned `channel_type` will include option_zeroconf if it was implied by a 0 minimum_depth, even if we didn't explicitly ask for a zero conf channel.
As per BOLT recommendation https://github.com/lightning/bolts/pull/1232, this means
we will insist on this being available.
For CLN, we added this in 0.12.0 (2022-08-23), though there were fixes as late as 24.02. Either way that's well outside our support window.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Closes: https://github.com/ElementsProject/lightning/issues/8152
Changelog-Changed: Protocol: We now insist that peers support `option_channel_type` (in CLN since 0.12.0 in late 2022, similar for other implementations).
Doesn't change anything for us, since we will already fulfull the incoming
HTLCs if we can, but good to note.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was already disabled by Dusty due to a number conflict with splicing, and
the proposal probably needs updating to use quiescence now that is merged.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: The non-functional `experimental-upgrade-protocol` config option.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Future release schedule moved one month: v25.05 is now v25.06, and all deprecations incremented accordingly.
