We had json_add_amount_msat_only(), which was designed to be used to
print out msat fields, if we had sats.
However, we misused it, so split it into the three different cases:
1. json_add_amount_sat_msat: We are using it correctly, with a field called
xxx_msat.
2. json_add_amount_sats_deprecated: We were using it wrong, so deprecate
the old field and create a new one which does end in _msat.
3. json_add_sats: we were using it to hand sats as a JSON parameter to an
interface, where "XXXsat".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: Plugins: `rbf_channel` and `openchannel2` hooks `their_funding` (use `their_funding_msat`)
Changelog-Deprecated: Plugins: `openchannel2` hook `dust_limit_satoshis` (use `dust_limit_msat`)
Changelog-Deprecated: Plugins: `openchannel` hook `funding_satoshis` (use `funding_msat`)
Changelog-Deprecated: Plugins: `openchannel` hook `dust_limit_satoshis` (use `dust_limit_msat`)
Changelog-Deprecated: Plugins: `openchannel` hook `channel_reserve_satoshis` (use `channel_reserve_msat`)
Changelog-Deprecated: Plugins: `channel_opened` notification `amount` (use `funding_msat`)
Changelog-Deprecated: JSON-RPC: `listtransactions` `msat` (use `amount_msat`)
Changelog-Deprecated: Plugins: `htlc_accepted` `forward_amount` (use `forward_msat`)
This was eliminated this morning in the latest spec. We still accept them,
we just don't produce them any more.
Changelog-Removed: Protocol: We no longer create gossip messages which use zlib encoding (we still understand them, for now!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have an explicit filter against redundant node_announcement
updates; we only allow 1 a week. This means that our change to force
a reannouncement every 24 hours did not work!
Allow once a day, instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This attempted to make us re-xmit our own node_announcement at restart,
by moving the node_announcement to the end of the gossip store. But,
as nothing is connected, yet, this had no effect!
We will rexmit it anyway, since it's marked PUSH.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We do this (send warnings) in almost all cases anyway, so mainly this
is a textual update, but there are some changes:
1. Send ERROR not WARNING if they send a malformed commitment secret.
2. Send WARNING not ERROR if they get the shutdown_scriptpubkey wrong (vs upfront)
3. Send WARNING not ERROR if they send a bad shutdown_scriptpubkey (e.g. p2pkh in future)
4. Rename some vars 'err' to 'warn' to make it clear we send a warning.
This means test_option_upfront_shutdown_script can be made reliable, too,
and it now warns and doesn't automatically close channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
This limit applies to both node_announcements (which we now send 1 per
day), and channel_updates; I've had reports of LND nodes going down
daily for database compation, so they end up ratelimited.
Changelog-Protocol: We now allow two channel_updates or node_announcements per day, up from 1.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
node_announcement has to follow at least one channel_announcement.
When channels close, if this isn't the case, we remove the old
node_announcement and put it at the end of the gossip_store.
But we lose the "send even if they don't want it" bit in the case it's
our own node_announceent, so keep it.
This only happens if you don't change your node configuration at all
since you opened your first channel, but still worth fixing.
We expose the force_node_announce_rexmit() for later use.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This restores the behaviour prior to `lightningd: use our cached
channel_update for errors instead of asking gossipd.`, where gossipd
would refuse to give us channel_updates for unannounced channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`hc` is never NULL, since it's `hc = &chan->half[direction];`;
we really meant "is it initialized", and valgrind under CI finally
caught it:
```
==69243== Conditional jump or move depends on uninitialised value(s)
==69243== at 0x11C595: handle_local_channel_update (gossip_generation.c:758)
==69243== by 0x115254: recv_req (gossipd.c:986)
==69243== by 0x128F8D: handle_read (daemon_conn.c:31)
==69243== by 0x16BEE1: next_plan (io.c:59)
==69243== by 0x16CAE9: do_plan (io.c:407)
==69243== by 0x16CB2B: io_ready (io.c:417)
==69243== by 0x16EE1E: io_loop (poll.c:453)
==69243== by 0x1154DA: main (gossipd.c:1089)
==69243==
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
Even if we're deferring putting them in the store and broadcasting them,
we tell lightningd so it will use it in any error messages.
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>
Increasingly we want to know is it local, and get the direction: it's
more efficient to do both at once.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>