lnd version, "hacked" to enable seedless restore from xprv + scb
5301da790c
This commit fixes an lingering bug within the path finding logic of the router. Previously we used the edge policy directly attached to the outgoing channel of the node we were traversing to calculate the fees and time lock information. This is incorrect, as we instead should be using the policy of the *connecting* node as we’ll need to pay for transit as they dictate. To remedy this, we now grab the incoming+outgoing edges and use those accordingly when building the initial path. |
||
|---|---|---|
| autopilot | ||
| brontide | ||
| chainntnfs | ||
| channeldb | ||
| cmd/lncli | ||
| contrib | ||
| discovery | ||
| docker | ||
| docs | ||
| htlcswitch | ||
| lnrpc | ||
| lnwallet | ||
| lnwire | ||
| macaroons | ||
| routing | ||
| shachain | ||
| zpay32 | ||
| .gitignore | ||
| .travis.yml | ||
| breacharbiter.go | ||
| chainregistry.go | ||
| config.go | ||
| doc.go | ||
| features.go | ||
| fundingmanager_test.go | ||
| fundingmanager.go | ||
| glide.lock | ||
| glide.yaml | ||
| gotest.sh | ||
| invoiceregistry.go | ||
| LICENSE | ||
| lnd_test.go | ||
| lnd.go | ||
| log.go | ||
| mock.go | ||
| networktest_test.go | ||
| networktest.go | ||
| nodesigner.go | ||
| params.go | ||
| peer_test.go | ||
| peer.go | ||
| pilot.go | ||
| README.md | ||
| release.sh | ||
| rpcserver.go | ||
| server.go | ||
| signal.go | ||
| test_utils.go | ||
| utxonursery_test.go | ||
| utxonursery.go | ||
| version.go | ||
Lightning Network Daemon
The Lightning Network Daemon (lnd) - is a complete implementation of a
Lightning Network node and currently
deployed on testnet4 - the Bitcoin Test Network. It utilizes an
upcoming upgrade to Bitcoin: Segregated Witness (segwit). The
project's codebase uses the btcsuite set
of Bitcoin libraries, and is currently dependant on btcd.
In the current state lnd is capable of:
- creating channels
- closing channels
- completely managing all channel states (including the exceptional ones!)
- maintaining a fully authenticated+validated channel graph
- performing path finding within the network, passively forwarding incoming payments
- sending outgoing onion-encrypted payments through the network
Lightning Network Specification Compliance
lnd doesn't yet fully conform to the Lightning Network specification
(BOLTs). BOLT stands
for: Basic of Lightning Technologies. The specifications are currently being drafted
by several groups of implementers based around the world including the
developers of lnd. The set of specification documents as well as our
implementation of the specification are still a work-in-progress. With that
said, lnd the current status of lnd's BOLT compliance is:
- BOLT 1: Base Protocol
lndcurrently utilizes a distinct wire format which was created before the emgergence of the current draft of BOLT specifications. We don't have aninitmessage, but we do have analogues to all the other defined message types.
- BOLT 2: Peer Protocol for Channel Management
lndimplements all the functionality defined within the document, however we currently use a different set of wire messages. Additionally,lnduses a distinct commitment update state-machine and doesn't yet support dynamically updating commitment fees.
- BOLT 3: Bitcoin Transaction and Script Formats
lndcurrently uses a commitment design from a prior iteration of the protocol. Revocation secret generation is handled byelkremand our scripts are slightly different.
- BOLT 4: Onion Routing Protocol
- BOLT 5: Recommendations for On-chain Transaction Handling
- BOLT 7: P2P Node and Channel Discovery
- BOLT 8: Encrypted and Authenticated Transport
Installation
In order to build from source, please see the installation instructions.
IRC
- irc.freenode.net
- channel #lnd
- webchat