This commit documents the allowance of non-strict
forwarding, permitting forwarding nodes to select
between any available outgoing channel with the peer
that would otherwise be specified by the
short_channel_id in the onion packet.
It also includes recommendations for fee schedules
when using non-strict forwarding, either by using
a uniform fee schedule with a peer or only
considering like-policied channels, to ensure the
channel is truly equivalent in terms of fee revenue
for the forwarder.
Technically this change may result in channels_announcements only
coming from one end. However, because c-lightning already implements
announcement_signatures in this way, in practice this will improve
reliability of channel_announcements.
[ After much bikeshedding, wording rewritten but same effect -- RR ]
Closes#468Closes: #474
Although commitment numbers are explained in the
[glossary](00-introduction.md#glossary-and-terminology-guide),
it's helpful to re-iterate at the place that it's first used.
To 'fail a channel' is mentioned multiple places in this
BOLT without any mention or definition of what that means.
This adds a link to the relevant text in BOLT 05 in the
first place that we mention 'fail the channel'.
ref. http://noiseprotocol.org/noise.html#dh-functions
The order of arguments of DH function is the order of private key, public key.
Made the same order.
This order is reflected in the expressions of `ee`, `se`, `es`, `ss`.
'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>
