Blogs & Articles: Lightning Network, Yield, and Incentives 🔗 3 years ago

What is the core incentive for locking up Bitcoin into a payment channel on the Lightning Network to route payment for other people? Make money on routing fees. What is another way to say that? To generate a yield on your Bitcoin. The entire design goal for the Lightning Network is to allow the atomic routing of payments between parties that do not have direct payment channels between themselves, and this is literally impossible to accomplish without the economic incentive that routing fees provide except to count entirely on altruistic charitable motivations.

So…greed or altruism? Which do you count on more? Personally in the name of a system that will remain sound in the long term I would choose greed. People who act in their own self interest are more predictable and plentiful than those who will forever act in the name of altruistic intent. So this presents a problem that most people don’t want to deal with.

Lightning as it stands right now is nothing but a children’s toy. Period. It is not some polished system, it is not a magical UX or UI, it is not even robust or solid in the face of adversarial attacks. It’s a fucking toy put together by a group of friends and maintained solely because it is composed predominantly of just that. Friends. Businesses who know each other. A tight social group that has not hit the point of growing past a socially scalable size.

I’m sorry if you don’t want to hear this, but if you need to go look at the lease volume on Lightning Pool. Sorry man, the network at the size it needs to be was already bootstrapped when Pool came online. No volume. Sorry man, even a good chunk of the new bootstrapping liquidity…not happening through Pool. It’s happening through social graphs, business connections, etc. No volume.

Sorry to burst your bubble, Lightning is a friends only nothing can ever go wrong toy network right now. The adversarial screws haven’t even been installed yet, let alone tightened. It’s time to wake up out of the hype dream.

There are two main classes of privacy attacks that really concern me, and as I will get into shortly are not just hypothetical things. They are very possible attacks with very real economic incentives that will inevitably create entities in the perfect position to exploit these classes of attacks.

The first class: passive privacy leaks. These are a consequence of HTLCs and how they inherently work. If I have multiple nodes on the network, and a payment happens to flow through multiple nodes I control…I learn quite a lot about a payment potentially. Firstly there is the decrementing timelocks. This allows me to guess both how many hops away the first node I run involved in the payment is from the origin point as well as how many hops away from the destination the last node I run that is involved is. Imagine you make a payment from A to B to C to D to E to F to G to H to I to J. That is 9 hops. Now imagine I control node C E and H. I’ll be able to see that the E timelock is longer than H, that the C timelock is longer than E, and I’ll know that direction wise things flowed from C towards H. This allows me to make a much better guess at where the payment was coming from and where it was going than if I just controlled node E. I can guess at how many hops overall the payment is, but only controlling one point in the route, it gets near impossible to guess the endpoints right; they could be any nodes ‘x’ hops away on either side. But when I make up three hops in the route, and can identify a payment definitively by the hashlock…it gets a lot more practical to do that.

The second class: actively probing channels by making payments (they can succeed or fail, this just changes the cost analysis of pulling off such attacks) to ascertain the liquidity distribution between each side of any channel over time. Taking regular snapshots like this would allow you to start playing summing games in global channel balance shifts and guessing at payment flows with a much better accuracy because of knowledge of channel balance distribution over time with your snapshots.

Now…why care? This would take a single actor or a handful of actors to make up massive amounts of all the public Lightning routing nodes and capital, right? That would never ever happen, right? Right?

WRONG.

What is the reality of Bitcoin and Lightning right now? Most people are hodling Bitcoin, and Lightning as a means of exchange is mostly about being payment rails between non-native Bitcoin payments. This is the cold harsh reality. Sorry to piss on your dreams of an instant cypherpunk utopia, but we aren’t there yet. I actually run a small t-shirt shop that accepts payments over Lightning. Every single channel I have was either randomly opened to me by strangers trying to earn fees because this is obviously a business (and I don’t advertise the store node, so they went through the extra step of making an order they let fail to get the LN node ID) and they want to try and earn fees, or a channel with someone I know personally that got opened because I just asked them to open one.

That is how immature the market on the Lightning Network is. It is literally just friends and acquaintances and public businesses opening channels to each other based on reputation either personally known or publicly inferred. It is accordingly something that has never actually been stressed by an adversarial actor, as by the very nature of being right now in its current form a socially constructed network, there really aren’t any. Yet.

So what is a consequence of the reality being that Bitcoin is mostly hodled and its MoE use it mostly as rails bridging other currencies? Yield chasing. BlockFi, Ledn, etc. are some of the biggest growing things in this spaces. All the platform that generate interest yield on people’s Bitcoin. See where I’m going with this? If you don’t, let’s take a stroll into the past. These platforms ostensibly work by taking your Bitcoin and lending them out to traders, paying you a cut of the interest the borrower will pay. It’s not always that simple though, these businesses actively manage things themselves anywhere they think they can find an edge against the market. One such case was BlockFi arbitraging the Grayscale Trust G-BTC premium against Bitcoin. They were arbitraging this premium across the lock up period (the time period after locking up BTC with them before you can sell the G-BTC shares) as a partial source of the interest yield they were paying out to customers. When G-BTC’s premium flipped negative, this put them in a tight spot. Interest rates came down. Then they started mining Bitcoin with Blockstream Mining. Why? Because it’s a predictable yield generation in Bitcoin terms!

Do you think these services are going away anytime soon? Did Coinbase or Bitpay post NYA? How about Bitmain after the UASF and Bcash debacle? No. They aren’t. Some subset of people want yield on assets they hold, and it will be a long while before that changes. Well that yield can come from three abstract places really:

• the actual organic market demand for borrowed Bitcoin liquidity, i.e. leveraged trading.
• the entity (such as BlockFi) making a trade to out perform the market (like arbitraging the G-BTC premium)
• a more steady and long term source such as mining, Lightning routing, etc.

Some of this wall of liquidity is inevitably going to crash into the full Bitcoin protocol stack in search of yield. Mining, Lightning routing, running oracles for DLCs, even coinjoining, you fucking name it. If having Bitcoin capital helps generate revenue somewhere, these companies offering yield generating profits to customers will allocate liquidity there. That simple. They will want to spread capital out in a decent balance between low risk low yield and high risk high yield areas, so as to try and be able to offer a higher yield return to their customers to attract more capital. Things like mining, routing, etc. are the low risk low yield side of that spectrum in Bitcoin denominated terms.

This has a lot of implications for how that playing out affects the Lightning Network as a whole if things go that way. First off, such entities will obviously until HTLCs are replaced with PTLCs (using adapter signatures instead of hashlocks, so each hop looks different instead of the same) have an ability to statistically pull off end to end passive analysis of Lightning payments routed through their nodes. This creates a very screwy incentive dynamic if you have an entity not controlled by people with certain ethical views. In this possible future scenario, this entity would be in the position to perform a systemic private attack on a certain % of the entire Lightning Network. It would also have an economic incentive to do so. That information is economically valuable, as evidenced by the existence of chainanalytics companies. Such an entity could make a pretty penny selling that data to analytics companies, or potentially doing their own. Either way, it’s a new source of yield generation off of the Bitcoin they allocate to the Lightning Network. And oh yeah, one more thing: wormhole attacks. If I find out that I have two nodes in the middle of a payment, I can just cut out the nodes in between my two and pocket the fee difference for myself. Which a yield generating entity deploying capital into the Lightning Network would have every incentive to do.

How do we deal with this? Point Time Lock Contracts (PTLCs) and Atomic Multipath Payments/Multi-Path Payments. To reiterate, with Hash Time Lock Contracts (HTLCs) every hop in a payment is locked up with the same hash/pre-image pair. So this means if you have multiple nodes along a single payment path, with HTLCs you can figure out that this is all one payment with 100% certainty because its all the same pre-image. If you use adapter signatures and PTLCs however, the lock is different for each hop, so that is not a basis by which you can identify that all your nodes are involved in one payment. The amounts however would allow you to figure that out with a very high degree of certainty. This would change however using AMP/MPP to break up a payment along multiple separate routes. The points at which a payment branches out through multiple channels decorelates the amounts making it much more difficult to figure out when you have multiple nodes routing a single payment.

It gets even more interesting when you start considering the second class of attacks I brought up above, active balance probing. There are incentives to do this for multiple reasons. What if I want to unbalance a competitors channel so people prefer routing through mine? If you think of Lightning like hoses of different sizes connected, there’s no guarantee a path is all of the same sized connectors. In unbalancing the competitor’s channel, I’m going to learn a lot about the balance distribution of all the channels in between mine and the competitor’s. If I store that data over time, that becomes a valuable commodity that can be used to analyze the direction and amount of payment flows on the network over time.

Or how about interest payments to customers? The whole logic of these entities is “give us your capital and we will manage it to generate the best return.” Lightning opens the door to granularity of interest payments down to tiny tiny amounts very frequently. Constant streams of payments like this will also give such an entity a basis by which to attempt to snapshot inferences or confirmed balance distributions for channels they are routing payments through. Same as above, storing this data offers the potential to sell and capture the value to generate more yield on their liquidity deployment. (Packetized payments I think opens similar doors…but that is a rant for another time)

And hell, in the end if these entities are mining too what kind of synergy is available for their mining operations and their Lightning operations? You could potentially have Lightning channels being opened directly from coinbase transaction outputs. Your miners could refuse to mine competitors Lightning channel closes if you can identify them. This would could possibly give you a marginal advantage by not allowing them to redeploy their capital as soon as possible if you find the next block. I’m sure there is much more subtle and deeper interplay possible here, but those are just two examples off the cuff.

So far really all I’ve gone into is risks to privacy being much more realistic despite requiring a pretty global presence on the network. But there is another major insight here that is important to point out. What is going to be the consequence of a capital flood into something like the Lightning Network? Yield will go down. There are only two types of people who will make money routing on the Lightning Network long term, people who know people, or people who have a lot of capital. Plebs need not apply.

All this talk of hobbyist routing, of PLEBNETS, etc. is frankly just childish silliness. If Lightning is going to be a profit incentive driven network organized by market forces, sorry guys, that option is out. Everything I just laid out above is what will happen, and what needs to be acknowledged and designed for.

If Lightning is not going to be a profit incentive driven network organized by market forces…well…it’s time for people who feel that way to start being open about it, and start discussing how they are going to structure and incentivize a web of trust to make it something else. And finally, at the end of the day, even such things as that cannot escape the forces that are the market for block space.

It’s time to stop looking at the toy we’re all playing with now as if it is the shape of the future. It’s not.

Lightning Network, Yield, and Incentives was originally published in Block Digest Mempool on Medium, where people are continuing the conversation by highlighting and responding to this story.