Improving SPV Security With POW Fraud Proofs

Bitcoin full nodes require increasing computer resources that are not available to most of the public, therefore most users tend to use SPV. Simplified Payment Verification is a way for users to check the validity of a block without downloading the whole blockchain, only needing a copy of the block headers of the longest chain.

This schema makes SPV clients vulnerable to forks as it is secure under the assumption that the longest chain is valid and as attacks like Segwit2x have shown and this is not always a safe assumption. A new schema has been proposed on the Bitcoin-dev mailing list that allows invalid blocks to be rejected as long as there are enough honest miners to create a block within a reasonable time frame. The new schema doesn’t fully protect clients against dishonest miners but is an improvement over the current SPV.

Self Balancing Between Excessively Low/High Fees and Block Size
A new BIP being discussed on the Bitcoin-dev mailing list is aiming at making variable Bitcoin block size depending on the fee the sender is willing to pay, the BIP is aiming at making the block space small, decrease the impact of spam transactions, balancing fees with smaller fees increasing in a higher percentage than higher fees, allow larger block size if the sender is willing to pay for it, allow wallets to display the amount, and price, of free block space left and allow senders to have more control on their fee/priority structure.
Bitcoin Optech Newsletter #41
This week’s newsletter requests testing for release candidates of Bitcoin Core and LND, describes a discussion about UTXO snapshots for fast initial syncing of nodes, and provides regular coverage of bech32 sending support and notable merges in popular Bitcoin infrastructure projects.
Bitcoin Optech Newsletter #40
This week’s newsletter notes a spike in estimated transaction fees, describes LN trampoline payments, and publicizes Bitcoin Core’s intent to default its built-in wallet to bech32 receiving addresses in version 0.20 or earlier. Also included are regular sections about bech32 sending support and notable code changes in popular Bitcoin infrastructure projects.
[BIP Proposal] Peer to Peer Message Transport Protocol V2

Peer to Peer messaging is already applied in Bitcoin courtesy of BIP 151, but the current way it is applied is inefficient and insecure, currently messages transported are non-encrypted so message tampering, block delay attacks and BGP hijacks are all valid threats using man in the middle attacks. A new BIP is aiming at adding opportunistic encryption using ChaCha20 as a cipher and Poly1305 as a message authentication code, which has been lately getting adopted in many state of the art protocol encryption schemes such as Wireguad and tinyssh.

The computation power required for encrypting and authenticating a message using these algorithms would be almost as much the current double-SHA256 checksum.

#### Releases

project release date
eclair v0.3

This is a major release which includes many improvements and bug fixes, and we recommend that users upgrade.

It is compatible with eclair v0.2-beta9 (i.e you don't have to close your channels) but upgrading may be not as seamless as for previous versions, please check the Upgrading section.

### Major changes

#### Eclair runs on mainnet by default

Default configuration now targets mainnet, but you can still easily run Eclair on testnet or regtest.

#### New RPC API

Our RPC API has been upgraded and improved and now include calls to retrieve payment information, see our API documentation. You can still choose to use the old API with a configuration option that will be removed in a future release.

#### Easy channels backup

Making backups of your channels is now simpler: we create an update an eclair.sqlite.bak backup file that is always consistent and safe to use even when your node is running.

Please note that an old backup can be used as a "static" backup: if you restore an old backup, channels open to peers that support Data Loss Protect will be recovered.

#### Simple Plugin Support

You can now easily write and deploy your own plugins, written in any JVM-compatible language. See the readme for more details.

#### Bitcoin Core v0.17 or newer is now required

We now require Bitcoin Core v0.17 or newer, meaning that eclair now works with Bitcoin Core v0.18. Eclair will not work anymore with older versions, you will have to upgrade.

#### Support for Tor Services

You can now run Eclair as a Tor hidden service for increased privacy.

Note that Tor also offers out-of-the-box NAT traversal, which solve the issue of changing ips.

#### Target JDK is now OpenJDK 11

We switched our target JDK from Oracle JDK8 to OpenJDK 11, and we recommend that you use it to run eclair. You can still use Oracle JDK8 (but it's up to you to check your licensing options).

#### Performance improvements

Eclair now embeds native JNI bindings for libsecp256k1 for Linux 64 bits, Windows 64 bits and Osx 64 bits, which makes eclair much faster. You can still use your own version of libsecp256k1 if you use a different OS.

Many internal structures and workflows have been optimised and eclair is now even faster (not that it was ever slow to begin with, eclair is used on some of the biggest nodes on LN).

### Verifying signatures

You will need gpg and our release signing key 7A73FE77DE2C4027. Note that you can get it: - from our website: https://acinq.co/pgp/drouinf.asc - from github user @sstone, a committer on eclair: https://api.github.com/users/sstone/gpg_keys

To import our signing key:

$gpg --import drouinf.asc  To verify the release file checksums and signatures: $ gpg -d SHA256SUMS.asc &gt; SHA256SUMS.stripped
\$ sha256sum -c SHA256SUMS.stripped


This release is compatible with Eclair v0.2-beta9. You don't need to close your channels, just stop eclair, upgrade and restart. However, there are 2 major runtime changes that you need to take into account:

• If you're using Bitcoin Core v0.16.3, you must upgrade to v0.17 (latest release is 0.17.1). Since we require indexing, you tx index database will be migrated the first time you start your Bitcoin Core, which may take up to a few hours. Please stop eclair, migrate your Bitcoin node, and wait until its index database has been migrated before you start eclair again !
• Our target JDK is now OpenJDK 11, and we suggest that you use it to run Eclair. You can still use Oracle JDK8 (but it's up to you to check your licensing options). See #846 for more details.

### Changelog

• Use bitcoind fee estimator first (#987)
• Ignore subprojects eclair-node/eclair-node-gui in the codecov report (#991)
• Accept commit_sig without changes (#988)
• Add bot support for code coverage (codecov) (#982)
• Set tcp client timeout to 20s (#990)
• Set default chain to "mainnet" (#989)
• Replace UnknownPaymentHash and IncorrectPaymentAmount with IncorrectOrUnknownPaymentDetails (#984)
• Update bash autocompletion for eclair-cli (#983)
• API: Support query by channelId or shortChannelId everywhere (#969)
• Better handling of closed channels (#944)
• Electrum: make debug logs shorter (#964)
• ElectrumWallet should not send ready if syncing (#963)
• Print stack trace when crashing during boot sequence (#949)
• Live channel database backup (#951)
• Added simple plugin support (#927)
• Add channel errors in audit db (#955)
• Added a timeout for channel open request (#928)
• Electrum: do not persist transaction locks (#953)
• Add a proper payments database (#885)
• Set max payment attempts from configuration (#931)
• Expose the websocket over HTTP GET to work properly with basic auth (#934)
• Send events when HTLCs settle on-chain (#884)
• Electrum: update client name (#930)
• Add random delay to rebroadcast (#925)
• Rollback tx if disconnected in WAIT_FOR_FUNDING_SIGNED (#923)
• Separate cases for bech32 testnet and regtest for BOLT11 fallback address
• API: use form data instead of JSON-RPC (#894)
• Deal with channels with fees=0 when computing a route (#905)
• Check WatchSpent in constant time (#916)
• Rework database initialization (#911)
• Use bitcoin-lib 0.11 which embeds libsecp256k1 (#907)
• Don't send updates if no filter has been set (#912)
• Upgrade to bitcoin 0.17.1 (#826)
• Better logic for sending channel_updates (#888)
• Replace BinaryData by scodec.bits.ByteVector (#896)
• Better error logs for socks5 proxy (#893)
• NetworkDb: remove stale channels in batch (#886)
• Clean channels with unexisting funding tx (#714)
• Set default to-remote-delay-blocks to 720 (#879)
• Routing heuristics (#821)
• Use ypub prefix for Electrum xpub (#875)
• Update jeromq dependency (#852)
• Use OpenJDK 11 as default JDK (#846)
• Electrum fixes and improvements (#873)
• Fixed computation of available balance (#868)
• Faster gui startup (#863)
• Support all-uppercase payment requests (#862)
• Reimplemented BOLT 11 with scodec (#856)
• Parametric route search (#844)
• Increased max-to-local-delay-blocks to 2016 (#853)
• Stop disconnected peer when it has no channels (#840)
• Improve Electrum start-up time (#848)
• Add balance and channel lifecycle events to the audit db (#827)
• Support for Tor onion services (#736)
• (Router) Always select direct channel if there is one to the target (#850)
• Proper handling of gossiped channels being spent (#838)
• Ignore reconnections requests to the same peer with the same address (#835)
• Replace initialization futures Future[Boolean] by FutureDone
• Set timestamp filter lower bound to current time (#837)
• ChannelSelectionSpec: use akka.event.NoLogging (#834)
• Relay to channel with lowest possible balance (#784)
• Complete commit logs

Thank you @btcontract @rorp @n1bor @Kukks !

2019-05-09
ledger-live-common v5.5.0
add locale in sanitizeValueString
2019-05-19
ledger-live-common v5.6.0
update libs
2019-05-19
ledger-live-common v5.7.0
• DEVICE_PROXY_URL env
• firmwareUpdate repair: new repairChoices export
2019-05-19
ledger-live-common v5.8.0
EthereumJSBridge: implement hasFailed
2019-05-19
ledger-live-common v5.9.1
• add missing lru-cache dep
2019-05-19
ledger-live-common v5.9.0
• update CryptoCurrencies list to match coins we have in Ledger Manager and also fix managerAppName to match them.
2019-05-19
ledger-live-common v5.9.1 2019-05-15
ledger-live-common v5.9.0 2019-05-15
ledger-live-common v5.8.0 2019-05-14
ledger-live-common v5.7.0 2019-05-13
ledger-live-common v5.6.0 2019-05-12
ledger-live-common v5.5.0 2019-05-07
ledger-live-common v5.4.0 2019-05-07
ledger-live-desktop v1.8.1
Fixes firmware update for Nano S 1.3.1.
2019-05-17
ledgerjs v4.57.0
• #355 WebUSB transport: fixes isSupported function that tells when webusb is available. (it was returning true when navigator.usb===null)
• #356 @ledgerhq/devices: Implement support for an incoming usb productId change.
• #353 WebBLE transport: Allow more time after a pairing to attempt to fix a firmware bug (that forget the bondings if not disconnecting). Bug still seems to happen in Chrome Android.
2019-05-19
ledgerjs v4.56.0
• #350 WebUSB: requestDevice() permission modal will only appear if a previously accepted device is not connected. a WebUSB transport instance also properly emits "disconnect" to be able to re-suggest user an UI to re-connect (it still needs to be in context of a click).
• hw-transport-http (proxy): implement logs.
2019-05-19
Bitcoin Core v0.18.0

Bitcoin Core version 0.18.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-0.18.0/

For the release notes please see the git repository:

https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.18.0.md

Preferably use the above download link, not the links provided by GitHub to download the source tarball, as the release tarballs are generated deterministically whereas GitHub's are not.

2019-05-18
BTC Pay Server v1.0.3.104 2019-05-15
BTC Pay Server v1.0.3.103 2019-05-12
BTC Pay Server v1.0.3.102 2019-05-12
BTC Pay Server v1.0.3.101 2019-05-12
BTC Pay Server v1.0.3.100 2019-05-12
BTC Pay Server v1.0.3.99 2019-05-09
BTC Pay Server v1.0.3.98 2019-05-09
BTC Pay Server v1.0.3.97 2019-05-08
BTC Pay Server v1.0.3.96 2019-05-08
BTC Pay Server v1.0.3.95 2019-05-07
lnd v0.6.1-beta

This release marks a minor release in the 0.6-beta series. This release contains no major new features, and instead contains a series of bug-fixes, optimizations, and stability improvements.

# 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 the keys that have signed this release if you haven't done so already:

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


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

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


You should see the following if the verification was successful:

gpg: assuming signed data in &#39;manifest-v0.6.1-beta.txt&#39;
gpg: Signature made Thu May  9 16:31:08 2019 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from &#34;Olaoluwa Osuntokun <laolu32@gmail.com>&#34; [ultimate]


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):

8fd4bfb26d402a4882f4c89ab700186431c178af0a9f0bf61513bbb48cd497c3  lnd-darwin-386-v0.6.1-beta.tar.gz
02330ede4e7508a37e92bcc4c0dd0ac977f51a8fd42be9f114b1e42e58ff07c9  lnd-darwin-amd64-v0.6.1-beta.tar.gz
60c7aef87789271cc1c55286068ce2e6e94ccae48d85465df0606fe96bbe01cd  lnd-dragonfly-amd64-v0.6.1-beta.tar.gz
9e2c4b926140aacfc680e53191b1b56a18b0def422b1f8f4cc66536298721115  lnd-freebsd-arm-v0.6.1-beta.tar.gz
00a7cd0ca657bb242b0f3acb5f4e26a13fd789946fab73c252118e3f89c1cf57  lnd-linux-386-v0.6.1-beta.tar.gz
d5f7280c324ebc1d322435a0eac4c42dca73ebc6a613878d9e0d33a68276da5c  lnd-linux-arm64-v0.6.1-beta.tar.gz
00ff9c61fbd272863aef677db240b04eecdaae0cfb479cf25c713b89ff81d41c  lnd-linux-armv6-v0.6.1-beta.tar.gz
5541959c7fde98d76d88cc8070ca626c681ba38c44afcb85bf417a9a677e23c2  lnd-linux-armv7-v0.6.1-beta.tar.gz
ed8aa2ef8f4e42651a16c90d5ab2d4485396b4c795bc183fd01ae63b39d4201e  lnd-linux-mips64-v0.6.1-beta.tar.gz
a97dfc432747f4dcd6deb8f263b18453c68b4882b1cc1ff84d90f25ba2ed5151  lnd-linux-mips64le-v0.6.1-beta.tar.gz
95ff869a1bbcba20b5c6387f09175eaf3a16f2026e5113eff9abb7b595039423  lnd-linux-ppc64-v0.6.1-beta.tar.gz
5efb454850f41f69a397d4a9cd4778f6a251ce21cf796960b60d6799ff128bf1  lnd-netbsd-386-v0.6.1-beta.tar.gz
6059ab2d6d03604d48c69eeaf1f59f2131b1ce76f714629a6e1c2063f4da4788  lnd-netbsd-amd64-v0.6.1-beta.tar.gz
c5b84fe5982ae4b7745d0f083d123d304f97c5da4e6fe515f84b3272495fb1a2  lnd-openbsd-amd64-v0.6.1-beta.tar.gz
68fcede095d6e4f038ba49c46f24a07ff2d07ea11eab95d2d02d5c1467d4d2fc  lnd-source-v0.6.1-beta.tar.gz
e2cb484fda567eb03a534f36613771b1bc10c7220b255b3972784f38abdc2342  lnd-windows-386-v0.6.1-beta.zip
c370735f280ab2b5f6421dafccbdc0e09ff5cfe5f3a65f87155d5cf1e20b1249  lnd-windows-amd64-v0.6.1-beta.zip
afb75c146f03bc4d2af77c49ac4ced88f945a5d3cb9ba32181bc9145149e6af6  vendor.tar.gz


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.6.1-beta


# Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependencies. Note that at this stage, binaries aren't yet fully reproducible (even with go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.6-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.6.1-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta&#34; ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta&#34; ./cmd/lncli


The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS=&#34;linux-arm64 darwin-amd64&#34; ./release.sh


The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

# Release Notes

## Tor

A bug has been fixed in the minimum version verification for the Tor daemon that lnd enforces. Before this fix, lnd would at times fail to connect to a Tor daemon with a version beyond the minimum version we require.

## Protocol and Cross Implementation Compatibility Improvements

lnd will now properly handle the conversion from an UpdateFailMalformedHTLC error to a regular UpdateFailHTLC error. Before this fix, lnd would incorrectly send an error that wasn't able to be decrypted by the sender of an the original HTLC.

## On-Chain Commitment/HTLC Handling

A series of parameters related to when lnd will go to chain for an HTLC, and also when it will reject an incoming/outgoing HTLC for being "too close for comfort" have been adjusted. As a result, it's no longer possible for lnd to accept an HTLC then immediately go to chain for it. Additionally, it's now possible for lnd to forward an HTLC as the last hop to a destination with a very low final CLTV delta.

lnd will now detect a local force close (self initiated) based on the outputs rather then the old txid based comparison. This patches an edge case related to SCB restoration where if a user broadcasted a force close then restored their SCB, lnd would miss this local force close transaction and attempt to redeem using an incorrect path. This bug has never been observed in the wild, but nevertheless warranted patching.

## Gossip and P2P Handling

### Non Write Pool Blocking Writes

Flushing a message to the socket is no longer blocks the write pool. One result of this change is that we are now we are able to gracefully handle timeout errors and resume partially sent messages. As of #2819, if a message is partially written to the wire due to a timeout error, we will try to write the full message again. In turn, this will produce an authentication error on the remote side (after it is able to read the number of bytes specified in the header) since the middle of the latter ciphertext will not pass as the MAC check.

We resolve this by splitting the Write call into two subroutines, WriteMessage and Flush. WriteMessage encrypts the plaintext and buffers the ciphertext on the underlying connection. A subsequent call to Flush will then attempt to write the bytes out on the wire. If a timeout error is encountered during flush, we can safely resume the byte stream by calling Flush again. In addition to being able to resume partial writes, this also has a yuuuge benefit in not blocking the write pool with network operations. This fully decouples the number of write pool workers from the number of peers, since the blocking operations now take place in each peer.

### Synchronous Gossip Response Writes

All replies to gossip query messages are now fully synchronous. This means that if a peer requests a set of channels, then we won't send the next message until after the current message has been flushed to the socket. Node operators should find that start up is now much snappier, and the post start up memory burst to also be much lower.

### SyncManager Simplification and Improvements

We've made some improvements to the recently introduced SyncManager. These improvements include: * Active syncers will no longer attempt to synchronize our graph with remote peers. Instead, we'll now rely on synchronizing our graph with remote peers through the routine historical syncs performed by the SyncManager. Since active syncers will no longer attempt this synchronization, the SyncManager's round-robin is no longer needed. * Handling initial historical sync disconnections: Every time lnd starts up, it attempts an initial historical graph sync with the first peer that connects. If the peer ends up disconnecting, then we wouldn't handle finding a replacement to continue performing the initial historical sync. * Queueing active syncers until the initial historical sync completes: We do this to ensure we can properly handle any new channel updates at tip. This is required for fresh nodes that are syncing the channel graph for the first time. If we begin accepting updates at tip while the initial historical sync is still ongoing, then we risk not processing certain updates since we've yet to learn of the channels themselves.

## RPC Bug Fixes

The route cache has been removed. After updates to the SendToRoute RPC command, the cache could at times cause an incorrect result from QueryRoutes.

## No More main Package!

There is no longer a main package, instead the top-level package within the project is now lnd. This is a prep for changes to make lnd easier to embed in mobile applications for iOS and Android.

## Changelog

The full list of changes since 0.6.0-beta can be found here:

# Contributors (Alphabetical Order)

Chris Coverdale Conner Fromknecht Damian Mee Danny Paz frennkie Johan T. Halseth Joost Jager Matt Drollette Offer Markovich Olaoluwa Osuntokun Robert Habermann Valentine Wallace Wilmer Paulino /laolu32@gmail.com

2019-05-09
lnd v0.6.1-beta-rc2

This release marks a minor release in the 0.6-beta series. This release contains no major new features, and instead contains a series of bug-fixes, optimizations, and stability improvements.

# 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 the keys that have signed this release if you haven't done so already:

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


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

gpg --verify manifest-v0.6.1-beta-rc2.txt.sig


You should see the following if the verification was successful:

gpg: assuming signed data in &#39;manifest-v0.6.1-beta-rc2.txt&#39;
gpg: Signature made Mon May  6 13:10:07 2019 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from &#34;Olaoluwa Osuntokun <laolu32@gmail.com>&#34; [ultimate]


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):

2bde52f143b1e18f1a09c527d15506061b870286fbac96188cc7760ee832e30c  lnd-darwin-386-v0.6.1-beta-rc2.tar.gz
d9b534a24784720efa7d350aa303783a017bec6968d0a325fdd6faa3ed8a9469  lnd-darwin-amd64-v0.6.1-beta-rc2.tar.gz
d6399e05a6b5644206b7c5ee6b42b3d2695464a8c055fc8233e483c37f96e501  lnd-freebsd-amd64-v0.6.1-beta-rc2.tar.gz
6ffd5de533005e24c56f7caafb44540cdae541ce6652acf9dac69daa8618beb2  lnd-freebsd-arm-v0.6.1-beta-rc2.tar.gz
19bb8acec1d79c376363a7660b7ef75624829cfdb6e83841e84b7dc98bbb10bc  lnd-linux-386-v0.6.1-beta-rc2.tar.gz
860a5d0a56c1ec9eef33a5f29c20013221b95298468825a1b7793d13320cba70  lnd-linux-amd64-v0.6.1-beta-rc2.tar.gz
acaed77436ea210164553ac9e11b87c92ed918f10b6a5e54f96c01ca0b93fe24  lnd-linux-armv7-v0.6.1-beta-rc2.tar.gz
531ded86200180aeb353fae688a27c47c3127db77ff2090e7a11b6301af33d9e  lnd-linux-mips64-v0.6.1-beta-rc2.tar.gz
2fc53aa465bb1328720236e1d3b935d7e8b5041419b090ef70887c570f1e89f1  lnd-linux-mips64le-v0.6.1-beta-rc2.tar.gz
8ba89de80eb8cceb455a2ec4e236390abccf856b5fc887e8ab72192e55ca1c9c  lnd-linux-ppc64-v0.6.1-beta-rc2.tar.gz
ea4577691c710aeda59b6c3275386d1636998d98526db88384d65f03eb904fa1  lnd-netbsd-386-v0.6.1-beta-rc2.tar.gz
e94d00624c857bfa00917f5b8679c294b749490e485ec20433fc3dcb29c5db4b  lnd-netbsd-amd64-v0.6.1-beta-rc2.tar.gz
ebdc2cca43877f680cd9f1ee6ac90c21e56f6ccde740288b3a37ddf46b954c27  lnd-source-v0.6.1-beta-rc2.tar.gz
dc8258ae4c7003876ba851e928006b796647598de2f5538e5c6f8d1fb3b176c0  lnd-windows-amd64-v0.6.1-beta-rc2.zip
6f75ce9dfb1a6f9c3f9537aee310429f89cd934f45079677ee59880d395d77e3  vendor.tar.gz


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.6.1-beta-rc2


# Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependencies. Note that at this stage, binaries aren't yet fully reproducible (even with go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.6-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.6.1-beta-rc2.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta&#34; ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta&#34; ./cmd/lncli


The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS=&#34;linux-arm64 darwin-amd64&#34; ./release.sh


The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

# Release Notes

## Tor

A bug has been fixed in the minimum version verification for the Tor daemon that lnd enforces. Before this fix, lnd would at times fail to connect to a Tor daemon with a version beyond the minimum version we require.

## Protocol and Cross Implementation Compatibility Improvements

lnd will now properly handle the conversion from an UpdateFailMalformedHTLC error to a regular UpdateFailHTLC error. Before this fix, lnd would incorrectly send an error that wasn't able to be decrypted by the sender of an the original HTLC.

## On-Chain Commitment/HTLC Handling

A series of parameters related to when lnd will go to chain for an HTLC, and also when it will reject an incoming/outgoing HTLC for being "too close for comfort" have been adjusted. As a result, it's no longer possible for lnd to accept an HTLC then immediately go to chain for it. Additionally, it's now possible for lnd to forward an HTLC as the last hop to a destination with a very low final CLTV delta.

lnd will now detect a local force close (self initiated) based on the outputs rather then the old txid based comparison. This patches an edge case related to SCB restoration where if a user broadcasted a force close then restored their SCB, lnd would miss this local force close transaction and attempt to redeem using an incorrect path. This bug has never been observed in the wild, but nevertheless warranted patching.

## Gossip and P2P Handling

### Non Write Pool Blocking Writes

Flushing a message to the socket is no longer blocks the write pool. One result of this change is that we are now we are able to gracefully handle timeout errors and resume partially sent messages. As of #2819, if a message is partially written to the wire due to a timeout error, we will try to write the full message again. In turn, this will produce an authentication error on the remote side (after it is able to read the number of bytes specified in the header) since the middle of the latter ciphertext will not pass as the MAC check.

We resolve this by splitting the Write call into two subroutines, WriteMessage and Flush. WriteMessage encrypts the plaintext and buffers the ciphertext on the underlying connection. A subsequent call to Flush will then attempt to write the bytes out on the wire. If a timeout error is encountered during flush, we can safely resume the byte stream by calling Flush again. In addition to being able to resume partial writes, this also has a yuuuge benefit in not blocking the write pool with network operations. This fully decouples the number of write pool workers from the number of peers, since the blocking operations now take place in each peer.

### Synchronous Gossip Response Writes

All replies to gossip query messages are now fully synchronous. This means that if a peer requests a set of channels, then we won't send the next message until after the current message has been flushed to the socket. Node operators should find that start up is now much snappier, and the post start up memory burst to also be much lower.

### SyncManager Simplification and Improvements

We've made some improvements to the recently introduced SyncManager. These improvements include: * Active syncers will no longer attempt to synchronize our graph with remote peers. Instead, we'll now rely on synchronizing our graph with remote peers through the routine historical syncs performed by the SyncManager. Since active syncers will no longer attempt this synchronization, the SyncManager's round-robin is no longer needed. * Handling initial historical sync disconnections: Every time lnd starts up, it attempts an initial historical graph sync with the first peer that connects. If the peer ends up disconnecting, then we wouldn't handle finding a replacement to continue performing the initial historical sync. * Queueing active syncers until the initial historical sync completes: We do this to ensure we can properly handle any new channel updates at tip. This is required for fresh nodes that are syncing the channel graph for the first time. If we begin accepting updates at tip while the initial historical sync is still ongoing, then we risk not processing certain updates since we've yet to learn of the channels themselves.

## RPC Bug Fixes

The route cache has been removed. After updates to the SendToRoute RPC command, the cache could at times cause an incorrect result from QueryRoutes.

## No More main Package!

There is no longer a main package, instead the top-level package within the project is now lnd. This is a prep for changes to make lnd easier to embed in mobile applications for iOS and Android.

## Changelog

The full list of changes since 0.6.0-beta can be found here:

# Contributors (Alphabetical Order)

Chris Coverdale Conner Fromknecht Damian Mee Danny Paz frennkie Johan T. Halseth Joost Jager Matt Drollette Offer Markovich Olaoluwa Osuntokun Robert Habermann Valentine Wallace Wilmer Paulino /laolu32@gmail.com

2019-05-06

#### RFC

type rfc # title date status
bip X add BANK Wallet to supported wallets list 2019-05-20 Update
bip bip-0079 fixed minor typo in BIP 79 2019-05-19 Merged
bip bip-0174 bip174: add global xpub field 2019-05-17 Update
bip bip-0158 Fix pseudocode on bip-0158 2019-05-14 Closed
bip bip-0158 BIP 158: kill off remnants of filter type 0x01. 2019-05-13 New PR
bip bip-0144 BIP 144: Old serialization format must be used on empty witness 2019-05-13 New PR
bip bip-0049 Update bip-0049.mediawiki 2019-05-11 Update
bip bip-0001 Create repository for translate Brazilian Portuguese BIP001 2019-05-10 Update
bolt messaging BOLT01: wire TLV proposal 2019-05-17 Update
bolt X Move founds before closing channel 2019-05-15 New Issue
bolt peer protocol BOLT2: past fulfillment deadline fails channel 2019-05-15 Update
bolt X Specify tlv format 2019-05-15 Update
bolt onchain BOLT5: Unify two practically redundant paragraphs 2019-05-14 Update
bolt onion routing bolt04: Multi-frame sphinx onion routing proposal 2019-05-14 Update
bolt onion routing BOLT 4: Merge final_expiry_too_soon into incorrect_or_unknown_payment 2019-05-13 Update
bolt onchain BOLT 5: Homogenize Local/Remote Commitment 2019-05-13 Merged
bolt X tools: update CSV generator to output fields for tlv's and subtypes 2019-05-13 Update
bolt X Onion format variation a-la @roasbeef (vs #593) 2019-05-13 Update
bolt routing gossip BOLT7: extend channel range queries with optional fields 2019-05-10 Update
bolt routing gossip [WIP] BOLT 7: Inventory-based gossip 2019-05-10 Update
bolt peer protocol BOLT2, BOLT3: reduce attack surface 2019-05-10 Closed
bolt onion routing BOLT 04: update test vectors 2019-05-10 Merged
bolt onion routing BOLT 4: fix onion test vectors 2019-05-10 Merged
slip slip-0044 slip-0044: add Zero 2019-05-19 Merged
slip X Added Shard & Linda 2019-05-17 Merged
slip X Add ECCoin 2019-05-16 Merged
slip X Add VBank coin 2019-05-16 Update
slip X Add VBank Coin 2019-05-16 Closed
slip slip-0044 slip-0044: Add zPrime (ZPM) 2019-05-16 Merged
slip slip-0044 slip-0044: add STASH 2019-05-15 Merged
slip slip-0044 slip-0044: Add Matrix AI (MAN) 2019-05-14 Merged
slip X Added CoinType for HBAR native currency of Hedera Hashgraph 2019-05-14 Merged
slip X Add Ardor 2019-05-14 Merged
slip slip-0044 slip-0044: add NTY 2019-05-13 Merged
slip slip-0044 slip-0044: Add Nervos CKB 2019-05-13 Merged
slip slip-0044 slip-0044: Add V Systems (VSYS) 2019-05-13 Merged
slip X Add ArrowChain 2019-05-13 Merged
slip slip-0044 Add PRKL to SLIP-0044 @ ID 667 2019-05-13 Merged
slip slip-0044 Update slip-0044.md 2019-05-12 Merged
slip X Rust implementation ping 2019-05-08 Closed
slip X Add Bitcoin Confidential 2019-05-07 Merged