Still needs some massaging (we print HTLCs as we add them, rather then
in the final order, which requires a manual move in one test vector),
but this makes it more trivial to compare the output with the BOLT 3
text after https://github.com/lightningnetwork/lightning-rfc/pull/852
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This may have made our feestates fully resolved, so we can send
update_fee again. Without this fix our tests sometimes timeout.
Also add debugging so we can see when we suppressed a feechange.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
By iterating through them forward, we would often increment
them more than once! Always print feestate transitions,
which is how I worked this out.
Changelog-Fixed: Protocol: handle complex feerate transitions correctly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There are several reports of desynchronization with LND here; a simple
approach is to only have one feerate change in flight at any time.
Even if this turns out to be our fault, it's been a historic area of
confusion, so this restriction seems reasonable.
Changelog-Fixed: Protocol: Don't create more than one feerate change at a time, as this seems to desync with LND.
Fixes: #4152
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't always get two transactions on line 1019; the comment is
confused (only one penalty tx successfully comes out of l3). So make
sure we get the other transactions when we expect them, and then
make this test more specific.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids subdaemons complaining about malformed messages from us,
or doing the completely wrong thing, if they are really the wrong
version.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You still shouldn't do this (you could get some transient failures),
but at least you have a decent chance if you reinstall over a running
daemon, instead of getting confusing internal errors if message
formats have changed.
Changelog-Added: lightningd: we now try to restart if subdaemons are upgraded underneath us.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: #4346
libwally has a bug which results in it failing to parse the 'empty tx'
cHNidP8BAAoAAAAAAAAAAAAAAA==. While we wait for the patch to land in
libwally, we patch over it.
Fix at: https://github.com/ElementsProject/libwally-core/pull/273
If we only add a single input/output for the funding transaction,
we'll only call openchannel_update once, which results in
a crash because the dest->state will never advance to
MULTIFUNDCHANNEL_UPDATED;
Instead, we update to UPDATED before we check for doneness.
We generally hang things off our JSON response (this pattern predates
tmpctx!) but sometimes it gets reported as a memleak. I'd prefer not
to mark JSON responses as "notleak", since they can be allocated for
a while), so use tmpctx here.
```
E ValueError:
E Node errors:
E Global errors:
E - Node /tmp/ltests-spnausnb/test_htlc_out_timeout_1/lightning-1/ has memory leaks: [
E {
E "backtrace": [
E "ccan/ccan/tal/tal.c:442 (tal_alloc_)",
E "ccan/ccan/tal/tal.c:471 (tal_alloc_arr_)",
E "wallet/wallet.c:1775 (wallet_state_change_get)",
E "lightningd/peer_control.c:922 (json_add_channel)",
E "lightningd/peer_control.c:1424 (json_add_peer)",
E "lightningd/peer_control.c:1454 (json_listpeers)",
E "lightningd/jsonrpc.c:643 (command_exec)",
E "lightningd/jsonrpc.c:767 (rpc_command_hook_final)",
E "lightningd/plugin_hook.c:275 (plugin_hook_call_)",
E "lightningd/jsonrpc.c:855 (plugin_hook_call_rpc_command)",
E "lightningd/jsonrpc.c:942 (parse_request)",
E "lightningd/jsonrpc.c:1033 (read_json)",
E "ccan/ccan/io/io.c:59 (next_plan)",
E "ccan/ccan/io/io.c:435 (io_do_always)",
E "ccan/ccan/io/poll.c:300 (handle_always)",
E "ccan/ccan/io/poll.c:377 (io_loop)",
E "lightningd/io_loop_with_timers.c:24 (io_loop_with_timers)",
E "lightningd/lightningd.c:1097 (main)"
E ],
E "label": "wallet/wallet.c:1775:struct state_change_entry[]",
E "parents": [
E "common/json_stream.c:29:struct json_stream",
E "ccan/ccan/io/io.c:91:struct io_conn",
E "lightningd/lightningd.c:116:struct lightningd"
E ],
E "value": "0x55c6b02150b8"
E }
E ]
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't wait for the sendtx to complete before shutting down,
and hence timed out:
```
l2.daemon.wait_for_log('Broadcasting funding tx')
l1.stop()
l2.stop()
bitcoind.generate_block(6)
l1.restart()
l2.restart()
# Make sure we're ok.
> l2.daemon.wait_for_log(r'to CHANNELD_NORMAL')
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
e.g. in test_closing_id we can get a spend from the first (closed) channel
in the same block as the open of the second. Half the time, we'll choose
the wrong one as scid.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Channel can be inactive before it disconnects, apparently. Check
explicitly for the disconnected state so we get the expected error.
Here's what happened:
```
# Can't pay while its offline.
with pytest.raises(RpcError, match=r'failed: WIRE_TEMPORARY_CHANNEL_FAILURE \(First peer not ready\)'):
> l1.rpc.sendpay(route, rhash)
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
```
And the logs show that the outgoing HTLC was sent to channeld before it
realized the connection was closed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Change the address in the canned db: it seems we won the lottery and
l1 connected, and got an error!
```
E ValueError:
E Node errors:
E - lightningd-1: had warning messages
E Global errors:
...
lightningd-1: 2021-04-07T02:44:53.579Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_out WIRE_CHANNEL_REESTABLISH
lightningd-1: 2021-04-07T02:44:53.579Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_in WIRE_GOSSIP_TIMESTAMP_FILTER
lightningd-1: 2021-04-07T02:44:53.580Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: peer_in WIRE_ERROR
lightningd-1: 2021-04-07T02:44:53.580Z INFO 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Peer transient failure in CHANNELD_NORMAL: channeld WARNING: error channel fdeb1ea12e02aa043f66ba581e969a1882d21142b19429995c6733bb71070bb6: Multiple channels unsupported
lightningd-1: 2021-04-07T02:44:53.580Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Will try reconnect in 60 seconds
```
So I changed the port in the db to "1" which will never succeed:
```
sqlite> .dump peers
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE peers ( id INTEGER, node_id BLOB UNIQUE, address TEXT, PRIMARY KEY (id));
INSERT INTO peers VALUES(1,X'022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59','127.0.0.1:38723');
COMMIT;
sqlite> UPDATE peers SET address="127.0.0.1:1"
...> ;
sqlite> .dump peers
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE peers ( id INTEGER, node_id BLOB UNIQUE, address TEXT, PRIMARY KEY (id));
INSERT INTO peers VALUES(1,X'022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59','127.0.0.1:1');
COMMIT;
sqlite>
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add an extra run configuration for the proto-tests.
Proto-tests require DEVELOPER=1; enabling EXPERIMENTAL_FEATURES=1
by default ensures that experimental additions are automatically put
under test also.
This centralizes the setup.py file, and parametrizes it so it can
auto-detect which bolt we are building. It also uses trick 3 from [1]
to avoid importing the package itself during the manifest creation,
which'd cause an import error due to missing dependencies.
[1] https://packaging.python.org/guides/single-sourcing-package-version/
This would lead to errors about missing dependencies when attempting
to install using `pyhon setup.py install`. This is because the
`setup.py` file effectively is the manifest file used to discover
which dependencies are needed, so when using it to detect dependencies
we obviously don't have them yet.
See https://packaging.python.org/guides/single-sourcing-package-version/
They are currently not installable due to circular dependencies and
stuff, so we just add their source to the path and lnprototest will
pick them up from there.
This allows to not have to worry about the source of the installation,
and we always use our in-tree version. It also means we pull in the
requirements.txt files through the setup.py and don't need to
replicate them.
niftynei
Rusty Russell
Christian Decker