'final' and 'endpoint' node don't make much sense out of
context of a payment (in the former case) or when referring to
a non-channel party node. this fixes this
The Initial Sync section is hard to parse, as is, because it's presented
without context. This adds a small clarifying statement, in particular
highlighting where the mode is triggered from (init message features)
and what in particular is being synced (gossip messages)
This optional padding makes it very difficulty to deserialize
node_announcements into internal structs for storage and then
reconstruct the original node_announcement, plus are unused on the
network today and no known implementations construct
node_announcement messages with them.
The fee calculation in BOLT 7 appears to imply that proprtional
fees must be paid on the incoming amount, not the to_forward amount
This is inconsistent with what is actually implemented in the
field (which uses amount_to_forward) and also would make
pathfinding more complicated as the fee would depend on itself,
making calculation no longer simple.
This helps lite nodes a little, but also gives a way of advertising a
lesser capacity than implied onchain.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ Note: in retrospect, adding this in the initial draft without its
own feature bit was a mistake. It was a premature optimization,
adds complexity and removes the ability to disable it if a problem
is found without disabling gossip_queries entirely. However, it
is already deployed as-is. --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ This was a joint effort by many people, with iterations not
indicated in this final commit: thanks to all who reviewed and
polished! Particularly: @jimpo @cdecker @sstone @ZmnSCPxj ]
This enables three new functions:
1. query_short_channel_ids: they will send channel_announcement /
channel_update / node_announcement followed by reply_short_channel_ids_done.
2. query_channel_range: they will send one or more reply_channel_range
with the short_channel_ids in these blocks.
3. gossip_timestamp_filter: filters what gossip they send.
It also changes behavior: we no longer send a `channel_announcement`
until we have at least one `channel_update`. The announcement is
fairly useless without an update already, but this in particular
enables reasonable timestamp filtering (channel_announcement does not
have an explicit timestamp).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As agreed at the previous meeting, we use the timestamp to prune,
so it does have to be a valid timestamp. We also suggest ignoring
if it's in the far future, too.
The minutes suggest we can prune for any reason, and that's really
true anyway; the requirements to keep it around are only SHOULD.
Note that this only applies to channel_update: node_announces
are not pruned (except, perhaps, by implication when all channels
are pruned)
Closes: #302
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a consequence of commit d1fbfd30f8: we now only use *outgoing* `channel_update` messages to build a route.
Basically the node publishing the `channel_update` says: I can only send htlcs > `htlc_minimum_msat` through this channel.
I think this is consistent with the current definition of the `amount_below_minimum` error (BOLT 4):
> If the HTLC does not reach the current minimum amount, we tell them the amount of the incoming HTLC and the current channel setting for the outgoing channel:
* BOLT 7: mention Tor hidden service.
This is a common term to search for, rather than onion address (which is
what Tor hidden services use).
Reported-by: Alan Manuel K. Gloria <almkglor@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Complete rewrite, including a routing example and the new
min_final_cltv expirt. I hope this makes it clear.
(Thanks to everyone who reviewed and gave feedback; you rock!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added an optional `c` field in the payment request specifying the
minimum `cltv_expiry` to use for the last htlc in the route. If
not provided, default value is 9.
This commit also clarifies how `channel_update` messages are only
to be used in the context of relaying payments, and how both htlc
amounts and expiries are to be calculated backwards from the values
provided in the payment request.
Not needing the `channel_update` for the first channel in a route also
means that it is possible to make a payment through a channel which
hasn't had any announcements yet.
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.
This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
