provide formatting for lnd references
This commit is contained in:
parent
2ddd139084
commit
ad40207126
@ -34,7 +34,7 @@ Basic of Lightning Technologies. The specifications are currently being drafted
|
|||||||
by several groups of implementers based around the world including the
|
by several groups of implementers based around the world including the
|
||||||
developers of `lnd`. The set of specification documents as well as our
|
developers of `lnd`. The set of specification documents as well as our
|
||||||
implementation of the specification are still a work-in-progress. With that
|
implementation of the specification are still a work-in-progress. With that
|
||||||
said, `lnd` the current status of `lnd`'s BOLT compliance is:
|
said, the current status of `lnd`'s BOLT compliance is:
|
||||||
|
|
||||||
- [X] BOLT 1: Base Protocol
|
- [X] BOLT 1: Base Protocol
|
||||||
- [X] BOLT 2: Peer Protocol for Channel Management
|
- [X] BOLT 2: Peer Protocol for Channel Management
|
||||||
|
@ -38,7 +38,7 @@ represent real money and introducing bugs and security vulnerabilities can have
|
|||||||
far more dire consequences than in typical projects where having a small bug is
|
far more dire consequences than in typical projects where having a small bug is
|
||||||
minimal by comparison. In the world of cryptocurrencies, even the smallest bug
|
minimal by comparison. In the world of cryptocurrencies, even the smallest bug
|
||||||
in the wrong area can cost people a significant amount of money. For this
|
in the wrong area can cost people a significant amount of money. For this
|
||||||
reason, the Lightning Network Daemon (lnd) has a formalized and rigorous
|
reason, the Lightning Network Daemon (`lnd`) has a formalized and rigorous
|
||||||
development process (heavily inspired by
|
development process (heavily inspired by
|
||||||
[btcsuite](https://github.com/btcsuite)) which is outlined on this page.
|
[btcsuite](https://github.com/btcsuite)) which is outlined on this page.
|
||||||
|
|
||||||
@ -78,7 +78,7 @@ security and performance implications.
|
|||||||
|
|
||||||
### 3. Required Reading
|
### 3. Required Reading
|
||||||
|
|
||||||
- [Effective Go](http://golang.org/doc/effective_go.html) - The entire lnd
|
- [Effective Go](http://golang.org/doc/effective_go.html) - The entire `lnd`
|
||||||
project follows the guidelines in this document. For your code to be accepted,
|
project follows the guidelines in this document. For your code to be accepted,
|
||||||
it must follow the guidelines therein.
|
it must follow the guidelines therein.
|
||||||
- [Original Satoshi Whitepaper](https://bitcoin.org/bitcoin.pdf) - This is the white paper that started it all. Having a solid
|
- [Original Satoshi Whitepaper](https://bitcoin.org/bitcoin.pdf) - This is the white paper that started it all. Having a solid
|
||||||
@ -132,7 +132,7 @@ This approach has several benefits:
|
|||||||
|
|
||||||
#### 4.2. Testing
|
#### 4.2. Testing
|
||||||
|
|
||||||
One of the major design goals of all of lnd's packages and the daemon itself is
|
One of the major design goals of all of `lnd`'s packages and the daemon itself is
|
||||||
to aim for a high degree of test coverage. This is financial software so bugs
|
to aim for a high degree of test coverage. This is financial software so bugs
|
||||||
and regressions in the core logic can cost people real money. For this reason
|
and regressions in the core logic can cost people real money. For this reason
|
||||||
every effort must be taken to ensure the code is as accurate and bug-free as
|
every effort must be taken to ensure the code is as accurate and bug-free as
|
||||||
@ -294,7 +294,7 @@ commit which introduced a bug or regression.
|
|||||||
|
|
||||||
#### 4.5. Code Spacing
|
#### 4.5. Code Spacing
|
||||||
|
|
||||||
Blocks of code within lnd should be segmented into logical stanzas of
|
Blocks of code within `lnd` should be segmented into logical stanzas of
|
||||||
operation. Such spacing makes the code easier to follow at a skim, and reduces
|
operation. Such spacing makes the code easier to follow at a skim, and reduces
|
||||||
unnecessary line noise. Coupled with the commenting scheme specified above,
|
unnecessary line noise. Coupled with the commenting scheme specified above,
|
||||||
proper spacing allows readers to quickly scan code, extracting semantics quickly.
|
proper spacing allows readers to quickly scan code, extracting semantics quickly.
|
||||||
@ -353,8 +353,8 @@ of `protoc`.
|
|||||||
|
|
||||||
The following commit hashes of related projects are also required in order to
|
The following commit hashes of related projects are also required in order to
|
||||||
generate identical compiled protos and related files:
|
generate identical compiled protos and related files:
|
||||||
* grpc-ecosystem/grpc-gateway: f2862b476edcef83412c7af8687c9cd8e4097c0f
|
* grpc-ecosystem/grpc-gateway: `f2862b476edcef83412c7af8687c9cd8e4097c0f`
|
||||||
* golang/protobuf: ab9f9a6dab164b7d1246e0e688b0ab7b94d8553e
|
* golang/protobuf: `ab9f9a6dab164b7d1246e0e688b0ab7b94d8553e`
|
||||||
|
|
||||||
Additionally, in order to maintain a uniform display of the RPC responses
|
Additionally, in order to maintain a uniform display of the RPC responses
|
||||||
rendered by `lncli`, all added or modified `protof` definitions, _must_ attach
|
rendered by `lncli`, all added or modified `protof` definitions, _must_ attach
|
||||||
@ -377,7 +377,7 @@ itself, and uses a `snake_case` style of name formatting. All added or modified
|
|||||||
### 5. Code Approval Process
|
### 5. Code Approval Process
|
||||||
|
|
||||||
This section describes the code approval process that is used for code
|
This section describes the code approval process that is used for code
|
||||||
contributions. This is how to get your changes into lnd.
|
contributions. This is how to get your changes into `lnd`.
|
||||||
|
|
||||||
<a name="CodeReview" />
|
<a name="CodeReview" />
|
||||||
|
|
||||||
|
@ -7,7 +7,7 @@ the `lnd` wire protocol.
|
|||||||
|
|
||||||
Lnd uses its own wire protocol to send and receive messages of all types. There
|
Lnd uses its own wire protocol to send and receive messages of all types. There
|
||||||
are 22 different message types, each with their own specific format. If a
|
are 22 different message types, each with their own specific format. If a
|
||||||
message is not in the correct format, lnd should logically reject the message
|
message is not in the correct format, `lnd` should logically reject the message
|
||||||
and throw an error. But what if it doesn't? What if we could sneakily craft a
|
and throw an error. But what if it doesn't? What if we could sneakily craft a
|
||||||
custom message that could pass all the necessary checks and cause an error to
|
custom message that could pass all the necessary checks and cause an error to
|
||||||
go undetected? Chaos would ensue. However, crafting such a message would require
|
go undetected? Chaos would ensue. However, crafting such a message would require
|
||||||
|
@ -1,7 +1,7 @@
|
|||||||
# How to write a Python gRPC client for the Lightning Network Daemon
|
# How to write a Python gRPC client for the Lightning Network Daemon
|
||||||
|
|
||||||
This section enumerates what you need to do to write a client that communicates
|
This section enumerates what you need to do to write a client that communicates
|
||||||
with lnd in Python.
|
with `lnd` in Python.
|
||||||
|
|
||||||
### Setup and Installation
|
### Setup and Installation
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user