Lyn - Lightning Your .NET

Adopt the Lightning protocol in your own software to enable use-cases beyond blockchains.



Read our Stratis Decentralized AcceleratorSDA proposal

Introducing Lyn

Lyn is an open source development project working to implement the Basis of Lightning Technology (BOLT), which is the standardized technical specification for the implementation of the Lightning Network.

We're building Lyn to enable Lightning-protocol applications and services ontop of Bitcoin and Stratis blockchains, making Stratis even better for real world financial services and businesses.

The team behind Lyn is an extremely experienced team of software developers and engineers that already have many years of experience working on Blockchain technologies.

There are other existing implementations of Lightning, but none that is based upon C# and .NET. We believe that an alternative implementation based on .NET, will increase innovation and adoptions among more developers globally.

A Stratis Decentralized Accelerator proposal

Lightning node in C#

We make a bid to the Stratis Decentralized Accelerator for funding to develop a lightning node in C#, this will be deployed on top of the Stratis network but will also be a scaling solution for the Stratis technology stack. Our focus will be a solution that is cloud aware (mainly the Azure cloud), multi chain and with support for multi users in mind.

C# is the 5th most used language and is very popular with enterprise and corporate environments, currently C# solutions that want to interact with the lightning network will need use bindings to external dlls and/or write extensions in unfamiliar languages, having a lightning implementation in C# using industry common practices will allow developers to easily extend lightning and the usage of native packages to interact with the lightning network.

What is lightning?

Lightning is a layer two scaling protocol that is sits on top of the Bitcoin network, the lightning protocol is designed with multichain support in mind and can be used to scale other blockchains such as the Stratis network. On the lightning network participants open bidirectional payment channels between them and can then send bitcoin payments off chain, but nodes can also advertise their channels on the lightning gossip network and respond to payment routing requests for a competitive fee.

Lightning is designed with the ability to add many new message types, lightning is also designed with privacy in mind such that all communications between peers are private and encrypted, payment routing uses onion like layers to hide recipients identity and protect privacy (when routing a payment a node does not know who initiated the payment and who it is for)

Applications of lightning

Anything that uses payments (and micro payments) can integrate lightning such as:

And we believe lots more features will come up over time.

Lightning projected growth

The lightning network capacity now exceeded $100m (2300 Bitcoin) with over 25k nodes and over 65k channels, in the last month alone the network capacity increased by 20%. Lightning network is constantly growing.

Technical proposal

Our proposal comes in two parts a full lightning node implementation based on the lightning RFC also referred to as BOLT (Basis of Lightning Technology), an implementation which is compatible with the Bitcoin network and the Stratis network (a multi-chain lightning node). The second part is about the applications of lightning that use the lightning node implementation such as swaps, watchtowers and routing services which will be targeting cloud provides or the Stratis master nodes.

Lightning Node

The following sections describe the BOLTs we will implement that are required to run a lightning node. It also includes a docker based test suite to test and insure compatibility between existing implementations. The node will be compatible with the popular UI for lightning called RTL (Ride The Lightning)

All the BOLT codebase will come in the form of nuget packages, this are lightning library components that can be used in C# applications such as web, mobile and even games (with unity).

Work has already started on an implementation called Lyn (lightning in Danish). The codebase can be found here Lyn

The lightning node adds scaling capabilities to the already wide Stratis technology stack, we will develop the node with cloud architecture in mind, parts of the workload required to successfully route payments in lighting can be delegated to dedicated cloud service providers or master nodes.

Payment Channels (BOLT1,2,3,5,8,9)

Payment channels allow the exchange of transactions between two participants which are sending payments off-chain in a trustless setup. This include a node that can create funding transactions to open channels, the commitment transaction to secure the funds and the HTLCs (hash timed locked outputs) to make off chain payments between participants. It also includes lots of boilerplate components such as the gossip messages, noise protocol the interaction with base layer etc..

A big part of this section is already implemented (BOLT1,3,8,9) in the Lyn repo.

Payment Routing (BOLT4,11)

Onion routing (built of layers like an onion) refer to the ability to route payments between participants who don't share a channel directly, an onion routed packet is used to route a payment from an origin node to a final node through a number of intermediate nodes, called hops. The payment initiator node, who knows the public keys of each intermediate, create the onion packet in such a way that each node only knows it's previous and next route but can't read information of any participant or how many hope this route has.

Invoicing, defining protocol messages where participants can request payments over Lightning.

Payment Channel Discovery (BOLT7,10)

Node and channel discovery serve two different purposes, Node discovery allows nodes to broadcast information about themselves, so that other nodes can open connections and establish payment channels with them. Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations. Discovery is done using gossip messages, each node that receives gossip messages stores it and routes it on to its peers.

Lightning Applications

Features that use and build on top of the lightning node and are intended to be used by Stratis master nodes

Atomic Cross-Chain Lighting Swaps

Lightning enables channel rebalancing using atomic swaps between an off-chain lightning channel to a Bitcoin on-chain address (and reverse) using a protocol extension called submarine swaps.

LBTC to STRAX swaps - We'll use the submarine swaps protocol to enable atomic swaps between LBTC (Bitcoin locked in lightning channels) to STRAX on the stratis main chain.

LBTC to LSTRAX swaps - A lightning protocol extension called HODL invoices introduces expirable hash locked lightning payments, where a routed lightning payment is locked for a certain time until a secret is revealed. Using this mechanism a lightning payment from one chain can be hash locked at the receiver until the lighting swap payment from the sender on the second chain is sent.

Swaps will come with a light weight lightning UI.

Master node swap services

Stratis master nodes can provide a swap matching service where users can register a request to make a swap or ask for available open swaps, effectively becoming a non-custodial market liquidity provider. When a swap will take place it will be routed using the master node channels and will incur routing and swapping fees.

Stratis master nodes are known, semi-trusted, entities however the swap users can stay unknown.

Master nodes that run a swap service will gain fees in BTC and STRAX and will be required to run a fullnode and a lightning node on the Bitcoin and Stratis main chain.

Master node watchtower services

Watchtowers are specialized services that are always online in order to monitor the blockchain for channel breaches on behalf of lightning network participants.

Lightning channels create asymmetric commitment transactions on each side of the channel when sending funds off-chain, every new commitment transaction effectively invalidates all previous commitment transactions. A malicious side of the channel who breach the channel can be punished by loosing all the funds in the channel. In order to spot channel breaches node operator must stay online to monitor the blockchain.

The services of monitoring a channel breach can be delegated to master nodes who keep an always online node anyway. A lightning user that is not always online and uses a watchtower service will register an encrypted justice transaction alongside a transaction locator to the Watchtowers. Both the encryption key and the transaction locator are derived from the breach transaction id, meaning that the Watchtower will be able to decrypt the justice transaction only after the corresponding breach is seen on the blockchain.

Master nodes that run a Watchtower service can claim fees for such a service either in BTC or STRAX and will be required to run a fullnode and a lightning node of the network they provides watchtower services for.

Master node routing services

Lighting nodes build payment routes in order to make a payment over several hopes. To be able to construct routes a node needs to maintain a recent and correct view of the network channels and balances. This is done using gossip messages that are sent over the lighting network. Nodes stay online and continuously listen to gossip messages to be able to create a graph of the network.

The services of constructing payment routes can be delegated to master who keep an always online node anyway. This enables light wallets that don't need to stay online to make route requests when making a lightning payment.

Master nodes that run a routing service can claim fees for such a service either in BTC or STRAX and will be required to run a fullnode and a lightning node of the network they provides routing services for.

Routing services have some privacy disadvantages, to overcome that we can use Trampoline payments which are a proposed type of payment where the spender routes the payment to an intermediate node who can select the rest of the path to the final receiver or to another Trampoline enabled node. Time permitting we may enable Master nodes to act as nodes that can route trampoline payments.

Our Team

The Stratis Decentralized Accelerator business proposal is made on behalf of the Softchain Ltd and the following group of individuals.

We all have a great passion for blockchains and is seeking financial support to continue our work to develop an open source Lightning protocol implementation in C# and .NET.


Dan Gershony

Dan is an ex-CTO of Stratis Group Ltd and brings almost 20 years of software development experience to the team, he had a main role in building the Stratis blockchain stack. He has many years of experience with blockchain development and is currently one of the active contributors to Blockcore (an open source blockchain platform based on Stratis tech) and Lyn (a lightning implementation in C#).

GitHub

Sondre Bjellås

Sondre has 23 years of experience with software development and many years experience with blockchain development and has made contributions to the Stratis codebase. Sondre has successfully launched the blockchain City Chain and is currently working as an architect and developer for the open source group behind Blockcore.

Sondre is an very active contributor on many open source projects related to decentralized technology and blockchain. He is currently working decentralized identities (DID) and verifiable credentials platform for NFT based marketplaces and personal data vaults.

GitHub

David Gershony

David brings 11 years of experience to the team, and is an expert in Problem Solving & Complex algorithms when it comes to code. With years of experience in software Development & Teach Lead in the world of banking, payments and billings domains.

GitHub

Adam Elgressy

Adam almost 20 years of experience and brings vast knowledge in Product Management, defining roadmaps, prioritizing and planning, managing product lifecycle & release, crafting UI/ UX requirements.

In addition, Adam has many years of experience as a software engineer and team leadership using industry-proven methodologies such as Agile and Scrum, working in Start-Up environments.

GitHub

Kyllian Le Borgne Roperch

Kyllian has 6 years of experience in development and around cryptocurrencies. He is currently working at Decentraland as a DevOps and engineering productivity.

GitHub

Emil

He has over 20 years of professional software experience and has specialized in embedded systems and mission critical real-time systems and low level IO. Emil also has extensive experience with enterprise systems, protocols, databases and distributed systems.

He is currently working on a complete end-to-end hardware/software design project for a customer. favourite languages are C# and C++.

GitHub

Cost and schedule

Estimating delivery of software is hard and very inaccurate, we provide our best effort estimation and delivery schedule. The estimations may change and we will provide updates to the community if and when delivery dates change.

Part 1 Node:

Part 2 Applications:

There will be two rounds of fund raising.
Estimated amount required for development:

Private funding $200,000

Part 1 $650,000

Part 2 $500,000

Due to the complexity of implementing Lightning-protocol, we have a good margin in our funding requirements to ensure we will be able to complete as much as possible. Even with a partially completed implementation, Lyn can be used for multiple useful purposes.

We might update the funding plan as more details emerges, and requirements are updated and changed.

If there is unused funding upon completion, the remaining funds will be returned to investors based upon percentage of total support.

Our development process will be public and we will release on weekly and monthly basis.

Stay connected