A sidechain-based settlement network for traders.
An API to issue and manage digital assets on the Liquid Network.
Financial products for the Bitcoin era.
Our own implementation of the Lightning protocol.
Colocation services for Bitcoin mining operations.
Cryptocurrency Data Feed
Real-time and historical cryptocurrency trade data.
The Bitcoin blockchain, delivered from space.
An open-source, sidechain-capable blockchain platform.
A simple Bitcoin and Liquid wallet built for everyone.
A fully open-source hardware wallet for Bitcoin and Liquid.
A multi-platform, feature-rich Bitcoin and Liquid wallet.
Search data from the Bitcoin and Liquid blockchains.
The long wait is over: we, the c-lightning team, are excited to announce the 0.6 release of c-lightning, an important milestone for the project. This complete rewrite of the previous implementation is the first fully specification-compliant release of c-lightning. It migrates away from the protocol used while designing the specification and toward a new architecture that is modular and extensible, to better adapt to your needs and your infrastructure.
Today also marks an important day in the growth and development of the Lightning Network: All three of the Lightning implementations (Eclair, lnd, and c-lightning) are now in beta! Since the introduction of the Blockstream Store in January, the Lightning Network has grown tremendously. Around the announcement of the Blockstream Store, the Lightning Network had a total of 46 open channels and 0.682 BTC in capacity. Today, there are roughly 7,800 open channels with 26 BTC of capacity. That is a 16,856% increase in channels and a 4,084% increase in channel capacity in 6 months!
While there are far too many new features in the 0.6 release to list, the following are the most interesting and impactful:
The c-lightning architecture is based on a number of independent communicating processes, each with its own responsibilities. This allows better integration into your infrastructure and better adaptation to your needs. Two daemons that are global for all channels,gossipd and hsmd, are of particular note because of their modular design.
gossipd manages a local view of the network and is tasked with finding a path from the source of a payment to its destination. The default implementation attempts to find a route with reasonable tradeoffs between fees, timeouts, and stability. It also obfuscates the route by selecting randomly among a number of candidate routes and tweaking the amounts and timeouts in order to conceal the endpoints of a payment. The default implementation can easily be switched out if you have particular routing requirements or want to enforce a specific routing policy, such as always selecting the route with the lowest timeouts or the lowest fees.
hsmd manages all operations that touch cryptographic materials and controls the funds in the channel. It is the sole subsystem that has access to the node’s private key. This means that other subsystems do not hold any private information and must communicate with the hsmd daemon to sign or decrypt anything. Centralizing the cryptographic operations in this manner reduces the surface that needs to be secured and opens up a number of interesting applications. While the default hsmd implementation already provides good security through process separation and the ability to further secure it via OS level security, e.g., SELinux and AppArmor, it can be easily replaced with an implementation that talks to a physical HSM. Replacing the hsmd implementation furthermore allows headless operation, e.g., running a c-lightning node at home, with a paired mobile app managing the private keys and initiating payments or creating invoices.
This separation of c-lightning functionality into multiple daemons is not only a big improvement in flexibility, but also a robust improvement to node security, as it ensures that an attacker cannot directly interface with anything that touches the private keys. Each subsystem independently verifies the consistency of the internal state, disconnecting a peer and killing its process if any inconsistency is detected. The multi-daemon architecture also enables the use of Docker, SELinux and AppArmor to lock down what information each daemon can access and what actions they can perform.
Our work with c-lightning is far from done; we are constantly working on features and enhancements, as well as improvements to performance, stability, and usability. Didn’t find your favorite feature? Have some feedback that might be helpful? Why not file an issue on Github, drop us a line on the mailing list, or contact us on IRC.
In parallel, we are also contributing to the advancement of the Lightning specification itself and are actively researching what the next iteration of the protocol could look like through initiatives like our eltoo proposal and upstream Bitcoin proposals such as SIGHASH_NOINPUT.
We’d like to thank the many contributors who have not only contributed code to c-lightning, but also those who were #reckless enough to test and give feedback about what works and what could be improved. And finally, we’d like to thank the other Lightning Network teams, ACINQ and Lightning Labs, as well as all individual contributors that pitched in to make the Lightning Network community such a pleasant, collaborative and open environment!