Rusty Russell's Coding Blog | Stealing From Smart People

Apr/15

8

Lightning Networks Part IV: Summary

This is the fourth part of my series of posts explaining the bitcoin Lightning Networks 0.5 draft paper.  See Part I, Part II and Part III.

The key revelation of the paper is that we can have a network of arbitrarily complicated transactions, such that they aren’t on the blockchain (and thus are fast, cheap and extremely scalable), but at every point are ready to be dropped onto the blockchain for resolution if there’s a problem.  This is genuinely revolutionary.

It also vindicates Satoshi’s insistence on the generality of the Bitcoin scripting system.  And though it’s long been suggested that bitcoin would become a clearing system on which genuine microtransactions would be layered, it was unclear that we were so close to having such a system in bitcoin already.

Note that the scheme requires some solution to malleability to allow chains of transactions to be built (this is a common theme, so likely to be mitigated in a future soft fork), but Gregory Maxwell points out that it also wants selective malleability, so transactions can be replaced without invalidating the HTLCs which are spending their outputs.  Thus it proposes new signature flags, which will require active debate, analysis and another soft fork.

There is much more to discover in the paper itself: recommendations for lightning network routing, the node charging model, a risk summary, the specifics of the softfork changes, and more.

I’ll leave you with a brief list of requirements to make Lightning Networks a reality:

  1. A soft-fork is required, to protect against malleability and to allow new signature modes.
  2. A new peer-to-peer protocol needs to be designed for the lightning network, including routing.
  3. Blame and rating systems are needed for lightning network nodes.  You don’t have to trust them, but it sucks if they go down as your money is probably stuck until the timeout.
  4. More refinements (eg. relative OP_CHECKLOCKTIMEVERIFY) to simplify and tighten timeout times.
  5. Wallets need to learn to use this, with UI handling of things like timeouts and fallbacks to the bitcoin network (sorry, your transaction failed, you’ll get your money back in N days).
  6. You need to be online every 40 days to check that an old HTLC hasn’t leaked, which will require some alternate solution for occasional users (shut down channel, have some third party, etc).
  7. A server implementation needs to be written.

That’s a lot of work!  But it’s all simply engineering from here, just as bitcoin was once the paper was released.  I look forward to seeing it happen (and I’m confident it will).

RSS Feed

15 Comments for Lightning Networks Part IV: Summary

Ben | April 8, 2015 at 3:43 pm

Rusty, you need to do a PhD and get some academic trinkets for this stuff!

Gene Vayngrib | April 11, 2015 at 9:32 am

Thank you for the analysis, this is a huge amount of work and insights for those of us who are building applications for the distributed world, but are not applied cryptographers!

I wonder if Lightening can be adapted to supply chain transactions, e.g. orders, shipments, invoices, negotiation workflow, etc.
Distributed commerce needs more than just scalable payments.
Can we build AirBnb, Uber, Alibaba this way?

Mashuri | April 15, 2015 at 5:25 am

Fantastic write up! This has really helped me wrap my head around the lightning network idea. To help clarify things further, I’d love to see a detailed diagram of which SIGHASH values gets used for each part of a transaction chain. Also, if relative OP_CHECKLOCKTIMEVERIFY is implemented, then you would not need to check for leaked HTLC’s every 40 days, right?

Author comment by rusty | April 15, 2015 at 2:36 pm

Yes, labelling how the proposed SIGHASH flags are used would be good, but I expect that to be further refined. I’m waiting for an update to the paper.

As for relative OP_CHECKTIMELOCKVERIFY; you still need to check regularly. The issue is subtler: in this scheme, you’d have to close out the channel completely before 40 days, otherwise the other side can post the very first transaction and cash it out immediately. With relative OP_CHECKTIMELOCKVERIFY, it’s 40 days from when it hits the blockchain, so you can keep using the same channel forever. You still need to check regularly if an old transaction has been leaked, though.

Mashuri | April 16, 2015 at 2:21 am

Maybe I’ll try labeling your flowchart and posting it to bitcointalk for evaluation / refinement.

If nlocktime becomes open to scripting via a soft fork, which looks likely with BIP65, couldn’t there be something that would also expire a transaction after a certain relative height? I’m thinking something like OP_RELATIVECHECKLOCKTIMEVERIFY and OP_RELATIVECHECKLOCKTIMEEXPIRE, which would create a self-closing “window” for that transaction to be valid.

Mashuri | April 16, 2015 at 2:32 am

Hmm… On second thought, the script commands would more fittingly be OP_RELATIVECHECKLOCKTIMEVERIFY or OP_CHECKLOCKTIMEVERIFY and OP_CHECKLOCKTIMEEXPIRE.

Mashuri | April 16, 2015 at 9:44 am

Apologies if I’m over-commenting but I can’t edit my previous posts. I went ahead and submitted my best guess as to how the sighashes would be distributed in your transaction example: https://bitcointalk.org/index.php?topic=970822.msg11098954#msg11098954

And just a final clarification for my CLTV idea. What I’m looking for is a way to encumber a transaction with a relative locktime, so that it is unspendable for a set amount of time after it’s inclusion in the block chain (what OP_RELATIVECHECKLOCKTIMEVERIFY would do) but also encumber it with a fixed time that the transaction would become permanently unspendable, regardless of when it gets included in the chain (I made up OP_CHECKLOCKTIMEEXPIRE to represent this). For example, I could create a HTLC with OP_RELATIVECHECKLOCKTIMEVERIFY at 10 days and OP_CHECKLOCKTIMEEXPIRE at 20 days. This would give the transaction a 10 day window to be included in the block chain, while still giving the counter party 10 days after its inclusion to cancel it with an unlocked transaction.

Mike | May 1, 2015 at 1:21 am

So I’m really trying to grasp how Lightning works, but I am a layman, so please bare with me. It sounds like instant transactions are possible, after an initial blockchain transaction to open a channel. So is it fair to say that the Lightning Network is not a “buy a coffee” solution as you aren’t likely to have a pre-existing channel open with a coffee shop. Rather, Lightning Network would be useful when paying for a service like use of someone’s wifi hotspot? If so, what is the advantage over micropayment channels?

Again, if my questions sound stupid, my apologies.

Author comment by rusty | May 1, 2015 at 9:03 am

Hi Mike, that’s OK, you missed a trick; these channels form a payment network. You would already have a channel open with eg. BitPay. The coffee shop would have a channel, eg. id number 1234567 with Credit Suisse. You scan a QR code which contains “Amount:$2. Vendor:Credit Suisse. Account:1234567. “; that sends $2 via your channel to BitPay, plus tells them where to route. They forward that $2 offer (minus fees) onwards, within milliseconds it reaches the Credit Suisse < -> Coffee shop, which accepts it by providing the receipt number.

Hope that helps!

Mike | May 2, 2015 at 12:01 am

How do maintain a persistent open channel on a smartphone? Aside from battery drain concerns, what about hopping on a subway or entering an area of no-coverage?

I’m curious as to how this would roll-out in the real world. Would the coffee shop be more likely to insist that any Bitcoin transactions occur only on the Lightning Network? What does this do to the utility of Bitcoin itself, if it can’t even be spent natively anymore due to merchants preferring/insisting on instant Lightning Network transactions over zero-conf or 10 minute wait blockchain transactions?

Author comment by rusty | May 6, 2015 at 6:27 am

Hi Mike,

Good questions! The maintenance of a channel does not imply the maintenance of a TCP connection. It’s simply a set of unpublished transactions. Sure, the other end might publish them to “cash in” if it doesn’t hear from you for long enough, though there’s no reason unless they want to spend the funds, since those are not going anywhere.

The coffee shop scenario was always an awkward fit with raw bitcoin: Poon-Dryja networks are an obvious improvement. This applies to any zero-conf transaction, or any transaction too small to justify the transaction fee. But if I want to send you $100 (from here in Australia) today’s bitcoin is going to win; I’m not likely to have that much sitting in my channel.

Cheers,
Rusty.

Jorge Stolfi | June 20, 2015 at 9:25 pm

I am lost in all the technical details. Could you please show (or point out) a worked out example like the one below, from start to end? Please omit the internal details, just say what the naive clients would see.

Three customers — Alice, Bob, and Carol — have 10 BTC each that they intend to spend over the next month by making several purchases from merchants Rakuten, Starbucks and Tesco, over the Lightning Network. Obviously they don’t know exactly how much they are going to spend with each. They are all served by one Hub.

I suppose that A, B, and C start by opening payment channels with H, locking up their 10 BTC with an automatic release time of one month.

Then what? I suppose that H has to open payment channels with R, S, and T? Does H have to lock up bitcoins in those channels too?

Author comment by rusty | June 21, 2015 at 3:28 pm

Thanks! I’ve been getting a few questions like this, and it’s worth doing a step back and writing a high level description.

The real problem with that is that it goes outside the scope of the paper; there are many other things needed to create a working network. I had a great face-to-face discussion with one of the authors (Joseph Poon) who envisioned a very distributed and fluid network; you would create channels to 5 random hubs. You might pay a small fee for them to lock up money in the channel too (which is a requirement if you want to receive payments), or it might be enough that you simply cover the bitcoin transaction fee.

R, S and T already have channels to someone (probably not the same as you). When Starbucks tells you where to send money (ie. which hub they’re on) you’d send from one or more channels of your choice; probably which ever’s closest, and whatever channels you have money in. They route from the network from your hubs to theirs, and they payment(s) go through once the routing works.

Hope that clarifies a little!

Mike | June 26, 2015 at 1:13 am

Any chance you can explain the relevant differences between Lightning and Duplex Micropayments?

Jorge Stolfi | June 27, 2015 at 9:02 pm

Thanks for the reply! You say:

> you would create channels to 5 random hubs [ … ] R, S and T already have channels to someone (probably not the same as you).

I know, but let’s simplify the example and assume a single hub.

> You might pay a small fee for them to lock up money in the channel too (which is a requirement if you want to receive payments), or it might be enough that you simply cover the bitcoin transaction fee.

Whatever the detailed path, the users will eventually have to pay the transaction fee F of every blockchain transaction that will be required to open, close, and maintain the channel(s) between them and the hub(s). I have seen estimates that F may be as high as 100 USD, once the bitcoin blockchain has become the settlement channel for the LN…

> They route from the network from your hubs to theirs, and they payment(s) go through once the routing works.

I am willing to trust that the mechanism work as claimed, but I am trying to understand how the system is supposed to work from the user’s perspecive: who has to lock up bitcoins, how much, for how long, when the merchants will get their coins, etc..

It would help a lot to have a worked-out example, *with numbers*…

«

»

Find it!

Theme Design by devolux.org

Tag Cloud