Last verified against DigiByte Core v9.26.4

DigiByte RPC: Deltas from Bitcoin Core

DigiByte Core's RPC interface is derived from Bitcoin Core — most calls (getrawtransaction, sendrawtransaction, createrawtransaction, the wallet RPCs, PSBT calls, estimatesmartfee, etc.) behave exactly as in Bitcoin Core and are not repeated here. This page documents only the deltas: the fields and calls that are new, renamed, or shaped differently because DigiByte mines with five independent proof-of-work algorithms instead of one.

Connect with the digibyte-cli binary against a synced mainnet node (RPC port 14022):

digibyte-cli getblockchaininfo

Multi-algorithm mining is the core delta

DigiByte mines with five independent PoW algorithms: sha256d, scrypt, skein, qubit, odo. Each block is mined with exactly one of the five; every RPC that reports difficulty, hashrate, or "which algo mined this" is shaped around that fact.

getblockchaininfo → per-algo difficulty lives in difficulties{}

digibyte-cli getblockchaininfo

{
  "chain": "main",
  "blocks": 23859609,
  "headers": 23859609,
  "bestblockhash": "0000000000000004df5166b65b0ae810a7364a4cc535e11c95ba1e88c347e8e4",
  "difficulty": 5402.385355490119,
  "difficulties": {
    "sha256d": 411703667.8987762,
    "scrypt": 132988.4266941861,
    "skein": 6699334.941262491,
    "qubit": 758611.3315191893,
    "odo": 179804.9774175665
  },
  "verificationprogress": 0.9999999694937327,
  "chainwork": "0000000000000000000000000000000000000000001d2a8a547f709e6b41834c",
  "pruned": false
}

The five algo keys are exactly sha256d, scrypt, skein, qubit, odo — there are no flat difficulty_<algo> keys; the per-algo numbers only exist nested under difficulties.

A flat top-level difficulty field is also present (5402.385355490119 above), but it does not correspond to any single algo's per-algo value. Treat difficulties{} as the authoritative per-algo source: the DigiScope block explorer reads difficulties directly and only falls back to the flat difficulty when a per-algo key is missing, so in practice the flat field is a legacy fallback, not "the current algo's difficulty."

No connections field exists on getblockchaininfo in this version — that is a Bitcoin-Core habit that does not carry over here. Peer count comes from getnetworkinfo or getconnectioncount (below).

getblockheader / getblock → pow_algo / pow_algo_id / pow_hash

digibyte-cli getblockheader $(digibyte-cli getbestblockhash)

{
  "hash": "1ca25878991b883ab38a2f4e4094bb4842280069bf006709a26f7c20de80eab2",
  "height": 23859610,
  "bits": "1a026fe2",
  "difficulty": 6884148.230962846,
  "pow_algo_id": 3,
  "pow_algo": "skein",
  "chainwork": "0000000000000000000000000000000000000000001d2a8a647db2c1f4c335cc",
  "previousblockhash": "0000000000000004df5166b65b0ae810a7364a4cc535e11c95ba1e88c347e8e4"
}

getblock returns everything getblockheader does, plus pow_hash — the actual proof-of-work hash for that algorithm, distinct from hash (the block's SHA256d identity hash used for chain linkage):

digibyte-cli getblock $(digibyte-cli getbestblockhash)

{
  "hash": "70bc517d0b7a3c5b1b5997ad5e3a8da1a0afcef3c6f2a267df1ae003db29cf7e",
  "height": 23859612,
  "bits": "1a02615a",
  "difficulty": 7048315.002884726,
  "pow_algo_id": 3,
  "pow_algo": "skein",
  "pow_hash": "00000000000002375564d39ccc19b97fc55c2f94cf633be47d94b7909ac3606c",
  "nTx": 1
}

Current pow_algo_id ↔ pow_algo mappings:

pow_algo_id pow_algo
0 sha256d
1 scrypt
3 skein
4 qubit
7 odo

The IDs are not contiguous: the gaps (2, 5, 6) belong to algorithms retired earlier in DigiByte's history. Do not treat the ID space as a dense 0–4 enum — key on the pow_algo name string instead, exactly as the block explorer does.

getmininginfo → per-algo shape

digibyte-cli getmininginfo

{
  "blocks": 23859610,
  "pow_algo_id": 1,
  "pow_algo": "scrypt",
  "difficulty": 132988.4266941861,
  "difficulties": {
    "sha256d": 411703667.8987762,
    "scrypt": 132988.4266941861,
    "skein": 6884148.230962846,
    "qubit": 758611.3315191893,
    "odo": 179804.9774175665
  },
  "networkhashesps": {
    "sha256d": 2.631029964861954e+16,
    "scrypt": 10711561829708.32,
    "skein": 573909156054721.6,
    "qubit": 49186662167255.77,
    "odo": 12171661202655.06
  },
  "networkhashps": 10711561829708.32,
  "pooledtx": 0,
  "chain": "main"
}

Note two distinct hashrate fields that are easy to confuse: networkhashesps (plural "hashes", an object — per-algo network hashrate) versus networkhashps (singular, a flat number — the hashrate for whichever algo pow_algo/pow_algo_id at the top of this same response refers to).

getdifficulty — returns an object, not a bare number

In Bitcoin Core, getdifficulty returns a plain number. On this node it returns an object wrapping the same difficulties{} map seen above:

digibyte-cli getdifficulty

{
  "difficulties": {
    "sha256d": 411703667.8987762,
    "scrypt": 132988.4266941861,
    "skein": 6884148.230962846,
    "qubit": 758611.3315191893,
    "odo": 179804.9774175665
  }
}

getnetworkhashps takes an algo parameter — default is scrypt, not sha256d

digibyte-cli getnetworkhashps 120 -1 sha256d

27704303206693.12

Per digibyte-cli help getnetworkhashps, the third argument is algo (string, optional, default="scrypt"). Calling getnetworkhashps with no arguments returns the scrypt estimate, not a combined or sha256d figure — confirmed live: the no-argument call and the explicit ... scrypt call return matching values, while ... sha256d and ... odo return values matching their respective networkhashesps entries from getmininginfo above.

Node version: read it from getnetworkinfo.subversion

There is no separate "get version" RPC. Read the running node's version string from subversion in getnetworkinfo:

digibyte-cli getnetworkinfo

{
  "version": 92604,
  "subversion": "/DigiByte:9.26.4/",
  "protocolversion": 70019,
  "connections": 124,
  "connections_in": 106,
  "connections_out": 18
}

subversion ("/DigiByte:9.26.4/" above) is the human-readable version string. version is the same information as an integer (92604 ⇒ 9.26.4).

Peer count: getconnectioncount, not getblockchaininfo

digibyte-cli getconnectioncount

124

getnetworkinfo.connections reports the same total (124 above), further broken out into connections_in (106) and connections_out (18). getblockchaininfo has no connections field — confirmed above; do not look for peer count there.

DigiAssets are not core RPC

DigiAsset data (assets, IPFS metadata, holders) is not served by digibyte-cli at all. It comes from a separate DigiAsset Core service with its own RPC interface (default port 14024). Do not search the core node's help output for asset-related calls — there aren't any.

Other DigiByte-specific command groups (surfaced, not detailed here)

digibyte-cli help shows several DigiByte-specific top-level sections beyond the ones above. Out of scope for this page, but worth knowing they exist so you don't assume they're missing:

Related

View raw markdown