validateaddress rejects a structurally valid legacy P2PKH address ("Invalid address format") in 8.26.2

[VladimirDiamandi]

Summary

validateaddress / dgb-cli validateaddress returns "isvalid": false with "error": "Invalid address format" for a legacy P2PKH (D...) address that is fully valid: correct Base58Check checksum, version byte 0x1e (mainnet PUBKEY_ADDRESS), and a 20-byte hash160 payload.

Other addresses with the identical structure (same version byte, same payload length, valid checksum) validate fine on the same binary, so this is not a broken prefix table — it looks like a content-dependent regression in Base58/address decoding.

The address has been independently verified as valid using a standard Base58Check decoder and is accepted by third-party DigiByte validators/explorers.

Version

DigiByte Core RPC client version v8.26.2

Steps to reproduce

$ dgb-cli validateaddress DGb6Ht4pBAiX7aq9JRS9bZEt1yCC7G71Zc
{
  "isvalid": false,
  "error_locations": [
  ],
  "error": "Invalid address format"
}

For comparison, two structurally identical addresses are accepted by the same binary:

$ dgb-cli validateaddress D5PDrdvGLYd6YjudwKCuCKGbahBHwXXpA2
{
  "isvalid": true,
  "address": "D5PDrdvGLYd6YjudwKCuCKGbahBHwXXpA2",
  "scriptPubKey": "76a91402abee68d11dc18c57f22427a83fe6f39c5049cf88ac",
  "isscript": false,
  "iswitness": false
}
$ dgb-cli validateaddress DJpNVpc8LF7TQMvCg1zodCfbng2WuUJxR2

{

"isvalid": true,

"address": "DJpNVpc8LF7TQMvCg1zodCfbng2WuUJxR2",

"scriptPubKey": "76a91496072dc2d9640ee593bd12b088b9c0799e90935788ac",

"isscript": false,

"iswitness": false

}

Expected behavior

The first address should validate as a legacy P2PKH address:

{
  "isvalid": true,
  "address": "DGb6Ht4pBAiX7aq9JRS9bZEt1yCC7G71Zc",
  "scriptPubKey": "76a9147d93fde076577243e53de88fbf1f24e55b25307b88ac",
  "isscript": false,
  "iswitness": false
}

Actual behavior

"isvalid": false, "error": "Invalid address format".

Why the rejected address is valid

Decoding all three addresses with a standard Base58Check decoder yields the same structure. They differ only in the hash160 payload:

Address	Accepted?	Version	hash160 (20 bytes)	Checksum
DGb6Ht4pBAiX7aq9JRS9bZEt1yCC7G71Zc	NO	0x1e	7d93fde076577243e53de88fbf1f24e55b25307b	valid
D5PDrdvGLYd6YjudwKCuCKGbahBHwXXpA2	yes	0x1e	02abee68d11dc18c57f22427a83fe6f39c5049cf	valid
DJpNVpc8LF7TQMvCg1zodCfbng2WuUJxR2	yes	0x1e	96072dc2d9640ee593bd12b088b9c0799e909357	valid

All three are 25 bytes after Base58 decode (1 version + 20 payload + 4 checksum), all use the mainnet PUBKEY_ADDRESS prefix 0x1e, and all have a correct double-SHA256 checksum. There is no homoglyph or hidden character in the rejected string — hexdump -C confirms 34 clean ASCII bytes:

$ printf '%s' 'DGb6Ht4pBAiX7aq9JRS9bZEt1yCC7G71Zc' | wc -c
34
$ printf '%s' 'DGb6Ht4pBAiX7aq9JRS9bZEt1yCC7G71Zc' | hexdump -C
00000000  44 47 62 36 48 74 34 70  42 41 69 58 37 61 71 39  |DGb6Ht4pBAiX7aq9|
00000010  4a 52 53 39 62 5a 45 74  31 79 43 43 37 47 37 31  |JRS9bZEt1yCC7G71|
00000020  5a 63                                             |Zc|

Since one 0x1e address is rejected while others are accepted, the problem is not the version-prefix configuration but appears to be a content-dependent defect in Base58/address decoding for certain payloads.

Impact

validateaddress is a foundational RPC. Exchanges, wallets, payment processors, pools, and explorers rely on it to validate destination addresses. A false negative (rejecting a valid address) can block legitimate withdrawals/payouts and break integrations. The 8.26.2 release notes explicitly advise all such operators to upgrade, which makes this regression high-priority.

Environment

• DigiByte Core: v8.26.2
• OS / platform: Ubuntu 24.04.4 LTS, kernel 6.17.0-29-generic, x86_64
• Build: official prebuilt release binary (not self-compiled) — digibyte-8.26.2-x86_64-linux-gnu.tar.gz from https://github.com/DigiByte-Core/digibyte/releases/download/v8.26.2/digibyte-8.26.2-x86_64-linux-gnu.tar.gz
• Network: mainnet