“`html
Bitcoin mining has evolved significantly from the era of GPUs and home setups. Throughout this period, miners have improved in numerous ways. For instance, ASICs have now become the norm, replacing GPUs. Moreover, professional-grade entities have joined the arena, unlocking new possibilities and bringing along the scale and institutional acknowledgment that grants access to otherwise inaccessible regions for smaller miners. Presently, the mining environment is characterized by grid services, curtailment tactics, and energy market involvement, which are now fundamental strategies rather than mere exceptions. As the surroundings have progressed, one query persists among miners: can PPLNS evolve?
Numerous miners, especially those closely collaborating with energy suppliers or implementing Demand Response methods, have begun to regard PPLNS with skepticism. They fear it penalizes inactivity and only rewards steady hashrate—a poor arrangement for those who frequently reduce machine output to assist the grid or provide other utility.
This apprehension isn’t unfounded. It stems from a crucial moment in the mining sector’s recent history, one that seemingly solidified the stance against PPLNS-style payouts: the fallout between RIOT and Braiins Pool.
At that time, Braiins was utilizing the Score payout approach. Established in 2011 by Slush himself, Score was developed to address the issue of pool hopping—when miners shift between pools to exploit reward frameworks. There’s also been a fallacy that Score operates as a PPLNS-style payment system, but as Rosenfeld’s guide on pool payout systems describes, Score and PPLNS are distinctly separate payout methods. The primary distinction lies in how they compute shares; specifically, Score adopted a rolling window with an exponential decay function, effectively shortening the lookback period. Conversely, PPLNS encompasses a variety of payout systems with different fixed-length lookback parameters.
As demonstrated on this preserved website illustrating how Score functioned, you can observe that after 90 minutes, your hashrate no longer influences the pool. This indicates that the instant a miner commences mining, their share of rewards rapidly achieves the fair value of their hashrate. Conversely, when a miner halts mining, it declines just as swiftly, as depicted in the animation below.
This might have been effective in the days of free spirits and hackers, but it was never intended for the intricate mining conditions of today. Certainly not with Demand Response, where miners strategically and profitably deactivate machines to stabilize energy grids or enter ancillary markets. To Score, that behavior seems no different than a pool hopper—someone trying to manipulate the system.
Thus, when RIOT departed from Braiins, citing worries regarding payout mechanics, it caused ripples throughout the mining community. Due to the aforementioned misunderstanding, the flaws of the Score system were unfairly projected onto a broader category of payouts, with PPLNS caught in the crossfire, resulting in the industry collectively discarding valuable methods.
Yet the mining landscape has transformed, and it’s time for the phoenix to rise from its ashes.
SLICE: A Payout Methodology for the 21st Century Grid
Introducing SLICE, a contemporary, open-source Stratum-V2-compatible payout system developed by the DMND team. It represents an enhancement and evolution of PPLNS, reconsidering how miners receive payments, how rewards are computed, and —most significantly—how downtime is regarded in relation to Score. All while maintaining the miner’s entitlement to create their own block templates with SV2.
At its essence, SLICE emphasizes fairness and transparency. It retains the foundational principle of PPLNS—compensating miners in relation to their actual contributions to block resolution—while refining it for today’s decentralized mining landscape.
The primary innovation resides in how SLICE organizes reward computation and manages the lookback window. Instead of perceiving the entire pool as a single entity, SLICE segments time into smaller, dynamic “slices” of work to accurately allocate the fee component. These slices denote batches of shares submitted over a defined period, where we adjust for the fee amounts in the mempool, comparing and assessing various job templates for their financial worth. When a block is discovered, SLICE distributes the block subsidy and transaction fees separately. The subsidy is allocated in proportion to hashrate, while fees are disseminated based on both hashrate and their financial merit.
This is particularly pertinent in a scenario where miners can choose their transaction selections. Some might favor high-fee MEV-style bundles, while others may opt out of particular transaction types for ideological, political, or technical reasons. SLICE guarantees that, within each slice, miners are compensated based on both the volume and caliber of their efforts—without penalizing them for inactivity or strategic energy choices. For those interested in further information, this piece may provide useful insights.
Demand Response Without Penalty
What makes SLICE particularly appealing for miners involved in Demand Response or curtailment schemes is its approach of not penalizing them for temporary offline status.
This is because SLICE does not diminish your payout simply because you paused operations. Your shares remain active in the PPLNS window—the rolling window of recent efforts that qualify for payouts—as long as they remain recent enough. In this manner, each share is treated autonomously, and is anticipated to receive 8 payouts, given that SLICE employs an 8-block rolling window; each valid share stays eligible for payout across the subsequent 8 blocks on average. This ensures that regardless of the pool’s size, you will never face the dreadful luck of experiencing unlucky days without a block, disconnection, the pool finding a block, and not receiving compensation.
This allows miners to reduce power during peak demand intervals, support their regional grid, and still garner their fair share from blocks mined after they restart, critically, even while they’re offline, as long as their shares are still within the window. In essence, if the pool encounters a stretch of bad luck, and then the miner is activated to perform demand response and powers down, even if the pool finds a block during their inactivity, that miner will receive their fair portion for all the time they were operational. This is because each share generated during that timeframe will remain active and compensated for an average of 8 blocks.
This is not a workaround; it is the intended feature. It renders SLICE entirely compatible with modern energy strategies that necessitate flexibility, whether you’re engaging in frequency regulation markets, reducing output during grid crises, or simply optimizing for lower pricing during off-peak hours.
For instance, let’s consider a scenario where a miner is partaking in a pool, and the pool has yet to discover that day’s block. This implies that the pool hasn’t unearthed the block yet, and therefore the miners haven’t been compensated for that day. Now, if the miner halts operations to offer ancillary services during peak summer load for a few hours, within that window, the pool finds the block. In a Score-based pool, the miner would not receive any Sat of that after 90 minutes, once the decay fully sets in. However, even if the pool finds a block 30 minutes later,
“““html
On account of the rapid decline, the miner would hardly observe anything. Conversely, the miner would have all of the shares they mined throughout the day receive compensation, as each share receives on average eight payments. Consequently, the miner would gain in favorable periods and not face penalties during adverse times.
Payment Clarity and Verifiability
Additionally, SLICE not only enhances payout equity—it achieves this in a manner that reduces reliance on the pool operator. Each slice is completely verifiable. Every share is monitored, cataloged, and publicly confirmable by any miner, enabling miners to independently authenticate their portion of the block reward. There’s no concealed process, no “trust me, buddy.”
If the pool operator attempts to deceive—say, by introducing fraudulent shares to dilute earnings—miners can contest the authenticity of the slice. The Job Declaration extension to Stratum V2, which SLICE depends on, incorporates methods for publishing share data, validating Merkle roots, and ensuring that each share aligns with actual computational efforts.
For miners who value decentralization, SLICE is not merely a payout system—it’s a tool for accountability.
From Reactive to Proactive
The transition from Score to SLICE signifies more than just a technical enhancement. It represents a change in mindset. Mining pools no longer need to protect against malicious actors by punishing all participants. Instead, they can organize payouts that mirror reality: miners are skilled contributors involved not only in the Bitcoin blockchain but also in the energy sector.
With SLICE, PPLNS transitions from being a burden to a strategic benefit. It facilitates improved revenue generation, enhanced transparency and verifiability, and seamless integration with grid services.
In a context where uptime is discretionary, yet fairness is essential, that’s precisely what enterprise-level miners require—a strategic pool partner that advances and innovates, bringing the future to the present and allowing miners to earn more with identical hardware.
This is a guest post by General Kenobi. The views expressed are solely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Source link
“`
