v0.1.3-alpha

This release is the third minor release for the application! Several bugs have been fixed on the backend. Additionally, the UI has received a few minimal updates.

NOTE: the version of lnd packaged includes a breaking change. As a result, before updating we recommend that users close out all their active channels, and also transfer any testnet coins they wish to hold onto to an external wallet before updating.

Before updating, users will need to remove all data from lnd's home data directory. This is required as there have been some breaking database changes within lnd itself. Depending on your operating system, the data directory will be found in a different location on the file system:

• MacOS: $HOME/Library/Application Support/Lnd
• Windows: %LOCALAPPDATA%\Lnd
• Linux: ~/.lnd

This release is pinned against the following commit of lnd: lightningnetwork/lnd@c0b8c29

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.1.3-alpha.txt and manifest-v0.1.3-alpha.txt.sig are in the current directory) with:

gpg --verify manifest-v0.1.3-alpha.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):

83159bb69c4eefc0670e250c29c275bd955e7d25b6a3a0fc1625a891c2127ee7  Lightning-darwin-x64v0.1.3.zip
04da4ddf32cb31b33c993d62213a7d97d92f1e6c58d7f54d73789bf938ed1492  Lightning-linux-x64v0.1.3.tar.gz
a15c39e642ed373610114def2352edebf4f92ff5fa4ac7863a96ed35959627c0  Lightning-win32-x64v0.1.3.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.

Notable Fixes

UI

The scrolling logs section in the settings page will now properly

Channel Graph Maintenance

The ChannelRouter within lnd will now properly respond to re-orgs by pruning any newly unconfirmed existing channel edges from the channel graph. If we wake up on a stale branch, then we'll now detect this, walk backwards, and then scan forwards on the new brach in order to detect any recently close channels while we were away.

A bug has also been fixed wherein we wouldn't properly detect channel closures while we were down when scanning forwards within the chain.

Time Locked Output Handling

The utxonursery within lnd has been fully revamped. It has been heavily refactored, with several edge cases being handled along the way. Most importantly it is now able to properly handle timed out second layer HTLC's, meaning offered HTLC's that have had their absolute CLTV timelock expired. Several new tests have been added to ensure the utxonursery is able to handle all persistence edge cases.

Channel Update Retransmission

We now fully adhere to BOLT-0002 by implementing the full channel re establishment retransmission logic. Tis means that fi were were mid commitment update, and the connection died, upon reconnection we'll now resynchronize state with the remote party, with both sides sending any updates which weren't fully ACK'd by the remote party.

Channel Announcement Processing

Announcements will now be fully duplicated within the pending batched before being flushed out to peers. This saves bandwidth, and also means that peers won't need to do any unnecessary validation. Additionally, we'll now process incoming message in parallel, reducing the total validation time when processing a new batch of messages during initial sync to the network.

Protocol Compatibility

The recent, final changes to the specification have been implemented. As a result, a few of the wire messages have undergone backwards incompatible changes. Due to these changes, users of the application may find that they're unable to interact with certain peers on the network, as the protocol has deviated since they last update. On the side of cooperative channel closures, the internal fee negotiation algorithm within lnd has been re-written. The new logic will now properly compromise, whereas the old algo would become stubborn and refuse to budge on its desired fee at a certain point.

Fee handling has been completely revamped. lnd nodes connected to a full node will now sample the fee rate on the network, and update the commitment transaction accordingly.

Contributors (Alphabetical Order):

• Brijan (DaReaper)
• Bryan Vu

v0.1.2-alpha

This release is the second minor release for the application! Several bugs have been fixed on the backend. Additionally, the UI has received a few minimal updates, making the application much easier to use and understand.

NOTE: the version of lnd packaged includes a breaking change. As a result, before updating we recommend that users close out all their active channels, and also transfer any testnet coins they wish to hold onto to an external wallet before updating.

Before updating, users will need to remove all data from lnd's home data directory. This is required as there have been some breaking changes in neutrino, the light client that lnd uses to interact with Bitcoin's test network. Depending on your operating system, the data directory will be found in a different location on the file system:

• MacOS: $HOME/Library/Application Support/Lnd
• Windows: %LOCALAPPDATA%\Lnd
• Linux: ~/.lnd

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.1.2-alpha.txt and manifest-v0.1.2-alpha.txt.gpg are in the current directory) with:

gpg --verify manifest-v0.1.2-alpha.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):

65bcc48822af6b1ad8ab91847d8b836cc3619950ca0610ba2949eb036066e3f8  Lightning-darwin-x64v0.1.2.zip
f9b1e0d5de8b1e09ca0c50805a704fa5ed87e6aa9beb96854da35708fd4a1645  Lightning-linux-x64v0.1.2.tar.gz
e71fa98c21234a82863f60d75a31a983c67b75ebb97fc3c7b641b095f015099a  Lightning-win32-x64v0.1.2.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.

Notable Fixes

UI

Full txid's and public keys are now properly displayed within the UI. Previously, they would be cut off short by a trailing ellipsis, rendering them unable to be properly copied.

Commas have been inserted in all instances where satoshis are displayed for better readability for users. Additionally, minor UI tweaks have been made to ensure the currency units no longer wrap around in certain viewport sizes.

It is now possible to right click on-chain addresses, and payment requests as w'eve added a proper right-click context menu to them. On certain operating systems, the prior "click to copy into paste buffer" would not always properly work. This fix has been extended to the the menu when creating channels, in order to allow users to paste in values for any of the fields.

Authentication

The application will now properly utilize the macaroons feature of lnd when making RPC requests. As a result, the lnd instance started will now automatically fully enforce the presentation of the appropriate macaroon credential when making RPC requests.

Development Tools

When running the application in dev mode, lnd will now properly read the lnd.conf from the default data directory. This allows developers to experiment with different configurations, and even point their dev instance at a local btcd node using the RPC mode.

Security

node.js is now disabled within the rendering process. This reduces the attack suerfce as it is no longer possible to access the main process from the rendering process via arbitrary `node.js code.

Peer Bootstrapping

A DNS fallback has been added which will attempt the DNS query of TCP if UDP initially fails. The DNS resolvers of many users would filter out the response to our SRV record as they were too large for many resolvers. lnd will now detect if the initial request fails, and will fallback to a TCP based DNS resolution instead.

lnd + neutrino

Payment requests have been updated to take into account a recent change within the lightning-rfc set of specifications. The receiver will now manually specify a CLTV expiry delta value to use for the final hop. As a result, if you receive a payment request from an updated receiver, you may be unable to complete the payment as they have a distinct policy.

A bug in the way fees were calculated for multi-hop transactions has been fixed. The existence of this bug would at times render users unable to complete a multi-hop payment with a path length greater than 3.

The state machine that handles channel updates has been modified slightly to use a different scheme to assign identifiers to each HTLC. As a result, users will be unable to complete channel updates on their existing channels, and may also be unable to update newly opened channels, if they're extended to an un upgraded node.

Several possible deadlock scenarios within the peer management logic have been addressed, eliminating a large class of peer related application freezes.

The ChannelRouter within lnd will now properly handle re-orgs on-chain. This means that if a channel is re-org'd out, lnd will no longer interpret it as being active and routable.

neutrino has been updated to a new version which properly implements the new light client protocol as specified within the updated BIP. As a result, if old clients were manually pointed at an un-updated btcd node, then after this update they may not be able to sync, as the protocol messages have changed slightly.

Contributors (Alphabetical Order):

• Brijan (DaReaper)
• Bryan Vu
• Case Sandberg
• Jason Tanner

v0.1.1-alpha

This release is a minor patch release to fix several bugs present in the initial v0.1.1 both within the application UI, and also within the lnd and neutrino backends the application depends on.

Notable Fixes

UI

Balances will now be properly updated when the entire application is rendered. Previously, users needed to click on either the accounts page, or the request page before the user's balance would properly be updated int he lower left corner.

lnd

A series of bugs have been fixed within the server itself which at times would cause a deadlock, rendering the server unable to proceed. Additionally, an issue with spontaneous high cpu usage has been identified and patched.

HTLC routing has been revamped to a lazier, iterative approach which should result in UX improvements when sending payments. A new system dubbed missionControl will now remember the results of prior HTLC routing attempts, using any failures encountered to avoid faulty links as reported by prior payment sending attempts.

An issue that would cause channel ID's to at times show up as 0, until the next block was mined has been resolved. With this fix, channel announcements should now eventually propagate throughout the network.

lnd will no longer request a full graph state synchronization with each new peer connect. This will reduce the initial CPU burst up peer bootstrapping and also reduce bandwidth usage.

neutrino

Stall detection has temporarily been disabled, as it can lead to false positives, causing the node to be unable to sync properly from peers. Users should no longer encounter cases where the node is unable to sync properly.

v0.1-alpha

This release marks the first release of the Lightning desktop application! The application comes pre-bundled with lnd at commit lightningnetwork/lnd@f20cb89. As there're a a few breaking changes planned for lnd, subsequent release will be frequent in order to keep up with the latest network protocol. As a result, the builds contained within the application won't be able to properly interact with the network after a two week period has passed. As lnd itself is still in alpha, this application will only track Lightning on Bitcoin's testnet blockchain.

Notable Features

Neutrino

The app is powered by neutrino, our new open source, light client operating mode for Bitcoin. Neutrino light clients don't rely on bloom filters (BIP 37) as most light clients currently do. Instead, neutrino relies on client side filtering which has numerous benefits including: increased privacy, less active load on full nodes, and a more flexible application model which is particularly useful for lightweight Lighting nodes. The full technical details for neutrino can be found in our soon to be finalized BIP draft.

With this new backend for lnd in place, users will be able to run Lightning applications without having a synced full node, reducing the barrier to entry for Lightning users.

Autopilot

The latest build of lnd comes equipped with a new experimental option for any planned flavors of automatic channel management, meaning users won't necessarily need to manually establish channels. We call this new operating node autopilot as it will automatically manage the opening of channels within the network.

autopilot is essentially a closed-loop control system: it takes inputs such as the number of channels opened, time when channels are closed, and changes to the wallet's balance. Once those signals are received, it consults a set of heuristic to decide if it needs more channels, and if so, to whom those channels should be opened. The Agent then carries out the recommendations of its heuristics.

BOLT 11

For sending/receiving funds over Lighting, the wallet implements BOLT-11 which defines an extensible invoicing protocol for Lightning payments. Using this encoding, a standard payment request to receive funds over Lightning looks like:

lntb4200n1pvaue4ypp5k86jth0zefkje0u88ftmp37rvy64p8fl5el7jla0cgn3av6nhmpsd8s0v3xzun5d93kce2ld9jzyw3zxy6nsefev93kyttp8psnwtf5xycrwttpxu6nyttz8p3rvv3jxpsnyerzxg3zcgnyv4ekxunfwp6xjmmwygazy5n9v9jzqstjw35kxmr98gs9y3f6yp28yctwwdskxarfdah8xgrpdejzq5mrwf5hqarn8gsyg42sypyyz56gxymrqgpw9chzq32324q5c4j92fy5vkfqgdyy2s6t2dy5wgnayhq8y6pw5957tqn374jczramqyzjr8f7vt7v3m2shtqgcnp9u538fv27zp2egju5uljscyuvul5n86kg0670zf68q4a09kcnzcyjgyqprd5d5p

If we go to the command line to decode the payment request, we'll see what's encoded:

$  lncli decodepayreq --pay_req=lntb4200n1pvaue4ypp5k86jth0zefkje0u88ftmp37rvy64p8fl5el7jla0cgn3av6nhmpsd8s0v3xzun5d93kce2ld9jzyw3zxy6nsefev93kyttp8psnwtf5xycrwttpxu6nyttz8p3rvv3jxpsnyerzxg3zcgnyv4ekxunfwp6xjmmwygazy5n9v9jzqstjw35kxmr98gs9y3f6yp28yctwwdskxarfdah8xgrpdejzq5mrwf5hqarn8gsyg42sypyyz56gxymrqgpw9chzq32324q5c4j92fy5vkfqgdyy2s6t2dy5wgnayhq8y6pw5957tqn374jczramqyzjr8f7vt7v3m2shtqgcnp9u538fv27zp2egju5uljscyuvul5n86kg0670zf68q4a09kcnzcyjgyqprd5d5p
{
    "destination": "028c620eb95c3907a779adf9c47612973b70c322e5b60a21886947867439ff63e6",
    "payment_hash": "b1f525dde2ca6d2cbf873a57b0c7c36135509d3fa67fe97fafc2271eb353bec3",
    "num_satoshis": "420",
    "timestamp": "1507747492",
    "expiry": "3600",
    "description": "{\"article_id\":\"158e9acb-a8a7-4107-a752-b8b6220a2db2\",\"description\":\"Read Article: RE: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG\"}",
    "description_hash": "",
    "fallback_addr": ""
}

Segwit Enabled

The Desktop App is fully segwit enabled, capable of sending funds to and receiving funds from native segwit addresses, which look like:

tb1q62cgd0u7h654rpu4fm9y4fe47x5khesyd9k2q9

Note that in the Desktop App, for incoming payments, we currently display nested P2SH addresses. This format is used so that non-segwit enabled services (such as faucets) can send funds to the wallet. For outgoing funds, the wallet will only send to segwit outputs in order to prevent new channels from being subject to transaction malleability. Testnet coins are available at faucets here and here.