Remove trailing whitespace

lightning · Jan 30, 2018 · 2c3466a · 2c3466a
1 parent 58f6a70
commit 2c3466a
Show file tree

Hide file tree

Showing 8 changed files with 27 additions and 27 deletions.
diff --git 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
@@ -18,15 +18,15 @@ 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)
         * [`localkey`, `remotekey`, `local_htlckey`, `remote_htlckey`, `local_delayedkey`, and `remote_delayedkey` Derivation](#localkey-remotekey-local_delayedkey-and-remote_delayedkey-derivation)
         * [`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
@@ -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
@@ -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
@@ -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`<sup>[1](#reference-1)</sup>. 
+and `Poly1305` that are used MUST conform to `RFC 7539`<sup>[1](#reference-1)</sup>.
 
 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
@@ -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
@@ -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
@@ -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