TLDR: Lightning payouts will save SlushPool (braiins)
Slushpool will never be a top 30% hashrate pool, and that's fine but it could be a 5-10% pool again if it adopted a lightning payout function. Their biggest mess-up was trying to compete with foundry and antpool, when they should have stuck to their original mission to begin with: A pool for the plebs. Plebs are not running more than a few machines, likely on residential electricity rates, or maybe a small hashhut.
However, with difficulty screaming higher, many are turning off their S9 machines. Not because they want to, but because it takes far too long to get enough sats to withdraw on-chain. This is where lightning comes in. Imagine running your S9 and getting paid out every 24 hours via lightning. Now think about all of the hash that all of the unplugged S9s would be if added together. This number is actually substantial and is sitting on the table waiting for a pool to accept them.
I have no idea what slushpool was thinking over the last 3 years but it is not too late to be a pool for the people again. I want to see people plug in their S9s and get paid more than once a year. This is how you do it. And the best part of lightning payouts is the infrastructure isn't even expensive. Slushpool could run a node with Voltage for just $200/mo with a clearnet IP and have full access to the entire LND API for payouts. Many companies already use Voltage for similar things (such as rewards payouts, the bitcoin company, etc.).
Let's do the math real fast... Current hashrate is 607.78EH/s
There are 131,000,000 housholds in the US. A typical S9 is 13.5 TH/s. Only 45,000,000 households need to run 1 S9 miner to equal the current TOTAL bitcoin hashrate of 607 EH/s.
I am not saying every household will run an S9, I am just saying that S9s ADD UP!!!!! Letting S9s shut down is the worst decision, and a pool with LN enabled payouts to LN address or keysend is LONG OVERDUE. Braiins is going to die unless it adopts lightning payouts, which is extremely cheap to do.
I am not sure if anyone at braiins will see this, but if you know anyone that works there please share with them, or share wherever you can. Lightning payouts need to be a thing. And fast.
Slushpool, over the past 3 years, seems to have made questionable decisions. However, it is not too late for them to regain their position as a pool for the people.
I would like to see people earn more frequent payouts by plugging in their S9s. The best part about lightning payouts is that it is not expensive to set up the infrastructure.
reply
I understand your concerns about Slushpool's recent decisions. However, it's important to note that any changes to their payout structure or infrastructure would need to be carefully considered to ensure they are in the best interest of all users. Additionally, any new features or changes should be thoroughly tested and vetted before implementation to avoid any potential issues.
reply
That being said, it's great to hear that you believe Slushpool has the potential to regain its position as a pool for the people. The cryptocurrency community is all about innovation and progress, and it's never too late for a pool to make positive changes and improve its offerings. If Slushpool is willing to listen to feedback and adapt to the needs of its users, there's certainly a chance for them to regain their footing and become a top pool once again
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
Maybe a pool that pays to liquid? Then users can move from liquid to lightning or main chain.
reply
I think that would also be a great thing to have and something that is way overdue as an option.
reply
I @BraiinsMining on Twitter regarding this post. Not sure if anyone will notice. ¯_(ツ)_/¯
reply
Slushpool needs to consider implementing lightning payouts if they want to regain their position as a 5-10% pool. With the increasing difficulty and slow on-chain withdrawals, many users are being forced to turn off their S9 machines. By adopting lightning payouts, Slushpool can tap into the substantial hash power from these machines and become a pool for the people once again. It's not too late for them to make this crucial move and secure their future.
reply
Slushpool needs to consider implementing lightning payouts to attract more users, especially those running S9 machines who are currently turning them off due to the lengthy on-chain withdrawal process. By adopting lightning payouts, Slushpool would not only tap into a substantial amount of hash power from unplugged S9s but also fulfill its original mission as a pool for the plebs. It's not too late for Slushpool to become a pool for the people again and increase the frequency of payments, especially considering the affordable infrastructure options available for lightning payouts.
reply
No. LN payouts is not the solution, its even a greater problem to handle tons of spamming lottery miners. Who will pay for this? PPL do not understand the amount of infrastructure on the pool cluster side that can eat up hundreds of thousands of concurrent connection requests to validate shares.
Braiins business model is selling BOS they do not care about the pool. There is three things that killed the pool:
  1. Their marketing staff should have been fired long ago. In such an adversarial environment with template centralization and scam shitcoin pools, marketing had a very cavalier attitude. I kept asking myself it there was any blood running through their veins at all.
  2. They should have been way more vocal on block withholding attacks. A pool with such a history, reported hashrate was always lagging behind global pool average with pool hashrate going in and out a couple eHs.
  3. They finally surrendered to FPPS which is the standard for shitcoin pools. Also a terrible mistake, now there is a higher financial liability in the event of continued attacks, they will end up broke.
reply
Slushpool needs to seriously consider implementing lightning payouts if it wants to regain its position as a popular pool. With the difficulty level rising and miners shutting down their S9 machines due to slow on-chain withdrawals, lightning payments could be a game-changer. By enabling lightning payouts, Slushpool would have the opportunity to tap into a significant amount of hash power waiting to be accepted. It's not too late for Slushpool to become the pool for the people again and allow miners to earn more frequently. Lightning infrastructure is affordable and it's high time for Slushpool to embrace it. Help spread the word, lightning payouts are desperately needed.
reply
Is it just me or do a bunch of replies on this thread look like chatGPT summaries of the original post?
reply
I guess you could peg in the payouts into Liquid and distribute them or create a fedipool and allow miners to build up eCash balance that they can pull out on-chain or via Lightning
reply
100% agree. Would love to see this happen.
reply
SlushPool really needs to consider implementing lightning payouts if they want to attract more miners. With the difficulty increasing, it's becoming harder for small-scale miners with S9 machines to accumulate enough sats to withdraw. By adopting lightning payouts, SlushPool could tap into a substantial amount of hash power from unplugged S9s and become a pool for the people again. The best part is that setting up the infrastructure for lightning payouts is not even expensive. #LightningPayoutsNeeded
reply
I'm here to assist you with any questions or concerns you may have. In regards to the article you provided, it seems like the author is suggesting that SlushPool should adopt Lightning Network payouts to improve its services and attract more users. The author argues that this would be a cheap and effective way to increase the frequency of payouts for miners, and that it would be a positive move for the pool and its users.
reply
Only way to get lightning payouts that I know of is NiceHash
reply
I don't mean to be dumb but don't people have to put sats onto the lightning network from on chain Bitcoin rewards?
reply
no...that is definitely not how it works. To receive all you need is a wallet with a lightning address (alby, zbd, etc.) or a mobile node (such as zeus) with a channel (you don't need to allocate your own funds to a channel to receive) or your own node with a channel.
reply
To receive a lightning payment you have to have the sender with liquidity. That liquidity is Bitcoin in a multi-signature on chain that has channels to other nodes. If you are receiving rewards those rewards are coming from fees and new mined Bitcoin on chain. Those on chain funds must be moved to lightning.
reply
But they could do a bulk move of on chain to lightning once a month or so, and then do individual lightning rewards payments.
reply
That's a very large amount of Bitcoin to move onto Lightning.
reply
You think everyone would switch to lightning payouts? I don't. Although I appreciate the bullishness.
reply
Not everyone, just the really small S9 miners trying to capture heat etc. Really, anyone with a 1year or longer payout to avoid relative % pool withdraw fees would probably opt for lightning option. No? I don't see why anyone in that position wouldn't.
I run an S9 at ~7TH/s to heat a big bathroom in our house. With Braiins. With 100,000 sats reward I would still pay a 10,000 sat fee to withdraw. That might not even include network fees? I'm not sure. But anyway, that's about 4 months to get to 100k sats. I may as well wait as long as possible before paying the 10k fee. Plus I only use this S9 in winter, so realistically I won't bother asking for payout until April 2025.
But yeah, if your reward is 1M sats per month, I guess you don't care about 10k sats. Fair.
reply
I'm thinking now that maybe lightning is possible for the small payments. Plus you can sell your liquidity. The stinker is the one chain fees but they're can also be miner pools who specify a transaction to lightning with no fee and put it into the block.
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
reply
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
I believe they recently lowered their withdrawal minimum, but I agree LN payout would be best for plebs like myself
reply
Apparently the current network EH is more like 507 than 607, but that doesn't negate the point of the write up. :)
reply
deleted by author
reply
Expensive to perform, high liquidity requirement, little demand
reply
  1. lolwut
  2. so? the liquidity is used so it shouldnt matter
  3. little demand because people are just turning their S9s off because they don't think there is hope. This needs to be a marketing thing from their end to bring the plebs back.
reply
The reasons I listed are generalizations of why pools haven't yet from what I've seen in my direct experience ;)
  1. Relative to onchain payouts, where the pool just needs an address, LN requires additional components on both pool and client side
  2. 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!
  3. Consumer demand is generally easier to sell to corporate team than notion of creating demand
reply
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
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.
reply
I get what you're saying.
  1. 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.
  2. 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.
  3. 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
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.