mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 10:00:04 +01:00
Code Issues Projects Releases Wiki Activity

bolt04: Formatting cleanup and fold clarifications into conventions

Browse Source 
The clarifications were tacked on after the fact, but they should really be
part of the conventions. I also updated the links to use the reference style,
which results in better text flow and makes it easier to read the source.

Signed-off-by: Christian Decker <decker.christian@gmail.com>
This commit is contained in:
Christian Decker 2019-03-28 14:10:27 +01:00
parent 1810eaf4c8
commit 3ac0091ef9
1 changed files with 32 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
04-onion-routing.md
View File

@ -6,9 +6,8 @@ This document describes the construction of an onion routed packet that is
used to route a payment from an _origin node_ to a _final node_. The packet
is routed through a number of intermediate nodes, called _hops_.
The routing schema is based on the
[Sphinx](http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
construction and is extended with a per-hop payload.
The routing schema is based on the [Sphinx][sphinx] construction and is
extended with a per-hop payload.
Intermediate nodes forwarding the message can verify the integrity of
the packet and can learn which node they should forward the
@ -73,19 +72,17 @@ A node:
There are a number of conventions adhered to throughout this document:
- Length: the maximum route length is limited to 20 hops.
- HMAC: the integrity verification of the packet is based on Keyed-Hash
Message Authentication Code, as defined by the
[FIPS 198 Standard](http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf)/[RFC 2104](https://tools.ietf.org/html/rfc2104),
and using a `SHA256` hashing algorithm.
- Elliptic curve: for all computations involving elliptic curves, the
Bitcoin curve is used, as specified in [`secp256k1`](http://www.secg.org/sec2-v2.pdf).
- Pseudo-random stream: [`ChaCha20`](https://tools.ietf.org/html/rfc7539) is
used to generate a pseudo-random byte stream. For its generation, a fixed
null-nonce (`0x0000000000000000`) is used, along with a key derived from a
shared secret and with a `0x00`-byte stream of the desired output size as the
Message Authentication Code, as defined by the [FIPS 198
Standard][fips198]/[RFC 2104][RFC2104], and using a `SHA256` hashing
algorithm.
- Elliptic curve: for all computations involving elliptic curves, the Bitcoin
curve is used, as specified in [`secp256k1`][sec2]
- Pseudo-random stream: [`ChaCha20`][rfc7539] is used to generate a
pseudo-random byte stream. For its generation, a fixed null-nonce
(`0x0000000000000000`) is used, along with a key derived from a shared
secret and with a `0x00`-byte stream of the desired output size as the
message.
- The terms _origin node_ and _final node_ refer to the initial packet sender
and the final packet recipient, respectively.
- The terms _hop_ and _node_ are sometimes used interchangeably, but a _hop_
@ -94,14 +91,13 @@ There are a number of conventions adhered to throughout this document:
- The term _processing node_ refers to the specific node along the route that is
currently processing the forwarded packet.
- The term _peers_ refers only to hops that are direct neighbors (in the
overlay network): more specifically, _sending peers_ forward packets to
_receiving peers_.
_sending peer_ --> _receiving peer_
# Clarifications
The longest route supported has 20 hops without counting the _origin node_ and _final node_, thus 19 _intermediate nodes_ and a maximum of 20 channels to be traversed.
overlay network): more specifically, _sending peers_ forward packets
to _receiving peers_.
- Each hop in the route has a variable length `hop_payload`, or a fixed-size
legacy `hop_data` payload.
- The legacy `hop_data` is identified by a single `0x00`-byte prefix
- The variable length `hop_payload` is prefixed with a `varint` encoding
the length in bytes, excluding the prefix and the trailing HMAC.
# Key Generation
@ -1114,3 +1110,10 @@ The same parameters (node IDs, shared secrets, etc.) as above are used.
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
[sphinx]: http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
[RFC2104]: https://tools.ietf.org/html/rfc2104
[fips198]: http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
[sec2]: http://www.secg.org/sec2-v2.pdf
[rfc7539]: https://tools.ietf.org/html/rfc7539