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.

Reply to this note

Please Login to reply.

Discussion

I’m going to add some of the notes you’ve posted here into the bounty and edit it a bit to make it specific to single splits. Seems like that’s the most practical way to start and better to keep the initial scope small then expand from there (if needed)

Appreciate you, Andre 🙏

Didn’t know ZBD was behind Fountain, very cool 🤙

Take your point on fees and order. What are talking about in real numbers though?

Say I wanted to do a 4-way split on 100 Sats I was being zapped; in my experience the fees on this are going to be 0-2 Sats most of the time, sure that doesn’t flow through perfectly per the Zapper or the Splitter’s desires but losing a couple Sats to fees is acceptable for the utility of passing through payments like this.

I can image a 7/21 Sat zap isn’t going to be great though with 4 splits..

Maybe if you can elaborate with some examples we can find a happy medium but otherwise even 1 split like Walker suggested is a good start.

For the record, we’re not “behind Fountain”. Fountain simply leverages ZBD as their LSP.

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.

Is a fixed fee indexed to the average total network cost out of the question? I have no idea how to implement such a mechanism, or if it’s even possible, but it seems like the correct way to do it.

Not how Lightning works unfortunately.

No your explanation makes complete sense.

I guess my view is simply that I’d prefer to have those Sats eaten in fees for the utility of having automated splits.

A 10% tithe is kind of what I was thinking, #[7]​ mentioned similar in his recent pod too - this is something I think every Nostrich should be willing to participate in to help fund the builders in V4V. Given the order of operations matters to the fees, I could simply set my tithe split as the first route for payment and then any fees would be eaten in my remaining 90%.

Since zaps are an unexpected bounty - ie, I’m receiving these because somebody else valued my content, not because I agreed a price and transacted - I’m not so bothered losing Sats to a tx fee as they weren’t my Sats to begin with, I’m still benefiting from the Zap and instead of 90 landing in my wallet I get 85 but my chosen devs get their 10, well end of the day that has served its purpose.