⚡LSPS2: Get "Just-In-Time" Lightning Channels
If you want to get an inbound channel from Megalith LSP for your own node, please go directly to our online form.
This page is for developers. It describes our API which follows the Lightning Service Provider Standard Two (bLIP52 / LSPS2) for automated "just in time" channel-opening.
You're here because you want your users to use Bitcoin in your application.
You've learned that supporting Lightning payments isn't 100% straightforward.
Should I just use an API for Lightning?
There are a few new, well-funded companies that are offering centralized solutions to onboard your users to Lightning.
For example Breez can get you set up with a private sidechain called "Liquid", run by Blockstream, and your users can get the "feeling" that they have their own Bitcoin, and are moving Bitcoin payments around, even if this isn't technically what is happening.
Similarly, other startups like Lightspark can offer you APIs, so your users won't even have to pretend to own Bitcoin -- they'll simply get an I.O.U. from Lightspark! As long as Lightspark is still running and their servers are online, your users will be able to interact with the Lightning network, using Lightspark as the single trusted intermediary.
These solutions could be perfect for some applications, and we'd encourage you to stop here if you don't think your users need to self-custody their funds, and/or if you don't really care about centralization risks.
But: These are venture-funded companies, and it's not guaranteed that they will survive forever. If funding dries up, if the founders decide they are ready to sell, or if they go out of business in the next bear market, all the work you have put into integrating their APIs might be wasted. And the worst-case scenario is that your users lose funds if one of these startups goes out of business at an inconvenient time.
The alternative: Do the work to allow your users to interact directly with Lightning. Freedom, for the win.
What about other Layer Twos?
In order to send and receive on Lightning, your users will need at least one Lightning channel.
But what about the stylish and exciting new "L2" solutions like Ark and Spark? These promise to get your users up and running on Lightning without a channel, right?
The problem is that very few people outside of these companies understand how these protocols are supposed to work, and actual production use of them is likely to be many years away. (And require a few more cycles of venture funding, too!) By that time, will these companies be far enough in debt that they will need to start charging massive fees?
There are also quite a few basic unanswered question about how these protocols will handle all the networking complexities -- basically, getting multiple distributed computers & devices to all talk to each-other reliably - something that has proven to be VERY complicated in Lightning and has taken years to get right. (With quite a few lingering problems even now, almost 8 years into the protocol! Just look at recent release notes for LND, CLN, LDK-Node, etc....)
So let's clear our mind for a second and ask: What if there was an open-source, well-tested standard by which your users could get hooked up to the Lightning Network, without marrying yourself to any one company or proprietary API?
Enter the first standard: LSPS1
Luckily, there is an open source standard that is already battle tested, with tens of thousands of users. It's called Lightning Service Provider Standard One (bLIP51 / LSPS1), and it's been implemented by LSPs (Lightning Service Providers) like Zeus, Megalith, and Flashsats. Collectively, these LSPs, along with dozens of others, have opened tens of thousands of channels using LSPS1, and routed many millions of payments.
LSPS1 is battle-tested and known to work well. It's impossible for funds to be "stolen" by the LSP, and furthermore, if and when your user's channel closes, their funds settle onto the Bitcoin mainchain automatically, so there's no need for complicated protocols, centralized control, or customer support.
There is no company providing an API that could suddenly go out of business, and since the LSP standards are open-source, you are free to switch LSPs at any time.
So. LSPS1 works great if your users already have at least a little Bitcoin. They pay a small invoice (usually around $20, depending on channel size and exchange rate), and then they get an "inbound" channel.
Especially if your users are somewhat savvy already with Lightning, and especially if your users are on desktop or using a desktop web browser, LSPS1 probably makes the most sense, and you can follow our guide to LSPS1 here.
Would somebody please think of the normies?
But here's the problem. What if your users don't yet have any Bitcoin? And furthermore, what if their potential attention span for getting onboarded onto Bitcoin is less than five seconds?
We've all seen the studies: When normies want to do something on the internet, it needs to be done in less than five seconds. If it takes longer than that, then they forget what they were trying to do, and they're already back on TikTok or Instagram.
LSPS1 is pretty elegant, but it involves a few user touch points...
- A user must know that he/she is running a Lightning node, and know that he/she needs a channel
- A user must pay an invoice (or you can pay it for them.)
- Here comes the confusing part: Once this invoice is paid, the channel can open quickly, but then the user has no Bitcoin in the channel! They then have to..
- Make a payment "to themselves" in order to get outbound capacity.
- So a user must (at least to some small degree) understand that they are getting a "lightning channel" -- and understand what this means.
And, remember -- Normies. They refuse to learn anything new, and you have less than five (5) seconds to get them what they want. Challenging, right?
LSPS2: From a user perspective, it's awesome
So the good people at the Lightning Layer Spec Group realized this issue, and have been chugging away for a couple years on a solution: bLIP52 / LSPS2.
LSPS2 allows for "just in time" channels. From the perspective of your user, this means they don't "pay for a channel" and "wait for it to open" and then "pay into their channel from an external wallet" -- instead, these three steps happen SIMULTANEOUSLY -- they instantly have a Lightning channel, and that channel instantly has both inbound liquidity AND outbound liquidity.
And all this can happen in LESS THAN TWO SECONDS, well before your user has lost interest and gone back to looking at gyrating bodies on TikTok, or similar.
LSPS2: For the developer of the client software, it's awesome
LSPS2 is ideal if you are using LDK Node, as there is an exceptionally simple and elegant API you can use to get your client a channel.
Even if looking at Rust gives you a headache, take a look here:
https://github.com/MegalithicBTC/ldk-node-liquidity-mutinynet/blob/master/src/main.rs
You need a grand total of TWO (2) API calls to get your user a channel:
set_liquidity_source_lsps2(lsp_address, lsp_node_id, lsp_token);
and then....
invoice = node.bolt11_payment().receive_via_jit_channel(1_000_000_000, "asdf", 3600, None).unwrap()
So there you get an invoice, which your user can pay, or, to prevent confusion, your service can pay the invoice for your user (recommended). Now your user instantly has a Lightning channel with both inbound and outbound liquidity!
LSPS2: For the LSP, it's challenging
Now, I won't say that I personally cried when reading the LSPS2 spec, but it did give me some pause: From the perspective of an LSP, this specification is at least FIVE TIMES more complicated to implement than LSPS1, and requires lots of fiddling with HTLCs. There's also some risk that if the LSP makes a mistake in the implementation, the LSP could be attacked.
Furthermore, if you've looked at our LSPS1 implementation, you might have picked up that we cheated a bit, and used HTTP communication instead of BOLT8. HTTP makes things easier because it's easier to hook in a database and web server.
In the case of LSPS2, however, HTTP communication between client and LSP would be totally impossible, as the protocol cleverly uses the characteristics of HTLCs in order maximize convenience for the client, so LSPs need to get down-and-dirty with BOLT8 communication, as that's the only way to talk to the client.
In any case: after doing quite a bit of battle, we have now implemented the LSP-side behavior of LSPS2, and we are ready for YOU, the client developer, to try it out.
Please fire up your LDK Node(s) and give this a whirl
We've got a VERY MINIMAL LDK client for you to look at, that runs on MutinyNet, so you don't have to risk real funds while testing. The entire story is told in just TWO Rust files, lib.rs and main.rs, here: https://github.com/MegalithicBTC/ldk-node-liquidity-mutinynet/tree/master/src
And for reference (although it's already in the above code), you can connect to our LSPS2 LSP on MutinyNet with this URI:
02d71bd10286058cfb8c983f761c069a549d822ca3eb4a4c67d15aa8bec7483251@143.198.63.18:9735
Happy hacking, and please reach out when you start testing so we can help you through it!