By Che Kohler, BTCStudy
Bringing Bitcoin to the next billion people will not be simple, but with growing pains come lessons. When mediating certain value transfers, such as your small electronic payments, tips, and streaming payments to higher levels of the settlement layer, on-chain transactions are impractical for many reasons, including the economic cost and transaction confirmation time. The request cannot be met.
Layer 2 solutions like the Lightning Network continue to mature, and route millions of transactions every day, reducing the need to confirm transactions on the chain, but this is inseparable from the tireless management of individual nodes. .
The Lightning Network can work, but it requires each user to manage their own payment system - running a node, establishing channels, guaranteeing capital, and constantly rebalancing channels. While this may be interesting to the average Bitcoin amateur, and those looking to make extra income by running a routing node, the average user is not going to figure this stuff out in order to route 69 satoshis.
The effort is not directly proportional to the return, which is why many Lightning Network users choose to use managed wallets or keep their Lightning funds with a Lightning Network service provider.
One of the pain points of the Lightning Network user experience is the startup cost; in the process of migrating to the second layer, you need a full node to broadcast transactions sent to the chain, establish a channel, and also need to collect payments. Get the collection amount beforehand. This is very different from the user experience of Bitcoin: from the moment you start using a Bitcoin wallet, you can receive payments at any time, and you can receive any large amount.
In order to save users from the hard work, technologies such as asynchronous payments and JIT channels were invented. These methods are proposed to completely change the user experience of entering and interacting in the Lightning Network.
What is a "JIT channel"?
"Just-In-Time (JIT)" is a concept borrowed from investment management, which refers to the creation of channels only when lightning payments arrive. A "JIT channel" is initially a virtual payment channel; once this virtual channel receives a payment, one party to the channel (Lightning Network Service Provider) broadcasts an on-chain transaction, anchoring the channel to the chain (making it become a regular channel).
In other words, a "JIT channel" is a channel that is opened by the LSP responsively to a customer when a payment from the public network comes in. This allows customers without Lightning channels to start receiving Lightning payments immediately, and their cost of obtaining onboard liquidity (receipt limit) will be deducted from the payment amount of this first payment.
This technology is very different from traditional methods. In the traditional model, users must open a channel in advance and prepare the funds to open the channel.
Note: JIT channels should not be confused with "JIT routing", which is a technique used to rebalance existing channels to accept payments that might otherwise be rejected.
What does the workflow of the JIT channel look like?
A customer wants to receive funds through the Lightning Network, but he does not have any receiving limit.
This client requires a Lightning Service Provider (LSP) to obtain the parameters to open a JIT channel.
This LSP returns a SCID (Short Channel Identifier), which is a unique identifier for this channel request.
This customer generates a Lightning Network invoice that contains the SCID and the node ID of the LSP.
The customer sends this invoice to the person who wishes to pay him.
Payments are forwarded to this LSP in the Lightning Network.
LSP identifies the SCID and opens a "zero confirmation channel" with the client.
LSP forwards the corresponding payment to the customer and deducts the handling fee required to open the channel.
Customer collects payment.
In other words, the JIT channel workflow allows a customer to receive payments through the Lightning Network even if there is no payment limit. The LSP serving the customer opens a zero-confirmation channel to route the payment while deducting the handling fee for opening the channel. After the channel is opened, the client can receive the payment.
Keywords in JIT workflow:
Lightning Network Service Provider (LSP): An LSP is the Lightning Network one node, and it can provide help to other nodes, such as opening JIT channels.
Short Channel Identifier (SCID): A unique identifier for a JIT channel request.
Lightning Invoice (Invoice): A payment request on the Lightning Network, including the amount to be paid, the node ID of the payee, and other information.
Zero-confirmation channel: A lightning channel that has not yet been fully confirmed by the Bitcoin blockchain. This means that the funds in the channel are not yet completely safe, but are still very likely to be.
Why does the Lightning Network need a JIT channel?
JIT channels are key to the Lightning Network for the following reasons:
Simplify the entry process: open the channel ( Locking up funds) can be a complicated experience for new users. The JIT channel removes this complexity and simplifies the onboarding process.
Efficient liquidity management: Because channels are only created when needed, JIT enables better liquidity management. The funds are locked only when the user's payment limit is insufficient, which can also optimize the user's resource utilization.
Driving adoption: By simplifying the user experience, JIT may boost Lightning Network adoption.
Risk of JIT channel
< p>Unfortunately, because of the difference in settlement speed between on-chain transactions and Lightning payments, the JIT channel has an inherent assumption that the UTXO that determines this channel will eventually be confirmed on the chain, but routing to the client Lightning payment is Settled immediately.
While JIT channels reduce reliance on channel construction and slower processing blockchain layers, it also introduces its own trust assumptions. The LSP bears the risk of forwarding the payment and needs to trust the customer; the customer also needs to trust the LSP.
LSPs will need to decide how much risk they are willing to take and evaluate clients accordingly; it may be helpful if clients can provide LSAT, node IDs, or Nostr public keys that can bear the reputational damage .
Then, users who have no experience may be limited in the payment scale of the JIT channel. Using a more restrictive LSP may be vulnerable, but the loss can also be viewed as a customer acquisition cost (in reality, only some on-chain fees are lost, and the opportunity cost of locking capital in a channel that will not be paid ), and hope that future returns from trusted customers will cover the losses.
Back to distrust and verification
If neither the client nor the LSP trusts each other, then they will be in a deadlock. LSPs who are not willing to trust customers will withhold the channel funding transaction without broadcasting it until they see the original image of the payment; customers who do not trust the LSP will withhold the original image of the payment until they see the funding transaction; this is the purpose of the JIT channel against. JIT channels require trust from both parties to assist in timely liquidity deployment.
The only way to break this deadlock without introducing trust is to use the blockchain to confirm that a contract was written to guarantee that the funding transaction will be broadcast when and only when the preimage is provided to the LSP.
This can be done by using an HTLC whose hash lock branch is signed by the LSP and the client together, and the LSP provides a witness from the hash lock branch spent to the channel funding output point, The customer provides his or her signature and original image to confirm the channel investment output point.
(Translator’s Note: This contract is not a standard hash time lock contract, but it is similar in principle. The hash lock branch requires the signature of both parties, not just one party; and the hash lock branch is constructed using the same preimage that goes into the payment. The LSP provides the client with a signature to spend the funds to the channel funding point, and once the client adds their signature and preimage, the channel is confirmed by the block. Of course, the channel The commitment transaction within the transaction must be constructed by both parties in advance.)
But in general, from a settlement perspective, this is no different from the creation of a standard payment channel.
Make liquidity readily available
Despite these potential shortcomings, it is clear that JIT channels hold great promise in making the Lightning Network more user-friendly and efficient . As with all developments in our field, there are bound to be trade-offs that need to be considered; after launch, the market will determine whether these trade-offs are worth it, whether the approach can continue to advance, and what trade-offs remain to be addressed.
In any case, the benefits of onboarding and liquidity management make JIT channels a huge advancement in the evolution of the Lightning Network.
Beincrypto
Bitcoinist
Cointelegraph