pull down to refresh
0 sats \ 1 reply \ @LNAnon69420 25 Dec 2023 \ parent \ on: SlushPool(Braiins) is dying. Here's how to save it bitcoin
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
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