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.
1. Change descriptions of closing tx construction to references to BOLT 3.
2. Recipient *should* check the fee offer has improved in closing_signed.
3. Therefore, sender *must* improve closing offer.
4. Offers do not persist across reconnection, so no state req'd, and
also helps if fee has changed.
5. You don't need to re-send `shutdown` if you received `closing_signed`
(implicit acknowledgement).
6. You don't have to accept a `channel_reestablish` which requests the last
revoke_and_ack be retransmitted if you've already received `closing_signed`
(which is an implicit acknowledgement).
Closes: #201Closes: #199
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The only surprise here (maybe?) is that we use the commitment number encoding.
I think that makes sense, but it was unspecified before.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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
We reuse the numeric values that we previously assigned to message
types in the failure_code, but there is no possibility for a mixup
since the latter is not transmitted directly on the transport layer
but wrapped in a return packet. Hence there is no way of confusing the
two. Added a short clarification.
Reported-by: Janus Troelsen @ysangkok
Signed-off-by: Christian Decker <decker.christian@gmail.com>
* BOLT 11: fix formatting typo, and `r` length value.
The r field is 408 bytes long, which is 82 characters encoded;
this should have been updated when the fee and cltv sizes were
updated (prior to merge into repo).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 11: `channel_id`->`short_channel_id`
This changes extract-formats.py so that other scripts can use it, but retains normal functionality.
The new script (structured.py) parses the CSV variant and shows a representation of an OrderedMap.
This could be used to write parsers.
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.
Consistency with BOLT 7 makes this much clearer.
Closes: #195
Reported-by: https://github.com/nayuta-ueno
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The actual fee of the final tx may include eliminated outputs, which can
differ between one side and the other (since they have different thresholds).
Simplify this corner case by using our base fee calculation as the upper bound;
it should be close enough we don't care, but disagreement here could cause
negotiation breakdown.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't eliminate an output and also guarantee a certain fee, so
we need to define exactly how to do this.
Since the output is (presumably) dust, we might as well just discard it
(effectively increasing the fee). This avoids the peer directly benefiting
from the elimination as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 adds a message for each channel reconnect (after we've
sent/received `funding_signed`, ie. when we rememeber the channel),
which says exactly how many `commitment_signed` and `revoke_and_ack`
we've received. Really, we could use one bit for each (they could
only be missing the last one), but better to be clear.
This leaves the "rollback if didn't get commitment_signed"
requirement, but avoids any need to handle update duplicates or wonder
what update number a `commitment_signed` applies to after reconnect.
Many thanks to pm47 and roasbeef especially for constructive feedback
which made this far better than I originally had.
Closes: #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can't do that, so allow "write, then send". That fails on the side of
timing out, rather than having a channel which can't be used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes the feature bit for channels_public as they have
been deprecated by the addition of the `announce_channel` field in the
`open_channel` message.
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 ]
This commit modifies the “Normal Operation” summarization by including
a link to BOLT #7 when mentioning the `announcement_signature` message.
Previously a reader would need to search other documents to figure out
what an `announcement_signature` was, and its purpose.
This is based on a series of patches from @EmelyanenkoK which makes the treatment of feature bits clearer and adds rationale so that future extensions can be made wisely.
Thanks to all involved!
Closes: #156
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 attempts to clarify some ambiguity in the way the
revocation key derivation was formerly described. Rather than framing
the description in terms of local vs remote nodes, we instead frame the
description around the _process_ of creating a new commitment
transaction for a remote node,
[ minor typos and remove weird part-sentence -- RR ]
Specify the payload for the last node in the route and how it is used to return
errors. The idea is to prevent the next to last node to guess if the next node is
the final one.
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
1. Tell the node when to broadcast the funding tx (we didn't do this!).
2. Allow timeouts generally if no progress is made (originally this
was just when waiting for funding_locked, but it applies generally).
3. Use `funding_signed` as the commitment point: before this, we forget,
after this, we remember. If lost, we'll timeout.
4. The core of the retransmission requirements now only applies to
the normal and shutdown states, and will be revised separately
depending on #172
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We talk about failing a channel, or channels, but we never spelled
out what a node does in that case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
