From 3476c9b25a4e4781aab5eec89cbd1511c4017996 Mon Sep 17 00:00:00 2001 From: Dimitris Apostolou Date: Wed, 25 Sep 2019 13:34:18 +0300 Subject: [PATCH] Fix typos --- .copy-edit-stylesheet-checklist.md | 2 +- 01-messaging.md | 2 +- 02-peer-protocol.md | 2 +- 07-routing-gossip.md | 4 ++-- 11-payment-encoding.md | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.copy-edit-stylesheet-checklist.md b/.copy-edit-stylesheet-checklist.md index 2a986e5..1f8660e 100644 --- a/.copy-edit-stylesheet-checklist.md +++ b/.copy-edit-stylesheet-checklist.md @@ -1,6 +1,6 @@ # Basic checklist/stylesheet used for copy editing BOLTs -Contributions should comply with this checklist/stylsheet to maintain correct, clear, consistent, and concise BOLTS. +Contributions should comply with this checklist/stylesheet to maintain correct, clear, consistent, and concise BOLTS. - spelling - run `tools/spellcheck.sh --check [0-9][0-9]-*.md` diff --git a/01-messaging.md b/01-messaging.md index 4ed85ad..672a996 100644 --- a/01-messaging.md +++ b/01-messaging.md @@ -158,7 +158,7 @@ structs, should do so by defining the encoding such that the object is serialized within a single `tlv_record`. The uniqueness constraint, among other things, enables the following optimizations: - canonical ordering is defined independent of the encoded `value`s. - - canonical ordering can be known at compile-time, rather that being determined + - canonical ordering can be known at compile-time, rather than being determined dynamically at the time of encoding. - verifying canonical ordering requires less state and is less-expensive. - variable-size fields can reserve their expected size up front, rather than diff --git a/02-peer-protocol.md b/02-peer-protocol.md index b816d7b..0ca3722 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -836,7 +836,7 @@ Invalid amounts are a clear protocol violation and indicate a breakdown. If a node did not accept multiple HTLCs with the same payment hash, an attacker could probe to see if a node had an existing HTLC. This requirement, to deal with duplicates, leads to the use of a separate -identifier; its assumed a 64-bit counter never wraps. +identifier; it's assumed a 64-bit counter never wraps. Retransmissions of unacknowledged updates are explicitly allowed for reconnection purposes; allowing them at other times simplifies the diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 254d288..d62fe23 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -472,7 +472,7 @@ The origin node: signal a channel's temporary unavailability (e.g. due to a loss of connectivity) OR permanent unavailability (e.g. prior to an on-chain settlement). - - MAY sent a subsequent `channel_update` with the `disable` bit set to 0 to + - MAY sent a subsequent `channel_update` with the `disable` bit set to 0 to re-enable the channel. - MUST set `timestamp` to greater than 0, AND to greater than any previously-sent `channel_update` for this `short_channel_id`. @@ -581,7 +581,7 @@ Note that a 65535-byte zlib message can decompress into 67632120 bytes[2](#reference-2), but since the only valid contents are unique 8-byte values, no more than 14 bytes can be duplicated across the stream: as each duplicate takes at least 2 bits, no valid -contents could decompress to more then 3669960 bytes. +contents could decompress to more than 3669960 bytes. Query messages can be extended with optional fields that can help reduce the number of messages needed to synchronize routing tables by enabling: diff --git a/11-payment-encoding.md b/11-payment-encoding.md index d22d4de..b034093 100644 --- a/11-payment-encoding.md +++ b/11-payment-encoding.md @@ -285,9 +285,9 @@ but it's worth noting that [BOLT #4](04-onion-routing.md#requirements-2) specifi accept up to twice the expected `amount`, so the payer can make payments harder to track by adding small variations. -The intent is that the payer recover the payee's node ID from the +The intent is that the payer recovers the payee's node ID from the signature, and after checking that conditions such as fees, -expiry, and block timeout are acceptable, attempt a payment. It can use `r` fields to +expiry, and block timeout are acceptable, attempts a payment. It can use `r` fields to augment its routing information, if necessary to reach the final node. If the payment succeeds but there is a later dispute, the payer can