Not two words out together. Single word
Less hard-to-pronounce
That’s 😎
Less weird #[2]
Best name for a Nostr client #[0]
You are not ready
Hahaha touché
Last week I met up w the LNMarkets
team to chat abt my background & ZEBEDEE. Interview also covers Lightning Address (lightningaddress.com), ZEBEDEE engineer @fiatjaf’s Nostr invention, as well as 🇧🇷Brazil's adoption of #Bitcoin with Vinteum!
Peep the interview here:
https://lnmarkets.substack.com/p/60-andre-neves-lnm-parabolic-growth
Not how Lightning works unfortunately.
The reality of 0-2 sats being the fees is unrealistic at scale given that LN is a “living organism”. Liquidity changes. Channels get depleted. Routes can go from being “cheap” to being quite expensive.
I said before, one can split things infinitely, it just doesn’t scale 100% because of the fees. Agree that “some fees” are okay because everyone’s still getting value out of it.
But say you have 100 sats divided evenly by 4. You’d expect 25 each. That’s not what’s going to happen. What if on the third split there was a 5-10 sat fee (for whatever reason), that fee is taken from the total 100 sats, not from the 25 sats that’s being sent. LN payments incur the fee AT THE TIME OF THE PAYMENT. So unless you know ahead of time the fee, you can’t say “oh you are supposed to receive 25 but your fee is 10 so we’ll send you 15 instead”. It’d be more like “sent you 25sats but it cost 10 sats to do that so the next splitter can ONLY RECEIVE 15 because 10 of the 100 were spent on fees”.
It’s hard to explain in writing like this but maybe I get the point across.
For the record, we’re not “behind Fountain”. Fountain simply leverages ZBD as their LSP.
Have discussed this with #[5] and recently #[6] as I’m very keen on having splits on lightning polls.
It’s going to need a separate NIP but a lot of the value block concept in podcasting 2.0 could be lifted and reused in nostr:
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md
That’s great and all. But as I explained above, the idea of splitting is great, the problem is the ACTUAL executing of it. Fees in LN are variable and that will lead to splitters receiving LESS than they were supposed to. And it’s all base on ORDER OF THE SPLIT. The first splitter will get the total share they were supposed to, but then the following may not, the next one likely won’t, and the last splitter will DEFINITELY not receive the correct amount (because there are fee costs in the mix here).
Doing it on LN Address is better than the keysend flow for sure though, which I know is a major active discussion at Podcasting2.0 folks.
Given that ZBD powers Fountain (the biggest podcasting 2.0 platform) we have tons of insights like these. Happy to share more.
I’d advise discussing these splitting ideas w the folks from podcasting 2.0. I’m sure they have some ideas. But they also have explicit minimums on the split. Can’t split less than 10 sats for example. And the fee distribution is very visible for the users.
Single splits seem fine without too much overhead / fee costs. 10 splits at best cost 10 sats. At worst could be much much more, rendering it infeasible. Maybe down the line when LN is much larger we can have better fee estimation but atm it can vary WILDLY.
You can split infinitely actually. The issue is that fees are variable in LN. The fewer splits, the less is paid in fees, know what I mean?
50 sats, split 2 ways is NOT 25 and 25. At BEST it’s 25 for you and 24 for the splitter since 1sat tx fee. Most likely it’s 25 for you 20-22 for them. If you do 10 splits, you can see how splitters 7, 8, 9, and 10 may not even get a single sat.
Also some routes are very liquid and cheap where you can realistically get somewhat good estimates for fees. Other routes (especially those who self host nodes and don’t have a TON of liquidity and channels) could be much larger fee.
Not to mention this is WIDE open for fee-siphoning attacks. Is the algorithm for splitting zaps going to be THAT smart? Wouldn’t every single service provider / wallet have to face this same problem?
The same issue will be faced here as it exists with v4v podcasting through keysend. It costs fees to split payments further. If you split 50 by 10npubs you’d expect 5 sats each. Reality is it costs many sats to send all of these txs and so the last split receivers will NOT receive the correct amount. This renders the ENTIRE premise null here as it’s going to be fully random as to WHO gets sats and who doesn’t because it was taken in fees.
You’d need to do some extremely perfectly estimates fee estimation on LN (good luck!) for this to work at scale.
Testing reply from Damus