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>
I was trying to compactly indicate that the considered alternative to
multiplier postfixes was just express everything in millisatoshi, but
it's just confusing, and anyway there are other notations we didn't use
so it seems like a weird thing to explain.
Reported-by: @cdecker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
a.k.a. landonmutch style, where requirements are explicit and bullet-pointed.
This also tightens requirements:
1. New requirement (previously implied) that writer use correct prefix.
2. Reader MUST rather than SHOULD fail malformed `amount`.
It also makes it clear that writer can omit the multiplier.
Fixes: #442
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>
We're about to introduce new messages which are gated by options (not
just single fields). Ignore them for the purposes of parsing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Obviously you can't include fields you don't understand, but importantly
if the other side doesn't agree, you don't need to include them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Some embarssing typos there! Anywho, here are you fixes.
I am out of town next week, but after I get back I will have some definite time on my schedule, and can draft an intro for the spec, if we're comfortable with all the terms here.
This is a big change to the glossary in BOLT-0.
The overarcing changes are:
1.) Reorganized glossary to be alphabetical
2.) Add copious "See also:" lines to cross-reference containers, contents, and other related entries.
*Changed Definitions:* Peer and node were revised based in on discussions with Rusty; commitment revocation secret key was changed to be commitment revocation private key based on #377.
*New Definitions:* New words added based on their usage in the bolts were: announcement, closing transaction, final node, hop, origin node, processing, node, receiving node, receiving peer, revoked commitment transaction, sending node, sending peer.
(I suspect the reorg will make the diffs almost useless, so this is the list of stuff to look at.)
Clarify the query semantics in BOLT #10 by briefly exemplifying how to pass the conditions to the DNS seed server.
Establish some rules for how a DNS seed is expected to parse conditions and handle possible conflicts (in case a key is repeated in multiple condition key-value pairs).
