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

fixup! bolt04: Introduce the notion of frames and make payloads variable

Browse Source
This commit is contained in:
Christian Decker 2019-05-13 23:34:25 +02:00
parent 54d6e1aeeb
commit 5c9b0ebc5a
No known key found for this signature in database
GPG Key ID: 1416D83DC4F0E86D
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
04-onion-routing.md
View File

@ -188,9 +188,9 @@ Each `hop_payload` has the following structure:
Notice that since the `hop_payload` is instantiated once per hop, the subscript `_i` may be used in the remainder of this document to refer to the `hop_payload` and its fields destined for hop `i`. Notice that since the `hop_payload` is instantiated once per hop, the subscript `_i` may be used in the remainder of this document to refer to the `hop_payload` and its fields destined for hop `i`.
The `hop_payload` consists of at least one `frame` followed by up to 15 additional `frame`s. The `hop_payload` consists of at least one `frame` followed by up to 19 additional `frame`s.
The number of additional frames allocated to the current hop is determined by the 4 most significant bits of `num_frames_and_realm`, while the 4 least significant bits determine the payload format. The number of additional frames allocated to the current hop is determined by the 5 most significant bits of `num_frames_and_realm`, while the 3 least significant bits determine the payload format.
Therefore the number of frames allocated to the current hop is given by `num_frames = (num_frames_and_realm >> 4) + 1`. Therefore the number of frames allocated to the current hop is given by `num_frames = (num_frames_and_realm >> 3) + 1`.
For simplification we will use `hop_payload_len` to refer to `num_frames * FRAME_SIZE`. For simplification we will use `hop_payload_len` to refer to `num_frames * FRAME_SIZE`.
In order to have sufficient space to serialized the `raw_payload` into the `hop_payload` while minimizing the number of used frames the number of frames used for a single `hop_payload` MUST be equal to In order to have sufficient space to serialized the `raw_payload` into the `hop_payload` while minimizing the number of used frames the number of frames used for a single `hop_payload` MUST be equal to
@ -200,7 +200,7 @@ In order to have sufficient space to serialized the `raw_payload` into the `hop_
The payload format determines how the `raw_payload` should be interpreted (see below for currently defined formats), and how much padding is added. The payload format determines how the `raw_payload` should be interpreted (see below for currently defined formats), and how much padding is added.
In order to position the `HMAC` in the last 32 bytes of the `hop` the `raw_payload` MUST be followed by `padding_len = (num_frames * FRAME_SIZE - 1 - raw_payload_len - 32)` `0x00`-bytes. In order to position the `HMAC` in the last 32 bytes of the `hop` the `raw_payload` MUST be followed by `padding_len = (num_frames * FRAME_SIZE - 1 - raw_payload_len - 32)` `0x00`-bytes.
The `realm` is specified as `num_frames_and_realm & 0x0F`. The `realm` is specified as `num_frames_and_realm & 0x07`.
It determines the format of the `raw_payload` field; the following `realm`s are currently defined. It determines the format of the `raw_payload` field; the following `realm`s are currently defined.
| `realm` | Payload Format | | `realm` | Payload Format |