What Is A Just-In-Time (JIT) channel?

Scaling Bitcoin to the next 1 billion people was never going to be a straightforward task, and as the growing pains continue, so do the lessons. On-chain transactions aren’t practical for several reasons, such as cost and time to confirmation, relegating certain transfers like your small eCommerce payment, and tipping or streaming payments to higher layers in the settlement stack.

Second-layer solutions like the Lightning Network have continued to mature and route millions each day, reducing the need for on-chain confirmations, but this is not without considerable management by individuals.

Lightning works, but it does require the individual to manage their own payment structure, have a node running, establish channels, keep capacity open, and rebalance channels. While this might be fun for the average Bitcoin hobbyist or those running routing nodes as a form of earning additional income, the average person is simply not going to participate with Bitcoin on that level to route 69 satoshis.

The payoff is not worth the hassle, which is why so many users of Lightning would rather opt for a custodial wallet or hold their Lightning balance with a Lightning Service provider instead.

One pain of Lightning is the start-up cost; in moving to the second layer, you need a full node to broadcast an on-chain transaction and establish a channel and have an inbound capacity before you can receive funds. This is very different from standard Bitcoin, where you can receive funds from the moment you start up the wallet.

Instead of giving a user so much work to simply secure their first payment, options like asynchronous payments and JIT channels are in the works. These approaches are poised to significantly alter the way users onboard and interact within the Lightning Network.

What are JIT Channels?

Just-In-Time, a concept borrowed from inventory management, refers to creating channels in the Lightning Network exactly when a payment is made. Just-In-Time (JIT) channels start their lives as virtual payment channels; once the first payment to the virtual channel is received, an LSP broadcasts a transaction that will anchor the channel on chain when it is confirmed (making it into a regular channel).

A “JIT Channel” is a channel opened in response to an incoming payment from the public network to a client via an LSP. This allows a client with no Lightning channels to start receiving Lightning payments immediately while the cost of their inbound liquidity is deducted from their first received payment.

This method offers a stark contrast to the traditional approach, where users must open channels in advance and commit funds to them.

Note: JIT channels should not be confused with JIT routing, which is a technique for rebalancing existing channels to allow accepting payments that might naively need to be rejected.

How would a JIT channel flow work?

• A client wants to receive funds over Lightning, but they don’t have any inbound capacity.
• The client queries a Lightning Service Provider (LSP) to get the parameters for opening a JIT channel.
• The LSP returns an SCID, which is a unique identifier for this channel request.
• The client generates an invoice that includes the SCID and the LSP’s node ID.
• The client sends the invoice to the person who is sending them funds.
• The payment is forwarded to the LSP.
• The LSP recognises the SCID and opens a 0-confirmation channel to the client.
• The LSP forwards the payment to the client, deducting a fee for opening the channel.
• The client claims the payment.

In other words, the JIT channel flow allows a client to receive funds over Lightning even if they don’t have any inbound capacity. The LSP opens a 0-confirmation channel to the client and forwards the payment, deducting a fee for opening the channel. The client can then claim the payment once the channel is open.

Key terms in the JIT channel flow:

• LSP: A Lightning Service Provider is a node on the Lightning Network that provides services to other nodes, such as opening JIT channels.
• SCID: A Service Channel Identifier is a unique identifier for a JIT channel request.
• Invoice: An invoice is a Lightning payment request that includes the amount of money to be paid, the recipient’s node ID, and other information.
• 0-confirmation channel: A 0-confirmation channel is a Lightning channel that is not yet fully confirmed on the Bitcoin blockchain. This means that the funds in the channel are not yet completely secure, but they are still very likely to be safe.

Why JIT is needed in the Lightning Network

JIT Lightning Channel creation is pivotal for the Lightning Network for several reasons.

1. Simplified Onboarding: Opening channels and committing funds can be a complex process for new users. JIT takes away this complexity, easing the onboarding process.
2. Efficient Liquidity Management: By creating channels just when they are needed, JIT allows for better liquidity management. Users only commit funds when they want to make a payment, optimising their resource utilisation.
3. Encourages Adoption: By simplifying the user experience, JIT could potentially catalyse the broader adoption of the Lightning Network.

Trade-offs Involved in JIT

As with any innovation, JIT Lightning Channel creation is not without its trade-offs.

1. Time Consumption: JIT channels are not always instant. The creation process when there is a dispute requires confirmation on the Bitcoin blockchain, which could lead to delays if blocks are full.
2. Channel Lifetime: Unlike traditionally opened channels that exist until closed by users, JIT channels may have a shorter lifespan, determined by the service creating them. This might limit long-term, repeated interactions with the same peers.
3. Dependence on Third-Party Services: With JIT, users might have to rely on third-party services to open channels. While these services can simplify the process, they also introduce a dependence on external parties.

The risks of JIT channels

Unfortunately, due to the time difference in settlement on chain and on Lightning, there is an inherent assumption of JIT channels is that the unconfirmed payment (UTXO) backing the channel will eventually settle while the LN payment is immediately routed to the client. 

While JITs channels reduce the dependency on channel formation and the use of the slow blockchain layer to handle trust, it brings in its own trust assumptions. The LSP is taking the risk of forwarding the payment on trusts the client or the client trusts the LSP.

LSPs will need to decide how much they are willing to risk and evaluate clients accordingly; if the client can produce an LSAT, Node ID or Nostr account that can be used for reputation management, that might help in certain cases.

While unfamiliar clients might be limited in the size of payments that can be JIT’d with an LSP. A more liberal LSP could be attacked but may treat its losses as part of the cost of doing business (effectively losing just on-chain fees and the use of capital while locked in an unpaid channel), and hope to make it up with future business with trusted clients.

Back to not trusting and rather verifying

If neither the client nor the LSP trusts each other, they will be stuck in a deadlock. The untrusting LSP withholds the funding transaction until it sees the payment preimage, and the untrusting client withholds the preimage until it sees the funding transaction, defeating the purpose of JITs; JITs require trust to facilitate liquidity deployment at speed. 

The only way to break this deadlock without invoking trust is to use the blockchain to ensure confirmation of some contract that ensures that the funding transaction is broadcastable if and only if the preimage is provided to the LSP. 

This can be done trivially by using an HTLC where the hashlock branch is signed by both LSP and client, and the LSP provides the witness required to spend from the hashlock branch into the channel funding outpoint, with the client providing its signature and the preimage in order to get the channel funding outpoint confirmed.

But again, this would be no different from your standard channel creation in terms of settlement.

Having liquidity available on the fly

Despite these potential downsides, it’s clear that JIT Lightning Channel creation holds great promise for making the Lightning Network more user-friendly and efficient. As with all developments in this space, there are trade-offs to consider, and if rolled out, the market will decide if these trade-offs are worth it or if the approach will continue to evolve, and the trade-offs will need to be addressed.

However, the potential benefits it offers for onboarding and liquidity management position JIT as a significant advancement in the Lightning Network’s evolution.

Do your own research.

If you want to learn more about JIT channels on Bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.

• GitHub – LSPS2 JIT Channel Negotiation

Are you a Bitcoin and Lightning fan?

Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? Have you tried all the forms of Lightning payments? Which one do you prefer?

Let us know in the comments down below.