Breez and Phoenix use this feature. The specific use case that it suits is that when the user sends a payment via LN intended to fund their wallet, the LSP opens a 0 conf channel to the user's client. The channel is balanced already in favour of the client, who could hypothetically close it, but the LSP's side its LN balance inbound has already moved in their favour. There just is no reason to do it, and the user has no reason to do it since they have control to spend their fully loaded new channel instead.
There is potential issues with this technique, and likely ones that some of the several proposed scripting language changes could solve. It is likely to be an important feature, regardless, especially in times of high L1 tx volume like the recent spate of consolidations and then Ordinals, or the predictable channel congestion as the bull market starts to get hot.
It's something Indranet will need to leverage for onboarding, for the same reason as LSPs use it. It's just bad UX to have to wait 40-120 minutes for full confirmation to get started. Relays on Indra, on the other hand, don't need to speed it up substantially, as it is they will be waiting some time before they get a lot of business anyway (part of the security of Indra comes from clients being averse to newer versus older versus known and used relays, since payments for sessions go forwards (but they are very small, to balance it).
reply
The link for this post uses a read-only front-end for Twitter, which can be easier to read for viewing a full Twitter thread. The Tweet that kicked off the thread is:
Zero Confirmations Channels: Accelerating Liquidity and channels on Lightning Network🧵⚡️⬇️
The format of open/close channels using 0 conf on layer two is winning adoption between companies, lightning implementations and Bitcoiners
#bitcoin #LightningNetwork #layer2 #taproot
reply