Currently our CI is not able to complete the compilation because
there is the following compilation error introduced in `0bcff1e76d`
```
cc wallet/db.c
wallet/db.c: In function 'migrate_normalize_invstr':
wallet/db.c:1734:3: error: too many arguments to function 'db_bind_text'
1734 | db_bind_text(update_stmt, 0, invstr);
| ^~~~~~~~~~~~
In file included from wallet/db.c:10:
./db/bindings.h:25:6: note: declared here
25 | void db_bind_text(struct db_stmt *stmt, const char *val);
| ^~~~~~~~~~~~
wallet/db.c:1735:3: error: too many arguments to function 'db_bind_u64'
1735 | db_bind_u64(update_stmt, 1, id);
| ^~~~~~~~~~~
In file included from wallet/db.c:10:
./db/bindings.h:23:6: note: declared here
23 | void db_bind_u64(struct db_stmt *stmt, u64 val);
| ^~~~~~~~~~~
wallet/db.c:1758:3: error: too many arguments to function 'db_bind_text'
1758 | db_bind_text(update_stmt, 0, invstr);
| ^~~~~~~~~~~~
In file included from wallet/db.c:10:
./db/bindings.h:25:6: note: declared here
25 | void db_bind_text(struct db_stmt *stmt, const char *val);
| ^~~~~~~~~~~~
wallet/db.c:1759:3: error: too many arguments to function 'db_bind_u64'
1759 | db_bind_u64(update_stmt, 1, id);
| ^~~~~~~~~~~
In file included from wallet/db.c:10:
./db/bindings.h:23:6: note: declared here
23 | void db_bind_u64(struct db_stmt *stmt, u64 val);
| ^~~~~~~~~~~
make: *** [Makefile:299: wallet/db.o] Error 1
make: *** Waiting for unfinished jobs....
rm external/build-x86_64-linux-gnu/libwally-core-build/src/secp256k1/libsecp256k1.la
```
Fixes: 0bcff1e76d
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This commit make a db migration to canonicalize all the
invoice string stored inside the database.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This avoids the mess where we override db_fatal for teqsts, and keeps it
generic.
Also allows us to get rid of one #if DEVELOPER, and an ugly global for
bookkeeper.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This was always the intent, but now we have to reconstruct from the
disparate fields.
This means `option_anchor_outputs` is now redundant.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't cover three common patterns:
1. Optional integers (db_col_u64 has different form from structs)
2. Optional strings.
3. Optional array fields.
But it does neaten and reduce the scope for cut&paste errors in the
common "if not-NULL, tal and assign".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We actually have an assertion that there are no channels remaining when
we delete peers, so this is confusing!
Actually removing the constraint is db-specific and deeply non-trivial.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`struct lightningd` is not completely initialized, so we added a
"migration_context" which only had some of the fields. But we ended
up handing in `struct lightningd` anyway, so I don't think this
complexity is worthwhile.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
At the moment only lightingd needs it, and this avoids missing any
places where we do bip32 derivation.
This uses a hsm capability to mean we're backwards compatible with older
hsmds.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Protocol: we now always double-check bitcoin addresses are correct (no memory errors!) before issuing them.
e778ebb9af ("wallet: only log broken if we
have duplicate scids in channels.") downgraded the fatal() to a broken
log message, but the user reports it still won't start up.
Perhaps they're hitting the fatal() outside the loop? (And we're
not getting that output).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Missed a DEFAULT in the db clause.
Feb 15 16:02:12 citrine lightningd[902093]: Accessing a null column lease_satoshi/15 in query SELECT funding_tx_id, funding_tx_outnum, funding_feerate, funding_satoshi, our_funding_satoshi, funding_psbt, last_tx, last_sig, funding_tx_remote_sigs_received, lease_expiry, lease_commit_sig, lease_chan_max_msat, lease_chan_max_ppt, lease_blockheight_start, lease_fee, lease_satoshi FROM channel_funding_inflights WHERE channel_id = ? ORDER BY funding_feerate
Fixes#6016
People are upgrading to 22.11.1 not, and in some configurations like the one
mentioned in the issue, we should
put some info information in the log when we are not able to upgrade.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
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??
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
We didn't actually populate them properly, and the real annotations
are on inputs and outputs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: JSON-RPC: `listtransactions` `channel` and `type` field removed at top level.
Rework the logic of the version check used in the
database migration, and make sure
that it is full functional to avoid confusion
at release time.
Changelog-Fixed: database: Correctly identity official release versions for database upgrade.
Reported-by: @urza
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This was reported, but the channel was closed. So however we ended
up with a duplicate, we're no *worse* off than we were before migration?
Fixes: #5760
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have a primary key that is spanning the `in_channel_id` and the
`in_htcl_id`. The latter gets set to NULL when the HTLC and channel
gets deleted, so we coalesce with a random large number that is
unlikely to collide for the primary key.
We no longer use offers for "I want to send you money", but we'll use
invoice_requests directly. Create a new table for them, and
associated functions.
The "localofferid" for "pay" and "sendpay" is now "localinvreqid".
This is an experimental-only option, so document the change under
experimental only.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: JSON-RPC: `pay` and `sendpay` `localofferid` is now `localinvreqid`.
Changelog-Changed: JSON-RPC: `listfunds` now lists coinbase outputs as 'immature' until they're spendable
Changelog-Changed: JSON-RPC: UTXOs aren't spendable while immature
We have to allow them (as otherwise `fees_collected_msat` in getinfo breaks),
but it means that actually, in_htlc_id might be missing in listforwards
(also, out_htlc_id might be missing, which we didn't catch before).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: #5628
Normally, we'd use the delete_columns function to remove the old
`short_channel_id` string field, *but* we can't do that for sqlite, as
there are other tables with references to it. So add a FIXME to do
it once everyone has upgraded to an sqlite3 which has native support
for column deletion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This one directly contains the scids of the channels involved, not
references, so can outlive the channels. As a side-effect, however,
it now never lists `payment_hash`. Having it listed (via join) is not
possible as it is a *string* in the channels table, and difficult
anyway because of channel aliases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
contrib/giantnode.py shows we're spending a lot of time looking up
payments by payment_hash: sendpays does it to see if we've already
paid, and bookkeeper does it in listsendpays:
```
- 94.52% 0.00% lightningd lightningd [.] read_json
- 94.52% read_json
- 94.48% parse_request
- 94.46% plugin_hook_call_rpc_command
- plugin_hook_call_
- rpc_command_hook_final
- 94.46% command_exec
- 49.08% json_sendpay
- 49.01% send_payment
- 48.86% send_payment_core
- 48.84% wallet_payment_list
- 48.80% db_step
+ db_sqlite3_step
- 45.38% json_listsendpays
- 45.36% wallet_payment_list
- 45.30% db_step
+ 45.30% db_sqlite3_step
```
This doesn't actually make much of a difference, so see next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a good sanity check that users understand that if they upgrade
to master mid-cycle they can't go back!
Suggested-by: @wtogami
Changelog-Added: Config: `--database-upgrade=true` required if a non-release version wants to (irrevocably!) upgrade the db.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`alias_local` is generated locally and sent to the peer so it knows
what we're calling the channel, while `alias_remote` is received by
the peer so we know what to include in routehints when generating
invoices.
Suggested-by: @t-bast
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `listforwards` has new entry `style`, currently "legacy" or "tlv".
Suggested by @m-schmook, I realized that if we append it later I'll
never get it right: I expect parameters min and max, not max and min!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Protocol: you can now alter the `htlc_minimum_msat` and `htlc_maximum_msat` your node advertizes.
We need to stash/save the amount of the lease fees on a leased channel,
we do this by re-using the 'push' amount field on channel (which is
technically correct, since we're essentially pushing the fee amount to
the peer).
Also updates a bit of how the pushes are accounted for (pushed to now
has an event; their channel will open at zero but then they'll
immediately register a push event).
Leases fees are treated exactly the same as pushes, except labeled
differently.
Required adding a 'lease_fee' field to the inflights so we keep track of
the fee for the lease until the open happens.
If we initialized the payment, the fees are the entire fee-chain
(final hop amount - starting hop amount)
If it's a payment we routed, the fees are the diff between the
inbound htlc and the outbound (net gain by this routing)
Added to database so data persists nicely.
The only thing that needs ld->wallet after this is destroy_invoices_waiter (off jsonrpc)
Could not find any other destructors (destroy_*) that need wallet or db access after this.
Any db access would now segfault.
