This commit got reduced to just changing a comment because
the stuff it initially did was already merged in before by
commit 7ff62b4a
So I just kept the changed comment as its more precise.
Changelog-None
Gossipd didn't actually suppress all gossip, resulting in a flake!
Doing it in connectd now makes much more sense.
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>
Simply exit, like we do when master daemon_conn exits.
```
Valgrind error file: valgrind-errors.2211908
==2211908== Invalid read of size 8
==2211908== at 0x12AC13: daemon_conn_send (daemon_conn.c:137)
==2211908== by 0x113CD9: queue_peer_msg (gossipd.c:118)
==2211908== by 0x11B806: query_channel_range (queries.c:1169)
==2211908== by 0x1250DD: peer_gossip_probe_scids (seeker.c:706)
==2211908== by 0x1253B1: check_firstpeer (seeker.c:788)
==2211908== by 0x1256CA: seeker_check (seeker.c:884)
==2211908== by 0x1366AC: timer_expired (timeout.c:62)
==2211908== by 0x1163D1: main (gossipd.c:1146)
==2211908== Address 0x4cafdf0 is 48 bytes inside a block of size 88 free'd
==2211908== at 0x48460C4: free (vg_replace_malloc.c:872)
==2211908== by 0x1805EA: del_tree (tal.c:421)
==2211908== by 0x1808BE: tal_free (tal.c:486)
==2211908== by 0x12AB25: destroy_dc_from_conn (daemon_conn.c:112)
==2211908== by 0x17FFDF: notify (tal.c:237)
==2211908== by 0x180519: del_tree (tal.c:402)
==2211908== by 0x1808BE: tal_free (tal.c:486)
==2211908== by 0x16EE9A: io_close (io.c:450)
==2211908== by 0x16ECA9: do_plan (io.c:401)
==2211908== by 0x16ED16: io_ready (io.c:417)
==2211908== by 0x1710B2: io_loop (poll.c:453)
==2211908== by 0x1163C5: main (gossipd.c:1144)
==2211908== Block was alloc'd at
==2211908== at 0x484384F: malloc (vg_replace_malloc.c:381)
==2211908== by 0x180064: allocate (tal.c:250)
==2211908== by 0x180634: tal_alloc_ (tal.c:428)
==2211908== by 0x12AB65: daemon_conn_new_ (daemon_conn.c:122)
==2211908== by 0x1155F4: gossip_init (gossipd.c:763)
==2211908== by 0x116014: recv_req (gossipd.c:999)
==2211908== by 0x12A828: handle_read (daemon_conn.c:31)
==2211908== by 0x16E09F: next_plan (io.c:59)
==2211908== by 0x16ECD4: do_plan (io.c:407)
==2211908== by 0x16ED16: io_ready (io.c:417)
==2211908== by 0x1710B2: io_loop (poll.c:453)
==2211908== by 0x1163C5: main (gossipd.c:1144)
==2211908==
```
This is the cheapest algo I came up with that simply checks that the
same `remote_addr` has been report by two different peers. Can be
improved in many ways:
- Check by connecting to a radonm peers in the network
- Check for more than two confirmations or a certain fraction
- ...
Changelog-Added: Send updated node_annoucement when two peers report the same remote_addr.
Even if nothing has changed. Note that this is different from simply
re-xmitting the old one, in that it has a different timestamp, so others
will re-xmit it too.
This is a side-effect of reports that node_announcement propagation
through the network is poor:
https://github.com/ElementsProject/lightning/issues/5037
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Protocol: We now refresh our ndoe_announcement every 24 hours, due to propagation issues.
Gossipd now simply gets told by channeld when peers arrive or leave.
(it only needs to know for the seeker).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We also no longer strip the type off: everyone handles both forms, and
Eclair doesn't strip (and it's easier!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want it to keep the latest, so it can make its own error msgs without
asking us. This installs (but does not use!) the message handler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
An "err" is only returned if the channel_update is malformed: more common
is that it's fine, but we don't know the scid.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's weird to have connectd ask gossipd, when lightningd can just do it
and hand all the addresses together.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now let gossipd do it.
This also means there's nothing left in 'struct per_peer_state' to
send across the wire (the fds are sent separately), so that gets
removed from wire messages too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
local_chan was mainly around so we could "soft" disable channels (and
really disable them once we used the channel_update in an error
message).
Instead we introduce the idea of a "deferred_update": it's either
deferred indefinitely (a peer goes offline, if we need to send it in
an error we'll apply it immediatly), or simply delayed to avoid
spamming everyone.
The resulting rewrite is much clearer, IMHO.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And turn "" includes into full-path (which makes it easier to put
config.h first, and finds some cases check-includes.sh missed
previously).
config.h sets _GNU_SOURCE which really needs to be done before any
'#includes': we mainly got away with it with glibc, but other platforms
like Alpine may have stricter requirements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's very similar to the previous, but there are a few changes:
1. The enctlv fields are numbered differently.
2. The message itself is a different number.
The onionmsg_path type is the same, however, so we keep that constant
at least.
The result is a lot of cut & paste, but we will delete the old one
next release.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is from 6e99c5feaf60cb797507d181fe583224309318e9
We renamed the enctlv field to encrypted_recipient_data in the spec, and the
new onion_message is message 513. We don't handle it until the next patch.
Two renames:
1. blinding_seed -> blinding_point.
2. enctlv -> encrypted_recipient_data.
We don't do a compat cycle for our JSON APIs for these experimental
features only used by our own plugins, we just rename.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Temporarily disable sendpay_blinding test which uses obsolete onionmsg;
there's still some debate on the PR about how blinded HTLCs will work.
Changelog-EXPERIMENTAL: onionmessage: removed support for v0.10.1 onion messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To minimize the diffs, we #if 0 the code. We'll reenable it once
channeld is ready.
We also temporarily disable the ping tests.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
One change from the obsolete version handling, gossipd will no longer send
forwarding onion msgs to lightningd, but will forward it directly.
That was the effect before, anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We never tested that we can correctly unwrap on the next step after
unblinding: it failed because we mangled the onion in place! Fix that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Before:
Ten builds, laptop -j5, no ccache:
```
real 0m36.686000-38.956000(38.608+/-0.65)s
user 2m32.864000-42.253000(40.7545+/-2.7)s
sys 0m16.618000-18.316000(17.8531+/-0.48)s
```
Ten builds, laptop -j5, ccache (warm):
```
real 0m8.212000-8.577000(8.39989+/-0.13)s
user 0m12.731000-13.212000(12.9751+/-0.17)s
sys 0m3.697000-3.902000(3.83722+/-0.064)s
```
After:
Ten builds, laptop -j5, no ccache: 8% faster
```
real 0m33.802000-35.773000(35.468+/-0.54)s
user 2m19.073000-27.754000(26.2542+/-2.3)s
sys 0m15.784000-17.173000(16.7165+/-0.37)s
```
Ten builds, laptop -j5, ccache (warm): 1% faster
```
real 0m8.200000-8.485000(8.30138+/-0.097)s
user 0m12.485000-13.100000(12.7344+/-0.19)s
sys 0m3.702000-3.889000(3.78787+/-0.056)s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If there's a rate-card for liquidity, we don't know about it until
after startup (the plugin *should* call us at init to tell us what their
current rates are)
This mainly helps our CI under valgrind, which starts a fresh instance
and immediately calls the invoice command. This can cause the topology
plugin to try to access the gossmap file before it's created.
We can also move the gossmap reading in topology to init time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
