1nd Alpha Release: Lightning Network Open to Developer Testing
The Lightning Network has always been seen as a solution to help alleviate the scalability problems we have seen in Bitcoin as daily transactions continue to rise. Due to the fixed block size of 1MB, Bitcoin can only handle seven transactions per second. Implementation of lightning would enable off-chain transactions with minimal fees and immediate confirmations. Talked extensively with some development testing done, Lightning Labs announced on January 10 the release of the alpha of the Lightning Network Daemon.
This alpha release is open to public developer testing and is the most feature-rich implementation of Lightning following its release. Over the next few months, the performance of the protocol will be enhanced, and while still in the experimental phase, a user-friendly version will be released too.
“The daemon is a full implementation of Lightning, capable of: opening channels with peers, closing channels, completely handling all cooperative and non-cooperative channel states, maintaining a fully authenticated and validated channel graph, performing pathfinding within the network, passively forwarding incoming payments, and sending outgoing onion-encrypted payments through the network.”
Known as “1nd”, it was coded from scratch using Go, which was chosen due to its “first-class language-level support for concurrency, expansive standard library, memory safety, and simple language design.” The last point holds particular importance due to the priority of readability in 1nd.
1nd also has an RPC layer powered by gRPC, allowing developers to interact with 1nd from nine different coding languages, including C++, Java, Python, and PHP. Due to the ability for gRPC to produce language-specific client-side libraries, manipulation of 1nd is as easy as changing objects in the chosen language of the developer.
The channels themselves feature both SegWit as well as onion-routed micropayments. SegWit allows for infinite channel lifetime, two-stage Hash Timelock Contracts (HTLCs), as well as Unlinkable Outsourced Channel Monitoring, is in essence where TXIDs do not reveal the transactions, and signatures do not reveal messages. Lightning would not just address scalability problems in Bitcoin, but also that of privacy:
“Within lnd, all outgoing payments are dispatched using a modified version of Sphinx, which allows us to send payments across the network that are encrypted end-to-end. There is no support for sending payments with plaintext routes, meaning privacy is the default, as it should be.”
The onion-routed payments are enabled by default and made possible using HTLCs, which are complemented by SegWit. All payments are sent using end to end encryption, with no support for sending payments via plaintext.However, as the team notes, Lightning could be implemented without SegWit, but would compromise efficiency and security:
“Although alternative less-ideal channel constructions are possible without SegWit, by utilizing SegWit we’re able to deploy the most efficient, flexible, and safe channel design.”
In the future, 1nd looks to achieve full compliance with BOLTs, or basis of Lightning Technologies, a series of documents defining the specifications of Lightning. On top of this, the developers behind 1nd also look to include interoperability with other Lightning implementations as well.
With work contributed from developers from Lightning Labs, Bitfury, Blockchain Lab, Chain Labs, and even MIT’s DCI, the amount of talent poured into this project just shows how monumental an implementation of the Lightning Network will be for the future of Bitcoin. While developers will now be able to build Layer-2 applications to see what is possible, the creators behind 1nd will continue to improve upon the alpha release.
More details about the Lightning Network and its implications for Bitcoin can be found in the white paper here.
