From 3c93b4f589d690e5e2892da11ee1acbefc18cbc3 Mon Sep 17 00:00:00 2001 From: Dimitris Tsapakidis Date: Wed, 6 Dec 2017 23:15:02 +0200 Subject: [PATCH] Fixed typos Fixed various typos in multiple documents. --- 04-onion-routing.md | 6 +++--- 08-transport.md | 2 +- 11-payment-encoding.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index 177df7342..71d7b0b69 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -2,7 +2,7 @@ ## Overview -This document describes the construction of an onion routed packet that is used to route a payment from a _origin node_ to a _final node_, over a number of intermediate nodes, called _hops_. +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_, over a number of intermediate nodes, called _hops_. The routing schema is based on the [Sphinx](http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) @@ -320,7 +320,7 @@ Comparison of the computed HMAC and the HMAC from the packet MUST be time-consta At this point the node can generate a _rho_-key and a _gamma_-key. The routing info is deobfuscated and the information about the next hop is extracted. -In order to do so the node copies the `hops_data` field, appends 65 `0x00` bytes and generates 1365 pseudo-random bytes using the _rho_-key and applies it using `XOR` to the copy of the `hops_data` +In order to do so the node copies the `hops_data` field, appends 65 `0x00` bytes and generates 1365 pseudo-random bytes using the _rho_-key and applies it using `XOR` to the copy of the `hops_data`. The first 65 bytes of the resulting routing info are `per_hop` field for the next hop. The next 1300 bytes is the `hops_data` for the outgoing packet. If the `realm` is unknown, then the node MUST drop the packet and signal a route failure. @@ -450,7 +450,7 @@ The failure message encapsulated in `failuremsg` has identical format to a normal message: two byte type (`failure_code`) followed by data suitable for that type. The following `failure_code` values are supported. A node MUST select one of these codes when creating an error message, and MUST include the appropriate data. -Notice that the `failure_code` are not message types defined in other BOLTs, not being sent directly on the transport layer, but wrapped inside an return packet. +Notice that the `failure_code` are not message types defined in other BOLTs, not being sent directly on the transport layer, but wrapped inside a return packet. The numeric values for the `failure_code` may therefore reuse values that are also assigned as message types, without causing collisions. In the case of more than one error, a node SHOULD select the first one diff --git a/08-transport.md b/08-transport.md index 9d6182cd2..316e23467 100644 --- a/08-transport.md +++ b/08-transport.md @@ -497,7 +497,7 @@ The *maximum* size of _any_ lightning message MUST NOT exceed `65535` bytes. A maximum size of `65535` simplifies testing, makes memory management easier and helps mitigate memory exhaustion attacks. -In order to make make traffic analysis more difficult, the length prefix for +In order to make traffic analysis more difficult, the length prefix for all encrypted lightning messages is also encrypted. Additionally we add a `16-byte` `Poly-1305` tag to the encrypted length prefix in order to ensure that the packet length hasn't been modified with in-flight, and also to avoid diff --git a/11-payment-encoding.md b/11-payment-encoding.md index cafe8d533..e3c46bf7b 100644 --- a/11-payment-encoding.md +++ b/11-payment-encoding.md @@ -22,7 +22,7 @@ encoding. ## Requirements -A writer MUST encode the the payment request in Bech32 as specified in +A writer MUST encode the payment request in Bech32 as specified in BIP-0173, with the exception that the Bech32 string MAY be longer than the 90 characters specified there. A reader MUST parse the address as Bech32 as specified in BIP-0173 (also without the character limit),