Changelog-Fixed: In `struct wireaddr`, the `addr` buffer is defined
with a length of DNS_ADDRLEN (255). When parsing a valid DNS name
that is exactly 255 bytes long, the subsequent attempt to append a
`NULL` terminator overruns the buffer and triggers an out-of-bounds
error under UBSan.
Fix this by removing the line that appends `NULL`. This change is
safe because the preceding call to:
`memset(&addr->addr, 0, sizeof(addr->addr))`
already zeroes the entire buffer.
The json_str_to_u64() function contains incorrect logic. It chops one character
off of the beginning and end of the JSMN token and then parses the remainder as
a u64, but JSMN_STRING tokens already do not include the enclosing quotation
marks, so json_str_to_u64() would actually parse the JSON string "1234" into
the integer 23. Oops! Also note that it would simply fail on all input strings
shorter than two characters since tok->end would wind up *before* tok->start.
Just drop the function entirely. It was only used in one place, and that place
explicitly doesn't care whether its input is a JSON number or a numeric string,
and it was already calling json_to_u64() as an alternative, and that function
already accepts both JSON strings and JSON numbers as input, so the call to
json_str_to_u64() would have been entirely redundant if it had been correct.
Changelog-Fixed: The `keysend` command no longer corrupts the type numbers of extra TLVs when they are specified as numeric strings longer than 2 digits.
Changelog-Fixed: Add checks in `amount_msat_scale` and
`amount_sat_scale` to return false when the scaling factor
is -NaN or negative.
This is important as the scaling factor may come from external
sources like wire, which can cause runtime errors if not handled
properly.
Changelog-Fixed: Use the correct context in `daemon_conn_new_()`
by allocating `struct daemon_conn` with `ctx` instead of `NULL`.
This ensures proper ownership and cleanup of `daemon_conn` objects,
avoiding memory leaks.
Prior to 23.05, we used this tag to mark onchain to-self inputs we didn't
wait for (because they were too small). This fixes migration if that happened
(and we are debating whether we should re-introduce this!).
```
lightningd: FATAL SIGNAL 6 (version v25.09rc2)
0x100c8683 send_backtrace
common/daemon.c:33
0x100c876f crashdump
common/daemon.c:78
0x7fffb2080493 ???
???:0
0x7fffb1ab0cac ???
__pthread_kill_implementation+0x1bc:0
0x7fffb1a48a5b ???
__GI_raise+0x2b:0
0x7fffb1a2a3db ???
__GI_abort+0x153:0
0x100935b7 migrate_from_account_db
wallet/account_migration.c:424
0x10093ff7 db_migrate
wallet/db.c:1139
0x10096763 db_setup
wallet/db.c:1185
0x100a1bcb wallet_new
wallet/wallet.c:223
0x1004485f main
lightningd/lightningd.c:1311
0x7fffb1a2aba3 ???
__libc_start_call_main+0x93:0
0x7fffb1a2adeb ???
__libc_start_main_alias_1+0x1ab:0
0xffffffffffffffff ???
???:0
lightningd: Died with signal 6
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8484
If we don't have an accountdb from bookkeeper:
1. Generate a deposit chain event for every confirmed UTXO.
2. Generate an open chain event for every open, confirmed channel.
3. Generate a push/lease event if necessary.
4. Generate a fixup "journal" entry if balance is different from initial.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
This allows the bookkeeper plugin to know it's not actually a channel account.
Remove the "ignored" tag from the schema too: we removed it previously.
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>
fetchinvoice is still good for detailed diagnostics and handling
recurring invoices and alternate currencies, but this covers the
"throw some sats" case well.
Changelog-Added: JSON-RPC: `xpay` can now pay a simple offer directly, rather than requiring fetchinvoice first.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The character classification functions in <ctype.h> are designed to
classify characters returned by <stdio.h> getchar() and friends, which
return characters as signed integers in the range 0 to 255 or EOF. The
behavior of the ctype functions is undefined if they are passed a value
outside of that range, which may happen if they are passed a char-typed
value and the system's char type is signed.
<ccan/str/str.h> defines some inline utility functions that perform the
necessary cast to coerce a char-typed argument into the allowed value
range. Call these wrappers instead of the bare ctype functions when
classifying char-typed characters.
Changelog-None
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
The strto{l,ul,ull} functions do not set errno upon a successful return, so a
successful return from a maximally valued input could be misinterpreted as an
overflow error if errno happened already to be set to ERANGE before the call.
To guard against this edge case, always set errno to zero before calling these
functions if checking errno afterward.
Changelog-None
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>
Undocumented, but the first tag in the coin_movement notification is
considered the primary tag, and the others are optional. The
bookkeeper plugin relies on this!
Enforce that this is true, and in the process document in the code which
is the primary tag.
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.
This appends the extra_tlvs to the internal wire htlcs "added" and
"existing" for the extra tlvs to be handed to lightningd.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
json_tok_streq(…) and json_get_member(…) are convenience wrappers for
json_tok_strneq(…) and json_get_membern(…) respectively. Unfortunately, using
them incurs a performance penalty in the common case where they are called with
a string literal argument because the compiler is unable to substitute a
compile-time constant in place of the buried call to strlen(…).
For example,
json_get_member(buf, tok, "example");
…will have worse performance than…
json_get_membern(buf, tok, "example", strlen("example"));
…because the former is forced to scan over "example" at run-time to count its
length whereas the latter is able to elide the strlen(…) call at compile time.
Hoist these convenience functions up into common/json_parse_simple.h and mark
them as inline so that the compiler can elide the strlen(…) call in the common
case of calling these functions with a string literal argument.
Changelog-None
We add `start_batch` to match t-bast’s splicing spec and we add a new internal wire type `WIRE_PROTOCOL_BATCH_ELEMENT` using the type number 0
Changelog-Added: support for `start_batch`
When doing a cross channel splice, inputs move from having no SIGHASH to having SIGHASH_ALL assigned.
This causes psbt_get_changeset to flag the input as having changed, as the sighash value is compared.
This causes the second channel splice to `tx_remove_input` the input as it doesn’t match anymore, breaking the splice.
We fix this by removing the sighash value from input comparisions.
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.
Changelog-None: Currently, fuzz testing for b64_encode() merely
encodes input and frees the result, providing no real verification
of its behavior.
Introduce a new b64_decode() function (modeled after b32_decode())
and update the fuzz test to perform a roundtrip—encoding followed
by decoding—to ensure that b64_encode() correctly preserves the
original data.
