lightning-onion

This repository houses an implementation of the LightningNetwork's onion routing protocol. The Lightning Networkuses onion routing to securely, and privately route HTLC's(Hash-Time-Locked-Contracts, basically a conditional payment) within thenetwork. (A full specification of the protocol can be found amongst thelighting-rfc repository, specifically withinBOLT#04.

The Lightning Network is composed of a series of "payment channels" which areessentially tubes of money whose balances can instantaneous be reallocatedbetween two participants. By linking these payment channels in a pair-wisemanner, a network of connect payment channels are created.

Within the Lightning Network,source-routing is utilized inorder to give nodes full control over the route their payment follows withinthe network. This level of control is highly desirable as with it, senders areable to fully specify: the total number of hops in their routes, the totalcumulative fee they'll pay to send the payment, and finally the totalworst-case time-lock period enforced by the conditional payment contract.

In line with Bitcoin's spirit of decentralization and censorship resistance, weemploy an onion routing scheme within the Lightningprotocol to prevent theability of participants on the network to easily censor payments, as theparticipants are not aware of the final destination of any given payment.Additionally, by encoding payment routes within a mix-net like packet, we areable to achieve the following security and privacy features:

• Participants in a route don't know their exact position within the route
• Participants within a route don't know the source of the payment, nor theultimate destination of the payment
• Participants within a route aren't aware exactly how many otherparticipants were involved in the payment route
• Each new payment route is computationally indistinguishable from any otherpayment route

Our current onion routing protocol utilizes a message format derived fromSphinx. In orderto cater Sphinx's mix-format to our specification application, we've made thefollowing modifications:

• We've added a MAC over the entire mix-header as we have no use for SURB's(single-use-reply-blocks) in our protocol.
• Additionally, the end-to-end payload to the destination has been removed inorder to cut down on the packet-size, and also as we don't currently have ause for a large message from payment sender to recipient.
• We've dropped usage of LIONESS (as we don't need SURB's), and insteadutilize chacha20 uniformly throughout as a stream cipher.
• Finally, the mix-header has been extended with a per-hop-payload whichprovides each hops with exact instructions as to how and where to forwardthe payment. This includes the amount to forward, the destination chain,and the time-lock value to attach to the outgoing HTLC.

For further information see these resources:

• Olaoluwa's original post to the lightning-dev mailinglist.
• Privacy Preserving Decentralized Micropayments -- presented at Scaling Bitcoin Hong Kong.

In the near future, this repository will be extended to also includes aapplication specific version ofHORNET.