Skip to content

Conversation

@JaredTate
Copy link

Fix: getmininginfo difficulty field always returns Groestl difficulty (Issue #346)

Summary

Fixes #346 - The difficulty field in getmininginfo RPC was returning a frozen/incorrect value because it was always querying Groestl's difficulty instead of the current mining algorithm's difficulty.

Problem Description

In DigiByte v8.26.1, users reported that the difficulty field in the getmininginfo RPC method displays a frozen value that doesn't update correctly. The difficulties field (plural) works as expected, but the singular difficulty field was broken.

Root Cause

During the Bitcoin Core v26.2 merge, the GetDifficulty() call in getmininginfo lost the algorithm parameter.

In v8.22.2 (working):

obj.pushKV("difficulty", (double)GetDifficulty(tip, NULL, miningAlgo));

In v8.26.1 (broken):

obj.pushKV("difficulty", (double)GetDifficulty(tip));

Since DigiByte's GetDifficulty() function signature is:

double GetDifficulty(const CBlockIndex* tip = NULL, const CBlockIndex* blockindex = nullptr, int algo = 2);

When called with only one parameter, algo defaults to 2 (ALGO_GROESTL), causing it to always return Groestl's difficulty regardless of the user's configured mining algorithm.

Changes Made

  • File: src/rpc/mining.cpp
  • Line 526: Restored the miningAlgo parameter to the GetDifficulty() call
  • Change: GetDifficulty(tip)GetDifficulty(tip, nullptr, miningAlgo)

Testing

This fix ensures that:

  1. The difficulty field returns the difficulty for the current mining algorithm (as set by -miningalgo)
  2. Behavior matches DigiByte v8.22.2
  3. The field updates correctly as blocks arrive for different algorithms

Test commands:

# Test with different algorithms
digibyted -miningalgo=sha256d
digibyte-cli getmininginfo | jq '.difficulty'

digibyted -miningalgo=scrypt
digibyte-cli getmininginfo | jq '.difficulty'

# Verify difficulty matches the corresponding value in difficulties object
digibyte-cli getmininginfo | jq '{difficulty, difficulties}'

Impact

  • Severity: Medium - Affects mining operations and monitoring
  • Affected versions: DigiByte v8.26.0, v8.26.1
  • Scope: Users running any algorithm other than Groestl see incorrect difficulty values

Additional Context

This is a regression introduced during the Bitcoin Core v26.2 merge. It highlights the importance of preserving DigiByte-specific multi-algorithm functionality when integrating upstream Bitcoin changes. The difficulties field was unaffected because it explicitly iterates through all algorithms with the correct parameters.


Repository: DigiByte-Core/digibyte
Branch: claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B
Target: develop
Commit: c6f3663

Create PR Link:

https://github.com/DigiByte-Core/digibyte/compare/develop...claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B?expand=1

@ycagel ycagel requested review from SmartArray, digicontributer, gto90 and ycagel and removed request for SmartArray, digicontributer, gto90 and ycagel November 18, 2025 00:30
@gto90 gto90 force-pushed the claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B branch from 290117f to b2107ed Compare November 23, 2025 21:41
@gto90 gto90 requested a review from Copilot November 23, 2025 21:43
@gto90 gto90 added the bug Something isn't working label Nov 23, 2025
Copilot finished reviewing on behalf of gto90 November 23, 2025 21:44

This comment was marked as resolved.

@gto90 gto90 force-pushed the claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B branch from ee685d0 to fca1489 Compare November 23, 2025 21:49
)

The 'difficulty' field in getmininginfo RPC was always returning Groestl's
difficulty (algo=2) instead of the current mining algorithm's difficulty.

Root cause: During Bitcoin Core v26.2 merge, the miningAlgo parameter was
lost from the GetDifficulty() call, causing it to default to Groestl.

Changes:
- src/rpc/mining.cpp: Restore miningAlgo parameter to GetDifficulty()
- test/functional: Add regression test for issue #346
- doc/ai: Move AI-generated PR documentation to dedicated directory
- ci: Fix macOS hashFiles() failure in Homebrew cache (GitHub #4134)

Fixes #346

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
@gto90 gto90 force-pushed the claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B branch from fca1489 to 9f77a4d Compare November 23, 2025 21:54
Copy link
Member

@gto90 gto90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK

Copy link
Member

@ycagel ycagel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cACK

@ycagel ycagel merged commit 7420281 into develop Nov 24, 2025
8 checks passed
@gto90 gto90 deleted the claude/investigate-digibyte-issue-018eRW2M8brZzweTZpj1e89B branch November 24, 2025 00:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: getmininginfo method not working properly

4 participants