CKB mining Decentralization Rewarder
Let me say this right off the bat: I would make the development and implementation contingent on the approval of the Spark program NNCBN, since otherwise I won’t have the necessary hardware.
Nevertheless, I make a clear distinction between the two ideas: first, the Spark program must be completed; next, the existing boot node can be considered for further decentralization concepts. It would be a learning process and an opportunity for me—I’m not a programmer.
If, in the meantime, someone picks up on the idea and works on it—or even implements it—I’m not opposed to that; the point here is first and foremost to share the idea and discuss it. The network’s success—and the decentralization that comes with it—is the top priority. I may not be the best person to work on this, but I would do it with passion and conviction. Please keep the discussion here in the forum for the sake of transparency.
GPT-5.6
My idea is technically feasible and could create a measurable incentive for solo mining. The main challenge is reliably identifying the miner address and avoiding false positives, because a pool may pay miners through addresses that are not obvious pool addresses.
+10% for Coinbase of solo-miners from DAO
A daemon monitors the Nervos CKB mainnet, detects newly mined blocks, and inspects each block’s coinbase transaction. After the block reaches a confirmation depth of at least 16 blocks, the daemon extracts the coinbase recipient address and calculates the miner’s estimated network share.
The daemon maintains a regularly refreshed list of known mining-pool addresses and their distribution data. This list should preferably be obtained from the backend/API or data source used by the Explorer’s miner-address-distribution chart, rather than by scraping the rendered Explorer.Nervos webpage.
A reward is eligible only if:
-
the coinbase recipient is not classified as a known pool address;
-
the recipient’s estimated mining share is below 1%;
-
the coinbase transaction and recipient address can be parsed unambiguously;
-
the block is at least 16 blocks deep;
-
the same block has not already been rewarded.
The reward amount is:
>reward=0.10×coinbase capacity>>reward=0.10×coinbase capacity>
Before sending, the daemon checks that the wallet has sufficient mature balance for the reward, transaction fee, and the minimum required cell capacity. It then invokes the local ckb-cli wallet or its local API server to create, sign, and broadcast a transfer to the solo miner’s address. Every processed block, decision, transaction hash, and failure is stored in a local database for auditability and replay protection.
Suggested processing flow:
for each new block:
if block_number <= last_processed_block:
continue
coinbase = parse_coinbase_transaction(block)
for each eligible coinbase output:
recipient = extract_lock_address(coinbase.output)
miner_share = lookup_distribution_share(recipient)
if (
recipient not in known_pool_addresses
and miner_share < 1%
and block_number + 16 <= current_tip
and not already_rewarded(block_hash, recipient)
):
amount = floor(coinbase_capacity * 10 / 100)
queue_reward(recipient, amount, block_hash)
process_reward_queue()
The wallet integration can use the local ckb-cli API server. Its transfer method accepts the amount in Shannon, the destination address, and a fee rate, and returns the transaction hash after broadcasting.
Important design improvements:
-
Use lock-script identity, not only textual addresses. Compare the coinbase output’s lock script and lock hash. This avoids address-format and network-prefix problems.
-
Do not trust a single distribution snapshot. Require the miner to remain below 1% across several observations or use a rolling seven-day estimate.
-
Add a minimum reward threshold. Otherwise, small coinbase outputs may not cover the transaction’s required cell capacity and fee.
-
Use a separate hot-wallet. Keep only a limited operational balance in the automatically signing wallet.
-
Require manual approval initially. Run in “dry-run” mode first and generate proposed payouts without broadcasting them.
-
Prevent self-reward loops. Exclude the reward wallet, its change addresses, and any configured related addresses.
-
Treat the 16-block rule as configurable. The daemon should verify the actual current CKB maturity rules rather than hard-code the value permanently.
-
Publish the rules and payout ledger. Transparency is important so miners can verify why they were or were not rewarded.
The strongest version would use a small community-funded reward wallet, an open-source daemon, reproducible payout rules, and a public list of every rewarded block and transaction. This makes the mechanism auditable while keeping the implementation relatively simple.