mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

Remove trailing whitespace

Browse source
This commit is contained in:
practicalswift 2018-01-30 14:56:52 +10:30 • committed by Rusty Russell
parent 58f6a70889
commit 2c3466a2af
8 changed files with 27 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
02-peer-protocol.md
View file

@ -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 forwards to C, who delivers the goods as soon as the payment is
received. received.
1. C needs to be sure that the HTLC from B cannot time out, even if B becomes 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 unresponsive; i.e. C can fulfill the incoming HTLC on-chain before B can
time it out on-chain. time it out on-chain.
2. B needs to be sure that if C fulfills the HTLC from B, it can fulfill the 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 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. HTLC on-chain before A can time it out on-chain.
The critical settings here are the `cltv_expiry_delta` in The critical settings here are the `cltv_expiry_delta` in
[BOLT #7](07-routing-gossip.md#the-channel_update-message) and the [BOLT #7](07-routing-gossip.md#the-channel_update-message) and the

8
03-transactions.md
View file

@ -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) * [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions)
* [Closing Transaction](#closing-transaction) * [Closing Transaction](#closing-transaction)
* [Fees](#fees) * [Fees](#fees)
* [Fee Calculation](#fee-calculation) * [Fee Calculation](#fee-calculation)
* [Fee Payment](#fee-payment) * [Fee Payment](#fee-payment)
* [Keys](#keys) * [Keys](#keys)
* [Key Derivation](#key-derivation) * [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) * [`revocationkey` Derivation](#revocationkey-derivation)
* [Per-commitment Secret Requirements](#per-commitment-secret-requirements) * [Per-commitment Secret Requirements](#per-commitment-secret-requirements)
* [Efficient Per-commitment Secret Storage](#efficient-per-commitment-secret-storage) * [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 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) * [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) * [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) * [Generation Tests](#generation-tests)
* [Storage Tests](#storage-tests) * [Storage Tests](#storage-tests)
* [Appendix E: Key Derivation Test Vectors](#appendix-e-key-derivation-test-vectors) * [Appendix E: Key Derivation Test Vectors](#appendix-e-key-derivation-test-vectors)
* [References](#references) * [References](#references)
* [Authors](#authors) * [Authors](#authors)
# Transactions # Transactions

2
04-onion-routing.md
View file

@ -186,7 +186,7 @@ hop in the path.
Using this end-to-end authentication, Using this end-to-end authentication,
each each
hop is able to hop is able to
cross-check the HTLC parameters with the `per_hop`'s specified values cross-check the HTLC parameters with the `per_hop`'s specified values
and to ensure that the sending peer hasn't forwarded an and to ensure that the sending peer hasn't forwarded an
ill-crafted HTLC. ill-crafted HTLC.

2
07-routing-gossip.md
View file

@ -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 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 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. 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. Bits which are not assigned a meaning must be set to 0.

14
08-transport.md
View file

@ -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 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 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 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 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. 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 and the AEAD cipher scheme. For Lightning, `SHA-256` is
chosen as the hash function, `secp256k1` as the elliptic curve, and chosen as the hash function, `secp256k1` as the elliptic curve, and
`ChaChaPoly-1305` as the AEAD construction. The composition of `ChaCha20` `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 The official protocol name for the Lightning variant of Noise is
`Noise_XK_secp256k1_ChaChaPoly_SHA256`. The ASCII string representation of `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. 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 * `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 * `.pub`, which returns an abstract object representing the public key
* `.priv`, which represents the private key used to generate the * `.priv`, which represents the private key used to generate the
public key public key
* where the object also has a single method: * where the object also has a single method:
* `.serializeCompressed()` * `.serializeCompressed()`
* `a || b` denotes the concatenation of two byte strings `a` and `b` * `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). message (not counting its MAC).
The *maximum* size of _any_ Lightning message MUST NOT exceed `65535` bytes. A 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. easier, and helps mitigate memory-exhaustion attacks.
In order to make traffic analysis more difficult, the length prefix for 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`. 3. Reset the nonce for the key to `n = 0`.
4. `k = k'` 4. `k = k'`
5. `ck = ck'` 5. `ck = ck'`
# Security Considerations # Security Considerations
It is strongly recommended that existing, commonly-used, validated 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 input: 0x00b9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c38228dc68b1c466263b47fdf31e560e139
output: ERROR (ACT3_READ_FAILED) 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.priv=2121212121212121212121212121212121212121212121212121212121212121
ls.pub=028d7500dd4c12685d1f568b4c2b5048e8534b873319f3a8daa612b469132ec7f7 ls.pub=028d7500dd4c12685d1f568b4c2b5048e8534b873319f3a8daa612b469132ec7f7
e.priv=0x2222222222222222222222222222222222222222222222222222222222222222 e.priv=0x2222222222222222222222222222222222222222222222222222222222222222

2
09-features.md
View file

@ -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 receiving specific bits are defined in the linked sections in the table above.
The requirements for feature bits that are not defined 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 ## Rationale

2
10-dns-bootstrap.md
View file

@ -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: 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) - `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) - `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) - `n`: the number of desired reply records (default: 25)

12
11-payment-encoding.md
View file

@ -14,7 +14,7 @@ over Lightning.
* [Implementation](#implementation) * [Implementation](#implementation)
* [Examples](#examples) * [Examples](#examples)
* [Authors](#authors) * [Authors](#authors)
# Encoding Overview # Encoding Overview
The format for a Lightning invoice uses 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 * `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) * `pubkey` (264 bits)
* `short_channel_id` (64 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) * `fee_proportional_millionths` (32 bits, big-endian)
* `cltv_expiry_delta` (16 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 the SHA-2 256-bit hash of the `payment_preimage` that will be given
in return for payment. 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 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 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, 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. on-chain payment if necessary.
The `c` field gives a way for the destination node to require a specific 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 to require a higher, more conservative value than the default one, depending
on their fee estimation policy and their sensitivity to time locks. Note on their fee estimation policy and their sensitivity to time locks. Note
that remote nodes in the route specify their required `cltv_expiry_delta` that remote nodes in the route specify their required `cltv_expiry_delta`
in the `channel_update` message, which they can update at all times. 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 The `f` field allows on-chain fallback. This may not make sense for