We get sent three corresponding arrays:
1. htlc stubs
2. whether we want to know if they're missing,
3. whether to wait 3 blocks or tell us immediately
We then sorted the htlc stubs by CLTV, *but didn't sort the corresponding arrays*.
This fixes that the simplest way possible, and probably also:
Fixes: #4649
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: onchaind: we sometimes failed to close upstream htlcs if more than one HTLC is in flight during unilateral close.
These trip when anything weird happens; turns out that we tell
onchaind about old htlcs (e.g. for penalties), so in that case we can
actually have it tell us about missing HTLCs which we no longer have
in memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This doesn't actually fix anything, but may shed more clues if it
happens again.
The broken() logs are overzealous, see next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Don't use dust HTLCs.
2. Make l3 unresponsive, like report.
3. Make l2-l3 fail because we time out on successive HTLC.
We use sendpay rather than pay, because pay can do multiple attempts.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The CI fails with the error
```
EnvCommandError
Command ['/usr/bin/python3', '-m', 'pip', 'install', '--no-deps', '-U', '/root/.cache/pypoetry/artifacts/07/6f/ab/ca33bde7c6751a5ad8d13495b766891cd70e61786112885733ce9b0562/cryptography-36.0.2-cp36-abi3-manylinux_2_24_x86_64.whl'] errored with the following return code 1, and output:
ERROR: cryptography-36.0.2-cp36-abi3-manylinux_2_24_x86_64.whl is not a supported wheel on this platform.
at ~/.local/lib/python3.8/site-packages/poetry/utils/env.py:1195 in _run
1191│ output = subprocess.check_output(
1192│ cmd, stderr=subprocess.STDOUT, **kwargs
1193│ )
1194│ except CalledProcessError as e:
→ 1195│ raise EnvCommandError(e, input=input_)
1196│
1197│ return decode(output)
1198│
1199│ def execute(self, bin, *args, **kwargs):
```
The solution is to upgrade the pip version as suggested in https://github.com/python-poetry/poetry/issues/2688#issuecomment-937837619
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>x
See: https://github.com/ElementsProject/lightning/issues/4991
We seem to correctly set end_time everywhere, so this looks like
a use-after-free somehow? But this will fix the crash right here :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the part which works: we have another old PR (or simply
uncomment the FIXME section) for the routehint case.
Closes: #4781
See-also: #4808
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
e.g.
```
lightningd-1: 2022-03-28T11:02:12.476Z DEBUG plugin-cln-grpc: add_pem_file processed 1 valid and 0 invalid certs
lightningd-1: 2022-03-28T11:02:12.478Z DEBUG plugin-cln-grpc: Connecting to \"lightning-rpc\" and serving grpc on 0.0.0.0:36331
lightningd-1: 2022-03-28T11:02:12.478Z DEBUG connectd: REPLY WIRE_CONNECTD_ACTIVATE_REPLY with 0 fds
lightningd-1: 2022-03-28T11:02:12.478Z INFO lightningd: --------------------------------------------------
lightningd-1: 2022-03-28T11:02:12.478Z INFO lightningd: Server started with public key
```
Which means we don't see it, since start() swallows it:
```
> raise TimeoutError('Unable to find "{}" in logs.'.format(exs))
E TimeoutError: Unable to find "[re.compile('serving grpc on 0.0.0.0:')]" in logs.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Suggested-by: Rusty Russell <@rustyrussell>
Changelog-Added: plugins: `cln-grpc` first class GRPC interface for remotely controlling nodes over mTLS authentication
If we aren't using the correct certificates we should reject the
connections during the mTLS connection setup. This test tries to
connect with the wrong client cert to the node, and the server will
reject it.
We get some memleak reports because ld owns the subd, but once
the peer/channel is freed, there's no reference for the brief time
until the subd exits.
This happens for both opening and closingd. For openingd, the
peer owns it, for others (including dualopend) the channel owns it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I removed these prematurely: we *haven't* had a release since
introducing them!
This consists of reverting d15d629b8b
"plugins/fetchinvoice: remove obsolete string-based API." and
plugins/fetchinvoice: remove obsolete string-based
API. "onion_messages: remove obs2 support."
Some minor changes due to updated fromwire_tlv API since they
were removed, but not much.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: REVERT: Removed backwards compat with onion messages from v0.10.1.
There's a race under CI, where a channel is deleted then we see the
channel_update in the gossip store. We assumed this wouldn't happen,
but it can!
```
[gw1] [ 95%] FAILED tests/test_connection.py::test_multichan
[gw1] [ 95%] ERROR tests/test_connection.py::test_multichan
...
> raise ValueError(str(errors))
E ValueError:
E Node errors:
E - lightningd-3: had BROKEN messages
E - lightningd-3: Node exited with return code 1
E Global errors:
...
lightningd-3: 2022-03-28T00:11:42.160Z DEBUG wallet: Owning output 0 100000sat (SEGWIT) txid 30616903feba1839a3834e2b3b6123759ce1fe0d76414ca77e2dbc17414772e0 CONFIRMED
lightningd-3: 2022-03-28T00:11:42.392Z DEBUG hsmd: Client: Received message 5 from client
lightningd-3: 2022-03-28T00:11:42.393Z DEBUG hsmd: new_client: 2
lightningd-3: 2022-03-28T00:11:42.398Z INFO plugin-topology: Killing plugin: exited during normal operation
lightningd-3: 2022-03-28T00:11:42.400Z **BROKEN** plugin-topology: Plugin marked as important, shutting down lightningd!
...
----------------------------- Captured stderr call -----------------------------
topology: update for channel 105x1x1 not found!
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Means that field is now optional in JSON output.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `delinvoice` has a new parameter `desconly` to remove description.
LNURL wants this so they can include images etc in descriptions.
Replaces: #4892
Changelog-Added: JSON-RPC: `invoice` has a new parameter `deschashonly` to put hash of description in bolt11.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was tlv_fields_valid that wanted a non-const: now that's gone, we
can make this correctly const.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Callers were supposed to call "tlv_fields_valid" after fromwire_tlv,
but few did. Make this the default, and call the underlying function
directly where we want to be more flexible (one place).
This loses the ability to allow misordered fields, or to pass through
*any* even fields. We restore that for special cases in the next
patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Requiring the caller to allocate them is ugly, and differs from
other types.
This means we need a context arg if we don't have one already.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we actually put bolt12 fields (.e.g tlv_invoice) in onion messages,
that code will try to call printwire_tlv_invoice(), so expose it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This works better in general: let printwire_x do the work of figuring
out how to demarshal x. This is particularly important for TLVs, which
require a call to tlv_x_new() first.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
