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

Fix formatting of BOLT links

Browse source
This commit is contained in:
MeshCollider 2018-01-17 19:37:58 +13:00 • committed by Christian Decker
parent b2960b4267
commit 4b5379b2ac
6 changed files with 12 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
01-messaging.md
View file

@ -258,7 +258,7 @@ typical exchanges without applying any true updates to their respective
channels. channels.
When combined with the onion routing protocol defined in When combined with the onion routing protocol defined in
[BOLT #4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md), [BOLT #4](04-onion-routing.md),
careful statistically driven synthetic traffic can serve to further bolster the careful statistically driven synthetic traffic can serve to further bolster the
privacy of participants within the network. privacy of participants within the network.
@ -268,7 +268,7 @@ of incoming traffic flooding (e.g. sending _odd_ unknown message types, or paddi
every message maximally). every message maximally).
Finally, the usage of periodic `ping` messages serves to promote frequent key Finally, the usage of periodic `ping` messages serves to promote frequent key
rotations as specified within [BOLT #8](https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md). rotations as specified within [BOLT #8](08-transport.md).
## Acknowledgments ## Acknowledgments

6
02-peer-protocol.md
View file

@ -35,7 +35,7 @@ consists of the funding node (funder) sending an `open_channel` message,
followed by the responding node (fundee) sending `accept_channel`. With the followed by the responding node (fundee) sending `accept_channel`. With the
channel parameters locked in, the funder is able to create the funding channel parameters locked in, the funder is able to create the funding
transaction and both versions of the commitment transaction, as described in transaction and both versions of the commitment transaction, as described in
[BOLT #3](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#bolt-3-bitcoin-transaction-and-script-formats). [BOLT #3](03-transactions.md#bolt-3-bitcoin-transaction-and-script-formats).
The funder then sends the outpoint of the funding output with the `funding_created` The funder then sends the outpoint of the funding output with the `funding_created`
message, along with the signature for the fundee's version of the commitment message, along with the signature for the fundee's version of the commitment
transaction. Once the fundee learns the funding outpoint, it's able to transaction. Once the fundee learns the funding outpoint, it's able to
@ -158,7 +158,7 @@ Only the least-significant bit of `channel_flags` is currently
defined: `announce_channel`. This indicates whether the initiator of defined: `announce_channel`. This indicates whether the initiator of
the funding flow wishes to advertise this channel publicly to the the funding flow wishes to advertise this channel publicly to the
network, as detailed within [BOLT network, as detailed within [BOLT
#7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery). #7](07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery).
The `shutdown_scriptpubkey` allows the sending node to commit to where The `shutdown_scriptpubkey` allows the sending node to commit to where
funds will go on mutual close, which the remote node should enforce funds will go on mutual close, which the remote node should enforce
@ -520,7 +520,7 @@ reason to pay a premium for rapid processing.
## Normal Operation ## Normal Operation
Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hash TimeLocked Contracts. Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hash TimeLocked Contracts.
Changes are sent in batches: one or more `update_` messages are sent before a Changes are sent in batches: one or more `update_` messages are sent before a
`commitment_signed` message, as in the following diagram: `commitment_signed` message, as in the following diagram:

2
04-onion-routing.md
View file

@ -205,7 +205,7 @@ Field descriptions:
incoming_htlc_amt - fee >= amt_to_forward incoming_htlc_amt - fee >= amt_to_forward
Where `fee` is either calculated according to the receiving peer's advertised fee Where `fee` is either calculated according to the receiving peer's advertised fee
schema (as described in [BOLT 7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#htlc-fees)) schema (as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
or is 0, if the processing node is the final node. or is 0, if the processing node is the final node.
* `outgoing_cltv_value`: The CLTV value that the _outgoing_ HTLC carrying * `outgoing_cltv_value`: The CLTV value that the _outgoing_ HTLC carrying

4
05-onchain.md
View file

@ -264,7 +264,7 @@ prevent the remote node fulfilling it and claiming the funds) before the
local node can back-fail any corresponding incoming HTLC, using local node can back-fail any corresponding incoming HTLC, using
`update_fail_htlc` (presumably with reason `permanent_channel_failure`), as `update_fail_htlc` (presumably with reason `permanent_channel_failure`), as
detailed in detailed in
[BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs). [BOLT #2](02-peer-protocol.md#forwarding-htlcs).
If the incoming HTLC is also on-chain, a node must simply wait for it to If the incoming HTLC is also on-chain, a node must simply wait for it to
timeout: there is no way to signal early failure. timeout: there is no way to signal early failure.
@ -420,7 +420,7 @@ Once it has timed out, the local node needs to spend the HTLC output (to prevent
the remote node from using the HTLC-success transaction) before it can the remote node from using the HTLC-success transaction) before it can
back-fail any corresponding incoming HTLC, using `update_fail_htlc` back-fail any corresponding incoming HTLC, using `update_fail_htlc`
(presumably with reason `permanent_channel_failure`), as detailed in (presumably with reason `permanent_channel_failure`), as detailed in
[BOLT 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs). [BOLT #2](02-peer-protocol.md#forwarding-htlcs).
If the incoming HTLC is also on-chain, a node simply waits for it to If the incoming HTLC is also on-chain, a node simply waits for it to
timeout, as there's no way to signal early failure. timeout, as there's no way to signal early failure.

6
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)
@ -32,7 +32,7 @@ Clients MUST NOT rely on any given condition being met by the results.
Queries distinguish between _wildcard_ queries and _node_ queries, depending on whether the `l`-key is set or not. Queries distinguish between _wildcard_ queries and _node_ queries, depending on whether the `l`-key is set or not.
Upon receiving a wildcard query, the DNS seed MUST select a random subset of up to `n` IPv4 or IPv6 addresses of nodes that are listening for incoming connections. Upon receiving a wildcard query, the DNS seed MUST select a random subset of up to `n` IPv4 or IPv6 addresses of nodes that are listening for incoming connections.
For `A` and `AAAA` queries, only nodes listening on the default port 9735, as defined in [BOLT 01](01-messaging.md), MUST be returned. For `A` and `AAAA` queries, only nodes listening on the default port 9735, as defined in [BOLT #1](01-messaging.md), MUST be returned.
Since `SRV` records return a _(hostname,port)_-tuple, nodes that are listening on non-default ports MAY be returned. Since `SRV` records return a _(hostname,port)_-tuple, nodes that are listening on non-default ports MAY be returned.
Upon receiving a node query, the seed MUST select the record matching the `node_id`, if any, and return all addresses associated with that node. Upon receiving a node query, the seed MUST select the record matching the `node_id`, if any, and return all addresses associated with that node.
@ -44,7 +44,7 @@ The results are serialized in a reply with a query type matching the client's qu
For `A` and `AAAA` queries, the reply contains the domain name and the IP address of the results. For `A` and `AAAA` queries, the reply contains the domain name and the IP address of the results.
The domain name MUST match the domain in the query in order not to be filtered by intermediate resolvers. The domain name MUST match the domain in the query in order not to be filtered by intermediate resolvers.
For `SRV` queries, the reply consists of (_virtual hostnames_, port)-tuples For `SRV` queries, the reply consists of (_virtual hostnames_, port)-tuples.
A virtual hostname is a subdomain of the seed root domain that uniquely identifies a node in the network. A virtual hostname is a subdomain of the seed root domain that uniquely identifies a node in the network.
It is constructed by prepending the `node_id` condition to the seed root domain. It is constructed by prepending the `node_id` condition to the seed root domain.
The DNS seed MAY additionally return the corresponding `A` and `AAAA` records that indicate the IP address for the `SRV` entries in the Extra section of the reply. The DNS seed MAY additionally return the corresponding `A` and `AAAA` records that indicate the IP address for the `SRV` entries in the Extra section of the reply.

3
README.md
View file

@ -7,9 +7,8 @@ Pull requests and comments welcome, seeking input from community stakeholders.
Discussion available on the [lighting-dev mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). Discussion available on the [lighting-dev mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev).
### [Start here for Table of Contents](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md) ### [Start here for Table of Contents](00-introduction.md)
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY") ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br> <br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).