Hey bitdern, great article! I think you did a great job in all the aspects you covered (btw I mentioned your piece here last week 😉).
You're touching a bit on this, but I think "mixed" solutions will probably be a thing in 2025. In such a solution, when a user receives a small amount it is kept by the LSP in a custodial way (for example as e-cash). Only when the balance is big enough and/or on-chain conditions are more favorable will an actual channel creation be triggered. This also allows for batching, and hence more fee savings. That's not ideal, since it involves a custodian at some point, but 2025 is quite near and I doubt we'll have things such as channel factories by then.
Something that is also a bit under-explored in today's wallets and might be a bigger thing in 2025 are "contacts". Blixt and Bitkit are the only wallets I can think of that are implementing some sort of contact repository for easier payments. There are technologies and networks seeing great development (Nostr, Slashtags, etc.) that can be abstracted from the user and provide dynamic contacts. This addresses the need for static payment "endpoints", in a different and complementary manner to Bolt12.
That's all I can think of right now, but there's probably more 😄 2025 is both so close and so far away 😅
Fanis! Thanks for saying so & for featuring it in the LN Markets newsletter, that means a ton to me.
  • On your first point, yes "mixed solutions" are approximately what I had in mind! I wonder if one version of that might be where the LSP opens (one) private channel to the user, and when the user goes to make payments, it's routed directly through the LSP. That way the # of channels doesn't spiral out of control.
  • Contacts is a reeeeeeally good point to bring up! I didn't realize that Blixt had implemented a contacts scheme, are they using nostr? I've played around with Bitkit and I like the idea & tech behind slashtags, too.
Thank you for your perspective here, much appreciated!
reply
My pleasure, really!
The contact thing in Blixt seems to be essentially storing payment info (such as a Lightning Address or LNURL-Pay link) under a contact name. So it lacks automatic updatability, but can still be very useful for frequent payments.
I'm not sure what you mean regarding the LSP opening only one private channel with each user. That's pretty much what Phoenix does already with splicing, resizing the channel every time its needed. But it's not possible to receive a 10 sats payment for the first time, because it doesn't cover the on-chain fees of opening a channel. So the idea behind a "mixed solution" is that the LSP would take the Lightning funds for themself and send the user e-cash tokens instead. Once the user's balance is big enough (say 10k sats), the LSP will open a private channel with them. If many users reach this balance threshold approximately at the same time, it becomes possible for the LSP to batch the channel opening of many users into only one bitcoin transaction.
reply
Yes that makes sense -- about the LSP not being able to open a channel for 10 sat transaction. I saw that Calle posted about this sort of model on twitter yesterday: https://twitter.com/callebtc/status/1696897866936053927?s=20
I think I am going to include the contacts aspect and this hybrid model in the article. Great suggestions!
reply