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.
This commit adds a 32-byte `chain_hash` value to both the
`channel_update` and `channel_announcement` messages. The rationale for
this change is that this value is already present within the
`open_channel` for identifying _which_ chain to open the channel
within. As is now, if a pair of peers had channels open on two chains
which somehow are encoded using the same `short_channel_id`, then the
announcements would be ambitious. We resolve this by explicitly
including the `chain_hash` is all channel related announcement
messages.
Note that with this change, we now require 40-bytes to uniquely
identify a channel globally.
Additionally, this modification of the channel announcement messages
allows peers to start building up a heterogenous network graph.
This is a recommendation to fuzz the CLTV on the HTLCs such that nodes
along the route have a harder time identifying the intended
recipient. We can either add a random offset or we can start a random
walk from the intended recipient and create a shadow route extension.
Closes#185
Appending new fields to the end of the messages allows us to add new
fields to an existing message, however it does not allow removing
existing fields, e.g., dropping the pubkeys like #187 proposes. Moving
the features bitmap at the beginning of the signed payload allows
this type of change in the future. Nodes verify the integrity of the
message and then check whether there are any even bits they don't
implement. These even bits being required features would then result
in the message being discarded.
In addition to what we discussed during the call I also went ahead and
did the same reordering on `node_announcement`, which I think has the
same issue.
There is a subtle change in semantics, i.e., previously we would
add channels with unknown bits to our local view, but then ignore them
when computing a route. Now we no longer add them to our view, and may
discard the announcement altogether, stopping the broadcast. This is
safe I think since otherwise we'd be forwarding things we can only
verify the signatures of, but nothing else.
This was pointed out by @btcontract in #188: we need to communicate
our forwarding parameters even for private channels since otherwise
the other endpoint cannot use the private channel for incoming
routes. So we also accept `channel_update`s for our own channels even
for channels that were not announced publicly. Adds a bit of special
handling for our own channels in the gossip, but it is needed since
private channels would be completely unusable otherwise.
Explicitly mentions that nodes SHOULD monitor the chain for channel
closes, and that a node MAY be removed if no open channels for that
node remain open.
Also mentions the 2 week lazy pruning we discussed on the call.
Closes#186
This commit gives peers the ability to signal their intent to make a
channel private in the `open_channel` message. This differs from the
current method as now peers are able to create multiple channels with
heterogeneous announcement policies _without_ disconnecting and
re-connecting in-between each channel funding. The prior requirement
for the nodes to re-connect was burdensome and unnecessary.
[ Minor tweaks from feedback folded in -- RR ]
We had 4 byte fields for amounts because people have no ability to assess
risk, and this limited the damage to $70 at a time.
But then that means $1 maximum HTLCs on Litecoin, which isn't enough
for a cup of (decent) coffee.
Rather than have boutique hacks for Litecoin we enlarge the fields now,
and simply have a bitcoin-specific restriction that the upper 4 bytes be 0.
The ctlv_expiry field is moved down in update_add_htlc, to preserve alignment.
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit extends the set of define address descriptor types to
include support for v2 (current-gen) and v3 (next-gen) onion service
addresses. This enables user to run their Lightning nodes as onion
services, only accepting in-bound connections via their onion
addresses. Running a Lightning node behind Tor may serve to boost the
privacy of a user as they no longer need to give away their location
when advertising their node as willing to accept in-bound connections.
The current generation onion service address are widely deployed and
similar looking. They consume 10-bytes of space as they are the SHA-1
hash of a 1024-bit RSA public key. Encoding using base-32, they look
like: v2cbb2l4lsnpio4q.onion.
The next-generation onion services addresses are defined within
prop224[1]. These addresses are a bit longer as they includes a full
e25519 public key (32-bytes), a 2-byte checksum, and finally a 1 byte
version. The full length of the raw version of these addresses are
35-bytes. When encoded using base-32, then next-gem onion address look
like: btojiu7nu5y5iwut64eufevogqdw4wmqzugnoluw232r4t3ecsfv37ad.onoin.
[1]:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-n
g.txt
