0 conf is a little bit of a controversial thing, especially now with RBF being enabled by default. But I'm wondering about this because of those times when opening channels is a 100ksat fee, as happens from time to time.
What work is being done on dealing with this issue? It seems to me like a bit of an obstacle for "layer 3" or "layer 2.x" type apps built on top of LN. The channel opening and state transactions all work off chain, so it seems to me like a signed tx can do some of the work of an on-chain tx in some situations.
A good example of 0-conf channels is Phoenix wallet: when you create a new wallet, if you send funds to that wallet with Lightning what actually happens is Phoenix opens a channel to your phone. Your wallet lets you use that wallet immediately, before the transaction confirms, to send funds back, because your wallet trusts Phoenix not to double spend you.
Phoenix meanwhile doesn't need to trust you, because their in full control of the 0-conf transaction: it's impossible for you to double spend them.
It's a great usability feature when onboarding new people as it lets you give them a working wallet immediately. The risk is also very small: if Phoenix started defrauding people, it'd be noticed immediately and people would quickly stop using Phoenix.
reply
Yeah, it is a very useful technique for exactly onboarding. I will be using it in Indranet for new users running the client for the first time, it just eliminates the problem of on chain congestion and allows the low fee to just clear a bit later in such a case but the user gets online immediately and can then make payments and top up their channel as they go.
reply
RBF being enabled by default.
Not true.
reply
I found information about it, here's an explanation from ldk: https://lightningdevkit.org/blog/zero-confirmation-channels/
There is counterparty risk with these channel openings, but they make it possible to pay a minimal fee to open a channel if the counterparty can be trusted to not double spend the transaction before it gets included in a block.
Indranet requires a low friction onboarding process for users, who may have minimal technical ability, and likely more used to trust based systems like the centralised banking services they probably use every day.
This capability makes it possible for users to get started using Indranet for maybe as little as 30,000 sats, around $6 at current prices, and enables them to establish sessions with an Indra seed node which they can then use to open sessions with relays and the Indra client will be able to generate invoices that they can use to top up the balance of their channel when it runs down and cannot make any more payments out to relays. Typical session fees can be as little as $0.05 which would give them like 50-100mb through a given relay or so, just plucking numbers out of the air, of course they will also be able to set maximum bandwidth prices for relays their client selects.
reply
Regarding bandwidth prices for Indranet, just doing some back of the envelope calculations, users must pay for 5x the cost of relay bandwidth. According to recent statistics, european bandwidth cost is about $5 for 324Gb (1mbit/s/month rate), or 64Gb/month base cost for european relays of $5. So it is easy to see how a relay can charge twice this rate and make a full 100% markup.
The same amount would be $8 typically in USA and $10 for asian relays. So routing in asian relays would be $5 for 16Gb of data allowance, which is still lower than typical mobile internet data allowance costs, which should be affordable.
reply