Using mpsc to send blocks to threads might cause a backlog if threads are slow to poll the channel. As a result, threads might try to solve outdated blocks, and in the extreme case, the channel will fill up, and this affected the RPC behavior

This mostly affected GPU threads, where polling was slower

I run the command sudo ./kaspa-miner --mining-address XXX in terminal, show "command not found", but I run the official miner ,no error, I'm confus with this problem

ubuntu@ubuntu01:~/kaspa/bin$ sudo ./kaspaminer --miningaddr kaspa:qpfa96cgmdqlptpv2k22ew0rjvn6jpf28jzdfpz62s6yf8yhumt86vq.........
2022-02-24 22:57:22.563 [INF] KSMN: Version 0.11.11
2022-02-24 22:57:22.570 [INF] KSMN: Connected to localhost:16110
2022-02-24 22:57:22.570 [INF] KSMN: Minimum average time per 10 blocks: 5s, smaller minimum time per block: 50ms
2022-02-24 22:57:22.571 [INF] KSMN: Waiting for the initial template
2022-02-24 22:57:32.571 [INF] KSMN: Current hash rate is 51.51 Khash/s
2022-02-24 22:57:42.571 [INF] KSMN: Current hash rate is 53.71 Khash/s


ubuntu@ubuntu01:~/kaspa/bin$ sudo ./kaspa-miner --mining-address kaspa:qpfa96cgmdqlptpv2k22ew0rjvn6jpf28jzdfpz62s6yf8yhumt86vq........
sudo: ./kaspa-miner: command not found

Connect the new miner 0.1.1 and began to create blocks many blocks and closed, the kaspa client says that they are orphans and you have no parents and keeps looking.

I don't speak rust so it'll take me forever to implement, but if you pass the target to heavy_hash then you you can stop populating the result as soon as it becomes clearly larger

let data: [u8; 32] = array_from_fn(|i| hash[i] ^ ((product[i * 2] << 4) as u8 | product[2 * i + 1] as u8));

Same for matrix multiplication right above it. So overall - do one row multiplication, then calculate one byte of data, compare to byte in target and continue only if necessary.

Please fix this part of a "Usage":

To start mining you just need to run the following: ./kaspa-miner --mining-address kaspa:XXXXX This will run the miner on all the available CPU cores.

The watch channel is kept inside regular CPU threads, not async tasks. so because of that using a tokio::watch channel required keeping a runtime for each CPU worker, which kinda sucks. also the block_on implementation had a lot of overhead.

This implementation assumes T: Clone (which is true for our case), and allows you to block on new states using non-async regular sync primitives.

Hello, i get this error after try to start kaspa-miner in ubuntu 22.04:

Error: tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("tcp connect error", Os { code: 111, kind: ConnectionRefused, message: "Connection refused" })))

any solutions?

Miner won't work like descripted with the acc-pool.pw Don't know the problem. Using wallet from the kdx.app. It's also not starting when connecting a mining rig to the Kaspa Node from KDX app.

Compiling hyper v0.14.16 Compiling hyper-timeout v0.4.1 Compiling tonic v0.6.2 error[E0433]: failed to resolve: use of undeclared crate or module keccak --> src/pow/keccak.rs:3:5 | 3 | keccak::f1600(state); | ^^^^^^ use of undeclared crate or module keccak

Using an IPv6 address results in: Error: tonic::transport::Error(Transport, InvalidUri(InvalidAuthority)) I think the address is not being enclosed in square brackets when forming the url, however my knowledge of rust is basically zero so I don't feel like patching it myself.

Miner stops if synchronization stops. Miner is not working even sync is going OK later. Please add flag such as -r for restarting miner automatically if node sync was lost.