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.
