Request for official GitHub / docs integration: community GPU miner (OpenCL + CUDA)

[Moskyera]

Summary

Hi jojoin and Hacash maintainers,

We maintain a community miner based on this repository (fullnodedev):

• HAC: OpenCL (AMD / NVIDIA / Intel) and CUDA workers
• HACD: CPU-only (no OpenCL dependency)
• Windows and Linux packaging, one-click setup scripts, and a GUI miner panel

We do not claim to be the official Hacash team. Community members suggested we contact you first and request official GitHub or docs integration before any community funding drive.

Links

Item	URL
Community fork	https://github.com/Moskyera/fullnodedev
Latest release (CUDA + OpenCL RC)	https://github.com/Moskyera/fullnodedev/releases/tag/v0.4.1-opencl-cuda-rc.11
All releases	https://github.com/Moskyera/fullnodedev/releases
Simple download page	https://moskyera.github.io
Upstream (this repo)	https://github.com/hacash/fullnodedev

What we ask for

1. Guidance on the preferred path (PR into official repos vs listed as a community tool)
2. A review checklist for compatibility with fullnode 1.0.x and post-Istanbul mainnet (height >= 765432)
3. If you accept it, a link from official miner docs, hacash.org miner page, and/or release notes

What we can do

• Open PRs toward official trees if that is preferred
• Adjust branding so it is clearly community until listed by the org
• Follow any security, license, or review process you require
• Provide build notes, smoke tests, and GPU hashrate notes on request

Scope note

This request is about integration and review, not about funding. Any economic support would only be discussed after a clear official or community-listed path, if you think that is appropriate.

Thank you for your time and for maintaining the Hacash fullnode stack.

cc @jojoin

[Moskyera]

Progress update (community 6 requirements)

We started integrating the six requirements into the Moskyera/fullnodedev tree.

#	Requirement	Status
1	Stratum + free IP pool	v1 shipped in-tree as crate \miner-pool\ / binary \hac-pool\ (HTTP miner-RPC proxy on free IP + minimal Stratum TCP)
2	New CUDA versions	Validated on NVIDIA Tesla T4 (Colab): \cargo test -p x16rs-cuda --features cuda\ = 4 passed
3	Official open-source libraries	Still based on this \ullnodedev\ tree; requesting preferred merge/list path
4	Diaworker + Poworker	Already present in packages
5	Anyone can broadcast a public pool	v1: anyone runs \hac-pool --http-bind 0.0.0.0:3333\ and points workers at it
6	JoJoin rebuild on fullnode updates	Rebuild recipe documented: \docs/JOJOIN-REBUILD.md\ (needs official process ownership)

Docs

• \docs/COMMUNITY-REQUIREMENTS.md\
• \docs/PUBLIC-POOL.md\
• \docs/JOJOIN-REBUILD.md\
• \docs/MINING-NVIDIA-CUDA.md\ (T4 evidence)

Limits (honest)

• Pool v1 is a work proxy (no PPS/share accounting yet).
• Existing \poworker\ uses HTTP pool port (zero worker change). Stratum is available for multi-client experiments.
• We still want your guidance on official listing vs PR path.

Happy to adjust naming, ports, or protocol details to match official preference.

[jojoin]

We’ll soon release a new full-node version with an improved architecture, and all future updates will be based on this new version. The dev version, due to its messy patch-on-patch structure, will be archived. Please wait for the new release.

[Moskyera]

we have upgrade the miner and we make a new pool for mining with some Istanbul features, we work to finish it. please inform us for the new release .

[Moskyera]

Update on the community GPU miner, plus one node bug that affects hacash/fullnodedev
directly and is worth looking at regardless of anything else here.

A sync bug in the node, independent of the miner

In node/src/core/protocol.rs, a failed sync batch ends the sync permanently:

if let Err(e) = res { println!("{}", e); return; }

Nothing ever requests another batch. We hit this on a real mainnet sync: one
[Block Sync Warning] insert 446201 failed: diamond status HTAKES not found and
the node sat at that height for hours, answering its RPC and looking healthy,
while the chain moved on. Only a restart advanced it, and then it stopped again
short of the tip.

This is worse than a stall, because a miner pointed at such a node hashes against
blocks the network settled long ago, and block_hash_repeat (height / 50000 + 1,
capped at 16) is smaller down there, so the miner reports a HIGHER hashrate than
normal. It reads as success while nothing is earned. That is how we found it: an
operator asked why a card showed 215 MH/s.

Our fix resumes from the chain's actual head after a pause, so a transient failure
recovers and a permanent one keeps reporting instead of going silent. Happy to
open a PR against your repo with just that change if it is useful.

What we have NOT found is the cause of the HTAKES error itself. We first suspected
fast_sync, then tested it properly: a clean sync from zero with fast_sync = true
reached the tip with zero warnings, so that hypothesis is withdrawn. The trigger is
still unknown.

The miner

Latest release: https://github.com/Moskyera/fullnodedev/releases/tag/v0.5.3

Verified on hardware rather than argued for:

• Consensus: 767,758 mainnet blocks and 133,737 diamonds validated with zero
  divergence from the live chain. No consensus code was changed.
• NVIDIA CUDA, end to end against a real pool at mainnet difficulty (block cost
  2^42): the card took 99.76% of the PPLNS window while holding 99.697% of the
  hashrate, measured against a single CPU thread in the same window.
• AMD OpenCL: same measurement on a gfx1201.
• Kernels pinned byte for byte against the CPU implementation by differential
  tests that run on a real device, at repeat 1 and repeat 16.
• HACD stays CPU only, and the release build fails if hacash or diaworker
  links libOpenCL at all.
• Windows and Linux x86_64 releases, signed with GitHub build provenance.

There is also a PPLNS payout pool (HBIT) in the same repository, packaged
separately, with the terms it serves published at its own /terms endpoint.

Happy to split any of this into focused PRs, or to keep it as a community
distribution and just track your releases. Whichever suits the project.