Hello. The Solo Mining Census says that a missing pool can be suggested, so I would like to ask how you want to treat a Hybrid Solo model before proposing any code change.
BTC PoW Lab publishes a fresh public JSON endpoint here:
https://btcpowlab-pool.com/public/v1/pool
The endpoint currently exposes generated_at, pool.active_miners, pool.active_workers, pool.hashrate_1h_ths, pool.hashrate_15m_ths, pool.hashrate_5m_ths, pool.accepted_shares, pool.network_blocks and network.difficulty. Hashrate values are expressed in TH/s. The response also states backend and Bitcoin template availability.
The economic model is not pure solo. A valid block allocates 85 percent to the finder, 10 percent to eligible community participants and 5 percent to BTC PoW Lab. The public response exposes those values under economics. For that reason I do not want to imply that it belongs in the same category as a pool where the finder receives the complete reward.
Would you consider one of these approaches appropriate for the census?
Include it with an explicit Hybrid Solo model label and the 85 / 10 / 5 allocation visible beside the fee field.
List it as out of scope with a short reason so readers understand why a live Bitcoin pool with public statistics is absent.
If inclusion fits the census methodology, I can prepare a small collector change using only the public endpoint and the fields above. I will follow your preferred naming and hashrate window.
Transparency: I am Carlos Monzon from Power CM Software and I operate BTC PoW Lab. This proposal comes from that direct relationship. There is no paid placement or reciprocal arrangement.
Hello. The Solo Mining Census says that a missing pool can be suggested, so I would like to ask how you want to treat a Hybrid Solo model before proposing any code change.
BTC PoW Lab publishes a fresh public JSON endpoint here:
https://btcpowlab-pool.com/public/v1/pool
The endpoint currently exposes generated_at, pool.active_miners, pool.active_workers, pool.hashrate_1h_ths, pool.hashrate_15m_ths, pool.hashrate_5m_ths, pool.accepted_shares, pool.network_blocks and network.difficulty. Hashrate values are expressed in TH/s. The response also states backend and Bitcoin template availability.
The economic model is not pure solo. A valid block allocates 85 percent to the finder, 10 percent to eligible community participants and 5 percent to BTC PoW Lab. The public response exposes those values under economics. For that reason I do not want to imply that it belongs in the same category as a pool where the finder receives the complete reward.
Would you consider one of these approaches appropriate for the census?
Include it with an explicit Hybrid Solo model label and the 85 / 10 / 5 allocation visible beside the fee field.
List it as out of scope with a short reason so readers understand why a live Bitcoin pool with public statistics is absent.
If inclusion fits the census methodology, I can prepare a small collector change using only the public endpoint and the fields above. I will follow your preferred naming and hashrate window.
Transparency: I am Carlos Monzon from Power CM Software and I operate BTC PoW Lab. This proposal comes from that direct relationship. There is no paid placement or reciprocal arrangement.