mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 01:50:03 +01:00
Fix typos
This commit is contained in:
parent
c8e53fe5bf
commit
3476c9b25a
@ -1,6 +1,6 @@
|
|||||||
# Basic checklist/stylesheet used for copy editing BOLTs
|
# 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
|
- spelling
|
||||||
- run `tools/spellcheck.sh --check [0-9][0-9]-*.md`
|
- run `tools/spellcheck.sh --check [0-9][0-9]-*.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
|
serialized within a single `tlv_record`. The uniqueness constraint, among other
|
||||||
things, enables the following optimizations:
|
things, enables the following optimizations:
|
||||||
- canonical ordering is defined independent of the encoded `value`s.
|
- 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.
|
dynamically at the time of encoding.
|
||||||
- verifying canonical ordering requires less state and is less-expensive.
|
- verifying canonical ordering requires less state and is less-expensive.
|
||||||
- variable-size fields can reserve their expected size up front, rather than
|
- variable-size fields can reserve their expected size up front, rather than
|
||||||
|
@ -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
|
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
|
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
|
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
|
Retransmissions of unacknowledged updates are explicitly allowed for
|
||||||
reconnection purposes; allowing them at other times simplifies the
|
reconnection purposes; allowing them at other times simplifies the
|
||||||
|
@ -581,7 +581,7 @@ Note that a 65535-byte zlib message can decompress into 67632120
|
|||||||
bytes<sup>[2](#reference-2)</sup>, but since the only valid contents
|
bytes<sup>[2](#reference-2)</sup>, but since the only valid contents
|
||||||
are unique 8-byte values, no more than 14 bytes can be duplicated
|
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
|
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:
|
Query messages can be extended with optional fields that can help reduce the number of messages needed to synchronize routing tables by enabling:
|
||||||
|
|
||||||
|
@ -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
|
accept up to twice the expected `amount`, so the payer can make
|
||||||
payments harder to track by adding small variations.
|
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,
|
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.
|
augment its routing information, if necessary to reach the final node.
|
||||||
|
|
||||||
If the payment succeeds but there is a later dispute, the payer can
|
If the payment succeeds but there is a later dispute, the payer can
|
||||||
|
Loading…
Reference in New Issue
Block a user