Quantus Miner v3.0.0 — GitHub Bug Reports

[kyorozaka-dot]

Issue 1
Title:
[Bug] RTX 50-series (Blackwell) falls through to minimum workgroup dispatch
Body:
Environment
Miner version: v3.0.0
GPU: NVIDIA RTX 5060 (Blackwell, SM120)
OS: Ubuntu 24.04 LTS
Driver: NVIDIA 570.x
Backend: Vulkan (wgpu)
Description
get_vendor_specific_dispatch in crates/engine-gpu/src/lib.rs selects workgroup counts based on substring matching of the adapter name. The current checks cover:
"rtx 40" / "rtx 4090" → (max_workgroups / 8).max(4096)
"rtx 30" / "rtx 20" → (max_workgroups / 12).max(2048)
"gtx" / "rtx 16" → (max_workgroups / 16).max(1024)
else → (max_workgroups / 20).max(512)
RTX 50-series GPUs (5060, 5070, 5080, 5090) match none of these patterns and silently fall through to the else branch, capping dispatch at 512 workgroups — roughly 1/8 to 1/16 of what the hardware can handle.
Impact
RTX 5060 has 4,080 CUDA cores (comparable to RTX 4070) but is dispatched at the same level as low-end / unknown GPUs.
Users see significantly lower hash rates than expected with no warning or log message.
As RTX 50-series adoption grows, this will affect an increasing number of miners.
Suggested Fix
Add an "rtx 50" branch before the existing "rtx 40" check:
if vendor_name.contains("rtx 50") {
// Blackwell — at least as capable as Ada Lovelace (RTX 40)
(max_workgroups / 8).max(4096)
} else if vendor_name.contains("rtx 40") || vendor_name.contains("rtx 4090") {
(max_workgroups / 8).max(4096)
} else if ...
A more future-proof approach would be to parse the generation number (e.g., extract 50 from "rtx 5060") so that future architectures don't require manual patching.
References
Similar issue in vLLM: vllm-project/vllm#31085 — SM120 Blackwell not recognized in backend selection
Similar issue in FlashInfer: flashinfer-ai/flashinfer#2577 — Blackwell falls through compute capability check
Issue 2
Title:
[Bug] try_send silently drops mining jobs when worker channel is full
Body:
Environment
Miner version: v3.0.0
File: crates/miner-service/src/lib.rs
Description
In start_job, new mining jobs are dispatched to worker threads via try_send with the result explicitly discarded:
for tx in &self.job_senders {
let _ = tx.try_send(job.clone());
}
The channel capacity is 1. If a worker has not yet consumed the previous job, try_send returns Err(TrySendError::Full(_)) and the new job is silently lost. No log message, no metric, no warning.
Impact
Mining jobs can be dropped without any indication, leading to missed block rewards.
Debugging is extremely difficult because there is zero observability into dropped jobs.
Under high job turnover (e.g., fast block times or network congestion), the drop rate could be significant.
Suggested Fix
At minimum, log the failure:
for (i, tx) in self.job_senders.iter().enumerate() {
if let Err(e) = tx.try_send(job.clone()) {
log::warn!(
"Worker {} channel full — job {} dropped: {}",
i, job.job_id, e
);
}
}
For a more robust solution, consider:
Increasing the channel capacity (e.g., 4–8) to buffer bursts
Using send().await to guarantee delivery (with a timeout)
Adding a metrics counter for dropped jobs
Notes
Discarding a Result with let _ is flagged by #[must_use] in Rust for good reason. In a mining context where every job represents potential revenue, silent drops are particularly costly.
Issue 3
Title:
[Security] InsecureCertVerifier disables TLS certificate validation on QUIC connection
Body:
Environment
Miner version: v3.0.0
File: crates/miner-service/src/quic.rs
Description
The QUIC client uses a custom InsecureCertVerifier that unconditionally accepts any TLS certificate:
struct InsecureCertVerifier;

impl rustls::client::danger::ServerCertVerifier for InsecureCertVerifier {
fn verify_server_cert(&self, ...) -> Result<ServerCertVerified, Error> {
Ok(ServerCertVerified::assertion()) // accepts everything
}
}
This completely disables TLS certificate validation on the miner-to-node QUIC connection.
Impact
MITM attack: An attacker on the same network can impersonate the node, intercept mining jobs, and potentially redirect rewards to their own address.
Job injection: Crafted jobs could be fed to the miner, wasting GPU resources.
Silent exploitation: The miner has no way to detect that it is talking to a rogue server.
This is especially concerning for miners connecting to remote nodes over untrusted networks (cloud, VPS, public Wi-Fi).
Suggested Fix
Option A — Certificate pinning (recommended for local setups):
// Pin the node's self-signed certificate fingerprint
let expected_fingerprint = "sha256:abcdef...";
fn verify_server_cert(&self, cert: &Certificate, ...) -> Result<...> {
let actual = sha256(cert.as_ref());
if actual == expected_fingerprint {
Ok(ServerCertVerified::assertion())
} else {
Err(Error::General("certificate fingerprint mismatch".into()))
}
}
Option B — Full CA validation (recommended for remote nodes):
Use rustls' default WebPkiVerifier or a custom root CA.
Option C — Opt-in insecure mode (minimum viable fix):
Add an --insecure CLI flag so users explicitly opt in:
quantus-miner --node-addr ... --insecure
Log a prominent warning when --insecure is used:
⚠️ WARNING: TLS certificate verification is DISABLED. Do NOT use on untrusted networks.