You clearly haven’t given this much thought.
I can open a single channel towards an LSP and make unlimited number of payments, in Ark, without any liquidity requirement aside from the initial deposit.
You clearly haven’t given this much thought.
I can open a single channel towards an LSP and make unlimited number of payments, in Ark, without any liquidity requirement aside from the initial deposit.
That’s fine either way. I’ll work with people to build a Lightning enabled wallet that blows native ones out of the water then we can check back on the “liquidity issues”.
You can do LN-on-Ark, indeed, which addresses some of the Ark LSP liquidity issues (without the trust model tradeoff), though you still require somewhat more liquidity than lightning natively, which seems pretty expensive.
My understanding was that no one was bothering with that since statecoins-on-Ark was simpler…
This is not LN on Ark this is just a normal spillman style payment channel.
I fail to see how this is more liquidity than LN. It’s infinitely better for LSPs who don’t have to tie up liquidity in channels with random users. Now that is expensive (Phoenix)
Indeed, that’s a bit better, though it’s still not a lot less than LN. If a user receives X sats, the LSP has to allocate at minimum X sats for the Ark transaction (and needs to complete that Ark update pretty quick, maybe in under a second or so, but that doesn’t require liquidity). Now if the user sends X/2 sats, the LSP is providing X/2 sats in liquidity (same as LN). Maybe it’s better because it’s a bit easier to under-allocate up front, but I’m not sure that that was a major part of the total lightning LSP float to begin with.
That said, I’m curious how you handle the ghettoization attack? That seems pretty nasty especially if you’re really strictly not over allocating liquidity.