pull down to refresh
5 sats \ 8 replies \ @LNAnon69420 25 Dec 2023 \ parent \ on: SlushPool(Braiins) is dying. Here's how to save it bitcoin
The reasons I listed are generalizations of why pools haven't yet from what I've seen in my direct experience ;)
- Relative to onchain payouts, where the pool just needs an address, LN requires additional components on both pool and client side
- Liquidity does very much matter, in the sense that pool needs to essentially 'pre-commit' funds to channels as opposed to paying out directly. Coinbase rewards into channel openings would be interesting!
- Consumer demand is generally easier to sell to corporate team than notion of creating demand
Liquidity is not a problem. Mining pools simply need to open large channels with their newly mined funds to large nodes, and make their payments using those channels.
Once all the liquidity is on the other side, you close the channel and let the large nodes deal with the liquidity naturally. Or alternatively, the pool could use that capacity to get into the lightning liquidity business themselves.
reply
An unexpected Peter Todd reply!
I get what you mean, perhaps I should have clarified that I meant liquidity of the pool operator themself as opposed to node or channel liquidity concerns. A newly mined block needs 100 confirmations to spend. For a say once daily payout, not all mined blocks in the cycle can necessarily be spent in this payout. A pool paying out 100 bitcoin/day needs 100 bitcoin of outbound ready to serve the payout at the time it is executed (at least in this once daily example), and they will not necessarily have 100 bitcoin ready to spend into outputs per cycle from freshly mined coinbase's. To guarantee payouts, it seems to me that the pool operator must pre-commit funds to these channels, implying they have at least 100 bitcoins available before having mined them. Is there something I am missing so as to avoid this pre-commitment in the business logic sense?
reply
Obviously the simple answer here is to not pay out until the coinbase matures, or borrow funds to be able to pay out immediately. This is a simple time-value-of-money problem. At 10%/year interest waiting 1 day costs ~0.03%
reply
Fair enough, perhaps it is a negligble concern at Braiins scale. I am only trying to form a fuller model of the cost inputs for my own understanding, as pools live and die on the margins, particularly in FPPS schemes. I believe you confirmed that there is not quite a way to avoid some pre-commitment of capital, but please correct me if I misunderstood
A rough cost formula might then look like;
((Channel Open fee + Channel Close fee) * (Frequency of open/close)) + (Payout Capacity * TLV of BTC)
Cost variance appears to greatly hinge on the number of channels the pool operator must maintain, with 1 large channel to a large node being cheapest, and per-client channels to individual nodes being most expensive. Reliability of the payment being delivered follows inversely, highest by per-client channels, lowest thru the general network, with some potential cost of inbound liquidity borne by the client as reliance of using the general network increases
reply
Not sure where you are getting this 100bitcoin/day number from. In a few months we are going to be hovering around 5 bitcoin reward per block, probably. Maybe less, but let's just assume 5 (subsidy+fees). If Braiins crawls back up to 5% of network hashrate (which would be amazing considering theyre sitting at 1%ish now), that is on average 7 blocks per day. 7x5 = 35 bitcoin of reward on average per day. Now the question becomes what percent of those seeking payouts will want Lightning payouts? I think we can agree it will absolutely not be 100%.
But what if they only get up to let's say 2% of hashrate after going lightning (maybe steady climbing after that as difficulty continues to trend up), then they will get 3 blocks per day, roughly on average, that's just 15 bitcoin per day.
I get what you're saying.
- The client of the pool could set up a primary and secondary payout scheme. They could list several LN addresses and then if the pool payments fail, the pool could payout to maybe Liquid or on chain, assuming it is not dust and makes sense fee wise.
- Liquidity does matter. The pool could commit whatever it wants and slowly build out over time or batch open a bunch of channels. Batch opening is more cost effective but depends on their risk profile. There is lots of flexibility here.
- Agreed, but I think the cost of putting in LN payouts is low relative to the very likely gains.
reply
Batch opening is more cost effective but depends on their risk profile.
We're talking about coinbase rewards here. The value of each coinbase is enough that batch opening is irrelevant.
reply
Think we're pretty much on the same page, I look forward to a discussion on the pod!
reply