The #Bitcoin #Lightning Spec Part 5/8: Onion Routing Protocol

Rusty Russell
Dec 12, 2016 · 2 min read

[ Index, previous, next ]

On the Internet, routing is easy. You throw a packet out with an address stamped on it, and the recipient figures out how to get it closer. It mostly Just Works.

If you want anonymity, that scheme doesn’t work. Early on, Joseph Poon challenged me with the concept of a completely decentralized lightning network where (well-connected) phones could be first-class members. And you can’t work with Adam Back and Greg Maxwell for long without gaining a deep appreciation for the importance of privacy.

Thus it was important that this be implemented from the very first versions, as it affects almost everything else (especially route discovery!). The result is that Christian Decker and Olaoluwa Osuntokun adapted the previously-published Sphinx scheme pointed out by Laolu for use in lightning.

The construction ensures that no node can tell how many hops have already passed, or how many remain; only the previous and next hops. How to achieve that robustly is a little complicated, but this spec spells it out in detail.

It’s worth noting that both c-lightning and lnd already have compatible implementations, and there were minimal changes in Milan, so this spec is currently a little lazy: it’ll be cleared up into a step-by-step process like that we’ll see when we cover BOLT #8, and test vectors added. It also fails to specify the exact contents of the hop payload (fixed soon, see, and I think we’ll be tweaking the format of the failure messages (

Rusty Russell

Written by

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade