Much like the database; peer contains id, address, channel contains
per-channel information. Where we create a channel, we always create
the peer too.
For the moment, peer->log and channel->log coexist side-by-side, to
reduce some of the churn.
Note that this changes the API to dev-forget-channel: if we have more
than one channel, we insist they specify the short-channel-id.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Both when we forget about an opening peer, and at startup. We're
going to be relying on this, and the next patch, as we refactor
peer/channel handling to mirror the db.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This caused a bit of confusion for our testers, when funding a channel
the funds are no longer available and listed in `lisfunds`, causing
them to believe funds to have disappeared. This PR adds funds that are
allocated to channels in the `listfunds` output, together with some
info about the channel, to make sure this doesn't happen again.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
These are now logically arrays of pointers. This is much more natural,
and gets rid of the horrible utxo array converters.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Still writing the channel since some of the channel setup parameters
depends on `chan->id` to be set. If we later set the `chan->id`
signatures fail. This prevents OPENINGD channels showing up after
restarting.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We were sideloading it, which is awkward, now it's a field that we can
actually use in the code.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
If needed, they should be directly #included; otherwise the following
patches really mess things up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* Add optional addresstype param to newaddr, which can be one of:
- bech32
- p2sh-segwit
- nothing (defaults to p2sh-segwit)
The naming here mirrors bitcoind
* txfilter already looks for p2wpkh outputs, so we're covered there
Signed-off-by: William Casarin <jb55@jb55.com>
This was removed because withdraw-to-self results in more than the
change being sent to us.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Maintaining it was always fraught, since the command could go away
if the JSON RPC died. Most recently, it was broken again on shutdown
(see below).
In future we may allow pay commands to block on previous payments, so
it won't even be a 1:1 mapping. Generalize it: keep commands in a
simple list and do a lookup when a payment fails/succeeds.
Valgrind error file: valgrind-errors.5732
==5732== Invalid read of size 8
==5732== at 0x4149FD: remove_cmd_from_hout (pay.c:292)
==5732== by 0x468BAB: notify (tal.c:237)
==5732== by 0x469077: del_tree (tal.c:400)
==5732== by 0x4690C7: del_tree (tal.c:410)
==5732== by 0x46948A: tal_free (tal.c:509)
==5732== by 0x40F1EA: main (lightningd.c:362)
==5732== Address 0x69df148 is 1,512 bytes inside a block of size 1,544 free'd
==5732== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5732== by 0x469150: del_tree (tal.c:421)
==5732== by 0x46948A: tal_free (tal.c:509)
==5732== by 0x4198F2: free_htlcs (peer_control.c:1281)
==5732== by 0x40EBA9: shutdown_subdaemons (lightningd.c:209)
==5732== by 0x40F1DE: main (lightningd.c:360)
==5732== Block was alloc'd at
==5732== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5732== by 0x468C30: allocate (tal.c:250)
==5732== by 0x4691F7: tal_alloc_ (tal.c:448)
==5732== by 0x40A279: new_htlc_out (htlc_end.c:143)
==5732== by 0x41FD64: send_htlc_out (peer_htlcs.c:397)
==5732== by 0x41511C: send_payment (pay.c:388)
==5732== by 0x41589E: json_sendpay (pay.c:513)
==5732== by 0x40D9B1: parse_request (jsonrpc.c:600)
==5732== by 0x40DCAC: read_json (jsonrpc.c:667)
==5732== by 0x45C706: next_plan (io.c:59)
==5732== by 0x45D1DD: do_plan (io.c:387)
==5732== by 0x45D21B: io_ready (io.c:397)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We move it into jsonrpc where it belongs, and make it fail the command.
This means it can tell us exactly what was wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
So many channels stuck in channeld_awaiting_lockin, and I don't like
suggesting manually editing the DB, so this adds a very simple way to
sync with bitcoind's UTXO view. `dev` since it is dangerous, then
again if bitcoind says those funds aren't available there's little we
can do anyway.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The previous tests didn't make sense anyway, but I think they were trying
to exclude onchain channels.
We delete completely forgotten channels anyway now, so we don't need
such testing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Error code is inverted (which makes sense: who returns 'true' on
error?), and anyway there's a leak if we do error.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`pay_index` has no valid value if not PAID anyway, so
we should correctly leave it uninitialized.
Analysis via valgrind will catch incorrect use of
uninitialized fields.
If we load it with a dummy 0 value, then an
incorrect use of `pay_index` whan invoice is not
PAID will not get caught by valgrind.
From test_reconnect_sender_add1:
lightningd(13643):BROKEN: backtrace: wallet/wallet.c:1537 (wallet_payment_set_status) 0x561c91b03080
lightningd(13643):BROKEN: backtrace: lightningd/pay.c:67 (payment_failed) 0x561c91ac4f99
lightningd(13643):BROKEN: backtrace: lightningd/peer_htlcs.c:132 (fail_out_htlc) 0x561c91acf627
lightningd(13643):BROKEN: backtrace: lightningd/peer_htlcs.c:321 (hout_subd_died) 0x561c91acfb62
When payment fails, we call wallet_payment_set_status; this is perfectly
possible before it's been committed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Christian Decker
practicalswift
luca vaccaro
William Casarin
ZmnSCPxj
rvandermeer