pull down to refresh
0 sats \ 3 replies \ @LNAnon69420 25 Dec 2023 \ on: SlushPool(Braiins) is dying. Here's how to save it bitcoin
Can you expand on the cheapness?
In my rough estimate, say a pool pays out 100 bitcoin a week across 100 customers, and they want to do this 100% via Lightning. For a week of daily payouts, they need to commit 700 bitcoin, say as a single batch tx with 100 outputs to every node. Call it .01 btc fees/week to open these channels.
Seems like its more expensive to perform than on-chain payouts, or am I missing something? Not even including the nominal risk of hot wallet infra, payroll for employees to manage, or the time-locked value of BTC
A few assumptions you are getting wrong. First, I would say LN payouts should only be in a specific range, as route finding becomes more difficult the bigger the payment. This becomes less so with MPP and AMP but let's put that aside. As for the node itself, there is no limit to how many channels one could have, as well as no limit to the amount of bitcoin that can be allocated to a channel.
Further, the bigger the channels, the less likely you have to perform opens. To add to that, batch opens are easy you could open 50 channels with 1 TX. Also, to replenish the channels, you do not have to open more, you can loop in or use other onchain to lightning methods to replenish. Personally, I would advise opening channels to Loop to milk fees when liquidity gets drained to replenish channels. it's win win on that.
The routing fees earned by the node will actually incentivize running of the node financially as well as if the runners of the node decide to lease channels as well by automating magma or other liquidity leasing services. It is unfathomably cheaper to do LN payouts in the case of paying out those with 100TH/s or less.
reply
I see, my assumptions hinged on a payout node opening individual channels per client to guarantee reliable payouts. Using the greater networks liquidity could surely reduce the liquidity req's on pool-side, though clients would then need to source their own inbound?
Sure, the bigger the channels, the less often tx need to be performed. Seems like the pool still needs some hundreds of bitcoin locked up in outbound channels? As payouts occur, you suggest looping vs. reopening- this seems to suggest another cost for the client to perform? Would not the client prefer to just close the channel, claim the funds onchain, and leave the source of their inbound with the closing costs? (Another cost for pool if they opened the channel)
Monetizing the flow of the node makes sense, I'd be interested in seeing what revenues could be expected to offset expected costs. Maybe The Lightning Pulse could open-source a model of how to perform payouts? Definitely interested to see how Nifty would sketch it out
reply
I am going to bring this topic up in Ep.2 for sure. The client has two options and those options can fluctuate based on how much theyre getting paid but generally they have option 1: Custodial alby/zbd are probably top 2 remaining custodial services since WoS is gone in US, anyway.
2. Run own node. This can be done on Zeus since Zeus added an embedded node into their app and they give out a free LNaddress with each embedded node or they can run their own node on Voltage or at home.
If they run a node at home all they would need is one channel and this channel they should open with the pool directly and then either swap out or buy something to get their inbound. When the channel fills they can loop out or continue just buying stuff to get more inbound. Each client would have their own personal preference. The cost savings is determined by volume of events multiplied by on chain fee rate.
reply