==1503== Use of uninitialised value of size 8
==1503== at 0x566786B: _itoa_word (_itoa.c:179)
==1503== by 0x566AF0D: vfprintf (vfprintf.c:1642)
==1503== by 0x569790F: vsnprintf (vsnprintf.c:114)
==1503== by 0x156CCB: do_vfmt (str.c:66)
==1503== by 0x156DB1: tal_vfmt_ (str.c:92)
==1503== by 0x1289CD: status_vfmt (status.c:141)
==1503== by 0x128AAC: status_fmt (status.c:151)
==1503== by 0x118E05: route_prune (routing.c:2495)
==1503== by 0x11DE2D: gossip_refresh_network (gossipd.c:1997)
==1503== by 0x1292B8: timer_expired (timeout.c:39)
==1503== by 0x12088C: main (gossipd.c:3075)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also, change the values to match the spec values (I made the
to_self_delays different to catch more bugs).
Suggested-by: @niftynei
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is also required for actually creating usable onions. For the moment,
due to API limitations, we only let them set realm 0.
Note that the privkey parsing was broken, requiring an additional two
hex digits, overflowing the buffer, and were ignored.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add odd-length string can never be valid hex!
In addition, don't try to print the next hop if there isn't one, but
always print the (raw) payload.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows for complete channel simulation, including HTLC
transactions, but means we use higher-level primitives to
make the easy.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These utilities allow us to create valid test txs and information given both
sides' complete set of secrets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us use it as an interactive driver of conversation, rather
than writing all packets then reading all packets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our previous param support was a bit limited in this case.
We create a dev- command multiplexer, so we can exercise it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
updates the bolt version to 6639cef095a2ecc7b8f0c48c6e7f2f906fbfbc58.
this requires us to use the new bolt parser at generate-bolt.py
and updates to all of the type specifications (ie. from u8 -> byte)
the RFC's extract-format.py is switching to a new format.
this script can correctly parse them.
mostly moves logic over from generate-wire.py, uses a
Python formatting libarary called mako, which needs to be
installed prior to running this script.
you can add it to your system with
sudo apt-get install python3-mako
We were having a few issues with malformed data in the past, so this time we
really check that stuff.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
test_funding_cancel_race explicitly attempts to trigger this via a race
condition; this conflicts with our post-test checks that no broken
logs were logged. as a middle ground, we log it as unusual, not broken,
as it's possible for it to attempt to fail if it was begun at the same
time as the complete is.
It probably doesn't matter to "fundchannel_cancel" exactly why the
fundchannel didn't work (though it can read the error msg), and we
should always fail any pending fundchannel_complete command.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Instead of taking over the ->cmd pointer, append ourselves to a list
of cancels. This fixes the test_funding_cancel_race.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Instead of freeing proposals, which we did in *some* places, we just
set ->resolved and check that in billboard_update which didn't get it right.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
At the beginning of the lightningd, we use "echo" command to check if bitcoin-cli is running.
Now we raplace "echo" with "getblockchaininfo" for this check, and also check whether the "chain" field in response is same as the blockchain that lightningd is on.
"getblockchaininfo" is also valid for litecoin-cli.
'bip70_name' is corresponding to the 'chain' field of
the API 'getblockchaininfo'.
At the beginning of lightningd, we use the 'chain' field of 'getblockchaininfo' to check if we are on right blockchain.
1. bcli_args_direct() will be used in wait_for_bitcoind;
At the beginning, we check if bitcoin-cli is running by "echo" command
whitout any bitcoin_cli struction. If this first command fails, we need
present the agrs gathered, like "-rpcuser", like "-rpcpassword".
Related changes include:
i) rename bcli_args() to bcli_args_direct(), and use 'const char **'
as the paramater for bcli_args_direct();
ii) add a new function bcli_args() warpped on bcli_args_direct(), this
warpping can reduce the large number of changes later in the file;
2. bcli_args() warpping on bcli_args_direct() is used like original.
And clean up some dev ones which actually happen (mainly by calling
channel_fail_permanent which logs UNUSUAL, rather than
channel_internal_error which logs BROKEN).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we now have a couple of long-lived dependents it is time we stop
removing channels from the table once they are fully closed, and instead just
mark them as closed. This allows us to keep forwards and transactions foreign
keys intact, and it may help us debug things after the fact.
Fixes#2028
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Instead of deleting the channels we will simple mark them as `CLOSED` from now
on. This is needed for some of the other tables not to end up with dangling
references that would otherwise survive the channel lifetime, e.g., forwards
and transactions.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Rusty Russell
darosior
lisa neigut
Juraj Bednar
Christian Decker
trueptolemy
Nicola Squartini
ZmnSCPxj