We now know the base reference, and we've rebased, so we can do a
simple diff. Also, this means we can use a magic commit message
`No-schema-diff-check` to suppress false positives.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This reflects what we actually do when we apply the commit, and also
means we can easily iterate the commits.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We will do this properly in master later (avoiding it only for branches named release-*)
but for now we simply suppress it so we can properly test.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we didn't hash the descriptions properly (see previous commit), we
cannot immediately deprecate omitting the descriptions (since you'd
have to omit them for backwards compat!).
And move the "must have description or hash" test into bolt11.c core.
Changelog-Deprecated: `pay` has *undeprecated* paying a description-hash invoice without providing the description.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we need to push off requring this for another full deprecation cycle!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `pay` and `decodepay` with description now correctly handle JSON escapes (e.g " inside description)
People running master notice that calling listconfigs fails, because
we don't handle objects called xxx_msat correctly (see
d348554ff4). This makes it painful
to test, until we release a pyln-client version.
Fortunately, the three changes in master are all fully backwards compatible,
so we can simply cut a release now and upload to pipy.org.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a minimal subset of the master commit b8aa3a579e
which fixes compile with --enable-experimental-features:
```
wallet/walletrpc.c: In function 'json_transaction_details':
wallet/walletrpc.c:521:56: error: 'const struct wallet_transaction' has no member named 'input_annotations'
521 | struct tx_annotation *ann = &tx->input_annotations[i];
| ^~
wallet/walletrpc.c:551:56: error: 'const struct wallet_transaction' has no member named 'output_annotations'
551 | struct tx_annotation *ann = &tx->output_annotations[i];
| ^~
```
Reported-by: @whitslack
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: build: compilation error when `--enable-experimental-features` configured.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
Reported in #6270, there was an attempt to delete gossip overrunning
the end of the gossip_store. This logs the gossip type that was attempted to be deleted and avoids an immediate crash (tombstones would be fine to
skip over at least.)
Changelog-None
We removed the (experimental-only!) annotation output in 611795beee
but we still loaded them from the db. Turns out that we were putting bogus
annotations into the db, and accessing out of range when loading them.
Consider the following db entry in transaction_annotations:
```
CREATE TABLE transaction_annotations ( txid BLOB, idx INTEGER, location INTEGER, type INTEGER, channel INTEGER REFERENCES channels(id), UNIQUE(txid, idx));
...
INSERT INTO transaction_annotations VALUES(X'19706f9af2875508a06c7db1754ef7ecb3da745ead005992e626441e4e83465f',18,1,129,53699);
```
Here is the corresponding entry in txs:
```
INSERT INTO transactions VALUES(X'19706f9af2875508a06c7db1754ef7ecb3da745ead005992e626441e4e83465f',710327,966,X'02000000000101f2add69112a1d557317826120e1f4ea3bc1cbe4674d720325695b26ecfe8355d120000000000000000013634000000000000160014dca21f104359bbb81e88ed7da985549f2cd0cbc30347304402201cdc854b76c4c7523e3ca09f38a81539d3b2f7fbd9a0de6ae10b7ceaa65ed9d402205a1770058cd1ef081c77c2fe957c07a334cb3a11bc0cc502834a29c59424fe010120589da1f809d955c7af150bf53123c27ffc0a741489b5291f6be811189863ec838576a9142f188d0d973c4ad1865a619d3748340b30746e088763ac672103b7bbcd592197ba6501e7176aabd3f908d94b126ae82ab1e7a4c58f5a789782e57c820120876475527c21029bcf62114eb36758fcb1aead7e67b6f707d32f34e67816894d5211ac9f2d6ce752ae67a9144483a115219ba65c63a3844be8445f739703bea988ac686800000000',NULL,NULL);
```
The annotation refers to output 18 of the tx, but it only has one output!
However, decoding the tx shows that it spent output 18 of a previous tx, so
that's probably where the `18` came from.
Remove this logic: we can remove the remaining (clearly broken!) annotation
adding code in another cleanup commit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a regression that we introduced in this release
due to some dirty parts of our codebase.
For historical reasons (I think), we were using a `json_add_sat_only`
procedure defined in `peer_control.c`. So when @rustyrussell removed the _msat,
we thought that all the fields were reflecting the new behavior, but
we were wrong.
This PR fixes this bug and also removes the additional function
from `peer_control.c`. This way, we can be sure that there is no other part
of our codebase that uses this method (except for other `json_add` methods).
Link: https://github.com/ElementsProject/lightning/issues/6244
Reported-by: @hMsats
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We were using per-type overrides which caused some asymmetries, where
conversions could end up dropping fields as we went along. Essentially
each conversion would need to override a superset of the previous one,
which then caused issues when attempting to close the loop. By
overriding on the model level we ensure that all representations are
equivalent and convertible into one another, at the expense of
overriding a bit more aggressively, which should be fine anyway.
We use overrides that omit fields in some cases, which makes the
conversion lossy. This also means that until we complete the mapping
we can't reconvert back.
gcc 13 add an extra check for the enum in the definition
of a method. In our case the code was failing with the
following error, and the compiler is right, our definition
is different from the implementation.
```
$ make
CC: cc -DBINTOPKGLIBEXECDIR="../libexec/c-lightning" -Wall -Wundef -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wold-style-definition -Werror -Wno-maybe-uninitialized -Wshadow=local -std=gnu11 -g -fstack-protector-strong -Og -I ccan -I external/libwally-core/include/ -I external/libwally-core/src/secp256k1/include/ -I external/jsmn/ -I external/libbacktrace/ -I external/gheap/ -I external/x86_64-redhat-linux/libbacktrace-build -I external/libsodium/src/libsodium/include -I external/libsodium/src/libsodium/include/sodium -I external/x86_64-redhat-linux/libsodium-build/src/libsodium/include -I . -I/usr/local/include -DSHACHAIN_BITS=48 -DJSMN_PARENT_LINKS -DCOMPAT_V052=1 -DCOMPAT_V060=1 -DCOMPAT_V061=1 -DCOMPAT_V062=1 -DCOMPAT_V070=1 -DCOMPAT_V072=1 -DCOMPAT_V073=1 -DCOMPAT_V080=1 -DCOMPAT_V081=1 -DCOMPAT_V082=1 -DCOMPAT_V090=1 -DCOMPAT_V0100=1 -DCOMPAT_V0121=1 -DBUILD_ELEMENTS=1 -c -o
LD: cc -Og config.vars -Lexternal/x86_64-redhat-linux -lwallycore -lsecp256k1 -ljsmn -lbacktrace -lsodium -L/usr/local/include -lm -lgmp -lsqlite3 -lz -o
cc plugins/spender/multifundchannel.c
plugins/spender/multifundchannel.c:71:6: error: conflicting types for ‘fail_destination_msg’ due to enum/integer mismatch; have ‘void(struct multifundchannel_destination *, enum jsonrpc_errcode, const char *)’ [-Werror=enum-int-mismatch]
71 | void fail_destination_msg(struct multifundchannel_destination *dest,
| ^~~~~~~~~~~~~~~~~~~~
In file included from plugins/spender/multifundchannel.c:13:
./plugins/spender/multifundchannel.h:263:6: note: previous declaration of ‘fail_destination_msg’ with type ‘void(struct multifundchannel_destination *, int, const char *)’
263 | void fail_destination_msg(struct multifundchannel_destination *dest,
| ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:307: plugins/spender/multifundchannel.o] Error 1
```
The gcc 13 is not released yet, but fedora beta is out for public testing,
so it is useful fix this error in this release candidate cycle.
Changelog-Fixed: Build: Compilation with upcoming gcc 13
Reported-by: @grubles
Link: https://github.com/ElementsProject/lightning/issues/6175
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
After the first iteration of the loop, we call memmem with a buflen that
points past the end of buf.
In practice we probably never read the uninitialized memory since we
guarantee the buffer ends with "\r\n", and since most/all libc
implementations probably read the haystack sequentially. But maybe
there's some libc with a crazy optimization out there. It's good to use
an accurate buflen just in case.
Discovered this while running some unit tests with MSan.
Avoids failing the test with the pip warning:
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
reported by: @ksedgwic
Changelog-None
Fixes a bug in installer registration where executable is evaluated
before entrypoints and other details are added.
***RECKLESS STDERR***
Traceback (most recent call last):
File lightning/tools/reckless, line 382, in <module>
INSTALLERS['nodejs'].add_entrypoint('{name}')
KeyError: 'nodejs'
Reported by @ksedgwic
Changelog-None
When enabling or disabling a plugin, the entrypoint is inferred
from the user provided name. A canonical name should be used, which
the installer entrypoint formats help to determine (this generally strips
the file extension if one is provided.)
Also adds a timeout when testing a plugin. Previously the behavior
of pyln-client was relied upon to exit if not communicating with
lightningd, however, this behavior is not universal.
Changlelog-Changed: reckless now installs node.js plugins
Also removes support for pip editable install using pyproject.toml
`pip install -e .` This was a fallback method when a requirements
file was not present, but was hacky and often failed anyway.
reckless: remove installation via pyproject.toml
This method relied on pip install in editable mode (hacky) and often
failed to complete anyhow. We should instead encourage a requirements
file to be created/used for user installation.
Rusty Russell
Christian Decker
Vincenzo Palazzo
Alex Myers
Shahana Farooqui
Matt Morehouse