Onion Routed Micropayments for the Lightning Network
Switch branches/tags
Nothing to show
Clone or download
Latest commit 725fcf8 Nov 20, 2018
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
cmd multi: switch over all imports to point to btcsuite Jun 5, 2018
.gitignore sphinx: add specification onion error obfuscation Jul 14, 2017
.travis.yml build: update travis to build against latest go versions Mar 11, 2018
LICENSE add copyright, license and discouragement in readme Jan 16, 2016
README.md Update README.md Oct 10, 2018
batch.go Expose some fields and methods publicly on Batch struct. Mar 26, 2018
bench_test.go multi: switch over all imports to point to btcsuite Jun 5, 2018
error.go Modify ReplayLog interface. Mar 26, 2018
glide.lock build: point glide file at btcsuite instead of roasbeef forks Jun 5, 2018
glide.yaml build: point glide file at btcsuite instead of roasbeef forks Jun 5, 2018
hornet.go multi: switch over all imports to point to btcsuite Jun 5, 2018
log.go log: introduces the SPHX subsytem logger Feb 21, 2018
obfuscation.go multi: switch over all imports to point to btcsuite Jun 5, 2018
obfuscation_test.go multi: switch over all imports to point to btcsuite Jun 5, 2018
replay_set.go replay_set: adds ReplaySet to store outcome of batched processing Feb 8, 2018
replaylog.go Expose some fields and methods publicly on Batch struct. Mar 26, 2018
replaylog_test.go Implement basic in-memory ReplayLog for use in tests. Mar 26, 2018
sphinx.go sphinx: expose the extra unused bytes within the HopData struct Jun 27, 2018
sphinx_test.go test: update set of tests to supply data for the set of extra bytes Jun 27, 2018

README.md

lightning-onion

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

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

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

In line with Bitcoin's spirit of decentralization and censorship resistance, we employ an onion routing scheme within the Lightning protocol to prevent the ability of participants on the network to easily censor payments, as the participants are not aware of the final destination of any given payment. Additionally, by encoding payment routes within a mix-net like packet, we are able 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 the ultimate destination of the payment
  • Participants within a route aren't aware exactly how many other participants were involved in the payment route
  • Each new payment route is computationally indistinguishable from any other payment route

Our current onion routing protocol utilizes a message format derived from Sphinx. In order to cater Sphinx's mix-format to our specification application, we've made the following 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 in order to cut down on the packet-size, and also as we don't currently have a use for a large message from payment sender to recipient.
  • We've dropped usage of LIONESS (as we don't need SURB's), and instead utilize chacha20 uniformly throughout as a stream cipher.
  • Finally, the mix-header has been extended with a per-hop-payload which provides each hops with exact instructions as to how and where to forward the 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:

In the near future, this repository will be extended to also includes a application specific version of HORNET.