Weekly Edition for Thursday, Nov 15

front
brief items
bulletin
Front
brief items
Advertising Node Liquidity
Thursday Nov 15, 2018
by Chakib
lightning

A proposal by Lisa Neigut allowing LN nodes advertise their willingness to provide incoming capacity in exchange of fees in a “market” of advertised liquidity rates. This would help merchants to have access to incoming capacity which they need in order to receive payments from customers. The current alternatives would be either for customers to wait for on-chain confirmations and open a new channel or for merchants to make arrangements with other merchants that offer channel liquidity.

Follow the discussion here

read more ...
Blockstream Block Explorer is now Live
Tuesday Nov 13, 2018
by Shedrach Kongvong
sidechains

Blockstream is introducing its block explorer which has gone live on the internet. The new block explorer is first for users of the Liquid Sidechain but Bitcoin has been integrated so Bitcoin transactions on the blockchain can be checked using the Blockstream block explorer.

read more ...
Introducing the Ledger Donjon
Monday Nov 12, 2018
by Shedrach Kongvong
security
Ledger, the manufacturer of the popular hardware wallet Ledger Nano S has been working to improve the security of their products. This time, they are introducing not a device, but a group of security experts known as the Donjon. It is a small group of 8 experts in the smartcard and security industry. Their primary function is to work on improving the security of Ledger products by assessing vulnerabilities, testing and putting in place measures to check the security leakages.
read more ...
Bitmex Research Launched a Fork Monitoring Website
Saturday Nov 10, 2018
by Chakib
blockchain
BitMEX research developed a fork monitoring tool that can be used to monitor network and protocol upgrades for soft and hard forks for Bitcoin and BitcoinCash. They plan to include different implementations of Bitcoin nodes such as Bcoin, BTCD and Libbitcoin which might be helpful to detect consensus bugs such as CVE-2018-17144 that was discovered last September. They also announced that the source code for the tool will be made available soon.
read more ...
New Third Party Applications Available for Ledger devices
Thursday Nov 8, 2018
by Chakib
wallets

Ledger announced new third party applications available on their hardware wallets Ledger Nano S and ledger blue. This was done as part of an initiative called CryptoTuesday started in August.

Ledger welcomes Lisk, Factom, MIX Blockchain, Musicoin, GameCredits and EtherGem to the Ledger Nano S. Equally, the last four mentioned will be compatible with the Ledger Blue. These six applications have been developed by the respective communities, bringing the number of third-party developed apps to 32 since the start of the year.

CryptoTuesday is celebrated each first Tuesday of the month. For this event, we review applications compatible with our devices created by the communities of respective cryptocurrencies and publish them. We are incredibly grateful and humbled to have such active, engaged communities and enabled this monthly rendez-vous to honor that. Naturally, there are certain requirements and procedures for these submissions, which can be found on this page. Plans for upcoming application releases can be found on our Ledger overview: Internal and External developments page.

read more ...
Bulletin
lnd: v0.5.1-beta-rc1
[lightning:release]
Thursday Nov 15, 2018

This release is minor release of lnd, which includes several fixes and optimizations to make lnd even better. This time around one of the points of focus has been around the reliability, robustness and speed of the Neutrino backend, which is now in a state where it can be used for building applications for the Bitcoin testnet. This will let us sort out the last quirks and performance bottlenecks before it is ready to be enabled for mainnet.

Breaking changes

  • Remove NewWitnessAddress: The RPC NewWitnessAddress has been removed. Since we are only using witness addresses, addresses can be fetched using NewAddress.

A few RPCs have changed their behavior slightly, see the the RPC changes section.

Migrations

We now store the wallet’s birthday block to speed up rescans. If you are upgrading from an older version of lnd you should at startup see something like

2018-11-15 13:11:15.636 [INF] LTND: Version: 0.5.0-beta commit=v0.5.1-beta-rc1, build=production, logging=default
2018-11-15 13:11:15.636 [INF] LTND: Active chain: Bitcoin (network=testnet)
2018-11-15 13:11:15.638 [INF] CHDB: Checking for schema update: latest_version=6, db_version=6
2018-11-15 13:11:15.649 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2018-11-15 13:11:15.649 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080
2018-11-15 13:11:15.650 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-11-15 13:11:27.207 [INF] LNWL: Applying wallet transaction manager migration #2
2018-11-15 13:11:27.207 [INF] LNWL: Dropping wallet transaction history
2018-11-15 13:11:27.208 [INF] LNWL: Applying wallet address manager migration #6
2018-11-15 13:11:27.209 [INF] LNWL: Setting the wallet's birthday block from timestamp=2018-11-12 19:15:05 +0100 CET
2018-11-15 13:11:27.211 [INF] LNWL: Estimated birthday block from timestamp=2018-11-12 19:15:05 +0100 CET: height=408929, hash=0000000000114718f816515d333731e0f9982a4e703665771a192beadeb88398
2018-11-15 13:11:27.211 [INF] LNWL: Applying wallet address manager migration #7
2018-11-15 13:11:28.319 [INF] LNWL: Opened wallet

Note that it will then perform a rescan from the birthday, which might take a while. By setting the debug level to debug you’ll be able to track the process of this rescan.

Verifying the Release

In order to verify the release, you’ll need to have gpg or gpg2 installed on your system. This release candidate is only signed by halseth:

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

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

gpg --verify manifest-v0.5.1-beta-rc1.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.5.1-beta-rc1.txt'
gpg: Signature made Thu Nov 15 10:25:29 2018 CET
gpg:                using RSA key 7AB3D7F5911708842796513415BAADA29DA20D26
gpg: Good signature from "Johan T Halseth <johanth@gmail.com>" [unknown]

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

cat manifest-v0.5.1-beta-rc1.txt

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.1-beta-rc1

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

Notable changes

Neutrino

Neutrino is a new light client for Bitcoin, that is more private and tailored for use on the Lightning Network than previous light clients. For more information, check out this blog post.

Since the previous release of lnd, the version of neutrino used has gained a lot in terms of stability and speed. We now start catching up to the necessary filter hashes the moment we have enough block headers to verify them. This let us do most of the header fetching in parallel, drastically speeding up initial sync.

A number of fixes has also been deployed to ensure neutrino correctly handles header and filter responses from multiple peers in parallel, and even peers serving invalid filters.

Height hint cache

When lnd opens channels to other nodes, it must always make sure the counterparty hasn’t unilaterally closed the channel without its consent. This is done by scanning all blocks following the opening of the channel, to ensure no closing transaction has been confirmed. This is a quick check on full nodes, but since neutrino doesn’t keep the entire chain around, it must request filters (and potentially blocks) from the network to perform this check.

lnd performs this scan on every restart, checking if any of its channels have been closed while offline. With the addition of height hint caches we are now able to cache the results of previous such scans, letting us start the scan from where we left off, instead of scanning the chain all the way from the block where the channel was opened. With these additions, both txid confirmations and spend detection is now cached. This saves a lot on time and bandwidth at startup, letting light client users get back into sync with the network faster.

Validating received channel updates

When sending a payment, there exists situation where the graph information the client has is not up to date with the nodes it is attempting to route through. In these cases the routing nodes will send an error back along with the updated information, such that the client can retry the payment with the correct parameters.

Previously we didn’t check the signatures on this updated information, making it possible for nodes to respond with information for channels they didn’t control. With an added validity check, this is no longer the case, and all graph information must be signed by the controlling parties.

forgetchannel RPC

A new RPC has been added for debug builds, that let users forcefully remove channels from their databases. This must be used with caution, as all state for the targeted channels will be lost, essentially making it impossible to recover any funds kept in these channels. This RPC is added to let advanced users get rid of leftover channels from earlier versions of lnd, where channels were not always cleaned up properly. Channels that had their funding transactions broadcast with a fee too small can also be removed with this RPC. To make sure no one uses this functionality by accident, it is only possible to use in debug builds.

Build package

A new package build has been added to lnd, greatly simplifying the process of adding build dependent changes, and improving logging during unit tests. The version string of lnd will with this change include the version tag, commit hash and number of commits since the tag. Logs from unit tests can be inspected by passing log="stdout <loglevel>" to make unit.

go 1.11 support

The recommended go version has been upgraded to v1.11! The project now supports go 1.10 and go 1.11.

gRPC 1.15.0

lnd uses gRPC for its RPC interface, making it easy to gain access to the functionality of lnd from a wide set of languages. The gRPC version used was due for an upgrade, and has been updated to v1.15.0, up from v1.5.2. You shouldn’t be seeing any breaking changes with this upgrade.

Reject insane timelocks

We now check that forwarded payments don’t impose a timelock that is too far in the future. Earlier an attacker willing to lock up his own funds could craft routes where funds got locked up for a very long time.

New sweep package

A new package sweep has been introduced, intended to take care of all kinds of sweeps within lnd, such as retrieving funds from closed channels. This is part of an ongoing effort to reduce the statefulness of funds sweeping, and be smarter about batching sweeps together in bigger transactions to save on chain fees.

rejectpush option

When opening a channel to a peer on the network, you have the option to immediately send some funds as part of the opening process (what is called push amount). For most users accepting incoming channels this is not a problem (hey, free money!), but some merchants have seen customers pushing funds to them by mistake, resulting in an annoying refund process. Now there’s a new configuration option --rejectpush that makes the node reject any incoming channels that include a push amount.

Use SendToRoute with private channels

SendToRoute is an RPC that is used by advanced users to send payments along custom paths. Previously it had the restriction that the edges used in these custom paths were known to lnd. A new option pub_key in the route description given to SendToRoute lets lnd create the route without relying on the channel graph, making it possible to attempt payments even for channels unknown to lnd, such as private channels. This works since the payment is encrypted with the given public key, and now all information needed to construct the payload can be supplied over the RPC.

RPC changes

  • Deprecating untyped value fields: Since RPC fields are not always typed to indicate their unit, there has been confusion especially whether satoshis or millisatoshis are used for certain RPCs. Going forward fields should indicate their type (ending with _sat or _msat), and you might see the existing, untyped fields getting deprecated.
  • IncludeUnannounced flag for DescribeGraph: The DescribeGraph RPC is used to get a list of the current information found in the local graph, including all known nodes and channels. Earlier this would include information about private nodes and channels you knew about. With this recent change, the caller must explicitly set the IncludeUnannounced flag if it wishes this private information to be part of the output, to avoid this information being leaked involuntarily.
  • Prevent spending unconfirmed funds by default: The SpendUnconfirmed flag must now be set for the wallet to use unconfirmed inputs when opening channels.
  • Reversed QueryInvoices consistency: When querying for an offset of invoices in the reverse order, we would earlier list the first available invoice found after this offset. This was inconsistent with the non-reversed case, and has been changed.
  • Number of inactive channels in GetInfo: The GetInfo RPC call now shows the number of inactive channels in addition to the number of active.

Changelog

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

Contributors (Alphabetical Order)

AdamISZ Alex Bosworth Boblechinois CirroStorm Conner Fromknecht Daniel McNally Dave Kerr Desuuuu ErikEk Harald Nordgren Johan T. Halseth Joost Jager Olaoluwa Osuntokun Oliver Gugger Oscar Lafarga Patrick Roei Erez Vincent Woo Wilmer Paulino Xavi Soler bluetegu bob-333 chokoboko maurycy sevastos tailnode whythat

Notable Commits For Thu, Nov 15
[newsletter]
Thursday Nov 15, 2018

Notable issues and merges on Bitcoin Core, LND, c-lightning and libsecp256k1

Originally published by BitcoinOptech on newsletter #21

  • Bitcoin Core #14410 adds an ischange field to the getaddressinfo RPC indicating whether the wallet used the address in a change output.

  • Bitcoin Core #14060 makes configurable the maximum number of messages the ZeroMQ (ZMQ) interface will queue for a client. The default High-Water Mark (HWM) allows up to 1,000 messages to be queued before some messages are dropped. A new HWM may be chosen by setting one of the following configuration options to the desired maximum number of queued messages (or the maximum queue size may be made unlimited by setting it to 0): zmqpubhashtxhwm,zmqpubhashblockhwm, zmqpubrawblockhwm, and zmqpubrawtxhwm. The greater the queue size, the more memory the program will use.

  • LND #1782 adds a num_inactive_channels field to the getinfo RPC with the number of the node’s inactive channels (similar to the existing counts of pending and active channels).

  • LND #1944 adds a pub_key field to the sendtoroute RPC so that LND doesn’t need to get the pubkey from an external source. This allows routing payments through private channels that are not listed on the public network.

RFC Updates For Thursday, Nov 15
[core:rfc-updates]
Thursday Nov 15, 2018

BIPS

  • Merged PRs: 0
  • Opened PRs: 1
BIP Title Type
199 bip199 bytecode optimization - link Open PR

BOLTS

  • Merged PRs: 1
  • Opened PRs: 9
  • Opened Issues: 1
BOLT Title Type
✗ 02-peer-protocol.md: Minor typo. - link Merge PR
4 BOLT 4, 9, 11: Base Atomic Multipath Payments. - link Open PR
2 BOLT 2: Hashed Time Locked Contracts not Hash TimeLocked Contracts. - link Open PR
3 BOLT 3: commitment number not commitment transaction number. - link Open PR
2 BOLT 2: advise ping-before-commitment_signed on quiescent connections. - link Open PR
✗ 04-onion-routing.md: Prepare for extra onion blob encoding. - link Open PR
✗ 07-routing-gossip.md: Describe standard human-readable format for short channel ID. - link Open PR
4 BOLT 04: document non-strict forwarding - link Open PR
11 BOLT 11: Copy edit - link Open PR
3 BOLT 3 : Fix ambiguity on HTLC transactions spendable by a penalty one - link Open PR
✗ Specify that globalfeatures in node_announcement are identical to the globalfeatures in init - link Open Issue

SLIPS

  • Merged PRs: 14
  • Opened PRs: 2
  • Opened Issues: 0
SLIP Title Type
✗ Added HTH - link Merge PR
✗ Add QRL - link Merge PR
173 Slip 0173: Add Susucoin. - link Merge PR
44 slip-0044: Adding QRL - link Merge PR
✗ add Genom - link Merge PR
44 Add FLUID to SLIP-0044 - link Merge PR
173 slip-0173: add VIPSTARCOIN bech32 addresses - link Merge PR
✗ Add ETI (EtherInc) - link Merge PR
✗ GinCoin and Polis version bytes - link Merge PR
✗ Added BitCash - link Merge PR
✗ Adding High Performance Blockchain - link Merge PR
44 Update slip-0044.md with NULS main chain ID - link Merge PR
44 Update slip-0044.md - link Merge PR
✗ Add PalletOne(PTN) to BIP44 - link Merge PR
44 slip-0044: Add BitcoinSV - link Open PR
✗ add Blockstream’s Liquid Bitcoin sidechain token - link Open PR

Ledger Live Desktop: v1.2.5
[wallets:release]
Tuesday Nov 13, 2018
ledger-live-desktop version v1.2.5 released.

Features

  • Support for more derivations (#1599)
  • Provide a way to inform users of eventual service disruption (#1615)
  • Add links to Terms & Privacy Policy

🐛 Bugfixes

  • Handle gaps in sqlite accounts (#1609)
  • Wording fixes
Bisq: v0.8.1
[misc:release]
Monday Nov 12, 2018

Release notes

In this release only trade statistics and account age witness db was updated to improve startup time for a fresh install.

Url of the signing key (Christoph Atteneder): https://bisq.network/pubkey/29CDFD3B.asc Full fingerprint: CB36 D7D2 EBB2 E35D 9B75 500B CD5D C1C5 29CD FD3B

Import the key: curl https://bisq.network/pubkey/29CDFD3B.asc | gpg --import GPG prints a confusion warning: “This key is not certified with a trusted signature!” - See https://serverfault.com/questions/569911/how-to-verify-an-imported-gpg-key for background information what it means.

How to verify signatures? gpg --digest-algo SHA256 --verify BINARY{.asc*,} Replace BINARY with the file you downloaded (e.g. Bisq-0.8.1.dmg)

Verify jar file inside binary: You can verify on OSX the jar file with: shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/Java/Bisq-0.8.1.jar The output need to match the value from the Bisq-0.8.1.jar.txt file.

Hint for Debian users: If you have problems starting Bisq on Debian use: /opt/Bisq/Bisq

If your Linux distro does not support .deb files please follow this instruction:

cd ~/Downloads  
mkdir tmp  
cd tmp   
ar x ../Bisq-64bit-0.8.1.deb  
sudo tar Jxvf data.tar.xz  
sudo cp -rp opt/Bisq /opt/

That instruction is not tested on many different distros. If you encounter problems please report it in a Github issue so we can improve it.

WalletWasabi: v1.0.1
[wallets:release]
Friday Nov 9, 2018

WalletWasabi version Wasabi v1.0.1: Small UX Tweaks released.

Summary

The 1.0.1 Release mostly consists of smaller fixes those came up due to the influx of mainstream users. The most notable improvements are the implementation of OSX cmd+… copy-paste related keys (it was previously working with ctrl) and fixing a bug that prevented users with non-English Linuxes to use Wasabi.

Newbie Guide

While setting up Wasabi is straightforward, even the Linux wizard with the longest beard can get stuck on the most basic tasks. In that case, take a look at the Installation Instructions guide.

Pro Guide

If you want to build Wasabi from source code or update the source code check out these instructions.

FAQ

  • Where is Wasabi’s working directory located? Configuration, wallet and similar files can be found in %appdata%\WalletWasabi folder on Windows and in ~/.walletwasabi folder on Linux/OSX.
  • Can I use my own Tor instance, instead of Wasabi’s built in one? If you already have Tor, and it is running, then Wasabi will try to use that first, if it is not running, then Wasabi will use its built-in Tor. If you are running a Tor daemon not on the default port, then you can configure it in Wasabi’s Tools/Setting menu. If Wasabi is using your Tor daemon, then bear in mind that some Linux distributions’ package repositories ship with out of date Tor. In that case, either remove or shut down that Tor of yours or make sure it’s not out of date: Check Tor version: tor --version. If it’s not at least 0.3.2.2, then see this writeup on how to update it.
  • Why are the binary sizes so big? Wasabi is using client side filtering and these filters must be synced before using the wallet. The size of these filters are currently about 90MB. These filters are included with the binaries to avoid initial wallet syncing.
  • Requirements? x64, linux, >win7, >osx.10.12.

Release Notes