When nodes receive HTLCs, they verify that the contents of those HTLCs
match the intructions that the sender provided in the onion. It is
important to ensure that intermediate nodes and final nodes have similar
requirements, otherwise a malicious intermediate node could easily probe
whether the next node is the final recipient or not.
Unfortunately, the requirements for intermediate nodes were more lenient
than the requirements for final nodes. Intermediate nodes allowed overpaying
and increasing the CLTV expiry, whereas final nodes required a perfect
equality between the HTLC values and the onion values.
This provided a trivial way of probing: when relaying an HTLC, nodes could
relay 1 msat more than what the onion instructed (or increase the outgoing
expiry by 1). If the next node was an intermediate node, they would accept
this HTLC, but if the next node was the recipient, they would reject it.
We update those requirements to fix this probing attack vector.
We also clarify `min_final_cltv_expiry`: this is actually a cltv_expiry_delta,
not an absolute cltv_expiry, so the field name should reflect that.
Recipients require incoming HTLC expiry to comply with that expiry delta.
Requirements for the htlc_maximum_msat field in channel_update were
inadvertently removed by #999 (this PR meant to make this field mandatory,
not removed explanations about what it does).
Since #910, nodes are allowed to use aliases instead of real scids. It is
helpful to make it explicit that updates using such aliases must not be
forwarded to other nodes by setting a flag in `channel_update`.
This flag is also generally useful for unannounced channels, regardless
of whether they use an scid alias or not.
We also make the `htlc_maximum_msat` field mandatory: every node on the
network currently sets it, so we can simplify the spec.
When a node creates a new `channel_update` to change its channel parameters,
it will take some time to propagate through the network and payers may use
older parameters. It is recommended to keep accepting older parameters for a
while to improve payment latency and reliability.
And `next_per_commitment_point` to explictly `second_per_commitment_point`;
this is particularly important since `channel_ready` can be retransmitted
after the channel has been in use, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Gossip query compression is not very useful - it was added for
mobile clients to, in theory, sync the gossip data directly from
P2P peers, but to my knowledge no mobile clients actually use it
for that, or at least use it where the gossip *query* data is a
substantial portion of their overall bandwidth usage.
Further, because of the semantics of `gossip_timestamp_filter`, its
impractical to ensure you receive a reliable, full view of the
gossip data without re-downloading large portions of the gossip
data on startup.
Ultimately, gossip queries are a pretty non-optimal method of
synchronizing the gossip data. If someone wants highly optimized
gossip data synchronization a new method based on set
reconciliation needs to be propose.
Finally, the current gossip query encoding semantics do not allow
for negotiation and instead require all lightning implementations
take a zlib dependency in some form or another. Given the recent
zlib decoding memory corruption vulnerability, this seems like an
opportune time to simply remove the zlib support, requiring that
nodes stop sending compressed gossip query data (though they can
support reading such gossip query data as long as they wish).
This is an alternative to the suggested gossip query encoding
support in #825.
This introduces a new gossip address descriptor type used for DNS hostnames.
This is particular useful for dynamic DNS users that want to use their home
ISP connection with changing IP addresses without relying only on TOR.
The `len` field is deliberately encoded with just a byte (u8) since
POSIX hostnames do not exceed 255 bytes in total.
And make most places warn or error. Places where we're operating
on a channel tend to be "warn and close connection" since we want to
forget the mistake they just sent, and closing the connection does that.
We now use the same words everywhere:
1. "fail channel" means to go onchain (if necessary).
2. "send `error`" means to send an error message.
3. "send `warning`" means to send a warning message.
4. "close connection" means close the connection.
These are all spelled out explicitly, rather than having "fail channel"
imply sending an error packet, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We previously insisted that `reply_channel_range` messages were not
overlapping: blocks content could not be split across multiple messages.
This made it possible to implicitly figure out when sync was complete, so we
re-purposed the previous `complete` field to a `full_information` field.
We now revert that change to allow blocks to be split across multiple
messages. An explicit flag is thus needed to signal that sync is complete.
Fixes#804
* Rename all the 'varint' to 'bigsize'.
Having both is confusing; we chose the name bigsize, so use it
explicitly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: use `byte` instead of `u8`.
`u8` isn't a type; see BOLT #1 "Fundamental Types".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: promote bigsize to a Fundamental Type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The introductory paragraph describes node discovery and channel
discovery, but changes the ordering. Keep the same ordering throughout
the paragraph for readability.
* Rename `complete` flag to `full_information` and provide rationale
This was confusing: the flag name made implementers *think* they
knew what it was for.
* Insist that reply_channel_range be adjacent and ordered
The current loose constraints causes confusion (and now all major
implementations meet the stricter requirements anyway).
You are allowed to provide more blocks than requested, but you have
to be complete and in order, and each reply has to have some overlap
with the requested range.
Its not uncommon to be multi-homed with different addresses, so we should probably allow nodes to do this. Also, it seems like this is pretty much universally not actually enforced on the network.
As more nodes on the network use timestamp_filter to block gossip
floods, we've seen some propagation problems. This should avoid it
(and is implemented now by c-lightning).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This appears to have been an oversight in the flat features spec,
and is somewhat implicitly relied on for several new feature bits -
if var_onion_optin is set on a node_announcement (its not allowed
on a channel_announcement), then trying to route through that node
using the pre-tlv formt is somewhat nonsensical, and should be
forbidden.
The feature fields refer to the properties of the channel/node, not the
message itself, so we can still propagate them (and should, to avoid
splitting the network).
If we want to make an incompatible announcement message, we'll use a
different type, or insert an even TLV type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We simply specify, in each case, where they will appear ("Context").
Because `globalfeatures` is already in use, we fold that into the
renamed `localfeatures` field to unify them (now called `features`),
but dissuade further use.
Note also: we REQUIRE minimal `features` field in
channel_announcement, since otherwise both sides of channel will not
agree and not be able to create their signatures!
Consider these theoretical future features:
`opt_dlog_chan`: a new channel type which uses a new discrete log HTLC
type, but can't support traditional HTLC:
* `init`: presents as odd (optional) or even (if traditional channels
not supported)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: presents as even (compulsory), since users need
to use the new HTLCs.
`opt_wumbochan`: a node which allows channels > 2^24 satoshis:
* `init`: presents as odd (optional), or maybe even (if you only want
giant channels)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: not present, since size of channel indicates
capacity.
`opt_wumbohtlc`: a channel which allows HTLCs > 2^32 millisatoshis:
* `init`: presents as odd (optional), or even (compulsory)
* `node_announcement`: the same as above, so you can seek suitable peers.
* `channel_announcement`: odd (optional) since you can use the channel
without understanding what this option means.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
* BOLT 7: fix cut & paste typo.
This is `reply_channel_range_tlvs`: `query_channel_range_tlvs` is defined
above. Somehow this fix got lost in the merge process, and breaks
our spec parsing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: add missing `encoding_type` field in query_short_channel_ids_tlvs / reply_channel_range_tlvs
The implementations have it, and the requirements refer to it,
but it's not actually in the description!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: clarify specification.
As agreed in http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-05-20.03.html,
checksums are not encoded as encoding_type + byte, but as a straight
array. Referring to them as `*byte` is thus underspecifying them:
they are literally `*channel_update_checksums`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Do not reply with a node_announcement if the query includes an optional query flag that does not request it.
The current wording could be interpreted as "always follow with node announcements whenever
you reply with a channel announcements" which defeats the point of using query flags (if you want the node
announcements just set the corresponding bits).
We use the more tool-friendly `...*` description for TLV extensions.
Checksums are now serialized as raw arrays, as using zlib compression here would not help.
Since some can be zero (missing updates), it's probably worth
doing the compression thing optionally.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Formatting changes only.
This make tools/extract-formats.py work (well, it misses some stuff
until the tlv-testcases merge, but then it's OK).
We use `tlvs` (for tlv stream), and we refer to TLV records as "being
included" rather than re-using the TLV name.
We even use subtypes for the pairs of checksums and timestamps.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Nodes that support extended queries will append an additional extended query flag to
their `query_channel_range` queries. If the receiver supports extended queries and
understands this flag, it will append the required additional data to its
`reply_channel_range` message.
There is currently only one type of additional data: one timestamp and one checksum
per `channel_update`.
The checksum is a CRC32 checksum computed over the `channel_update`
with `timestamp` and `signature` omitted.
Along with query_short_channel_ids extension, this can be used to
avoid querying `channel_updates` that are older than the ones you
already have, or that are newer but don't include new information.
Nodes can append additional data to their `query_short_channel_ids`
messages, which consists in one flag per short channel id and
specifies what they would like to receive (`node_announcement`,
`channel_announcement`, or/and one `channel_update` or both).
If a node sends its own `channel_update` to a peer node before receiving a `funding_lock`, the peer node may discard because it has not `short_channel_id` yet.
