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