mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 01:50:03 +01:00
Bolt 04: fix a few left-over spelling / clean-up nits (#653)
* Fix a few left-over spelling / clean-up nits * Bolt 09: fix spec links
This commit is contained in:
Bastien Teinturier
GitHub
parent
44c6071d18
commit
8b2cf00546
@ -58,12 +58,6 @@ A node:
|
||||
* [Failure Messages](#failure-messages)
|
||||
* [Receiving Failure Codes](#receiving-failure-codes)
|
||||
* [Test Vector](#test-vector)
|
||||
* [Packet Creation](#packet-creation)
|
||||
* [Parameters](#parameters)
|
||||
* [Per-Hop Information](#per-hop-information)
|
||||
* [Per-Packet Information](#per-packet-information)
|
||||
* [Wrapping the Onion](#wrapping-the-onion)
|
||||
* [Final Packet](#final-packet)
|
||||
* [Returning Errors](#returning-errors)
|
||||
* [References](#references)
|
||||
* [Authors](#authors)
|
||||
@ -151,7 +145,7 @@ The overall structure of the packet is as follows:
|
||||
2. data:
|
||||
* [`byte`:`version`]
|
||||
* [`point`:`public_key`]
|
||||
* [`1300*byte`:`hops_data`]
|
||||
* [`1300*byte`:`hop_payloads`]
|
||||
* [`32*byte`:`hmac`]
|
||||
|
||||
For this specification (_version 0_), `version` has a constant value of `0x00`.
|
||||
@ -187,7 +181,7 @@ The `length` field determines both the length and the format of the `hop_payload
|
||||
## Legacy `hop_data` payload format
|
||||
|
||||
The `hop_data` format is identified by a single `0x00`-byte length, for backward compatibility.
|
||||
It's payload is defined as:
|
||||
Its payload is defined as:
|
||||
|
||||
1. type: `hop_data` (for `realm` 0)
|
||||
2. data:
|
||||
@ -210,7 +204,7 @@ Field descriptions:
|
||||
then the HTLC should be rejected as it would indicate that a prior hop has
|
||||
deviated from the specified parameters:
|
||||
|
||||
incoming_htlc_amt - fee >= amt_to_forward
|
||||
incoming_htlc_amt - fee >= amt_to_forward
|
||||
|
||||
Where `fee` is either calculated according to the receiving peer's advertised fee
|
||||
schema (as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
|
||||
@ -219,7 +213,7 @@ Field descriptions:
|
||||
* `outgoing_cltv_value`: The CLTV value that the _outgoing_ HTLC carrying
|
||||
the packet should have.
|
||||
|
||||
cltv_expiry - cltv_expiry_delta >= outgoing_cltv_value
|
||||
cltv_expiry - cltv_expiry_delta >= outgoing_cltv_value
|
||||
|
||||
Inclusion of this field allows a hop to both authenticate the information
|
||||
specified by the origin node, and the parameters of the HTLC forwarded,
|
||||
@ -261,7 +255,6 @@ The writer:
|
||||
- MUST include `amt_to_forward` and `outgoing_cltv_value` for every node.
|
||||
- MUST include `short_channel_id` for every non-final node.
|
||||
- MUST NOT include `short_channel_id` for the final node.
|
||||
- MUST include the `destination_signal` for the final node.
|
||||
|
||||
The reader:
|
||||
- MUST return an error if `amt_to_forward` or `outgoing_cltv_value` are not present.
|
||||
@ -422,18 +415,18 @@ following operations:
|
||||
bytes that exceed its 1300-byte size.
|
||||
- The varint-serialized length, serialized `hop_payload` and `HMAC` are copied into the following `shift_size` bytes.
|
||||
- The _rho_-key is used to generate 1300 bytes of pseudo-random byte stream
|
||||
which is then applied, with `XOR`, to the `hops_data` field.
|
||||
which is then applied, with `XOR`, to the `hop_payloads` field.
|
||||
- If this is the last hop, i.e. the first iteration, then the tail of the
|
||||
`hops_data` field is overwritten with the routing information `filler`.
|
||||
`hop_payloads` field is overwritten with the routing information `filler`.
|
||||
- The next HMAC is computed (with the _mu_-key as HMAC-key) over the
|
||||
concatenated `hops_data` and associated data.
|
||||
concatenated `hop_payloads` and associated data.
|
||||
|
||||
The resulting final HMAC value is the HMAC that will be used by the first
|
||||
receiving peer in the route.
|
||||
|
||||
The packet generation returns a serialized packet that contains the `version`
|
||||
byte, the ephemeral pubkey for the first hop, the HMAC for the first hop, and
|
||||
the obfuscated `hops_data`.
|
||||
the obfuscated `hop_payloads`.
|
||||
|
||||
The following Go code is an example implementation of the packet construction:
|
||||
|
||||
@ -538,7 +531,7 @@ necessary, in order to constrain the worst-case storage requirements or false
|
||||
positives of this log.
|
||||
|
||||
Next, the processing node uses the shared secret to compute a _mu_-key, which it
|
||||
in turn uses to compute the HMAC of the `hops_data`. The resulting HMAC is then
|
||||
in turn uses to compute the HMAC of the `hop_payloads`. The resulting HMAC is then
|
||||
compared against the packet's HMAC.
|
||||
|
||||
Comparison of the computed HMAC and the packet's HMAC MUST be
|
||||
@ -998,7 +991,19 @@ The _origin node_:
|
||||
|
||||
## Returning Errors
|
||||
|
||||
The same parameters (node IDs, shared secrets, etc.) as above are used.
|
||||
The test vectors use the following parameters:
|
||||
|
||||
pubkey[0] = 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619
|
||||
pubkey[1] = 0x0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c
|
||||
pubkey[2] = 0x027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007
|
||||
pubkey[3] = 0x032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991
|
||||
pubkey[4] = 0x02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145
|
||||
|
||||
nhops = 5/20
|
||||
sessionkey = 0x4141414141414141414141414141414141414141414141414141414141414141
|
||||
associated data = 0x4242424242424242424242424242424242424242424242424242424242424242
|
||||
|
||||
The following is an in-depth trace of an example of error message creation:
|
||||
|
||||
# node 4 is returning an error
|
||||
failure_message = 2002
|
||||
@ -1035,6 +1040,12 @@ The same parameters (node IDs, shared secrets, etc.) as above are used.
|
||||
|
||||
# References
|
||||
|
||||
[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
|
||||
|
||||
# Authors
|
||||
|
||||
[ FIXME: ]
|
||||
@ -1042,10 +1053,3 @@ The same parameters (node IDs, shared secrets, etc.) as above are used.
|
||||
|
||||
<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
|
||||
|
||||
@ -20,20 +20,20 @@ see [BOLT #1: The `init` Message](01-messaging.md#the-init-message).
|
||||
|
||||
These flags may only be used in the `init` message:
|
||||
|
||||
| Bits | Name | Description | Link |
|
||||
|------|----------------------------------|---------------------------------------------------------------------------|------------------------|
|
||||
| 0/1 | `option_data_loss_protect` | Requires or supports extra `channel_reestablish` fields | [BOLT #2][bolt02] |
|
||||
| 3 | `initial_routing_sync` | Indicates that the sending node needs a complete routing information dump | [BOLT #7][bolt07] |
|
||||
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | [BOLT #2][bolt02open] |
|
||||
| 6/7 | `gossip_queries` | More sophisticated gossip control | [BOLT #7][bolt07query] |
|
||||
| Bits | Name | Description | Link |
|
||||
|------|----------------------------------|---------------------------------------------------------------------------|------------------------------|
|
||||
| 0/1 | `option_data_loss_protect` | Requires or supports extra `channel_reestablish` fields | [BOLT #2][bolt02-retransmit] |
|
||||
| 3 | `initial_routing_sync` | Indicates that the sending node needs a complete routing information dump | [BOLT #7][bolt07-sync] |
|
||||
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | [BOLT #2][bolt02-open] |
|
||||
| 6/7 | `gossip_queries` | More sophisticated gossip control | [BOLT #7][bolt07-query] |
|
||||
|
||||
## Assigned `globalfeatures` flags
|
||||
|
||||
The following `globalfeatures` bits are currently assigned by this specification:
|
||||
|
||||
| Bits | Name | Description | Link |
|
||||
|------|-------------------|-------------------------------------------------------------|---------------------------------------|
|
||||
| 8/9 | `var_onion_optin` | This node requires/supports variable payload routing onions | [routing onion specification][bolt04] |
|
||||
| Bits | Name | Description | Link |
|
||||
|------|-------------------|--------------------------------------------------------------------|---------------------------------------|
|
||||
| 8/9 | `var_onion_optin` | This node requires/supports variable-length routing onion payloads | [Routing Onion Specification][bolt04] |
|
||||
|
||||
|
||||
## Requirements
|
||||
@ -51,8 +51,9 @@ interpret the flag, as defined in the initial spec.
|
||||
|
||||
<br>
|
||||
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
|
||||
[bolt02]: 02-peer-protocol.md#message-retransmission
|
||||
[bolt02open]: 02-peer-protocol.md#the-open_channel-message
|
||||
|
||||
[bolt02-retransmit]: 02-peer-protocol.md#message-retransmission
|
||||
[bolt02-open]: 02-peer-protocol.md#the-open_channel-message
|
||||
[bolt04]: 04-onion-routing.md
|
||||
[bolt07]: 07-routing-gossip.md#initial-sync
|
||||
[bolt07query]: 07-routing-gossip.md#query-messages
|
||||
[bolt07-sync]: 07-routing-gossip.md#initial-sync
|
||||
[bolt07-query]: 07-routing-gossip.md#query-messages
|
||||
|
||||
Loading…
Reference in New Issue
Block a user