Lightning Network 2.0

Published in

The Abacus Crypto Journal

36 min readAug 23, 2018

Understanding the next wave of Lightning Network innovations, and the obstacles they seek to overcome on the winding road to a scalable Bitcoin

Lightning, it turns out, travels fast.

It’s quite a thing to marvel that it’s only been a year since Bitcoin’s Great Block Limit Fiasco of 2017, when it became undeniably clear that the cryptocurrency that was once regularly lauded as being “free and instant” had become neither of those things. Amidst the frenzied discussions of how to handle this serious PR problem was a sudden resurgence in interest in the Lightning Network (LN) — a method for making payments on a second layer on top of the Bitcoin protocol — that had first been proposed and outlined in 2015.

Last year, the LN existed only theoretically in whitepapers, message boards, and the minds of intrepid developers; skip ahead to today, and the thing is up and running and processing real, no-kidding payments, and even has had a few popular gimmicky applications on it to boot.

Now to be very clear: its current state of roughly 1500 nodes and 91 BTC of in-network liquidity (as of writing) is light-years away from offering anything like true scaling; it’s probably even fair to say it hasn’t quite yet approached proof-of-concept territory. But perhaps more noteworthy that the evolving technical implementation has been witnessing the evolution of the surrounding discourse: after the internecine feuding of the Great Scaling Debates literally split the Bitcoin community in two, the group narratives of the two sides suddenly cauterized: talk to a Bitcoiner, and it’s a safe bet that they’ll see LN as their inevitable scaling savior; talk to a Bitcoin Casher, and it’s safe that they’ll see block-size increase as the only canonical, Satoshi-sanctioned way to scale Bitcoin, and LN as some sort of non-functional Blockstream conspiracy.

The level of spite in this debate probably looks ridiculous and insane to crypto-outsiders, which may be in part because it is, indeed, kind of ridiculous and insane. However, to properly understand this debate, one must first understand that it’s really a debate about the nature of Bitcoin scaling in general, which is really a debate about the nature of economic value itself, which is really a debate about the future trajectory of human civilization, at which point the elevated passions don’t seem quite as out of place.

Digressions aside — the point is, the resurgence in LN attention has also meant a concomitant resurgence in debates about viability of the LN itself; a semi-predictable call and response of claims that the LN has inherent limitations and rebuttals of how they will be gracefully overcome. Thing is, as these debates rage on, there’s a community of developers coming up with new ideas and, ya know, actually building stuff. The attention (and — let’s face it — panic) around finding a scaling solution has lead to the LN community absorbing significant developer mindshare, and there are some pretty powerful innovations being conceived and, in some cases, already rolled out. Thus, much of the back and forth in said debates is outdated, or — if the discussion does acknowledge these new innovations — is bound to come off to new-comers like something of a foreign language.

This post attempts to provide a helping hand. I’ve split the criticisms of LN into three broad categories:

Problems with liquidity between channels
Difficulty obtaining the state of available routes
Issues associated with the necessity of live nodes

For each of these, I’ll be going over some technical proposals that set out to help overcome these obstacles, and I’ll provide explanations as to what they do, and technical-but-hopefully-not-overly-technical explanations of how they actually work. I’ve also included some thoughts and ideas of my own, because who’s gonna stop me.

While I have no illusions that any of this will help settle the eternal scaling debates, or even remotely decrease animosity among its participants, if this helps to educate, intrigue, and demystify things, so that at least some folks have a better understanding of what it is they’re yelling about, I’ll chalk it up as a victory.

Preliminaries

This post will assume basic knowledge of Bitcoin and blockchain tech. Should a reader be lacking such knowledge and find themselves having trouble following along, many have attempted to give introductory, 101 explanations (myself included). Knock yourself out.

As for the Lightning Network itself, in the next section, I’ll give an overview of what it is, why it matters, and how it works, as succinctly as I can.

If the basics of Lightning are already old-hat to you, you’re encouraged to skip ahead to the “Lightning Problem 1” section.

What the Lightning Network Is, Why it Matters, and How It Works, As Succinctly As I Can

Lightning: Why?

Gold is valuable, but it’s also hard to move it around quickly, especially in large quantities. Thus, historically, most gold transactions don’t actually involve the physical movement of gold, but rather involve moving something far easier to transport, like paper bonds, which can later be redeemed for gold. This is all well and good, except owning a treasury bond isn’t quite as good as owning gold, since now the holder is exposed to the risk of being unable to ever redeem it.

Bitcoin, like gold, is “hard to move” (namely, “hard” in terms of price and speed, when it comes to small transactions); thus, we seek a similar mechanism of trading it without having to “move it” on the blockchain itself. However, being the stubborn cypherpunks we are, we seek a way to do this without being exposed to the sort of risk we saw with gold treasury bonds. The Lightning Network makes this possible.

So what then exactly are you receiving when you get a Lightning payment? You could think of it as simply receiving Bitcoin. Or you could think of it as a Bitcoin IOU for which the counterparty has no way of shirking their obligation to redeem. Or as a Bitcoin check which can’t possibly bounce. It’s hard to find a good analogue, because it really is a historically unprecedented financial asset.

Lightning: How?

There are two things to grasp in order to understand how this works: the first is two-party payment channels; i.e., how two parties can send payments to (only) each other without broadcasting them on the blockchain; the second is connecting a number of these channels together, allowing all members of the network to pay one another.

For a two-party channel, the parties — let’s adhere to tradition and call them Alice and Bob — deposit an equal amount of funds into a 2 of 2 multisig wallet, which is effectively a joint Bitcoin account in which funds can only be withdrawn with the approval of both parties (we call this the “funding transaction.”) Now, Alice can send Bob a transaction that spends from the funding transaction, effectively updating their balance sheet. Bob could, in theory, broadcast this transaction (i.e., withdraw his Bitcoin on-chain), but, since he can see the funds on the chain, and thus knows he has the ability to withdraw them, he doesn’t need to actually do so. The couple (I, for one, have always assumed Alice and Bob are dating) can proceed like this — sending payments to each other (these are called “commitment transactions”), never broadcasting any of them, and treating the latest payment as the effective bottom line on their balance sheet.

So the big challenge is this: what’s to stop Alice or Bob from broadcasting one of their older, outdated payments? Remember, even though Alice and Bob are treating the latest payment as the canonical one, as far as the blockchain is concerned, all of the payments in the channel are equally valid.

The answer is this: remember, these commitment transactions all have two outputs; some BTC goes to Alice, and some goes to Bob. When Alice settles on the main chain, the BTC that goes to Bob is his immediately; if Alice wants to pay Bob, there’s no reason not to allow her to do so. The BTC she’s claiming for herself, however, is what we need to be more careful with, and thus, this output is a bit more complicated; the transaction is what’s called a Hashed Time-Locked Transaction (HTLC). In essence, Alice can only claim the Bitcoin as her own after some allotted period of time — one week, say (time is measured in block confirmations, naturally.) During this week-long period, Bob can broadcast a revocation transaction claiming the BTC as his own, providing that in this transaction, he includes a secret.

What I didn’t tell you is that when this transaction first gets created, Alice generates a secret, hashes it, and includes the hash in the transaction. Then, when she makes a subsequent transaction (and would thus like to nullify the former one), she shares the secret with Bob, which, again, gives him the ability to claim it as his own if it ever gets broadcast (as long as he does so within his allotted week). She is effectively giving Bob the ability to punish her if she violates their contract, telling him “Look, I know you don’t know me well enough yet to trust me not to spend this old transaction, so here’s the deal: I’ll give you this secret, so even if I do try to spend it, you’ll catch me doing so (it’ll all happen on the public blockchain after all) and you’ll have the ability to take all of the money for yourself anyway.” Bob can verify for himself that the secret he was given does indeed grant him revocation, and thus, with this assurance, can accept the latest payment as valid.

So now Alice and Bob can pay each other off-chain, which is neat, but not particularly useful, with them being only two people and all. The real goal is to extend this so that any two parties using lightning channels can potentially pay each other.

https://blog.scottlogic.com/jhill/assets/hash_lock_transaction_diagram.png

So let’s say, for example, Alice wants to pay Claire, with whom she does not have an open payment channel. She does, however, still have her channel opened with Bob, and she notices that Bob has his own channel opened with Claire. The goal is to essentially relay her payment to Claire through Bob; i.e., tell Bob “I’ll pay you, and then you pay Claire.” But as usual, this must be accomplished trustlessly; no party should be able to run away with anyone else’s money mid-transaction.

To achieve this, we use HTLCs again, though this time, the process takes a few more steps:

First, Claire generates a secret, hashes it, and gives the hash to Alice. Alice then sends Bob an HTLC payment, which Bob can redeem within one week (or whatever) providing that he has the key; as of now, only Claire has the key, so the transaction is currently worthless to Bob. Bob then sends a similar HTLC to Claire using the same hash; i.e., Claire can unlock it, if she has the key, which, as we know, she does. So if Bob’s transaction from Alice is currently worthless, why is he willing to send a redeemable payment to Claire? Well, Bob knows that if Claire decides to redeem his transaction, she will, by necessity, have to expose her secret on the public blockchain; Bob can then use this secret to redeem his transaction from Alice, so he breaks even.

Now Claire, seeing that she has a redeemable transaction from Bob, is willing to share her secret with him directly. So at this stage, both Bob and Claire are guaranteed redemption of their funds. The only issue is, this whole arrangement is built on ephemeral HTLCs; when they time out, both parties will be forced to broadcast onto the main chain. So to make the off-chain arrangement permanent, now that all funds are secured, Alice can pay Bob directly in their state channel (as described earlier) with a commitment transaction that effectively overwrites the HTLC; only one, but not both, can be broadcast, so when the HTLC times out, all that will be left will be the commitment transaction. Upon receiving this, Bob does the same for Claire, and at last, we’ve got ourselves a payment.

The example above involved one intermediary relayer (Bob), but in theory, the exact process can be extended to use an arbitrary number relayers. Since these routers are just forwarding the payments of others, what incentive do they have to get involved at all? Other than an altruistic desire to promote the growth of lightning and earn good standing among their Bitcoin cohorts, routers like Bob can collect transaction fees. Transaction fees, as with Layer 1 Bitcoin payments, are included by the sender in addition to their payment; with lightning, each router along the way collects their share. Given the relative ease and low cost of running a lightning node relative to mining, lightning fees are assured to be far lower than Layer 1 fees.

And that’s it, you’re officially a Lightning expert!

As a nascent expert in the field you’re probably already spotting the technology’s various pitfalls, obstacles, and limitations, and wondering what tools and tricks are out there to help overcome them. So, without any further ado, the main event:

Lightning Problem 1: Liquidity

Perhaps the most oft levied criticism of the LN is the problem of liquidity limitations. As described above, payments are made by effectively having intermediaries forward collateral across multiple channels. That means that if our friend Alice wants to pay 1 BTC to Bob, it isn’t enough for Alice to simply find a route of channels between herself and Bob; she must find a route in which each channel hop has at least 1 BTC available in the direction her payment is to travel.

As should go without saying, in a network without a central planner, it’s difficult — if not impossible — to anticipate the paths that value will flow, and to what extent the liquidity pool will consolidate. This gets thornier when one realizes that money has a way of flowing unidirectionally; my last full-time employer, for example, payed me every two weeks, and I don’t recall ever sending them a check. I regularly give money to my favorite restaurant, and they have yet to send me any in return. Etc. The fear is that payment channels will naturally deplete, thus increasing the odds that if Alice wants to pay Bob, she doesn’t actually have a way to do so without opening a new channel or two, which means broadcasting transactions on the chain, and lest we forget that minimizing the amount of transactions that need to be broadcast on the chain was the whole point of this here Layer 2 exercise to begin with.

One intriguing retort to this is that the LN’s free market economy will organically sort this out for us; if two LN nodes are “far apart” (in terms of the minimum number of edges in the network’s graph a payment must traverse to connect them), and a significant amount of capital is traveling between them, routers will be naturally incentivized, via routing fee potential, to establish more direct paths.

And while I can indeed imagine things playing out this way, I, for one, can also imagine the incentives taking things in the exact opposite direction, namely towards consolidation; the easiest way for me to maximize my access to the network is to connect with a node that already has many channels; thus, the nodes with the most channels may be natural attractors for even more channels (I propose that we call them “lightning rods.”) This could lead to a “hub and spoke” topology, in which a select few large hubs maintain the majority of channel traffic.

https://chrispacia.files.wordpress.com/2015/12/hub-spoke-2.png

Exactly how much of a bummer this “hub and spoke” effect would be is a matter of debate (see here for the “not actually as bad you think” argument), but in any case, most Bitcoiners would probably agree that ideally, we want the network to be as dispersed and distributed as possible. This means coming up with ways to facilitate more flexibility in terms of liquidity flow, channel rebalancing, and the like.

Here are some of the ideas that are in the works (in no particular order):

Atomic Multipath Payments

Suppose dear Alice wants to pay Bob 1 BTC, but no path exists between Alice and Bob with 1 BTC staked each step of the way. However, Alice, clever lightning router she is, does find one path where she can send Bob 0.5 BTC, another path for 0.3 BTC, and another for 0.2 BTC. With an Atomic Multipath Payment (AMP), Alice can pay Bob by splitting her payment into these three (or more, in theory) parts.

Of course, even without any AMP tech, nothing is stopping Alice from making many small payments instead of one big one. The key feature that allows AMPs to replace a single payment is that there are no “partial payments” possible. In other words, either Bob can redeem all three payments or none of them; the payment either clears as a lump sum or it doesn’t, as we’d reasonably expect a payment to behave.

It works like this: Alice starts by constructing a Big Secret Code. Let’s say her secret code is “AlicesBigSecret” (note: this is a poorly chosen secret).

Using this Big Secret Code, Alice constructs three Small Secret Codes, one for each payment she’s going to send, by simply concatenating the numbers 1 through 3 to her Big Secret, like this:

Small Secret Code 1: “AlicesBigSecret1”

Small Secret Code 2: “AlicesBigSecret2”

Small Secret Code 3: “AlicesBigSecret3”

These small secrets are then each hashed, and the hashes are attached to each of the three partial payments, such that Bob needs to know each payment’s small secret in order to claim its funds. (Note that the similarity of the small secrets has no effect on the resultant hashes, which look effectively random.) As additional data included with each payment, Alice also sends “one third” of her big secret; i.e., payment 1 gets “Alice,” payment 2 gets “sBigS”, and payment #3 gets “ecret.”

If Bob does indeed get all three payments, he uses this data to create the Big Secret Code, concatenates the numbers 1–3 to the end, and presto, he can claim all of his money. If, however, even one payment fails to arrive (say it got lost on the way from a node going offline, or Alice just never even sent it, the scamp), Bob’s data is useless in helping him claim any transactions, and the transactions he does receive will simply time out.

(Note to nitpickers: no, the “Big Secret” isn’t simply split into thirds and re-concatenated; the partitioning and recombining uses the XOR operation. But the principle is the same. Also, if you’re concerned about nodes on the way colluding to share the partial data with each other and crack the secret themselves, note that the “additional data” is in an onion routed blob. So relax.)

A nice thing about implementing AMPs is that only the payment sender and receiver need to do any additional work; the routers in between them relay the data just as they would with regular LN payments, completely none-the-wiser that anything jazzier is going on.

Splicing

In the regular Lightning Network arrangement — henceforth referred to as “Vanilla LN” — the only way funds “exit” the network back onto the main chain is by closing the channel they sit in, and likewise, the only way funds enter the network is by opening a brand new channel. The ability to alter channel balance in a single transaction would be a nice benefit for network liquidity, as it would mean users could replenish channels as they get depleted, and that they could withdraw only the funds they absolutely need, keeping as much of that precious funding as possible within the network.

Splicing opens up the door for this, enabled by an alternative state-channel transaction structure called “FundCasc.” In this arrangement, funding transactions can take an arbitrary number of inputs and outputs, including — crucially — other funding transactions. So under the hood, “splicing in” (adding funds to a channel) simply entails closing out one channel and opening up a new one in a single transaction. This new channel takes as inputs the old channel (and thus the old stack of commitment transactions are invalid, so we don’t have to worry about them) along with some other, on-chain BTC. The net result being that the two counterparties still have a channel open together, only now the available funds in the channel have increased. Splicing out follows similar logic; a single transaction closes a channel and spends its funds in the form of two new outputs: one output lives outside of the LN, the other establishes a new channel with the remaining BTC.

Just to underscore a point: splicing in and out does require one on-chain transaction, putting an upper bound on how much this technique could and should be relied on. But the key point is that achieving these same results without splicing would require two or more transactions, making splicing a net win for scaling, preserving that sacred block space.

Submarine Swaps

The idea of submarine swaps is to help bridge the divide between on-chain and off-chain funds; with a submarine swap, Alice can pay Bob by sending him an on-chain transaction, which Bob effectively receives as a payment in one of his already existing state channels; conversely, Bob can pay Alice by sending a lightning payment that Alice ends up receiving as on-chain BTC. There are a number of potentially valuable use-cases for this mechanism, the most obvious being helping Bitcoin through its transition phase to more LN adoption, when some — but only some — users have taken to using lightning.

So suppose Alice wants to send Bob some BTC, but since Alice has become a die-hard believer in Bitcoin Cash, she refuses to ever set up an LN node on principle; Bob is a Bitcoin man who’s adamant about accepting all of his payments in lightning channels. Although their relationship is most likely on hiatus, Alice still wants to pay Bob — but how?

What they do is, they find a third party willing to facilitate this transaction — reenter Claire. The requirements for Claire here is that she’s willing to be the middlewoman (though a trustless, non-custodial middlewoman; relax) in Alice and Bob’s transaction, and that she has enough funds in the LN to forward Alice’s payment to Bob.

The procedure is then similar to that of a regular LN, multi hop payment (described in “Lightning: How?”), only this time, one side is on-chain; Bob generates a secret key, hashes it, and exposes the hash to Alice. Alice now creates an on-chain transaction to Claire that can only be redeemed if Claire has the secret. Claire sends Bob an HTLC payment with the same hash; recall that to complete the payment, Bob has to reveal the secret to Claire. At this point, Claire can claim her on-chain funds, and Bob has access to his off-chain funds in his channel with Claire; Bob got paid, and Claire breaks even (or comes a away slightly ahead via routing fees).

If you happen to also already be familiar with Atomic Swaps, then you can think of submarine swaps as combining vanilla LN multi-hop payments and Atomic Swap mechanisms into one. In fact, since the only requirement for the Atomic-Swap-Esque on-chain side of things is an HTLC transaction, submarine swaps could even occur between two different cryptocurrencies, giving us a decentralized mechanism for exchanging assets on the first layer of one chain with assets on the second layer of another. Which is neat.

Channel Factories

I feel obligated to warn you: shit’s about to get weird.

We know, from Vanilla LN, how to construct a system where theoretically, only transactions that open and close two-party state channels need to be sent to the main chain. Could we establish a mechanism, one might well ask, such that even those transactions won’t need to be broadcast? More specifically, a mechanism by which many parties could enter a different type of state channel, where in between its opening and closing, any two parties could effectively open and close a two-party state channel with each other, without having to do so on-chain each time?

That’s right: while we’re here still trying to wrap our minds around Layer 2 solutions, these mad scientists are already proposing a system with three layers: the two-party state channels we’re familiar with from Vanilla LN get bumped on up to layer three; back down on layer one — the blockchain itself — sits an n of n multisig funding transaction; in between these sits a Layer 2 channel factory, upon which pairs of parties can open and close channels without touching the blockchain.

The benefit here, if it isn’t clear, is that this joint venture provides its members with major flexibility in partnering up to forward payments along; liquidity and routing possibilities galore.

How It Works

Okay: to really exploit the benefits of this arrangement, you’d want many parties to commit, perhaps around ten. But to keep things from going too hog-wild, let’s assume there are four parties involved; our beloved Alice and Bob, who, in an effort to liven things up, now bring Claire and Derrick into the mix. First, the four of them put their k̶e̶y̶s̶ ̶i̶n̶t̶o̶ ̶a̶ ̶b̶o̶w̶l̶ Bitcoin into the initial funding transaction; let’s suppose they deposit 2 BTC each. So the balance is:

Alice: 2
Bob: 2
Claire: 2
Derrick: 2

Now, say Alice and Claire decide they would like to enter a two-party channel together with 1 BTC contributed from each of them; the two of them broadcast an allocation transaction (this step is analogous to the funding transactions in Vanilla LN) to the rest of the channel’s party participants (but NOT to the blockchain). They all verify that the two of them each do indeed have 1 BTC available, and sign off on this request. At the end of this exchange, each party will have a copy of the allocation transaction signed by all parties except themselves; thus, everybody agrees it’s valid, and everybody has the ability to settle it on the main chain. This new allocation transaction represents the latest canonical state of the channel, which now looks like this:

Alice: 1
Bob: 2
Claire: 1
Derrick: 2
Alice/Claire: 2 (in total)

At this point, since they’ve all agreed on this allocation transaction, Alice and Claire can trade on top of their joint 2 BTC, Vanilla LN style, without informing the rest of the group; what they do behind closed doors is nobody else’s business.

Now suppose that Claire wants to open up another channel with Bob using her remaining 1 BTC. A new allocation transaction is passed around and signed, just as before, replacing the old state with the new one:

Alice: 1
Bob: 1
Claire: 0
Derrick: 2
Alice/Claire: 2 ( total)
Bob/Claire: 2 (total)

Now Bob and Claire can trade between each other on Layer 3. And so on. What we have is a transaction-tree structure; everybody knows that any transaction is valid, so long as they can follow it up the tree to a transaction that can be settled.

https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf

So let’s talk on-chain settlement:

Can Claire settle one of her commitment transactions in her Layer 3 channel with Bob? Yes, but not right away; her commitment transaction spends from an allocation transaction that itself lives off chain, after all. However, recall she has the power to broadcast that transaction herself. So to settle, she first broadcasts the allocation transaction, and then she can claim her funds with her commitment transactions. Any sort of arbitration/revocation that needs to occur at that point plays out exactly as it would with a Vanilla LN channel (because at this point, that’s effectively all this is).

A more troubling question is, how to do we enforce valid settlement of those allocation transactions? We said earlier that the latest one represents the canonical state of the channel factory, but what’s to stop somebody from broadcasting an old, outdated state?

One can imagine a way of preventing this using a revocation/punishment model ala Vanilla LN. The problem is, we now have more than two parties, so the punishment can’t simply be “slash the dishonest party’s funds and give everything to the other party”; we would need some way to punish one party, and then somehow distribute the right funds to everybody else. This would get messy.

So instead, the Channel Factory mechanism for ensuring that the latest allocation transaction gets settled borrows an alternative state channel strategy known as “Duplex Micropayment Channels” (DMC), which instead of relying on punishment, relies on having transactions’ validity “unlock” over time. (Details in the next section, sit tight.)

In sum, there are three levels of statefulness that need to be kept track of: Layer 3 state channels (really off-chain), maintained by the two parties involved; the Layer 2 stack of allocation transactions (just barely off chain), maintained by all n (in our case, 4) members of the channel factory, and finally, the good ole fashioned Layer 1, maintained by the Bitcoin ecosystem at large, where parties settle their debts on the on the public ledger, just like our ancestors did.

Is this all getting complicated? Well, yes. Too complicated? Hard to say, though I suppose once we’re willing to consider blockchain-bound state channels which themselves are blockchains which themselves can spawn other blockchains, all bets are off. I myself do have a number of questions (Is there really no collusion strategy here? Wouldn’t trying to route through on these things get a bit tangled?) but I hesitate to further explicate since I can feel a migraine starting to form, so probably best to just move on.

Related Tangent: Duplex Micropayment Channels?

I mentioned that enforcing settlement of the proper allocation transaction in channel factories is achieved using the Duplex Micropayment Channel (DMC) method.

DMCs are a mechanism for two (or more) party state channels that achieves a similar result to the better known Lightning Channels, but do so using a different strategy.

If, once again, the fundamental question of state channels as “how do we make sure that only the bottom line of the balance sheet gets broadcast?”, a Lightning Channel’s answer is, “If someone broadcasts any other line of the balance sheet, the other party can punish them by taking all of their money.” Alternatively, the DMC’s answer is, “Let’s ensure that there is a window of time in which only the bottom line can be broadcast and any other line will be considered invalid.”

So, for example, the first transaction in a DMC could include a condition that it will only be considered valid if included in a block 10 days later; the second would have a condition that it will be valid only after 9 days; the third after 8 days, etc. Say Alice and Bob work their way down to a transaction that has a 3 day waiting period, and then stop there. After 3 days, there will be a 24-hour period in which that transaction — and only that transaction — can be broadcast. As long as Bob can act fast enough (i.e., he doesn’t dilly-dally for more than a day), he’s guaranteed his money.

Keen observers will notice that, as described above, DMCs have a major weakness compared to the LN model; channels have a limited lifespan. In the example above, the channel would stay open for at most ten days, and even that lifetime gets slashed by a day with each additional transaction. This obstacle, however, can be cleverly circumvented: instead of starting the “timer” at the initial funding transaction, we can start the timer only when and if the adjudication process starts, which is initiated by an intermediary “kick-off” transaction. Once the maximum number of transactions is reached (10, in our example) parties can mutually agree to effectively “reset” it; i.e., branching off and starting a new transaction stack, and bringing the time delay back up to 10.

This requirement for regular “resets”, along with a few other factors, make DMC’s an (arguably) weaker alternative to the Lightning Channels we know and love. However, when it comes to channel factories, using timing instead of punishments becomes a more suitable option, since this scales better to situations with more than two participants, and thus a DMC-style system is used to enforce allocation transaction settlement.

Payment Loops

As a chaser, here’s a fairly simple one: say Alice has a channel she could use for a payment to Bob if it had enough funds, and another open channel that does have a lot of funds. To rebalance her own channels, she can simply pay herself via the LN, from one channel to the other, providing, of course, that such a payment loop exists. If indeed it does, this channel balancing procedure takes place entirely off chain. Cheap, fast, and sleek.

Other Thoughts

Many of the above proposals involve the rebalancing of one’s payment channels; ideally, this would be something handled without the user having to be aware of the exact mechanism involved. However, all of the proposals above involve at least sending an off chain payment, which cost money, and some (splicing, submarine swaps) include at least one on-chain payment, which costs more money; this starts to get us into “automated micro-payments” territory. And as has been convincingly argued, consumers aren’t going to accept automated micropayments anytime soon, for the simple reason that humans don’t like the psychological burden of knowing a computer is repeatedly deciding how to spend their money.

Subscription-style services, on the other hand — in which a strict upper bound is given to the amount of money a user will be charged over a given period of time — is something we can, and indeed have, adapted to. Thus, providing an experience where a user can effectively say “I’m willing to spend X per month, at most, for you to use whatever wizardry you want to keep my channels more liquid,“ or, for routing nodes, perhaps ”I’m willing to pay X% of my routing fee profits,” should be the aim here. A user would reap the benefits of channel rebalancing strategies while having the psychological peace of mind of knowing that no algorithm will decide that it behooves the greater good of Bitcoin scaling to drain their retirement savings (so to speak).

On another note: finding topological network structures that would be conducive to maximizing available liquidity is still a ripe area for research. One simple but compelling example of these sorts of arrangements is cyclic payments, proposed by LN developers and as REVIVE in by the Liquidity Network project; in essence Alice has a channel with Bob, Bob with Claire, and Claire back with Alice, and payments tend to flow around the loop unidirectionally, naturally making the liquidity more balanced and available. Again, there’s no surefire way to structure a decentralized network, but if if sub-network structures are proven effective, higher throughput, and thus higher routing fees, could naturally incentivize more parties to adopt them; players could even encourage others to open up channels that facilitate such topologies via negative routing fees.

Problem 2: Liveness

For any digital payment system, one must have some sort of connection to the internet to send out a transaction; that’s just kind of how the internet works. However, when it comes to the Lightning Network — or many (any?) other non-custodial Layer 2 scaling solutions for that matter — having live internet access, and a bit of bandwidth to spare, becomes a necessity for other vital features, namely, routing others’ payments, receiving payments of one’s own, and securing one’s funds.

While all three of these things are obviously important, the big one here is security, which will be the main focus of this section. The security model for individual ownership of Bitcoin — beyond relying on the general security and persistence of the network itself — is simply that a user must keep their private keys secret, end of story. Lightning adds another layer; for fund security, one must still secure their private keys, and also have the ability to monitor the main chain, and to potentially broadcast transactions within an allotted timeslot. Any change in the security model is something to take seriously, so let’s:

Watchtowers

A semi-controversial suggestion for easing the necessity of liveness is to use Watchtowers. Watchtowers are third party nodes that you could hire to monitor the chain for you, and broadcast revocation transactions on your behalf if and when the need arises. The big question here is, are we just outsourcing trust to a third party? And if so, what the hell are we doing here?

If a watchtower is simply given a signed transaction, that watchtower has custody over your funds, no way around it. However, there is a better way:

Say I want to give my watchtower the ability to revoke a transaction with id “1234567890”. What I do is, I create the relevant revocation transaction, signed and all. I then encrypt it using the secret “67890” (the second half of the target transaction ID). What I then share with the watchtower is this encrypted blob and the string “12345,” the first half of the transaction ID.

What’s the point of all this? If (and only if) the transaction that needs revoking gets broadcast, the watchtower will be able to spot it from the first half of its ID, at which point they can retrieve the second half of the ID, decrypt my revocation transaction, and broadcast it. If the transaction in question never gets broadcast (which is most likely), all the watchtower has is a useless blob of data. In other words, the only time a watchtower actually gets my transaction is when I want them to have it anyway.

So have we found a truly trustless watchtower system? Well… not quite. Even though the watchtower can’t directly run off with my money, what they can do is, well, nothing; i.e., if they simply sit idly after an unauthorized broadcast, my counterparty ends up with my funds. God forbid they even collude with my counterparty and ultimately share the bounty. So ultimately, what we can say is that this arrangement “can’t hurt” and is “better than nothing,” and could certainly provide a second layer of fall-back protection to mitigate risk of one’s one node failing. But as far as I can tell, full reliance on third-party watchtowers should, in principle, be considered a trustful relationship.

Compact Block Filters for SPV clients

Ultimately, the safest way to use LN — and the safest way to use Bitcoin itself, is by running a full node. Major merchants and exchanges can and should continue to do so. However, it isn’t reasonable to ask the average user to run their own node; we don’t all have ~170GB of hard drive space and 15 GB/day of bandwidth to spare.

When it comes to Layer 1 transaction verification and validation, light SPV clients let users have some of the self-verification security without running a full node themselves; in essence, a full node can send the light client enough information (the transaction in question and a Merkle proof to its block hash) for the light client to verify for itself that the transaction is indeed included in the block. For LN security however, we need the opposite — not proof of the presence of a given transaction, but proof of the absence of certain transactions (namely, transactions closing one of our channels).

A different type of light client can accomplish exactly this, using compact block filters. The idea here is that full nodes expose a “filtered” block to any listening light client; now, instead of a light client requesting data for relevant transactions, the client can examines the filter and probabilistically determine whether their transaction-in-question could be included. The key here is that the client cannot get any false negatives; the data structure is such that the answer is either “your transaction is definitely not in this block” (this will be the answer most of the time) or “your transaction might be in this block.” In the later case, the client can then simply request the full block in question, verify it against their own block headers, and then act accordingly.

As for verifying that block filters do indeed accurately represent their corresponding block’s data, block filters have “filter headers” that bear an analogous relationship to blocks as block headers do; the headers are mapped from the data itself, and each header is chained to the previous one. By downloading all of the headers, cross referencing them against several different nodes, and occasionally verifying them directly against their corresponding blocks, a node can be confident that the filter headers it receives are accurate.

Net result: self-verification that all channels are still open, no full node required.

Eltoo

Another issue associated with liveness is the fact it necessarily makes any LN node a hot wallet. This opens up the risk of an out-of-date commitment transaction accidentally being signed and broadcast — either by user error, or a software bug, or an attacker gaining access to the node’s OS, at which point your counterparty could slash your funds, essentially punishing you for a crime you didn’t commit.

Eltoo is yet another trustless, multi-party state channel mechanism (that makes three) that mitigates this particular risk. This time, the answer to the canonical “what happens when outdated transactions get broadcast” question is “those transactions will be considered perfectly valid, but any later transaction from the channel will then be able to replace it.”

The mechanism behind this is as follows: every time a member of the channel wants to send a payment, the parties (we’ll assume there are only two for this example) create a pair of transactions; a “settlement transaction” and an “update transaction.” Settlement transactions are analogous to commitment transactions from vanilla LN; they distribute BTC from the funding transaction to both parties in the channel. Once broadcast, a period exists where an update transaction can be broadcast; this transaction (assuming it’s sent within the allotted time) also spends from the funding transaction and creates a new output almost identical to the previous one, effectively nullifying the settlement transaction and keeping the channel open (to be resettled/updated etc. in the future). A key difference with this new output is that it specifies a higher “sequence number” than before; a sequence number is also associated with each update transaction. These sequence numbers enforce ordering, the rule being simply that as arbitration plays out, the sequences numbers must increase; this ensures that updates only go forward in time, and thus guaranteeing that an honest party always has a chance to broadcast their most up-to-date settlement transaction. The net result here is that in the case of an arbitration, we end up settling with the balances that each party is owed; no punishments are doled out.

https://www.scribd.com/document/377886999/Eltoo-Whitepaper

Beyond just mitigating the risk of punishing an innocent actor, Eltoo has an added bonus: thanks to the SIGHASH_NOINPUT flag, update transactions behave as “floating transactions,” meaning they can be used to nullify any attempted settlement with a lower sequence number than their own. Thus, the only pieces of data that a party needs to hold on to are the latest update and settlement transactions; compare to Vanilla LN channels, in which a revocation transaction needs to kept for each commitment. This means easier, simpler state management for everyone.

Other Thoughts

Something to note about the liveness requirement for security is that you don’t need constant liveness but rather, only “frequent enough” liveness. Say, for example, the challenge period for a lightning channel is one week. This means that as long as a node stays less than five days behind, that node is guaranteed to have a two day window to revoke (if necessary). Given the possibility for a block-filtering light client described above, this bar is very easy to reach; the device running the node could have the LN software running in the background, limiting the amount of processing power it uses to what’s currently available; should it start getting too close (to the “five day” limit), it could simply alert the user explicitly.

There is also the possibility for having alert systems that exist entirely separate from the LN; this system wouldn’t interact with the chain itself, but simply alert the user of relevant activity so the user can act accordingly. Various block explorers already support things like email notifications for activity around subscribed addresses; these sorts of things could be tooled to support lightning. Better yet, some sort of decentralized messaging ecosystem could emerge; this data is very public after all, so it shouldn’t be too hard to get it to whoever wants to subscribe to it. (I’ve got some ideas on this front: stay tuned!)

As with watchtowers, these alert systems shouldn’t be relied on as the primary mechanism for security, but between these, watchtowers, and the users’ node itself, the ecosystem could have enough layers of protection that the odds of sneaking something past a user becomes negligible.

Finally, one additional piece of the LN security model worth noting is the threat of a hard-drive crash. Any Bitcoiner knows that losing a private key means losing one’s money, and thus one should have their private keys backed up in multiple places. When it comes to lightning, there’s an additional piece of data that ought to be backed up for trustlessly securing funds; transaction data itself. However, unlike private keys, which are static and unchanging, and thus only need to be backed up once, transaction data grows over time (every time you receive a new payment), thus making backups more of an ongoing process. Fortunately, backing up LN transaction data is also, in a different way, easier: a commitment transaction need not be signed by you until you send it, and thus need not be treated as secret, vulnerable data, so there’s no trust-risk to simply storing a copy somewhere on the cloud. For the self-reliance purists, a simple, cheap hardware backup device could connect to the device running your node and dump in copies of your commitment transactions as they come in (Ledger/Trezor, perhaps?)

Problem 3: Routing

In the “liquidity” section, we addressed the question of, “How do we increase the likelihood of a payment route between Alice and Bob existing, and what do we do if there isn’t one?” That problem is one that is fairly unique to lightning, and thus merits serious analysis. With that problem aside, we are still left with a milder, and frankly less interesting problem: “Even if there is a route between Alice and Bob, how are the two of them supposed to find it?”

I say “less interesting” because this isn’t particularly unique to lightning or public blockchain protocols, and gets us more into the wonky realm of routing in P2P networks in general. Some, like Andreas Antonopolous, notably, predict that as the Lightning Network grows, the routing mechanisms will organically evolve along with it to keep up with its capacity needs, taking a similar trajectory to the evolution of routing mechanisms for the internet itself. Thus, we need not speculate and map out exact routing strategies in advance.

It’s worth pointing out that routing in LN is, in at least one way, fundamentally more difficult than routing around the world wide web as we know it: many components of routing architecture on the net — like the Border Gateway Protocol — are explicitly trust-based; the LN obviously doesn’t have this luxury. However, even routing data in open, P2P systems is hardly a new field of study.

So why is it then that “the routing problem” is a such a battle-cry for LN critics? The sense I get that by “routing,” many are really referring to the section 1 channel/liquidity problem; being clearer on this distinction would probably clear up some confusion.

But with all that said, it seems worth giving an overview, if only briefly, of what a routing strategy geared specifically toward the architecture of the LN would look like. All sorts of ideas have been floated around, many of which were consolidated into the Flare whitepaper:

A state-snapshot of the LN essentially comes down to four dynamic variables:

Existence of channels
Amount of funding in channels
Routing fees
Liveness of nodes

Of these, one could reasonably expect that 2–4 would be changing very rapidly, whereas the existence of a channel itself would alter comparatively rarely. Thus, the strategy for maintaining network state is to keep channel existence up to date proactively; in other words, a node, for all intents and purposes, knows the state of all of the channels it cares about at all times. Alternatively, the information in 2–4 is obtained reactively; only when a node is making or receiving a payment does it bother digging in to find it; it’s strictly a “need to know” basis.

https://bitfury.com/content/downloads/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf

Using this hybrid strategy, each node constructs its own routing table which stores paths of nodes within that node’s neighborhood, a neighborhood being all of the nodes that are within n channel-hops away. Additionally, each node has a randomly selected group of beacon nodes. These beacon nodes are simply other nodes in LN from which a node uses to get a random snapshot of data about sections of the network outside of its neighborhood. When Alice and Bob wish to find a route between them, they check for overlaps in their own neighborhoods, then check for overlaps among the collective nodes they have access to via their beacons, and finally, if necessary, start polling their peers for additional data until a path is found.

Flare borrows from the CJDNS proposal a strategy of assigning node addresses — the assignment of unique identifiers to each node — from which the node distance between two nodes can be calculated. This distance is not the same as the number of channel hops between nodes; rather, it represents something more abstract, but, in short, it gives a probabilistic answer to the question “how likely is it that these two nodes have information that’s useful to each other,” a metric that guides the polling process described above.

In sum, there’s a straw man that gets repeated that for LN to function, each node needs a perfect view of the rapidly changing state of the network. As we can see though, there are a number of strategies to employ that attempt to optimize the tradeoffs between memory, computation/bandwidth, and time that seek to achieve the necessary functionality using a whole lot less effort.

Lastly, the trustlessness of the relationships between nodes introduces risks of new types of denial of service attacks; a node could theoretically broadcast fraudulent data about the state of its channel and peers, tricking Alice into thinking a route is available when it isn’t, wasting her precious time. To help mitigate this, we can introduce channel proofs; parties can/should send data verifying that the channel state really is what they say it is. The proofs outlined in Flare involve a combination of SPV style merkle proofs (to prove that the channel is in fact still open on the blockchain) in addition to a new authentication system that let’s parties verify and sign off on the off the Layer 2 state of the channel’s transactions.

So while we cannot, and perhaps need-not, predict exactly what lightning routing will look like, we can take comfort in knowing that it at least could look something like that.

Final Thoughts

Congratulations, you made it — and what a journey it’s been!

Having gone over all of this, it’s hard to avoid concluding that this whole Lightning thing is going to be a rather complex, radical experiment. Complexity, though, may just be the nature of the beast here; as wary as I am of “early days of the internet” cliches, it seems applicable in this case. New ideas introduce new challenges, which in turn require novel solutions. And the history of scientific progress has shown us that goal-directed research can yield all sorts of fruitful results, even results that are applicable and useful for other things entirely. So even if nothing else, it ought to continue to be fascinating to watch how this all plays out. And as for “radical”, well, yes, but if radical experiments aren’t your thing, you probably aren’t involved in cryptocurrency to begin with, in which case you probably aren’t even reading this, in which case this sentence has an audience of nobody.

You may have noticed my intentionally trying to avoid tipping my hand as to my opinions on the likelihood of wide LN adoption; I did this because a) what they hell do I know, and b) the last thing crypto needs is another person with strong opinions about what will or won’t happen.

Again, the goal here was primarily to inform and thought-provoke, so hopefully it was helpful on those fronts. Thanks for reading, feedback welcome, and may your state-channels runneth over.

Thanks to Rene Pickhardt and the folks at Lighting Network Developers and Lighting Makers for the helpful feedback.

“Submarine Swap” section updated to better reflect which steps in the procedure are ordinary LN payments, h/t Alex Bosworth

For inquiries: daniel@theabacus.io