mirror of
https://github.com/lightning/bolts.git
synced 2025-03-10 09:10:07 +01:00
Remove trailing whitespace
This commit is contained in:
practicalswift
Rusty Russell
parent
58f6a70889
commit
2c3466a2af
8 changed files with 27 additions and 27 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue