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>
This commit fixes an advisory error in the current spec draft. We
currently use `fee-per-kw` where `kw = 1000` weight to determine the
proper fee to pay for commitment transactions. Currently, the spec
advises implementer to take the typical sat/Kb at _multiply_ by 4. This
will result in implementations overpaying for commitment transactions
as the scaling should actually be in the _opposite_ direction. As the
weight is scaled up by 4, for fee-per-kw should be scaled down by 4.
So: sat/Kb * 1/4, instead of sat/Kb * 4.
[Minor fixup: "1/4th" to "1/4", better english, and doesn't trip spellcheck. -- RR]
Not all of them: sometimes we refer to to-self including HTLCs which we're
spending ourselves, but in three places we're explicitly referring to
the `to_local` output.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Plus a few more missing ones, and some consistency fixes in names
as pointed out by Roasbeed and Fabrice.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
One minor change to refer to field name:
preserves `to_self` delay
to:
preserves `to_self_delay` requirement.
Typo fixes:
1. revocation -> revoke_and_ack
2. ctlv_expiry -> cltv_expiry.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This also converts data structures to the same format used elsewhere.
One other minor change, from:
In addition, every _(address, HMAC)_-pair is incrementally obfuscated at each hop.
to:
In addition, `hops_data` is incrementally obfuscated at each hop.
The old wording was left over from the previous format.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`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.
