search

OCEAN-xyz / datum_gateway

Decentralized Alternative Templates for Universal Mining
Other
39 stars 11 forks source link

Behavior inconsistency for non-pooled mining #38

Open wizkid057 opened 2 weeks ago

wizkid057 commented 2 weeks ago

https://github.com/OCEAN-xyz/datum_gateway/blob/665aa787950260ae5054ae562783186f0b165f67/src/datum_gateway.c#L174

Basically if the host is blank, but pooled_mining_only is not set to false, there's inconsistency here. The datum protocol will try to connect to nothing, and the dashboard will show a green status even though its rejecting stratum connections.

Should probably just reject startup in datum_config.c if host is blank but pooled_mining_only is true.

BitcoinMechanic commented 2 weeks ago

A more intuitive approach might be to have "modes" - pooled or lottery. Lottery at the moment feels like something you do when something else breaks rather than intentionally. If you enter a pool url that'd be kind of irrelevant unless you switch back to pooled mode (and there can be an additional failover-to-lottery boolean).

wizkid057 commented 2 weeks ago

There's several possible configs:

Currently "Non-pooled ONLY" requires setting pooled_mining_only to false AND setting the pool_host to null/"" explicitly.

The bug I opened the issue for is that you can set the pool host to null/"" but not set pooled_mining_only to false and the gateway will continue to try and connect to the pool while rejecting stratum clients all while showing good to go for non-pooled on the dashboard.

Behavior just needs to be more consistent, and possibly be more clear about how to achieve one of the three configs above.