Clean up markdown (#9)

Apply common markdown linting rules.
2024-11-19 00:50:02 +01:00 · 2022-01-05 17:02:37 +01:00 · 2022-01-05 17:02:37 +01:00 · 6e5493832e
commit 6e5493832e
parent 44434a9738
4 changed files with 160 additions and 161 deletions
--- a/README.md
+++ b/README.md
@ -17,8 +17,8 @@ published here.
 For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
 [bLIP-0002](./blip-0002.md).

-| Number | Title                     | Author                      | Status |
-|--------|---------------------------|-----------------------------|--------|
+| Number                   | Title                     | Author                      | Status |
+|--------------------------|---------------------------|-----------------------------|--------|
 | [1](./blip-0001.md)      | bLIP Process              | Ryan Gentry                 | Active |
-| [2](./blip-0002.md)      | reserved values           | Bastien Teinturier          | Active |
+| [2](./blip-0002.md)      | Reserved Values           | Bastien Teinturier          | Active |
 | [3](./blip-0003.md)      | Keysend                   | Valentine Wallace           | Active |
--- a/blip-0001.md
+++ b/blip-0001.md
@ -9,7 +9,7 @@ Post-History: 2021-06-30: https://lists.linuxfoundation.org/pipermail/lightning-
 License: CC0
 ```

-# Abstract
+## Abstract

 bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document
 providing information to the Lightning community, or describing a new feature for
@ -19,11 +19,11 @@ building consensus within the community and documenting dissenting opinions.
 Importantly, if a feature is intended to become universal or near universal, it must
 be a BOLT.

-# Copyright
+## Copyright

 This bLIP is licensed under the CC0 license.

-# Rationale
+## Rationale

 As the Lightning community has grown, new features, standards, and protocols have
 been developed outside of the BOLT specification process: particularly at the
@ -47,7 +47,7 @@ implementation. Ideally, each implementation editor would list the bLIPs they ha
 implemented. This will give end users a convenient way to know the current status of
 a given implementation or library.

-# bLIP Workflow
+## bLIP Workflow

 The bLIP process begins with a new idea for Lightning. Each potential bLIP must have
 a champion -- someone who writes the bLIP using the style and format described below,
@ -91,7 +91,7 @@ and must not complicate the protocol unduly.
 The bLIP author may update the draft as necessary in the git repository. Updates to
 drafts should also be submitted by the author as pull requests.

-## Transferring bLIP Ownership
+### Transferring bLIP Ownership

 It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In
 general, we'd like to retain the original author as a co-author of the transferred bLIP,
@ -229,7 +229,7 @@ bLIP that it rendered obsolete.

 The typical paths of the status of bLIPs are as follows:

-![](blip-0001/blip-0001-1.png)
+![blip status workflow](blip-0001/blip-0001-1.png)

 * **Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by
 a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted.
@ -269,7 +269,7 @@ subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is th

 All bLIPs must be licensed under CC-BY or CC0.

-# History
+## History

 This document was derived heavily from [Bitcoin's
 BIP-0002](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr.
--- a/blip-0002.md
+++ b/blip-0002.md
@ -7,7 +7,7 @@ Created: 2021-11-05
 License: CC0
 ```

-# Abstract
+## Abstract

 bLIPs may need to define messages and fields that need to be correctly parsed and interpreted
 throughout the network to ensure interoperability and guarantee backwards-compatibility.
@ -24,9 +24,9 @@ bLIP authors must edit the tables below to reserve values in these various names
 there will be no conflict between unrelated bLIPs, which would otherwise potentially lead to a
 network split.

-# Reserved values
+## Reserved values

-## Table of Contents
+### Table of Contents

 * [Feature bits](#feature-bits)
 * [Messages](#messages)
@ -35,7 +35,7 @@ network split.
  * [`ping`](#ping)
  * [`update_add_htlc`](#update_add_htlc)

-## Feature bits
+### Feature bits

 Feature bits are specified in [Bolt 9](https://github.com/lightning/bolts/blob/master/09-features.md).
 They let nodes publicly advertise that they support or require a given feature.
@ -47,7 +47,7 @@ bLIPs may reserve feature bits by adding them to the following table:
 |---------|----------------------|-------------------------------------------------|----------------|--------------------------------|--------------------------------|
 | 54/55   | `keysend`            | A form of spontaneous payment                   | N              | `var_onion_optin`              | [bLIP 3](./blip-0003.md)       |

-## Messages
+### Messages

 The BOLTs define a standard [message format](https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-format)
 that every lightning implementation understands.
@ -59,7 +59,7 @@ bLIPs may create new messages and reserve their type in the following table:
 |-------|-----------------------------|--------------------------------|
 | 32768 | `message_name`              | Link to the corresponding bLIP |

-## TLV fields in BOLT messages
+### TLV fields in BOLT messages

 Every BOLT message contains a trailing `extension` field, which is a tlv stream with tlv fields
 specific to that BOLT message.
@ -71,7 +71,7 @@ bLIPs must carefully decide whether these new tlv fields should be even or odd,
 When adding new tlv fields to existing BOLT messages, bLIPS must use types greater than `65536`
 and fill the table corresponding to the message they're modifying.

-### `init`
+#### `init`

 The following table contains extension tlv fields for the `init` message:

@ -79,7 +79,7 @@ The following table contains extension tlv fields for the `init` message:
 |-------|-----------------------------|--------------------------------|
 | 65536 | `tlv_field_name`            | Link to the corresponding bLIP |

-### `ping`
+#### `ping`

 The following table contains extension tlv fields for the `ping` message:

@ -87,7 +87,7 @@ The following table contains extension tlv fields for the `ping` message:
 |-------|-----------------------------|--------------------------------|
 | 65536 | `tlv_field_name`            | Link to the corresponding bLIP |

-### `update_add_htlc`
+#### `update_add_htlc`

 The following table contains extension tlv fields for the `update_add_htlc` message's onion payload:

@ -95,6 +95,6 @@ The following table contains extension tlv fields for the `update_add_htlc` mess
 |------------|-----------------------------|--------------------------------|
 | 5482373484 | `keysend_preimage`          | [bLIP 3](./blip-0003.md)       |

-# Copyright
+## Copyright

 This bLIP is licensed under the CC0 license.
--- a/blip-0003.md
+++ b/blip-0003.md
@ -7,7 +7,7 @@ Created: 2021-12-08
 License: CC0
 ```

-# Abstract
+## Abstract

 Keysend is a type of lightning payment that does not require the payee to
 provide an invoice. Instead, the payer includes their payer-selected payment
@ -18,13 +18,14 @@ This bLIP serves to document what is already well-supported in the wild (see
 that new implementations don't have to reverse-engineer keysend from existing
 implementations.

-# Copyright
+## Copyright

 This bLIP is licensed under the CC0 license.

-# Specification
+## Specification

 Sender:
+
 * MUST include a TLV record keyed by type `5482373484` with a TLV value of a
  randomly generated and cryptographically-secure 32-byte value that serves as
  the HTLC payment preimage
@ -35,11 +36,12 @@ Sender:
 * SHOULD only send payments to nodes advertising the `keysend` feature bit

 Receiver:
+
 * if failing the payment due to not wanting to accept keysend payments or if
  the preimage does not match the payment hash, SHOULD error with
-	`PERM|15 incorrect_or_unknown_payment_details`.
+  `PERM|15 incorrect_or_unknown_payment_details`.

-# Motivation
+## Motivation

 A convenience of layer 1 bitcoin is being able to spontaneously send to a
 bitcoin address with no advance work required on the part of the payee. Keysend
@ -51,7 +53,7 @@ supported by major implementations. So regardless of whether it is the best
 solution to spontaneous payments, it's a good idea to have some form of
 official documentation for it.

-# Rationale
+## Rationale

 Design decisions for keysend were largely made by the original lnd keysend
 implementation (e.g. the choice of `5482373484` for the TLV type).
@ -62,7 +64,7 @@ implementation (e.g. the choice of `5482373484` for the TLV type).
  explicitly know that receivers support keysend is by attempting a keysend
  payment and seeing whether or not it fails.

-# Keysend Drawbacks
+## Keysend Drawbacks

 * Inability for the payee to specify their preferred `min_final_cltv_expiry`.
  This is an issue because payer and payee may have differing security
@ -80,12 +82,9 @@ implementation (e.g. the choice of `5482373484` for the TLV type).
  [Offers](https://github.com/lightningnetwork/lightning-rfc/pull/798) or
  [AMP](https://github.com/lightningnetwork/lightning-rfc/pull/658)

-# Reference Implementations
+## Reference Implementations

-LDK: https://github.com/rust-bitcoin/rust-lightning/pull/967
-
-C-Lightning: https://github.com/ElementsProject/lightning/blob/master/plugins/keysend.c
-
-lnd original keysend PR: https://github.com/lightningnetwork/lnd/pull/3795
-
-Eclair: https://github.com/ACINQ/eclair/pull/1485
+* LDK: <https://github.com/rust-bitcoin/rust-lightning/pull/967>
+* C-Lightning: <https://github.com/ElementsProject/lightning/blob/master/plugins/keysend.c>
+* lnd original keysend PR: <https://github.com/lightningnetwork/lnd/pull/3795>
+* Eclair: <https://github.com/ACINQ/eclair/pull/1485>