Skip to content

win.32 - DigiAssetPoolServer.exe Phase 1 + honest Payment row

Choose a tag to compare

@chopperbriano chopperbriano released this 12 Apr 03:22

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:

  1. Creates a local pool.db SQLite database in the current directory.

  2. Snapshots mctrivia's current /permanent/0..23.json pages into that database so the pool has an immediately usable canonical asset list (about 7,800 entries).

  3. Opens a minimal TUI dashboard showing listening port, registered node count, permanent asset count, payouts config state, and uptime.

  4. Listens on port 14028 (configurable via poolpayouts/poolport in pool.cfg) and serves:

    • GET /permanent/<page>.json
    • POST /list/<floor>.json
    • POST /keepalive
    • GET /nodes.json
    • GET /map.json
    • GET /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 yellow disabled, client dashboard shows yellow registered (no payouts yet) - pool operator has not enabled payouts.
  • poolpayouts=1: pool dashboard shows green ENABLED, client dashboard flips to green active within the next /list probe interval (or on client restart).
  • Pool server's Requests: counter increments as the client hits /keepalive, /permanent/23.json, and /list/<floor>.json on 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 /list gets marked registered; 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=1 makes clients report "active" but DGB must still be sent manually from digibyte-qt if the operator wants to pay out today. The pool's payouts_ledger SQLite table is stubbed and will be the basis for a DigiAssetPoolServer.exe payout CLI subcommand in a later release.
  • mctrivia's original pool server at ipfs.digiassetx.com is 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 folder
  • DigiAssetCore.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)