Tipping in bitcoins!
Like something here? I hate ads, but throw me a few cents at 1RustyR X2oai4EYYDpQGWvEL62BBGqN9T so I can use those to tip others!
See bitcoin:
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:
- A soft-fork is required, to protect against malleability and to allow new signature modes.
- A new peer-to-peer protocol needs to be designed for the lightning network, including routing.
- 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.
- More refinements (eg. relative OP_CHECKLOCKTIMEVERIFY) to simplify and tighten timeout times.
- 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).
- 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).
- 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).
11 Comments for Lightning Networks Part IV: Summary
Ben | April 8, 2015 at 3:43 pm
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.
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.
Rusty, you need to do a PhD and get some academic trinkets for this stuff!