Feed for tag: c-lightning
A suggestion to hint for channel capacity in BOLT 11 invoices
In making payments through lightning channels, space is a factor that must be considered. However, one cannot tell how much capacity is available on which channel. Rusty Russell is proposing a change to the system that automatically attaches an ‘r’ field to any channel that has sufficient capacity to receive a certain amount. Some members of the community however think this may be risky because an unauthorized user can tell how much capacity one has and use it to attack.
Commit Activity For Thursday, Sep 20

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

Bitcoin Core #14248 and #14249:

This was a fix to a denial-of-service vulnerability (CVE-2018-17144) exploitable by miners that has been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of the vulnerable versions to 0.16.3 as soon as possible. The fix was backported to the 0.16 branch.

Bitcoin Core #7965:

This week a long-standing issue that tracked the removal of code handling whether the wallet is compiled in the libbitcoin_server component was closed by the merge of #14168.

This issue is part of an ongoing long-term effort to separate the wallet related code from the server code, along with a number of issues such as #10973(separate wallet from node whose PR is still being reviewed) and #14180(Run all tests even if wallet is not compiled) which will provide many benefits such as easier code maintenance, more straightforward way to test individual components and overall could help for a more secure software if the wallet component is moved to its own process.

LND #1843

The configuration option --noencryptwallet that was originally intended only for testing has been renamed to --noseedbackup and has been marked as deprecated. The help text for the option has been updated to mostly uppercase warning text:


This is intended for for users who might be using this option without realizing the real risk of losing money when using it.

NOTE: Any users that are actively using noencryptwallet will have to switch any scripts/confs to use noseedbackup as a result of this PR, though no further modification should be required.

LND #1516

This merge adds support for the v3 onion services available through Tor’s control port available since Tor v0.3.3.6. This will allow LND to automatically create and set up v3 onion services in addition to its exsiting v2 automation. For this to work users must have a running Tor service along side LND.

c-lightning #1963:

A series of patches that improve the cli and its help command by showing the command usage in the output. It also allows to verify a command without running it by using the check command:

lightning-cli check newaddr bech32

The above will check the parameter but won’t create a new address. It will just respond with “ok”.

On Lightning Nodes Centrality

Lightning Network is one of the key upcoming technologies that will change Bitcoin for the better, it’s a network of nodes with channels between these nodes that process payments and transactions “off-chain”, to keep only the few important transactions on-chain and decrease the load on the blockchain and the time it takes to send a transaction.

However there is a potential for node centrality in the lightning network, the main issue being that some nodes might end up functioning like banks, processing the bulk of these transactions. Developer Kulpreet Singh set out to measure the centrality of nodes in the Lightning network.

An Explainer on the Different Implementations of the Lightning Network
There are three different implementations of the Lightning Network. So far two of them have already reached mainnet beta phase (lnd and Eclair), while the last one (c-lightning) is still at the pre-beta phase. Although this is a big step for Lightning technology adoption, it will take some time until the first user-friendly wallets and applications will be available on the mainnet.