win.32 - DigiAssetPoolServer.exe Phase 1 + honest Payment row
Headline: the first real tool for getting off mctrivia's dead pool server
win.32 ships a new optional executable, DigiAssetPoolServer.exe, that re-implements the exact wire protocol mctrivia's original pool server uses so the Windows fork's client can register payout addresses and fetch the permanent asset list from a pool YOU run, on the same Windows box as DigiByte Core and DigiAssetCore.
This is not yet full "DGB flowing to node operators" — that's Phase 3, still to come — but it is the first time a Windows operator can stop depending on an unreachable third-party server. Every part of the protocol loop except automated payout distribution is working end-to-end, verified both when the pool declares payouts enabled and when it declares them disabled.
New binary: DigiAssetPoolServer.exe
Ships alongside DigiAssetCore.exe and DigiAssetCore-cli.exe in the release zip. Completely optional — only operators who want to run their own pool need it. Same C++ toolchain, same Boost, same SQLite amalgamation, no new language or build dependency.
Running it:
cd C:\path\to\unpacked\release
.\DigiAssetPoolServer.exe
On first launch it:
-
Creates a local
pool.dbSQLite database in the current directory. -
Snapshots mctrivia's current
/permanent/0..23.jsonpages into that database so the pool has an immediately usable canonical asset list (about 7,800 entries). -
Opens a minimal TUI dashboard showing listening port, registered node count, permanent asset count, payouts config state, and uptime.
-
Listens on port 14028 (configurable via
poolpayouts/poolportinpool.cfg) and serves:GET /permanent/<page>.jsonPOST /list/<floor>.jsonPOST /keepaliveGET /nodes.jsonGET /map.jsonGET /bad.json
The endpoint shapes match mctrivia's protocol so both the win.32 C++ client and the legacy NodeJS digiasset_node client can connect to it unchanged.
Point the client at your pool
Add one line to the DigiAssetCore config.cfg:
psp1server=http://127.0.0.1:14028
Default (absent) remains https://ipfs.digiassetx.com for upstream compatibility. When present, every /permanent, /list, /keepalive, and /bad.json call the client makes goes to your pool instead.
Honest Payment: dashboard row
Before this release, the DigiAssetCore dashboard printed green Payment: active the moment any pool server accepted a /list registration request. That meant pointing at a brand-new DigiAssetPoolServer with poolpayouts=0 (which is the default!) would falsely tell the operator they were earning DGB when in reality no money was flowing anywhere. Not shipping that.
The pool server now emits {"payoutsEnabled": false} or {"payoutsEnabled": true} in its /list response body. The client parses it and the dashboard renders four distinct states:
| Pool state | Dashboard |
|---|---|
/list returns 200 with payoutsEnabled: true |
Payment: active (green) |
/list returns 200 with payoutsEnabled: false |
Payment: registered (no payouts yet) (yellow) + explanation |
/list returns 500 or fails |
Payment: unavailable (red) + "pool payment service offline" |
| no probe yet | Payment: checking... (dim) |
On the pool server side, setting poolpayouts=1 in pool.cfg additionally prints a pre-dashboard warning block to stdout reminding the operator that Phase 3 automated distribution has not shipped — flipping the flag on advertises "paying" to every client without DGB actually moving. That's a deliberate and explicit foot-gun guard.
Pool server dashboard
The pool server has its own minimal TUI dashboard so the operator always sees the live state of their pool without needing to inspect the database:
DigiAsset Pool Server (experimental) - Phase 1
------------------------------------------------------------------------------------------
Listening: Port 14028 Requests: 4
Registered: 1 nodes Active (1h): 1 nodes
Permanent: 3,442 assets / 24 pages
Payouts: disabled (clients see 'registered (no payouts yet)')
Time: 22:17:42 Uptime: 0 min 44 sec
Key hints: [Q] Quit [N] Nodes [A] Assets [P] Pending Payouts [E] Execute Payout [H] Help. The [P] and [E] key handlers are placeholders for Phase 3 — pressing them today prints an informational log line explaining Phase 3 is not yet implemented.
Bug fix: keepalive log line no longer lies
DigiAssetCore's keepalive log message previously hardcoded "Reported online to ipfs.digiassetx.com" even when it was actually talking to a local pool. Now uses _baseUrl so the log reflects reality:
INFO: Reported online to http://127.0.0.1:14028 (server id: /ip4/...)
Expanded [H] help
Pressing H in the DigiAssetCore dashboard now explains all four Payment: states in plain English and documents the psp1server config key so first-time operators know how to point at a different pool.
End-to-end smoke test, both branches
Before shipping, verified:
poolpayouts=0(default): pool dashboard shows yellowdisabled, client dashboard shows yellowregistered (no payouts yet) - pool operator has not enabled payouts.poolpayouts=1: pool dashboard shows greenENABLED, client dashboard flips to greenactivewithin the next/listprobe interval (or on client restart).- Pool server's
Requests:counter increments as the client hits/keepalive,/permanent/23.json, and/list/<floor>.jsonon the normal cadence. - First-run snapshot successfully imported all 24 pages from mctrivia into the local pool.db (about 7,800 entries, dominated by two fat pages at 3,115 and 1,032 entries).
Known limitations
- Phase 2 (dial-back verification) of registered peers is not yet built. Any client that POSTs
/listgets markedregistered; the pool does not verify they are actually serving the assets they claim. - Phase 3 (operator-approved automated payout distribution) via local DigiByte Core RPC is not yet built.
poolpayouts=1makes clients report "active" but DGB must still be sent manually fromdigibyte-qtif the operator wants to pay out today. The pool'spayouts_ledgerSQLite table is stubbed and will be the basis for aDigiAssetPoolServer.exe payoutCLI subcommand in a later release. - mctrivia's original pool server at
ipfs.digiassetx.comis still broken for payouts and this release does not and cannot fix that. The whole point of the new server is to route around the dead upstream.
Files in this release
DigiAssetCore-0.3.0-win.32-x64.zip— all three exes in a folderDigiAssetCore.exe— main client (2,461,696 bytes)DigiAssetCore-cli.exe— JSON-RPC CLI (328,704 bytes)DigiAssetPoolServer.exe— new optional pool server (1,245,696 bytes)