lnd v0.4.2-beta

This release marks the second patch release to the recently released v0.4-beta! No new major features have been added in this release. Instead, this release packages a series of bug fixes, modifications to ensure better cross-implementation compatibility, the ability to perform on-chain seed rescans w/ full look ahead, and a series of important fixes related to the switch and state machine. No database level breaking changes have been made in this release, as a result users should be able to perform a clean update.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import roasbeef's key if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

The keybase page of roasbeef includes several attestations across distinct platforms in order to provide a degree of confidence that this release was really signed by "roasbeef".

Once you have his PGP key you can verify the release (assuming manifest-v0.4.2-beta.txt and manifest-v0.4.2-beta.txt.sig are in the current directory) with:

gpg --verify manifest-v0.4.2-beta.txt.sig

That will verify the signature on the main manifest page which ensures integrity and authenticity of the binaries you've downloaded locally. Next, depending on your operating system you should then re-calculate the sha256 sum of the binary, and compare that with the following hashes (which are included in the manifest file):

62c6d6df01d3adab63af0e25987e8567a9e1dec3b0d42c2df9a10e6cde6675d8  lnd-darwin-386-v0.4.2-beta.tar.gz
b0636c39fec61e9a4e9d19c026393b3f080d93c0c674edaf4156df2ed2b1c244  lnd-darwin-amd64-v0.4.2-beta.tar.gz
b3e8ad43ebaaa357c930020996cb7f8d0db175d8187d893a4dc02b6ab1f1bf43  lnd-dragonfly-amd64-v0.4.2-beta.tar.gz
199fe9adea0c91c1ba93eac17781234bf98e05d83780b394592b30d60c80b88d  lnd-freebsd-386-v0.4.2-beta.tar.gz
db63789a8a94b13cf8dce041e81c0a403c9cda375efbd9a02dadb9670c791114  lnd-freebsd-amd64-v0.4.2-beta.tar.gz
a38a5c8930c12988cf241028c760f50d73e900b0fc578fd7b5d291779a186989  lnd-freebsd-arm-v0.4.2-beta.tar.gz
06aab3858f141d92e602097e64725292677b68f818914c026dfebde2676a38d8  lnd-linux-386-v0.4.2-beta.tar.gz
2b6b617d804bfee5352aefcabaae9e27e58013084f9c5654d3f1185222f604c8  lnd-linux-amd64-v0.4.2-beta.tar.gz
583afca9f4ebb53bc9a9ce2b643d686c28868c05e225b64c0694140e628f928b  lnd-linux-arm-v0.4.2-beta.tar.gz
ba206e02ed589f3779500e6ab48089b8af6dba3a19526afb2263c298afc9f137  lnd-linux-arm64-v0.4.2-beta.tar.gz
2cacf4bb0e252ebea2a47cf873c198aaabe0172bd09e7ffccbc1024a4474ff34  lnd-linux-mips64-v0.4.2-beta.tar.gz
016d6e7a3482e7ca52bd6ccc76f3cb3577a8b0aaf11e62f81a8d701203ba5d9c  lnd-linux-mips64le-v0.4.2-beta.tar.gz
e2788aa696ebb6dadf8d1ee9b3636ab27f6ca235c7132f9c00805b6b06fc9070  lnd-linux-ppc64-v0.4.2-beta.tar.gz
c3e4d58cf5f1f11b1e5e594d10c53399dc31e3c0f3b585cc12dbb2ef9a5a90c4  lnd-netbsd-386-v0.4.2-beta.tar.gz
5c582a393e4bd1eacff2490c90a81da7d70e6ade80d1ce83183df37cc813d516  lnd-netbsd-amd64-v0.4.2-beta.tar.gz
26f4d6be6bc73062034333e084d546ea524506200c92ca0168f9653c90225737  lnd-openbsd-386-v0.4.2-beta.tar.gz
7ab8e802029b878b849ec2d726834097211d54faecbd61f00610df90f70a75ef  lnd-openbsd-amd64-v0.4.2-beta.tar.gz
b7ea54308ada52ab599009577f375e8ff561fda3683d62f990a0cda38a1209a3  lnd-windows-386-v0.4.2-beta.zip
807fe7edc02741e1f433110af748219158e1f47181e0aa0f9de1ce175594a520  lnd-windows-amd64-v0.4.2-beta.zip

One can use the shasum -a 256 <file name here> tool in order to re-compute the sha256 hash of the target binary for your operating system. The produced hash should be compared with the hashes listed above and they should match exactly.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.4.2-beta

You should see the following if the verification was successful:

gpg: Signature made Tue May 29 16:31:39 2018 PDT
gpg:                using RSA key 964EA263DD637C21
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

This release can also be found in roasbeef's public keybase folder.

Notable Changes

Litecoin

The max payment size and channel size for Litecoin has been increased by ~60x. This is a stop gap measure before a feature bit is added to the protocol to enable arbitrarily sized payments and channel sizes.

lnwallet

Full on-chain seed recovery with configurable look aheads is now fully implemented!. As a result, users will now be able to use their aezeed with lncli create or lncli unlock to trigger a full rescan to recover any on-chain funds. The implementation is generic, so it works with: btcd, bitcoind, and neutrino. The look ahead value is configurable in order to give users more control over the thoroughness of the on-chain key search.

We'll now ensure that that any transaction broadcast have fee rates above the min relay fee of the node lnd is connected to.

Bitcoind and btcd Chain Backends

A bug in the bitcoind chain backend has been fixed that would cause lnd to stall on start up at times due to an internal bug when attempting to rescan to see if an output has been spent or not. As a result, startup using the bitcoind backend should be generally much snappier. Future versions of lnd will continue to increase the performance of the bitcoind backend. Particularly, once the BIP 158 implementation is merged and exposed over RPC, we'll be able to use those filters for rescans internally as we do for btcd.

The txindex is now no longer required for either btcd or bitcoind!. However, users will find that lnd is generally more performant if the index is enabled, as it saves us from performing manual rescans. v0.5-beta will contain an overhaul to the way we perform historical notifications dispatches which will eliminate manual rescanning all together.

It's now possible to shutdown lnd with the lncli stop command while lnd is still syncing with the chain backend.

Configuration and Documentation

Users can now configure log rotation to optional. By default lnd will maintain 3 compressed log files on disk, rotating them over each time we fill up a new log file. When running with the trace or debug logging levels, the logging can be quite verbose, which warrants disabling log rotation all together or tweaking parms concerning the max log size and also the total number of log files to maintain.

lnd will now properly recognize the BIP 173 hrp prefix for regtest.

The Javascript docs for lnd's gRPC interface have been updated to show proper usage of macaroons and TLS cipher suites.

contractcourt

A number of bugs have been fixed in the contract court ensuring that we don't play duplicate commitments, properly lay the remote party's full set of commitments, and also ensure that all related goroutines exit properly on shutdown (c5169a7).

The ChannelArbitrator sub-system has been modified to only act on confirmed commitments. This fixes a number of bugs encountered and ensures that we'll only attempt resolve contracts which are properly buried in the chain. As a result, new state has been added to the pendingchannels RPC: commitment broadcast. Channels will be in this state once we broadcast a commitment, but before a transaction spending the funding output has been confirmed. We do this as although we broadcasted a commitment, it's possible that another distinct transaction is confirmed instead. In either case, we'll play which ever spending transaction is confirmed, and proceed to resolve any active contracts.

The ChainWatcher has been modified to ensure it always plays all possible active commitments.

For cooperative channel closes, we'll now ensure that we play the transaction which ultimately enters the chain, rather than assuming the final signed closing transaction would be the one that wins over.

Channel Funding

A bug has been fixed that would at times cause a state desynchronization if both sides were lnd nodes and had selected custom values for the CSV delay.

BreachArbiter

The BreachArbiter (the sub-system tasked with enforcing justice against cheating channel peers) has been significantly simplified. Along the way, hand off between the breach arb and the contractcourt has been improved to ensure the hand off is atomic, even in the phase of a breach at the point of a daemon shutdow...

lnd v0.4.1-beta

This release marks a minor patch release to the recently released v0.4-beta! No new major features have been added in this release. Instead, this release packages a series of bug fixes in addition to modifications to ensure better cross-implementation compatibility. No database level breaking changes have been made in this release, as a result users should be able to perform a clean update.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import roasbeef's key if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

The keybase page of roasbeef includes several attestations across distinct platforms in order to provide a degree of confidence that this release was really signed by "roasbeef".

Once you have his PGP key you can verify the release (assuming manifest-v0.4-beta.txt and manifest-v0.4.1-beta.txt.sig are in the current directory) with:

gpg --verify manifest-v0.4.1-beta.txt.sig

That will verify the signature on the main manifest page which ensures integrity and authenticity of the binaries you've downloaded locally. Next, depending on your operating system you should then re-calculate the sha256 sum of the binary, and compare that with the following hashes (which are included in the manifest file):

dd4ca874416f3a261b0e4a88c758585061d1b936d93158f6e7c0a8b0dbca6c05  lnd-darwin-386-v0.4.1-beta.tar.gz
6c46bd9a6ebd27f99eea8324c32c026983359c1d117323d9e42fa3c8ac7e49f5  lnd-darwin-amd64-v0.4.1-beta.tar.gz
0887700ffe7822fed404d6912dcb590b205629b49557edf94c8b9b6fb595b877  lnd-dragonfly-amd64-v0.4.1-beta.tar.gz
390a439efe6cd4c62e58c99415856590ec0ed7cbca6f79f89d9067a73c53017c  lnd-freebsd-386-v0.4.1-beta.tar.gz
8e9c23f71b52a0ebd219445a7d8102072c202042e18605bd95bf905bf90dc226  lnd-freebsd-amd64-v0.4.1-beta.tar.gz
8ef165cf3be3ec9a1f2e03cc305ba2d6a379449552a98d9af3b83fdfeca7f6e5  lnd-freebsd-arm-v0.4.1-beta.tar.gz
5aa9c77506a0fee1060bc88e4cd18f46fd05147ffb14d264b788b0fcd92da724  lnd-linux-386-v0.4.1-beta.tar.gz
f4582cd3ae99488165dee46f2afa7d43842413e1bdd59baba63aafd34a1e3246  lnd-linux-amd64-v0.4.1-beta.tar.gz
4ee088593b611672e51f9c131177d3c50084312ed8c4a78a04c717ed83045bc9  lnd-linux-arm-v0.4.1-beta.tar.gz
03c0b90e71067a86e14555f92071cffc641aa3cb8a11d480816e3448ea690993  lnd-linux-arm64-v0.4.1-beta.tar.gz
ab9d50e3ee784dae2ee5d65bfc0b7c5016dff760222dcc3cf10975b39fe13750  lnd-linux-mips64-v0.4.1-beta.tar.gz
eb2ec3fcaae1fee29c1872e20b8d5cad208902b55dc50e539eb6fe92bfaae9b1  lnd-linux-mips64le-v0.4.1-beta.tar.gz
9659a6713f5c9f7042fead29d046189fd7e16a2381fbbb92f8386fe35e55ea76  lnd-linux-ppc64-v0.4.1-beta.tar.gz
0ea45ca68a76ddd06b71c9897fcb31937f41a553a6276ffbd5fda0405dd30d99  lnd-netbsd-386-v0.4.1-beta.tar.gz
218adf117f4a2f4597f43f5065c67870c90fcfd91d635674d2e30bf310d1d66a  lnd-netbsd-amd64-v0.4.1-beta.tar.gz
3510bcda313017837eb47d9b0345e7a6c5157f19fe4a503649e02be4117b311b  lnd-openbsd-386-v0.4.1-beta.tar.gz
de86c0a401bfc95cb7432758d092fed01ee9af0652407d77736d7dad2d5949f1  lnd-openbsd-amd64-v0.4.1-beta.tar.gz
6c81cfa8fb6459b18a2c86843b47acb49e0325829cfd109d71dcf4b029ec5948  lnd-windows-386-v0.4.1-beta.zip
de22da756a51a298bfe7db83e3d7d5e9b21173f0c74dcaaadfe4a349ec16a786  lnd-windows-amd64-v0.4.1-beta.zip

One can use the shasum -a 256 <file name here> tool in order to re-compute the sha256 hash of the target binary for your operating system. The produced hash should be compared with the hashes listed above and they should match exactly.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.4.1-beta

You should see the following if the verification was successful:

gpg: Signature made Mon Apr  2 17:10:37 2018 PDT
gpg:                using RSA key 964EA263DD637C21
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

This release can also be found in roasbeef's public keybase folder.

Notable Changes

DNS Bootstrapping

Reported issues concerning the initial automatic peer bootrapping via DNS have been resolved. In the case that lnd had to fallback to direct TCP resolution, a bug prevented the DNS name from being fully qualified. This new release ensures we craft a valid DNS query.

Channel Funding

The min channel size that we'll create outbound has been raised to 20k satoshis.

When using the current version of autopilot users can now set the min and max channel sizes. Before this change, as this mode was primarily used on testnet, the default pilot would at times create a single channel using all available funds, which in many cases is undesirable.

Users are now able to set a custom value for the CSV parameter imposed on the remote node using the new --remote_csv_delay argument of the openchannel command. This is useful as peers that have existing business relationships may wish to relax the time-based security parameter in order to allow swift channel force closures.

A rounding error (#943) has been fixed. This would at times be an issue when converting from BTC to satoshis as returned by the various RPC interfaces. With this fix we ensure that we can no longer at times leaks a few satoshis when creating channels. On-chain sends were unaffected.

RPC

The ListChannels command now has the ability to filter out active, public, private, and inactive channels (#834). The lncli listchannels command has also gained the ability to filter out these channels with the following new arguments:

• --active_only
• --inactive_only
• --public_only
• --private_only

A new macaroon type has been added! In this release, lnd will now generate an invoice.macaroon invoice. The capabilities that this macaroon can unlock are restricted only to: listing invoices, generating invoices, subscribing for invoice notifications, and also generating new addresses (#904).

One thing to note is that we'll only generate the invoice macaroon if none of the macaroons are found. This mirrors the existing behavior to allow an instance to be spun up, only having a particular macaroon in its data directory. In order for this new macaroon to be generated, users need to delete their old set of macaroons on disk.

Payment routing

Several cross-implementation payment routing issues have been resolved. Users should find they have an easier time routing directly to another implementation, or taking a route that traverses other implementations. Additionally, we'll now more aggressively route around any faulty channels.nodes based on prior routing failures encountered.

Configuration

A new --tlsdomain config line option has been added (#864). This allows users to generate RPC certs that themselves bind to a particular domain. With this command, users are now able to expose an lnd RPC service that's accessed directly via a domain over TLS.

A new --minchansize config option has been added. This option allows users to configure the smallest channel size they'll accept as an incoming payment. Using this command, users can start to filter out the set of incoming channel requests in order to ensure their node has a healthy set of usable channels. The default value for this is 20k satoshis.

Channel State Machine

A bug that would at times cause channel desynchronization when channels peers use asymmetric dust values has been resolved (#920).

We'll now ensure that we'll only accept sane commitments. This entails performing a series of quick checks for standardness and context-free consensus rules when we create or accept new commitments. Uncompliant commitments will be rejected.

We'll now accept incoming payments that pay more than the amount stated on the invoice.

Attempted cooperative channel closures while a commitment still has lingering HTLCs are now disallowed.

Litecoin

Several minor bugs have been fixed within lnd's Litecoin mode. The most notable fix is properly using a sane dust value to ensure we only produce easily mineable commitments.

bitcoind Chain Backend

The bitcoind chain backend will now properly reconnect to bitcoind's interface for zmq in the case of a connection drop, or restart by bitcoind (c653b62).

Peer to Peer Networking

We'll no longer disconnect peers that send address types within NodeAnnouncement messages that we don't know of. This caused unnecessary connection flapping in the prior release as there are several nodes on mainnet which forward such messages (which is spec compliant).

A series of bugs have been fixed concerning automatic peer reconnection (#982), exponential backoff when retrying connections to peers. Additionally, we'll now properly perform the brontide handshake asynchronously (#1001). As a result of these fixes, users should see overall lower memory usage and less pending connection manager requests. Subsequent releases will start to introduce dynamic ban/DoS protection to further harden lnds P2P interface.

Build System

This new release of lnd packages an easier to use build system for those that are unfamiliar with go. lnd now has a primary Makefile. A new set of documentation has been added to detail the various commands and...

lnd 0.4-beta

This release marks the 4th major release of lnd! All planned breaking changes have been implemented, and any breaking database changes in the future will utilize the built-in migration system. With this release, lnd has gained a considerable feature set, deeper cross implementation compatibility, a new specialize wallet seed, comprehensive fault-tolerance logic, has had a multitude of bugs fixed, and much more!

This is the first release that comes enabled with a flag to run on Bitcoin's mainnet, and also Litecoin's mainnet. For now, the neutrino backend mode has been disabled on both main chains as the developers of lnd feel that the required testing infrastructure to ensure correct operation in the face of all edge cases has not yet been implemented. However, with this release lnd now supports using bitcoind, and bcoin in addition to btcd as full-node backends!

The maintainers of lnd would like to thank all the dedicated testers, and 60+ contributors which have helped to make this release possible!

NOTE: It is important to note that this release of lnd contains several breaking changes. As a result, users will either need to upgrade using a completely fresh installation, or remove their existing channel.db database file before upgrading. As a courtesy, we recommend that users close out their prior channels (either cooperatively if the peer is online, or unilaterally (force close) otherwise) before upgrading. A new utility command on the cil, lncli closeallchannels has been added to streamline this process.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import roasbeef's key if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import

The keybase page of roasbeef includes several attestations across distinct platforms in order to provoide a degree of confidence that this release was really signed by "roasbeef".

Once you have his PGP key you can verify the release (assuming manifest-v0.4-beta.txt and manifest-v0.4-beta.txt.sig are in the current directory) with:

gpg --verify manifest-v0.4-beta.txt.sig

That will verify the signature on the main manifest page which ensures integrity and authenticity of the binaries you've downloaded locally. Next, depending on your operating system you should then re-calculate the sha256 sum of the binary, and compare that with the following hashes (which are included in the manifest file):

db811b2c94288d50f1709508c72a35d1893b31fdfb54b2e19a4a65c92f32c581  lnd-darwin-386-v0.4-beta.tar.gz
bcf7813522d9461f27e47ee7879d00ebf45002ad497a1907c7a4312ee3800f0b  lnd-darwin-amd64-v0.4-beta.tar.gz
d75a52a695fabee8c18fd8880120b86e891a1689c51fabd5a947584824223284  lnd-freebsd-386-v0.4-beta.tar.gz
86db36bf033e1237ea778f2ba6dbf82b750a2524796e3240803855db941ed8eb  lnd-freebsd-amd64-v0.4-beta.tar.gz
43df7ec2eda8e754374b9065259afac360a57bf6c6698b5103aa137061616bbc  lnd-freebsd-arm-v0.4-beta.tar.gz
fbda15e493fcf4e187a15852b3ae686cc0df2abdf91c846fcaef3e74df2d5c64  lnd-linux-386-v0.4-beta.tar.gz
dd781604c1f946414c0b053e6ae71b323556dbe4ff87f59408b6b13993e8d688  lnd-linux-amd64-v0.4-beta.tar.gz
be5d855d0ddb4db6db9861e86abd01c227ac892dd0cab8dd3610ff12287035a4  lnd-linux-arm-v0.4-beta.tar.gz
8e04d769c903805a20bafb79ae38ef50b0b98261b79e31ccc99edf5e41306446  lnd-linux-arm64-v0.4-beta.tar.gz
6e0d73c5f63a7500109945787121a479197b6c6af6593a9fabd4286f27d980af  lnd-linux-mips64-v0.4-beta.tar.gz
f5e0eb6489346a649dbc85cf69872d6c1fe3c3e3c957d8487529734144b8f0bb  lnd-linux-mips64le-v0.4-beta.tar.gz
ca6a99fce87afb9d542d299bd50d957846679840ddf00e1be137ce9bc281622a  lnd-linux-ppc64-v0.4-beta.tar.gz
021814819002fb004cfe302c17fded9597567feaf38ee92ad8d7c07bebd8eb25  lnd-netbsd-386-v0.4-beta.tar.gz
e94aeb38b7d7124b29bb6628b28b752d650baa68e3247392294dc4700d208059  lnd-netbsd-amd64-v0.4-beta.tar.gz
a985e6ece98e6eb4d5170ca232517374625e29146946d36bc6f168f30f39c556  lnd-openbsd-386-v0.4-beta.tar.gz
3c7889892a205f7734be9b1c5fa832e0e9c14c29eec30019a026c1907e0a6112  lnd-openbsd-amd64-v0.4-beta.tar.gz
d039c371d01bf788d26cb2876ceafcb21f40f705c98bb0b0b9cf6558cac4ca23  lnd-windows-386-v0.4-beta.zip
1245abe9adeb2fab74fe57d62b6d8c09d30b9ada002cd95868a33406e5a14796  lnd-windows-amd64-v0.4-beta.zip

One can use the shasum -a 256 <file name here> tool in order to re-compute the sha256 hash of the target binary for your operating system. The produced hash should be compared with the hashes listed above and they should match exactly.

This release can also be found in roasbeef's public keybase folder.

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Notable Changes

Switch to dep for dependency management

In this release, we've switched to dep to handle all dependency management within lnd. In prior release we used a tool called glide. However, glide is no longer being actively developed, and dep provides a much more stream lined UX compared to glide. Most operations can be completed with a simple dep ensure. All installation guides have been updated to account for the new way of syncing the set of dependancies that lnd requires. We're also keeping an eye on vgo as it aligns well with our short-term goal of producing fully verifiable builds for future release.

New Directory Structure

The default directory structure of lnd has been fully revamped, and shouldn't change for the foreseeable feature. After we added dual-chain support, the directory structure was sitting in a bit of an awkward position, as it was only half way to supporting for multi-chain (simultaneous active chains) within lnd. The new structure is now future proof as it maintains a shared channel.db (where all the channel specific state lives), and segmented chain directories that will store the wallet specific information for each chain.

Example of new data directory structure

data/
├── admin.macaroon                                                  
├── chain                                                           
│   ├── bitcoin                                                     
│   │   └── testnet                                                 
│   │       ├── block_headers.bin                                   
│   │       ├── ext_filter_headers.bin                              
│   │       ├── neutrino.db                                         
│   │       ├── reg_filter_headers.bin                              
│   │       └── wallet.db                                           
│   └── litecoin                                                    
│       └── testnet4                                                
│           └── wallet.db                                           
├── graph                                                           
│   └── testnet                                                     
│       └── channel.db                                              
├── macaroons.db                                                    
└── readonly.macaroon 

Example of new log directory structure

log/
└── bitcoin
    └── testnet
        └── lnd.log

Additionally, we'll no longer have a hard coded, unchangeable directory location for lnd's home directory. Instead, users can now use the --lnddir=X argument to set the home directory of lnd to an arbitrary location.

Automatic Peer Bootstrapping

With this release, lnd will now automatically seek out peers to connect with upon initial startup. In order to implement this functionality, we've added a new interface the to discovery package:
NetworkPeerBootstrapper. The NetworkPeerBootstrapper interface is meant to be used to bootstrap a new peer joining the network to the set of existing active peers within the network. Callers are encouraged to utilize several boostrappers in series as redundant sources of information. The MultiSourceBootstrap function will takes a set of boostrappers, and compose their outputs into a single unified set of addresses.

Two concrete implementations of the NetworkPeerBootstrapper interface have been added as a part of this release: the ChannelGraphBootstrapper and the DNSSeedBootstrapper. The former will utilize the authenticated node advertisements within the calling nodes view to boostrap new connections. The latter will use a set of BOLT-0010 compliant DNS seeds to query. This DNS seeding more will likely be used by nodes initial joining the network, as they may not yet have the channel graph as they haven’t connected to any peers. We've also extended our DNS seeder with support for queries over TCP. It was observed that users behind certain name resolvers would filter out the results of our SRV queries. As a result, if we detect this, we'll connect directly over TCP in order to complete the initial bootstrap.

As of this release, there are 3 active DNS seeders queryable:

node.lightning.directory (BTC mainnet)
ltc.nodes.lightning.directory (L...

lnd v0.3-alpha

This release marks the 3rd major release for lnd! With this release, lnd is now has gained a considerable feature set, a new automatic channel management operating mode, RPC authentication, additional persistence logic, and further major strides towards complete spec compliance.

This release lands on the eve of the activation of segwit on Bitcoin's mainnet 🎉! As the developers of lnd, we're extremely excited to see Lightning integrated into the ecosystem, and to see all the novel applications that developers will buildout! However, we recommend that users of lnd do not yet attempt to use the software on the live network with real funds. We're getting very close to enabling a mainnet mode usage, but at this point necessary safety and fault tolerance measures aren't yet in place. With our next release: lnd v0.4-beta, we'll be targeting full spec compliance, cross-implementation interoperability, and the additional assurance and safety measures we deem necessary before adding a mainnet mode to the software.

NOTE: It is important to note that this release of lnd contains several breaking changes. As a result, users will either need to upgrade using a completely fresh installation, or remove their existing channel.db database file before upgrading. As a courtesy, we recommend that users close out their prior channels (either cooperatively if the peer is online, or unilaterally (force close) otherwise) before upgrading.

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Notable Changes

TLS Integration and Macaroon Based RPC Authentication

In this release of lnd, we now enforce the usage of TLS by default when communicating with the RPC server either via gRPC or the HTTP interface. In addition the the server authentication, we now also expose per-call RPC authentication. This mode is on by default, and can be disabled with the --no-macaroonsflag on the command line, or the corresponding line within ones lnd.conf configuration file.

For per-call RPC authentication, lnd currently uses macaroons. Macaroons are bearer credentials that are based on a construction of nested HMAC calls with a single root IV key. The root key is kept secret by the server and allows it to mint (or bake) new macaroons and also authenticate the validity of presented macaroons. Macaroons are bearer credentials meaning presenting or holding the macaroon entitles the holder to a specific set of capabilities. Macaroons are very flexible and allow the holder of a particular macaroon to add additional caveats which contextually confine the set of capabilities unlocked by the macaroon. Currently we only expose two flavors of macaroons: an admin macaroon which allows unrestricted access to all RPC calls, and a read-only macaroon which is created by adding caveats to the admin macaroon dictating which calls the holder of the macaroon can access.

In the future, we'll be adding additional granularity of the usage of macaroons within lnd. We believe tha macaroons are very exciting as they enable a very flexible mechanism of authentication which can be used to build applications upon lnd which have the most minimal set of capabilities possible. For example, imagine an application built on top of lnd which only needs access to a particular channel, and will only be sending payments below N satoshis over said channel. The flexibility of the macaroon scheme makes it easy for lnd to bake such a macaroon and present it to the application in question.

Litecoin Operating Mode

In this release, we've added support for a toggle-able Litecoin chain and wallet backend. This means that lnd is now capable for easily switching back and forth between the Bitcoin and Litecoin chains. This is very exciting as the code scaffolding put in place to make this switch seamless also lays some important ground work for the multi-chain lnd operating mode that is under development. With multi-chain, lnd will be able to manage channels on both Bitcoin and Litecoin simultaneously. In the near future, this means that lnd nodes with channels on both chains will be able to acts as a border node between the two networks, facilitating instant swaps and transfers between the two chains.

The daemon backend configuration options have been split, into two mirroring option classes for both Bitcoin and Litecoin:

Litecoin:
      --litecoin.active        If the chain should be active or not.
      --litecoin.chaindir=     The directory to store the chains's data within.
      --litecoin.rpchost=      The daemon's rpc listening address. If a port is omitted, then the default port for the selected chain parameters will be used. (localhost)
      --litecoin.rpcuser=      Username for RPC connections
      --litecoin.rpcpass=      Password for RPC connections
      --litecoin.rpccert=      File containing the daemon's certificate file (/Users/roasbeef/Library/Application Support/Ltcd/rpc.cert)
      --litecoin.rawrpccert=   The raw bytes of the daemon's PEM-encoded certificate chain which will be used to authenticate the RPC connection.
      --litecoin.testnet       Use the test network
      --litecoin.simnet        Use the simulation test network
      --litecoin.regtest       Use the regression test network

Bitcoin:
      --bitcoin.active         If the chain should be active or not.
      --bitcoin.chaindir=      The directory to store the chains's data within.
      --bitcoin.rpchost=       The daemon's rpc listening address. If a port is omitted, then the default port for the selected chain parameters will be used. (localhost)
      --bitcoin.rpcuser=       Username for RPC connections
      --bitcoin.rpcpass=       Password for RPC connections
      --bitcoin.rpccert=       File containing the daemon's certificate file (/Users/roasbeef/Library/Application Support/Btcd/rpc.cert)
      --bitcoin.rawrpccert=    The raw bytes of the daemon's PEM-encoded certificate chain which will be used to authenticate the RPC connection.
      --bitcoin.testnet        Use the test network
      --bitcoin.simnet         Use the simulation test network
      --bitcoin.regtest        Use the regression test network

Our docker configuration has been updated to allow users to spin up a cluster of lnd nodes on simnet or testnet of either Bitcoin or Litecoin.

autopilot: Self-Driving Lightning

This release also includes the first of many planned flavors of automatic channel management. We call this new operating node autopilot as if set, will automatically manage the opening of channels within the network. This operating mode is attractive is it enables a new level of plug-and-play interaction with the daemon, and can also be used in aggregate to tend the ultimate topology of the channel graph to one of a set of heuristically determined characteristics.

The autopilot operating mode is essentially a closed-loop control system: it takes in outside input such as the number of channels opened, when channels are closed, changes in the wallet balance and applies that to its internal state. Once outside signals are received, it then consults it's registered heuristic to decide: if it needs more channels, and if so to whom those channels should be opened to. The Agent then carries out the recommendations by the registered heuristic, ultimately going back to the top of it's loop to await further outside signals.

The autopilot package has been signed to be as abstract as possible in order to allow users, developers, and researchers to plug in various heuristics in order to experiment with the possibilities, or attempt to optimize the channel sub-graph for their targeted nodes. The current default heuristic is a mode called
ConstrainedPrefAttachment. This heuristic takes a set of inputs parameters, namely: the smallest allows channel size, the max channel size, the max number of active channels, and a target balance of funds within channels vs regular on-chain utxo's. Given this set of constraints (eg: 4 channels, 40% of available funds), given the known channel graph, the heuristic will employ an channel attachment recommendation driven by the Barabási–Albert model in order to attempt to drive the global graph towards a scale free topology. This is only one example of the possible heuristics which could be hooked into an active autopilot.Agent instance. We look forward to the additional heuristics that developers/researchers will implement! The package has been crafted such that, it facilitates easily generating a simulated graph with several agents each following the same heuristic, or a heterogenous set.

The current default heuristic can be activated, and configured with the following new command line flags:

autopilot:
      --autopilot.active       If the autopilot agent should be active or not.
      --autopilot.maxchannels= The maximum number of channels that should be created (5)
      --autopilot.allocation=  The percentage of total funds that should be committed to automatic channel establishment (0.6)

neutrino: a new Bitcoin Light Client Operating Mode

In prior release of lnd, the only configurable chain-backend was communicating directly with btcd over its websockets RPC interface. In this release, we've added a new configurable chain-backend: neutrino. With this option, it's now possible to run lnd standalone, as `neutri...

lnd v0.2.1-alpha

lnd-v0.2.1-alpha marks the first minor patch release after our latest release (lnd-v0.2-alpha). This release includes a number of bugs reported by our testers and encountered during normal usage after the latest release. No major features or RPC command have been altered with this release, therefore users should be able to upgrade to this new version without preforming any precautionary steps.

0.2.1-alpha Change Log

Routing

• 41a5414 -- routing: capitalize first letter of new error messages
• f7c8938 -- discovery: use debug logging level for rejected announcements
• 2d10d83 -- routing: assert that paths have same length in isSamePath
• a4e26ea -- routing: fix bug in path finding when len(rootPath) > len(shortestPath)
• 5442e42 -- routing: fix slice mutation bug that could result in an infinite loop

RPC Server

• 9ff4a7a -- rpcserver: use semaphore to limit # of goroutines in SendPayment

Wallet

• 0858d8a -- lnwallet: fix constant overflow build issue on 32-bit systems
• eca3a10 -- lnwallet: reorder PaymentDescriptor attributes to reduce padding
• a3fd738 -- lnwallet: fix HTLC mutation bug in commitment chain
• 4cd277c -- lnwallet: eliminate usage of LightningChannel.theirPrevPkScript
• 31acace -- lnwallet: convert PendingUpdates to FullySynced
• 17d6835 -- lnwallet: removed unused sync.RWMutex in PaymentDescriptor

Peer

• 3393f3a -- peer: simplify channel state update handling by using
• 178f26b -- peer: restore the htlcManager's logCommitTimer to a persistent ticker
• 54c63f4 -- peer: remove unused lastNMessages map
• b51a0eb -- peer: increase initial handshake timeout to 15 seconds

Docs

• 35c9a12 -- docs: fix port in sample lnd.conf

Server

• a22ba92 -- server: eliminate possibly deadlock, peerConnected now async
• d93e3e6 -- server: assume default port if one not present for --externalip

Database

• fe3c364 -- channeldb: use the Batch method when writing payment details

Command Line Utility

• 2cb6878 -- cmd/lncli: make getnodeinfo accept positional arguments

UTXO Nursery

• e43d1dd -- utxonursery: log process of catch up graduation on restart

Test Framework

• 07437f6 -- test: update the ConnectPeer framework method to block until connect

Contributors (Alphabetical Order):

• Alex Akselrod
• Olaoluwa Osuntokun

lnd v0.2-alpha

lnd-v0.2-alpha marks the latest minor (but in a sense major) release of lnd! This release represents a substantial step forward in the stability, feature set, BOLT specification compliance, performance, reliability and maturity of lnd and also Lightning as a whole.

As the lead maintainer of the lnd software, I would like to express my gratitude to the extremely dedicated community of software testers and application developers that have started to emerge around lnd. Your swift bug reports, constant experimentation, and passion for the system you're helping to create have significantly accelerated the development progress of lnd, and for that I deeply thank you. In no particular order, I would like to recognize the efforts of (also bare in mind this isn't an exhaustive list):

• moli
• juscamarena
• takinbo
• mably
• weedcoder
• dts

NOTE: It is important to note that this release of lnd contains several breaking changes. As a result, users will either need to upgrade using a completely fresh installation, or remove their existing channel.db database file before upgrading. As a courtesy, we recommend that users close out their prior channels (either cooperatively if the peer is online, or unilaterally (force close) otherwise) before upgrading.

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Notable Changes

Sphinx Packet Shared Secret Derivation Change

The method we use to generate the shared secret which is used to derive several keys used in the generation and processing of our Sphinx packets used in multi-hop routing has been modified. Previously we directly used the btcec.GenerateSharedSecret method which returned the raw bytes of the x-coordinate of the derived shared point. After our last release the BOLT#4 specification was modified to instead utilize the SHA-256 of the entire coordinate serialized in compressed format. Within the specification this derivation method was modified in order to align ourselves with the ECDH method used by libsecp256k1, a widely used and extremely well tested library within the Bitcoin ecosystem.

lncli Support for Positional Arguments

The lncli command line tool has now gained support for positional arguments, keyword arguments, and mixing the two within most command line commands. This change was made in order to minimize the required typing for users on the command lone. For example, commands like:

lncli openchannel --node_key=7a379c554dd680083432648e4416255deaf113d655d002baea62652cd9e5b95f --local_amt=100000000 --push_amt=50000 --num_confs=5

Can now optionally be entered as:

lncli openchannel 7a379c554dd680083432648e4416255deaf113d655d002baea62652cd9e5b95f 100000000 50000 5

Multi-Path Payment Path Finding

In this release of lnd, when attempting to select a candidate path for a payment requests we now utilize a modified version of Yen's algorithm to select a set of candidate paths which themselves each have the necessary capacity to carry a target payment. Within our modified version of Yen's algorithm, rather than removing conflicting edges in the current root path and non-spur node edges from the root path, we instead utilize a black-list of edges and vertexes which are to be ignored within the K_ith iteration. This allows us to avoid loading the entire graph into memory during our repeated graph traversals.

Once we obtain a set of candidate payments paths, we then rank the set of candidate paths according to the cumulative fee-rate, and then cumulative absolute time-lock value. As a result, the dispatch of payments within the daemon is now much more reliable as we're able to serially fall-back to lower ranked paths in the case that a payment attempt to the highest ranked path fails.

Additionally, the version of Dijkstra's algorithm we employ (which is used as a subroutine within Yen's) has been modified to: include the capacity of a target edge within the relaxation condition, utilize a binary heap when selecting the next edge to greedily explore and gains white-box knowledge of its role in Yen's algorithm. Finally, we've added an additional layer of caching/memoization of the map: {paymentAmt, targetVertex} -> [path_1, path_2, ....path_n]. Such caching serves as a significant optimization as we are able to skip any dis access when querying repeated payment tuple if no new edges have been added to the graph or modified since the last invocation.

Due to the changes above, the queryroute within the lncli tool and the QueryRoute RPC command of the gRPC Lightning service is no more. Instead they've been replaced with queryroutes and QueryRoutes which are identical to their predecessor commands aside from the fact that they now return a list of all eligible candidate paths rather than simply returning the first available path and exiting.

Complete Authenticated Channel Graph Verification

In the prior release(s) of lnd, the daemon didn't fully verify the authenticity of all vertex and edge announcements within the graph. This meant that lnd would gladly accept an invalid or false channel to it's channel graph, or a forged node announcement as a vertex within the graph. With this release, we now both fully validate all edge+vertex announcements seen within the network, and also generate valid channel authentication and node announcement proofs.

These changes eliminate a class of error encountered by our alpha testers wherein an invalid or non-existent channel would be accepted to the channel graph leading to egregious payment routing failures. Furthermore, with this change, lnd is now fully compliant with BOLT#7. Due to this change, the prior channel graph generate and accepted by prior version of lnd has now been invalidated.

BOLT Commitment State Machine Compliance

In the prior releases of lnd we utilized a channel commitment update state machine which pre-dated the one currently specified within the current BOLT drafts. This statement used an "initial revocation window" which was then dynamically adjusted using a TCP sliding window like commitment update procedure with explicit log indexes used in state transitions. In this new release of lnd, we've now restricted the functionality of lnd's state machine in order to comply with the current BOLT drafts. One minor deviation still exists: we use an initial revocation window of 1, as our current funding state machine still requires such as construct.

Independent of the modification of lnd's state machine a number of minor bugs within the state machine itself have been fixed which include: an incorrect reporting of the number of HTLC/s within the htlcSwitch logs, a fix for a HTLC commitment transaction overflow bug which could results in state desynchronization, and an omitted HTLC cancellation error back propagation within the state machine.

Graph Topology Notification Client

With this release of lnd we've added a new serving streaming RPC command. This RPC command, tilted: SubscribeChannelGraph allows callers to receive streaming asynchronous notification whenever the channel graph has been updated from the PoV of the serving lnd node. Within our integration tests usage of this new streaming RPC has allowed us tighten the running time of our integration test and eliminate several lingering flakes. Outside of our integration tests the addition of this new streaming RPC call opens up the door for client side applications to dynamically render the known channel graph in real-time.

The added gRPC stub service and new proto definitions follow:

rpc SubscribeChannelGraph(GraphTopologySubscription) returns (stream GraphTopologyUpdate);
message GraphTopologySubscription {}
message GraphTopologyUpdate {
    repeated NodeUpdate node_updates = 1; 
    repeated ChannelEdgeUpdate channel_updates = 2;
    repeated ClosedChannelUpdate closed_chans = 3;
}
message NodeUpdate {
    repeated string addresses = 1;
    string identity_key = 2;
    bytes global_features = 3;
    string alias = 4;
}
message ChannelEdgeUpdate {
    uint64 chan_id = 1;
    ChannelPoint chan_point = 2;
    int64 capacity = 3;
    RoutingPolicy routing_policy  = 4;
    string advertising_node  = 5;
    string connecting_node = 6;
}
message ClosedChannelUpdate {
    uint64 chan_id = 1;
    int64 capacity = 2;
    uint32 closed_height = 3;
    ChannelPoint chan_point = 4;
}

--externalip observance by NodeAnnouncement

In the prior releases of lnd, the externalip command-line/configuration parameter was present, yet unobserved and unused. With this new release of lnd, users that wish to advertise their willingness to accept inbound connection to establish channels from participants on the network should set their --externalip parameter to their publicly reachable IP address. Along with a set of global features, if set, this value will now be advertised to the network.

A future minor release of lnd will utilize this new reachability information to optionally automatically bootstrap a persistent channel balance by automatically maintaining a set of channels with peers selected via various heuristics.

Near Uniform Usage of Satoshis within the RPC Interface

In prior releases of lnd, we mixed the usage of BTC and Satoshis within he RPC interface, both when accepting input and displaying results to the user. In order...

lnd v0.1.1-alpha

This release marks the first minor point release after the initial release of lnd v0.1-alpha.

This release contains a number of bug fixes reported by testers exercising the prior release on testnet which were reported on IRC (#lnd on freenode), and also encountered via various interactions with the current proto Lightning Network developing on test. Some RPC's have had their responses augmented with additional data, but no new breaking change have been introduced in this release. Thanks to everyone that has been experimenting with lnd so far! Your feedback has been very valuable.

Notable Changes

Partial Channel Advertisement

Before this release, there was an implicit assumption in the daemon that both directed edges of a channel would always be advertised within the network. This assumption is false as whether or not to advertise the directed edge of the channel they control is a matter of node policy. This assumption led to a series of bugs when only one half of a ChannelUpdateAnnouncement was propagated through the network.

This release now properly supports partial channel advertisement by properly handling the non-existence of a directed of a channel with the ChannelGraph, ChannelRouter, and rpcSever.

Minimum Channel Size

Currently within the daemon, due to hardcoded fees in certain areas, the minimum channel size is 6000 SAT. Before this release creation of a channel funded with less than 6000 SAT would be allowed, but then the node would find that they were unable to close the channel due to the attempted creation of a negative valued output.

Full dynamic fee calculation and usage is planned for lnd, but until then, we now enforce a soft-limit on the minimum channel size that the daemon will created. To reiterate, this a temporary change and will be lifted in a future release.

Full Docker Configuration for Testnet

With this release, we now include a full docker configuration set up that will make it much easier to set up lnd. Within the new README for the docker package, we now outline two workflows for using the new configuration.

The first workflow walks the user through setting up a test Lightning Network cluster on their local machine using simnet. This set up can be useful to debug new features one is attempting to add to lnd or just to experiment with the capabilities of the daemon on a private network constrained to your local machine. Think of it sort of as a lightning-network-in-a-box.

The second workflow targets Bitcoin's current testnet and cleanly packages up both lnd and btcd allowing users to deploy both and join the network with just a few docker related commands. This container set up has been fashioned such that one doesn't even need Go or any other dependancies installed on their local machine before booting up lnd. The docker configuration will handle all the ncessary set up within the created containers.

RPC Interface Modifications:

Two new RPC commands have been added to lnd.

The first is the debuglevel command. This command lets uses modify the verbosity level of lnd's logs via the command line interface, or directly using gRPC. The RPC can either target a caorse grained, daemon wide logging level:

lncli debuglevel --level=debug

Or instead target a set of specific sub-systems with a more fine-grained level-spec target:

lncli debuglevel --level=PEER=trace

The second new RPC packaged as a part of this release is the decodepayreq command. This command allows users to decode an encoded payment request in order to obtain the exact conditions of the encoded payment request.

Example usage:

▶ lncli decodepayreq --pay_req=yep3c3bqqe43f5ombfca89t4r5rmenhjr4me5n5ind1t3fbj4tmn3jpyi4peh53jaoy7em4xoaxfcg7o7ircwcfb3dwz9najwfuhe5mbyyyyyyyyyyb6tg9yuk1y
{
    "destination": "021b96642e723592ee0b095983fe3a26c8b40b8926968d8b7510e51c9429d4562c",
    "payment_hash": "a5a0ae9a8e6f29c401d42f4f861e561bb0ed48ca30a1c8e97f8b09a167c46d61",
    "num_satoshis": 1000
}%

The final RPC interface modification concerts the sendpayment RPC command. The RPC command now returns the full route the payment took within the network to arrive at the target destination. This slight change gives users a greater degree of visibility into the network, detailing the fees and total time-lock required for the route.

Example usage:

github.com/lightningnetwork/lnd  master ✗                                                                                                                                                                      4d ◒
▶ lncli sendpayment --pay_req=yep3c3bqqe43f5ombfca89t4r5rmenhjr4me5n5ind1t3fbj4tmn3jpyi4peh53jaoy7em4xoaxfcg7o7ircwcfb3dwz9najwfuhe5mbyyyyyyyyyyb6tg9yuk1y
{
    "payment_route": {
        "total_time_lock": 2,
        "total_amt": 1000,
        "hops": [
            {
                "chan_id": 1191986053231738880,
                "chan_capacity": 100000000,
                "amt_to_forward": 1000
            },
            {
                "chan_id": 1190997592276926465,
                "chan_capacity": 100000000,
                "amt_to_forward": 1000
            }
        ]
    }
}%

0.1.1-alpha Change Log

Docs

• 1e8a801 -- docs: update INSTALL.md with new btcd commit hash, correct instructions

Database

• 5c41167 -- channeldb: return correct error when unable to find node
• 7a36fb4 -- channeldb: fix assumption that both channel edges will always be advertised
• 0c7fcb1 -- routing: fix nil pointer panic when node has no outgoing channels
• 7312565 -- routing: allow full syncing graph state with partially advertised edges
• e7631c9 -- rpcserver: ensure graph RPC's work with partially advertised channels

Wire Protocol

• d884efe -- lnwire+lnd: Make Logging Messages Great Again
• f82d957 -- lnwire+peer: introduce new error for unknown message type for forward compat

RPC

• 6a67d48 -- lnrpc: add CloseChannel to README description of RPC calls
• d79530e -- lnrpc: add encoded payment requests to the ListInvoices response
• 0bfdcde -- rpcserver: include encoded payment requesting ListInvoices response
• 9b4ac77 -- rpcserver: allow channels to be opened using --node_id
• 6beaa7f -- lnrpc: add DebugLevel command
• 012480b -- rpcsever: implement DebugLevel command
• ee96052 -- cmd/lncli: add parsing+dispatch for the debuglevel command
• 765d9fd -- lnrpc: return route taken in SendPayment response
• 7d6d818 -- rpcserver: return full path payments go over in SendPayment
• fb523ff -- rpcserver: add a min channel size for funding requests
• 440cf6f -- rpcserver: properly limit min channel size
• faae0b3 -- lnrpc: add new RPC to decode payment requests
• 9662887 -- rpcserver+cmd/lncli: implement DecodePayReq

Lightning Payments

• 99c1ef6 -- lnd: add additional logging statement on payment recv

Typos

• 9588861 -- multi: minor fixes for README's
• #99 51d53ea -- test: fix typos
• #101 40c7bac -- multi: fix a variety of typos throughout the repo

ChainNotifier

• cc4617c -- chainntnfs: break out of loop once txIndex is found

On-Chain Channel Events

• 8990de4 -- breacharbiter: ensure failure to retrieve channels triggers start-up error
• 1cbdf64 -- utxonursery: ensure we don't attempt to create negative value'd outputs

Configuration

• d7a050b -- config: remove deprecated configuration parameters

README

• #100 a13ac90 -- multi: add link to LICENSE in README license badges
• #99 299217a -- README: reformat and add IRC badge

Docker

• #99 a421069 -- docker: add send payment alice->bob workflow for newcomers
• a070d41 -- docker: add example output to commands in workflow
• be66e03 -- docker: general improvements
• 67b300f -- docker: make blockchain persistant
• 0948bc3 -- docker: add BITCOIN_NETWORK param
• 0325b0c -- docker: add 'Connect to faucet lightning node' section in readme
• 49df1b0 -- docker: make 'lnd' dockerfile download project from github rather than mount it localy

Build

• e057684 -- travis: update build to go1.7.4
• ff74d83 -- build: add release script
• c40cb49 -- build: update glide.lock to latest commit hashes
• 6405b1c -- glide: pin sphinx package dependency at the commit level

Integration Tests

• dc28052...

lnd v0.1-alpha

lnd - Lightning Network Daemon v0.1-alpha

This release marks the first pre-release for lnd, the Lightning Network Daemon. With this release, lnd implements a complete Lightning node capable of: opening channels with peers, closing channels, completely handling all cooperative and non-cooperative channel states, maintaining a fully authenticated+validated channel graph, performing path finding within the network, passively forwarding incoming payments, and sending outgoing onion-encrypted payments through the network.

Lightning Network Specification Compliance

Witth this release, lnd doesn't yet fully conform to the Lightning Network specification
(BOLT's). 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
  • lnd currently utilizes a distinct wire format which was created before
    the emgergence of the current draft of BOLT specifications. We don't
    have an init message, but we do have analogues to all the other
    defined message types.
• BOLT 2: Peer Protocol for Channel Management
  • lnd implements all the functionality defined within the document,
    however we currently use a different set of wire messages. Additionally,
    lnd uses a distinct commitment update state-machine and doesn't yet
    support dynamically updating commitment fees.
• BOLT 3: Bitcoin Transaction and Script Formats
  • lnd currently uses a commitment design from a prior iteration of the
    protocol. Revocation secret generation is handled by elkrem and 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

Contributors (alphabetical order):

• Alex Akselrod
• Aleksei Ostrovskiy
• Andrew Samokhvalov
• Bryan Bishop (kanzure)
• Bryan Vu
• Christopher Jämthagen
• Evgeniy Scherbina
• John Newbery
• Joseph Poon
• Mykola Sakhno
• Olaoluwa Osuntokun (roasbeef)
• Riccardo Casatta
• PaulCapestany
• Slava Zhigulin
• Tadge Dryja