From 2c3466a2af8e62215b9240f9932256a509652b5d Mon Sep 17 00:00:00 2001 From: practicalswift Date: Tue, 30 Jan 2018 14:56:52 +1030 Subject: [PATCH] Remove trailing whitespace --- 02-peer-protocol.md | 12 ++++++------ 03-transactions.md | 8 ++++---- 04-onion-routing.md | 2 +- 07-routing-gossip.md | 2 +- 08-transport.md | 14 +++++++------- 09-features.md | 2 +- 10-dns-bootstrap.md | 2 +- 11-payment-encoding.md | 12 ++++++------ 8 files changed, 27 insertions(+), 27 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 563974e..4558ca3 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -614,13 +614,13 @@ Consider the following scenario, where A sends an HTLC to B, who forwards to C, who delivers the goods as soon as the payment is received. -1. C needs to be sure that the HTLC from B cannot time out, even if B becomes - unresponsive; i.e. C can fulfill the incoming HTLC on-chain before B can - time it out on-chain. +1. C needs to be sure that the HTLC from B cannot time out, even if B becomes + unresponsive; i.e. C can fulfill the incoming HTLC on-chain before B can + time it out on-chain. -2. B needs to be sure that if C fulfills the HTLC from B, it can fulfill the - incoming HTLC from A; i.e. B can get the preimage from C and fulfill the incoming - HTLC on-chain before A can time it out on-chain. +2. B needs to be sure that if C fulfills the HTLC from B, it can fulfill the + incoming HTLC from A; i.e. B can get the preimage from C and fulfill the incoming + HTLC on-chain before A can time it out on-chain. The critical settings here are the `cltv_expiry_delta` in [BOLT #7](07-routing-gossip.md#the-channel_update-message) and the diff --git a/03-transactions.md b/03-transactions.md index 72d83b1..69846c5 100644 --- a/03-transactions.md +++ b/03-transactions.md @@ -18,7 +18,7 @@ This details the exact format of on-chain transactions, which both sides need to * [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions) * [Closing Transaction](#closing-transaction) * [Fees](#fees) - * [Fee Calculation](#fee-calculation) + * [Fee Calculation](#fee-calculation) * [Fee Payment](#fee-payment) * [Keys](#keys) * [Key Derivation](#key-derivation) @@ -26,7 +26,7 @@ This details the exact format of on-chain transactions, which both sides need to * [`revocationkey` Derivation](#revocationkey-derivation) * [Per-commitment Secret Requirements](#per-commitment-secret-requirements) * [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage) - * [Appendix A: Expected Weights](#appendix-a-expected-weights) + * [Appendix A: Expected Weights](#appendix-a-expected-weights) * [Expected Weight of the Commitment Transaction](#expected-weight-of-the-commitment-transaction) * [Expected Weight of HTLC-timeout and HTLC-success Transactions](#expected-weight-of-htlc-timeout-and-htlc-success-transactions) * [Appendix B: Funding Transaction Test Vectors](#appendix-b-funding-transaction-test-vectors) @@ -35,8 +35,8 @@ This details the exact format of on-chain transactions, which both sides need to * [Generation Tests](#generation-tests) * [Storage Tests](#storage-tests) * [Appendix E: Key Derivation Test Vectors](#appendix-e-key-derivation-test-vectors) - * [References](#references) - * [Authors](#authors) + * [References](#references) + * [Authors](#authors) # Transactions diff --git a/04-onion-routing.md b/04-onion-routing.md index e70ab0a..322eeec 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -186,7 +186,7 @@ hop in the path. Using this end-to-end authentication, each -hop is able to +hop is able to cross-check the HTLC parameters with the `per_hop`'s specified values and to ensure that the sending peer hasn't forwarded an ill-crafted HTLC. diff --git a/07-routing-gossip.md b/07-routing-gossip.md index eaecb30..bc95d8c 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -377,7 +377,7 @@ double-SHA256 of the entire remaining packet after `signature`, using its own `n The creating node MUST set `chain_hash` and `short_channel_id` to match the 32-byte hash and 8-byte channel ID that uniquely identifies the channel within -the `channel_announcement` message. +the `channel_announcement` message. The creating node MUST set the `direction` bit of `flags` to 0 if the creating node is `node_id_1` in that message, otherwise 1. Bits which are not assigned a meaning must be set to 0. diff --git a/08-transport.md b/08-transport.md index e3abfad..6b9e5c0 100644 --- a/08-transport.md +++ b/08-transport.md @@ -61,7 +61,7 @@ The authenticated key agreement (`Noise_XK`) is performed in three distinct steps. During each "act" of the handshake the following occurs: some (possibly encrypted) keying material is sent to the other party; an ECDH is performed based on exactly which act is being executed, with the result mixed into the current set of -encryption keys (`ck` the chaining key and `k` the encryption key); and +encryption keys (`ck` the chaining key and `k` the encryption key); and an AEAD payload with a zero-length cipher text is sent. As this payload has no length, only a MAC is sent across. The mixing of ECDH outputs into a hash digest forms an incremental TripleDH handshake. @@ -106,7 +106,7 @@ three abstract cryptographic objects: the hash function, the elliptic curve, and the AEAD cipher scheme. For Lightning, `SHA-256` is chosen as the hash function, `secp256k1` as the elliptic curve, and `ChaChaPoly-1305` as the AEAD construction. The composition of `ChaCha20` -and `Poly1305` that are used MUST conform to `RFC 7539`[1](#reference-1). +and `Poly1305` that are used MUST conform to `RFC 7539`[1](#reference-1). The official protocol name for the Lightning variant of Noise is `Noise_XK_secp256k1_ChaChaPoly_SHA256`. The ASCII string representation of @@ -168,11 +168,11 @@ The following functions will also be referenced: arguments, with nonce `n` encoded as 32 zero bits, followed by a *little-endian* 64-bit value. * `generateKey()`: generates and returns a fresh `secp256k1` keypair - * where the object returned by `generateKey` has two attributes: + * where the object returned by `generateKey` has two attributes: * `.pub`, which returns an abstract object representing the public key * `.priv`, which represents the private key used to generate the public key - * where the object also has a single method: + * where the object also has a single method: * `.serializeCompressed()` * `a || b` denotes the concatenation of two byte strings `a` and `b` @@ -408,7 +408,7 @@ another AEAD ciphertext, which encodes the total length of the following Lightni message (not counting its MAC). The *maximum* size of _any_ Lightning message MUST NOT exceed `65535` bytes. A -maximum size of `65535` simplifies testing, makes memory management +maximum size of `65535` simplifies testing, makes memory management easier, and helps mitigate memory-exhaustion attacks. In order to make traffic analysis more difficult, the length prefix for @@ -495,7 +495,7 @@ Key rotation for a key `k` is performed according to the following: 3. Reset the nonce for the key to `n = 0`. 4. `k = k'` 5. `ck = ck'` - + # Security Considerations It is strongly recommended that existing, commonly-used, validated @@ -696,7 +696,7 @@ The responder should produce the given output when fed this input. input: 0x00b9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c38228dc68b1c466263b47fdf31e560e139 output: ERROR (ACT3_READ_FAILED) - name: transport-responder act3 bad MAC for ciphertext test + name: transport-responder act3 bad MAC for ciphertext test ls.priv=2121212121212121212121212121212121212121212121212121212121212121 ls.pub=028d7500dd4c12685d1f568b4c2b5048e8534b873319f3a8daa612b469132ec7f7 e.priv=0x2222222222222222222222222222222222222222222222222222222222222222 diff --git a/09-features.md b/09-features.md index 3226c41..c19514e 100644 --- a/09-features.md +++ b/09-features.md @@ -28,7 +28,7 @@ There are currently no `globalfeatures` flags. The requirements for receiving specific bits are defined in the linked sections in the table above. The requirements for feature bits that are not defined -above can be found in [BOLT #1: The `init` Message](01-messaging.md#the-init-message). +above can be found in [BOLT #1: The `init` Message](01-messaging.md#the-init-message). ## Rationale diff --git a/10-dns-bootstrap.md b/10-dns-bootstrap.md index 937c329..1c05201 100644 --- a/10-dns-bootstrap.md +++ b/10-dns-bootstrap.md @@ -21,7 +21,7 @@ The conditions are key-value pairs with a single-letter key; the remainder of th The following key-value pairs MUST be supported by a DNS seed: - `r`: realm byte, used to specify what realm the returned nodes must support (default value: 0, Bitcoin) - - `a`: address types, used to specify what address types should be returned for `SRV` queries. This is a bitfield that uses the types from [BOLT #7](07-routing-gossip.md) as bit index. This condition MAY only be used for `SRV` queries. (default value: 6, i.e. `2 || 4`, since bit 1 and bit 2 are set for IPv4 and IPv6, respectively) + - `a`: address types, used to specify what address types should be returned for `SRV` queries. This is a bitfield that uses the types from [BOLT #7](07-routing-gossip.md) as bit index. This condition MAY only be used for `SRV` queries. (default value: 6, i.e. `2 || 4`, since bit 1 and bit 2 are set for IPv4 and IPv6, respectively) - `l`: `node_id`, the bech32-encoded `node_id` of a specific node, used to ask for a single node instead of a random selection. (default: null) - `n`: the number of desired reply records (default: 25) diff --git a/11-payment-encoding.md b/11-payment-encoding.md index c6e7089..2309e83 100644 --- a/11-payment-encoding.md +++ b/11-payment-encoding.md @@ -14,7 +14,7 @@ over Lightning. * [Implementation](#implementation) * [Examples](#examples) * [Authors](#authors) - + # Encoding Overview The format for a Lightning invoice uses @@ -125,7 +125,7 @@ Currently defined tagged fields are: * `r` (3): `data_length` variable. One or more entries containing extra routing information for a private route; there may be more than one `r` field * `pubkey` (264 bits) * `short_channel_id` (64 bits) - * `fee_base_msat` (32 bits, big-endian) + * `fee_base_msat` (32 bits, big-endian) * `fee_proportional_millionths` (32 bits, big-endian) * `cltv_expiry_delta` (16 bits, big-endian) @@ -135,7 +135,7 @@ A writer MUST include exactly one `p` field, and set `payment_hash` to the SHA-2 256-bit hash of the `payment_preimage` that will be given in return for payment. -A writer MUST include either exactly one `d` or exactly one `h` field. If included, a +A writer MUST include either exactly one `d` or exactly one `h` field. If included, a writer SHOULD make `d` a complete description of the purpose of the payment, and MUST use a valid UTF-8 string. If included, a writer MUST make the preimage of the hashed description in `h` available through some unspecified means, @@ -206,10 +206,10 @@ to be reasonable for most payments and to allow sufficient time for on-chain payment if necessary. The `c` field gives a way for the destination node to require a specific -minimum CLTV expiry for its incoming HTLC. Destination nodes may use this +minimum CLTV expiry for its incoming HTLC. Destination nodes may use this to require a higher, more conservative value than the default one, depending -on their fee estimation policy and their sensitivity to time locks. Note -that remote nodes in the route specify their required `cltv_expiry_delta` +on their fee estimation policy and their sensitivity to time locks. Note +that remote nodes in the route specify their required `cltv_expiry_delta` in the `channel_update` message, which they can update at all times. The `f` field allows on-chain fallback. This may not make sense for