#### Weekly Edition for Thursday, Feb 7

##### bulletin
Card Shuffle to Bitcoin Seed
Bitcoin seed generation is the most important event for any Bitcoin holder, as without this seed your wallet and ultimately your money is lost. We as users trust hardware and air gapped wallets to be correct and honest in their seed generation, which is hard to verify. A new bring-your-own-entropy method was proposed on the Bitcoin dev mailing list by developer Ryan Havar to allow users to create randomness they trust.
The Bitcoin Developer Network (BDN) Is Looking for Contributors

The Bitcoin Developer Network (BDN) aims to become a community-driven project looking at educating the next wave of Bitcoin developers. This is a public invitation for developers, authors, editors, proofreaders, enthusiasts and technical writers to get in touch so that we may reduce the barrier to entry in developing solutions at various layers of this technology.

Considering it’s a community-driven initiative, it only seems fair to do this collaboratively.

Get in touch at inbox@bitcoindev.network

https://bitcoindev.network/

Chaincode Labs Is Hosting Its Fourth Residency Program in Midtown Manhattan Over Summer 2019
Chaincode Labs announced its fourth residency program that will take place in Midtown Manhattan over summer 2019. Read the full announcement here Supporting the developer community and helping new contributors get their start in Bitcoin protocol development is a key part of our mission. Over the past three years, our residency programs have helped many developers start contributing to Bitcoin projects. Alex Bosworth and Johan Halseth (Lightning Labs), Neha Narula (MIT DCI), James O’Beirne and John Newbery (Chaincode Labs), Chris Stewart (SuredBits), Pierre Rochard (Lightning Node Launcher), Rene Pickhardt (LN developer and educator) and Will O’Beirne (Lightning Joule and WebLN) are all Chaincode Residency alumni.

#### Releases

project release date
ledger-live-common v4.16.0-beta.0 2019-02-05
ledger-live-common v4.15.0 2019-02-04
lightning-peach-wallet v0.4.2-mainnet-beta

# LightningPeach wallet v0.4.2-mainnet-beta

Release notes:

• We have added a possibility to increase an amount of payment requests. It means that now you can add some tips to scanned payment requests. Such service as tippin.me also becomes available.

# 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 LighntingPeach Wallet's key if you haven't done so already:

curl &#34;https://keyserver.ubuntu.com/pks/lookup?op=get&amp;search=0x3B50C645039078ED&#34; | gpg --import

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

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

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

b9f7f74b549be6d15872912115649ec3454de605a7f13015b083d8181c2a69de  lightning-peach-wallet_0.4.2-mainnet-beta_amd64.deb
cc4dee17b928e11874407d9934754765a285b7255580f8e4a2659eccfbae2acc  lightning-peach-wallet-0.4.2-mainnet-beta.exe
a2a04fd8f710f3821f80e9da47a6595c3c45a89ce01857583d3975a53ce20c99  lightning-peach-wallet-0.4.2-mainnet-beta-mac.zip
5ecf14bb130f7244bcb2e22c7bc92926f041e39f14d6a3fc737b874c06f36164  lightning-peach-wallet-0.4.2-mainnet-beta-x86_64.AppImage
d3351faa811e319827b88df3422216287b234ae966dfbba27a6a92032cc25b13  lightning-peach-wallet-setup-0.4.2-mainnet-beta.exe


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

2019-02-04
Samurai Wallet 0.99.08-gb

sha256 file hash: d011a4883d40d06a7f75e768c4fab8f8af6ec4b6242052cd468334c33b87973b

Source code in 'google-banned' branch. Signed commit e63b9dd.

2019-02-05
lnd v0.5.2-beta

This release is minor release of lnd, which includes several fixes which increase the stability of lnd, and also further increases cross implementation compatibility. There are no new database migrations, or functional RPC changes in this new version. As a result, users should expect a smooth upgrade path with no manual intervention required.

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

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


You should see the following if the verification was successful:

gpg: assuming signed data in &#39;manifest-v0.5.2-beta.txt&#39;
gpg: Signature made Thu Feb  7 13:29:16 2019 PST
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):

8c1d4c50847c665ac277bc8a659b8320f8a053d074a05e99c59f52ac87033968  lnd-darwin-386-v0.5.2-beta.tar.gz
478833d7d4efbbfe5c04f6ce7f5d69f45a163fcca0d4b83a1cba96556e76b916  lnd-darwin-amd64-v0.5.2-beta.tar.gz
8c351581f7887e5eeb9b2fc905e2057e5d1b03d5e58c29acbaeb19fb320cc157  lnd-dragonfly-amd64-v0.5.2-beta.tar.gz
ae2858e8ae7b2cfd9b0901032634056f9839bc26d01edc32e26524d2ba386084  lnd-linux-386-v0.5.2-beta.tar.gz
d876ffe5f18431cb0ec97c75e3d8b34a8d2c84e36a0114636a92dabe71340a99  lnd-linux-amd64-v0.5.2-beta.tar.gz
e178ba9aa7b207b5381519c34fd0b24cc74eebb0e1498536cf267988c6946858  lnd-linux-arm64-v0.5.2-beta.tar.gz
f03401fb24ce7a5d4dc498a6f3c88a766c186ac88d7f52791ecb95b5e983ef5c  lnd-linux-armv6-v0.5.2-beta.tar.gz
33037ed61c7f0c1939b1233d579fb39aa9261086f75dd24c7172ea3dba1aa63f  lnd-linux-mips64le-v0.5.2-beta.tar.gz
671bf900995eaa9349e869383397580c9f4d6cbe4d5fbb32673c7b217b4fe10f  lnd-linux-ppc64-v0.5.2-beta.tar.gz
d720671b9fc253c4e857bb53875daa15a367b21d20e2d9d2e149714315cfb15a  lnd-openbsd-386-v0.5.2-beta.tar.gz
af0db952379a67e40f988eb94261f59fb0173f63de1806eb38c529751dd6c674  lnd-openbsd-amd64-v0.5.2-beta.tar.gz
64ce298461dae68133823b3b43cfa7cb05e821e7688f29df14fbce02e64e14a9  lnd-windows-386-v0.5.2-beta.zip
9ac0667a877e3884627c019390cc593b5a783777314b2e30121aac76d1c71993  lnd-windows-amd64-v0.5.2-beta.zip
70607224b051c8919090f108669c35f5582c080cc0341ee1fe953b10b82368ca  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.5.2-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 dependancies. 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.5.2-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.5.2-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.5.2-beta&#34;
GO111MODULE=on go install -v -mod=vendor -ldflags &#34;-X github.com/lightningnetwork/lnd/build.Commit=v0.5.2-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! ⚡️⚡️⚡️

# Notable changes

## Expansion of lncli block size

In this release, we increase the gRPC block size from 4MB to 50MB. Recently, the output of lncli describegraph has hit the block size cap due to the expansion of the mainnet graph. Without this attempts to fetch the graph return an error of:

[lncli] rpc error: code = ResourceExhausted desc = grpc: received message larger than max (4246753 vs. 4194304)


With this commit, we give ourselves some breathing room. It's important to note that the max message size limit is a client side setting. As a result, any developers driving lnd with gRPC will also need to raise their block size limit as well if they wish to fetch the graph over gRPC.

## Switch to Go Modules for Dependency Management

With this release, lnd now uses go modules rather than glide to handle our package dependency management. End users and developers should see no functional change, as the Makefile is still the primary interaction point when building and testing lnd. Switching to go modules also preps us for the fully reproducible binary builds for Go which are slated to land in go1.13.

## Config and Wire Protocol Validation Fixes

A node's color is now properly validated when passed in as a config or command line parameter. This fix ensures that we're able to properly parse a hex color before attempting to commit it to the database. With this change, if an invalid color is passed, then lnd will refuse to start.

We'll now validate our own node announcement as a sanity check to ensure generated announcements elsewhere in lnd are fully protocol compliant.

We'll now properly avoid creating empty buckets within bolt which have been the source of prior inadvertent bugs.

We'll now ensure that we don't accept any node announcements with an invalid alias.

A bug has been fixed wherein we'd encode an invalid (too long) length for the enclosed ChannelUpdate within an onion error. This didn't affect lnd nodes as we didn't rely on the encoded length when decoding the error payload. However, other implementations did, which rendered them unable to decode a sub-set of our onion error messages.

A bug related to the FeeUpdate message has been fixed which could at times cause two channels to de-synchronize.

lnd, will no longer send the IncorrectHtlcAmount error. Instead, it will now use the new UnknownPaymentHash error that includes the amount of the HTLC.

All channels created by lnd will now properly have the new max_htlc field set. This is a prep for our upcoming AMP implementation. Payment splitting heuristics can use this value as a guide when determining payment chunk size, and nodes can use this value to control the largest payment shard they'll accept. In a future release, we'll make this value configurable over the RPC interface.

## Payment Path Finding and Retries

We've modified our retry and search space pruning code when routing payments to be more consistent. The following issues has been fixed: - If the channel update of FailFeeInsufficient contains an invalid channel id, it is not possible to properly add to the failed channels set. - FailAmountBelowMinimum may apply a channel update, but does not retry. - FailIncorrectCltvExpiry immediately prunes the vertex without trying one more time.

A bug has been fixed to ensure that we get passed a non-nil route. Previously with unchecked usage of the SendToRoute API, this may have caused a panic.

A change has been made to decouple the disabled bit from our local path finding. This is a preparatory step for an overhaul w.r.t the way we enable/disable channels, which is expected to land in 0.6.

## RPC Interface Bug Fixes

We'll now properly validate the ChannelPoint argument for the CloseChannel RPC call. The lncli command validates this field already, but a check was lacking in the main RPC pipeline as it assumed lncli was being used.

Invoices that were created with hop hints will now show up as "private" within the output of lncli listinvoices.

Additional validation has been added to ensure that it's no longer possible to attempt to force close a channel twice over the RPC interface. The second time wouldn't generate any new changes, but could at times unnecessarily block this second call.

Channels that are waiting to be opened, but which also have an unconfirmed closing transaction will now properly show up within lncli pendingchannels.

## HTLC Forwarding Fixes

We'll now properly return FinalFailExpiryTooSoon rather than FinalFailIncorrectCltvExpiry when the final hop of a route receives an HTLC expiry that's too soon.

## Switch from bolt to bbolt.

In this version, we've made a full switch from bolt to bbolt. bbolt is the maintained fork of the original bolt project. As it's maintained by CoreOS it actively has bug fixes land it in, which should increase the stability of our primary database.

## Optimizations

We'll now scan backwards from the latest height back to the height hint when a sub-system needs to query for the unspentness of an output. This speeds up routine scans of recent channel closes as we no longer need to start from potentially months back in the past.

Rather than create a thread pool to generate/check signatures for the commitment updated protocol, we'll now use a global signature thread pool. This serves to reduce the total number of goroutines, idle CPU usage, and memory usage of lnd for larger nodes.

## Changelog

The full list of changes since 0.5-beta can be found here: * https://github.com/lightningnetwork/lnd/compare/v0.5.1-beta...v0.5.2-beta

# Contributors (Alphabetical Order)

Chris Coverdale (ccdle12) Conner Fromknecht ErikEk Federico Bond Johan T. Halseth Joost Jager Olaoluwa Osuntokun orbitalturtle Valentine Wallace Wilmer Paulino Xavi Soler /laolu32@gmail.com

2019-02-06

#### RFC

type rfc # title date status
bolt routing gossip BOLT 7: add extended channel queries 2019-02-06 Closed
bolt X Access to the minutes of the IRC meetings? 2019-02-05 Closed
bolt onion routing BOLT 4: Correct "16-byte" to "12-byte" (padding) 2019-02-05 Merged
bolt X Rephrase Forwarding HTLCs Requirements 2019-02-05 Merged
bolt X Clarify ownership of max_htlc limits at receiving update_add_htlc 2019-02-04 Merged
bolt X Specify OP_DATA to express accepted/offered_htlc_script with same 2019-02-04 Merged
bolt X Recurring Payments 2019-02-04 Update
bolt onion routing BOLT 4: Clarify final_incorrect_cltv_expiry data 2019-02-04 Update
bolt X limit max_value_in_flight to channel capacity. 2019-02-01 Closed
slip X Add Snowblossom 2019-02-06 Merged
slip X Add Energy Web 2019-02-04 Merged
slip slip-0044 slip44: Add IoTE 2019-02-07 Merged