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
`channel_update` does not make sense as it does not have fields
with either addresses or ports.
Moved it to `node_announcement` on the assumption that the text
was just inserted in the wrong place, since `node_announcement`
is described before `channel_update` and does have addresses
and ports.
At cost of a few extra bytes between peers, this avoids the whole "oops, we were on a chain fork" problem, and simplifies generation of temporary channel-ids (just pick a random one).
Now we move the announcement_signature exchange to at least 6 confirms, which makes re-xmit tricky; I resolved that by insisting on reconnect that we send if we haven't received, and reply to the first one.
The term "channel shortid" wasn't used anywhere, so I removed it; it's now a gossip-only thing anyway.
One subtle change: pkt_error on unknown channels is now "MUST ignore"; this section was reworked anyway, and we'll want this if the #120 goes through, where one side might have forgotten unformed channels).
Closes: #114
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Two bytes for funding-output-index.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Channel-id rework, temp ids, 32 bits only.
Re-add the idea of temporary channel ids: far simpler since they're now
big enough we can just fill with noise.
Remove the alignment issues by combining txid and outnum using XOR; we
could reduce to 128 bit if we really wanted to, but we don't.
Error handling is now simple again, but while editing I changed the
behaviour for unknown channels to MUST ignore (this is important for
Change the 8-byte gossip channel id to `short-channel-id`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Minor text tweaks from Pierre-Marie and Christian
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Christian assumed first bit was 1, I assumed 0. And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.
By giving names we avoid smearing values over the spec, containing them in
BOLT 9.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 2&7: Cleaner separation of concerns wrt announcement signatures
So far we did not have any indication on what to do if a node does not
allow announcing the channel and we had a mix of concerns in the
`funding_locked` message, which would also transfer the signatures
needed for the announcement. This is a proposal about splitting the
signatures into their own message, so that simple omission is an
opt-out of announcements, and it does not mix announcement/gossip
stuff into the peer-protocol.
(It also ended up adding a localfeatures flag to opt-into the channel-announcement, and thus creating BOLT 9)
Reorders the `channel-id` and `bitcoin-signature-x` fields so that the
signed part of the message is contiguous. Simplifies the signing logic
not to just simple signatures of a contiguous region of the message,
no need to sign signatures, they all commit to the same payload. This
also removes the chicken and egg problem @pm47 reported in #92.
Furthermore it specifies that the signed payload also includes any
future appended fields.
This lets us have both IPv4 and IPv6 (and Tor etc in future) address,
while still preserving the ability to add other fields to the message
in future.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Inspired by Andrew Samokhvalov's PR, this makes the relationship
between the signatures in `channel_announcement` explicit.
Closes: #27
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We could spam the network with 64k announcements, and each node has to
rememeber them for rebroadcasting. There's a tradeoff between
allowing future expansions and this potential DoS, so allow nodes to
choose.
My current implementation thinking is: each extra byte reduces chance
of rebroadcast by a small amount, such that if you're twice the
minimum size your chance of rebroadcast hits 0.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The sending side says it needs to bitcoin-style sign double-SHA, but the
receiving side doesn't. Make it clear.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us gain 7 more bits, but also as Christian points out, you need
to remember the padding for re-broadcast since the signature covers it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The MSG_XXX is trivially derived from the name of the message if
people want to do that, so just change it to the actual message name.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means they cover future fields as well (which may or may not be good!)
but also ensures they're naturally aligned in case anyone cares.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
