win.33 - Phase 2 dial-back verification + Phase 3 payout pipeline + peerId fix

Phase 2 verified working (413/413 probes passed overnight) + Phase 3 payout pipeline ready

Phase 2: dial-back verification

New PoolVerifier background thread probes each registered node every 60 seconds via IPFS swarm/connect. Nodes that pass are marked verified; nodes with 3+ consecutive failures are excluded from /nodes.json and from payouts.

Ran overnight on a real Windows box with one client: 413 out of 413 probes succeeded (100% pass rate). The self-detection feature auto-verifies when the pool server and client are on the same machine (NAT hairpinning workaround).

Phase 3: operator-approved payout pipeline (code complete)

• [P] Payout Preview: shows verified node count, pool budget, per-node share, and each eligible payout address. Read-only, safe to press anytime.
• [E] Execute Payout: shows preview then requires explicit Y keypress. Calls sendtoaddress on the local DigiByte Core wallet via JSON-RPC for each eligible node. Logs txid/error per node, records in payouts_ledger table. Dashboard shows real paid-total from the ledger.
• Guards: refuses to execute if poolpayouts=0, poolspendperperiod missing/zero, zero verified nodes, or rpcuser not configured. Each guard prints a clear reason.
• New pool.cfg keys: rpcuser, rpcpassword, rpcport (wallet RPC), poolspendperperiod (DGB per payout cycle)

PeerId bug fix

IPFS::getPeerId now filters the /id response addresses by the local node's own ID field. Previously could return a DigitalOcean bootstrap node's address as "ours". Confirmed fixed: log now shows the real 12D3KooW... peerId.

UI polish

• [H] help sub-menus: press H for a 3-line topic index, then 1-6 for detail sections that fit on one screen
• Pool dashboard aligned columns: same cell() fixed-width helper as the main exe
• Pool header matches main exe format: DigiAsset Pool Server for Windows v0.3.0-win.33
• Dynamic log area: fills terminal height, no blank gap
• Uptime format matches: N sec / N min / N.N hours / N.N days
• Phase 3 keys dimmed in key-hints bar since payouts default off

Files

• DigiAssetCore-0.3.0-win.33-x64.zip — all three exes
• DigiAssetCore.exe — main client
• DigiAssetCore-cli.exe — JSON-RPC CLI
• DigiAssetPoolServer.exe — pool server (Phase 1 + 2 + 3)

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:

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)

win.31 - Dashboard serving/coverage rows, getnodestats RPC, fix RPC server actually listens

Headline fix: the RPC server actually listens now. For the first time.

src/boost/asio.hpp in this fork was a hand-written no-op stub that silently emulated boost::asio's socket API with empty implementations. Because src/ sat on the include path, #include <boost/asio.hpp> in RPC/Server.cpp resolved to the stub, not to real boost. Every bind() / listen() / accept() call was a no-op:

class acceptor {
    void open(int) {}
    void set_option(const reuse_address&) {}
    void bind(const endpoint&) {}
    void listen() {}
    void accept(socket&) {
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }
};

The RPC Server listening on port 14024 log line was printed after a no-op listen() returned. The RPC call # received debug entries were the stub's sleeping accept loop spinning once per second, not real inbound connections. netstat never showed port 14024 bound because no socket was ever actually created.

DigiAssetCore-cli.exe has never worked on this Windows fork for any RPC command. Not version, not getblockcount, not listassets, nothing. Every call failed with a libcurl-style error because there was nothing listening to connect to.

Upstream src/CMakeLists.txt even acknowledged the stub existed, for WebServer.cpp:

# WebServer.cpp needs real Boost Beast headers (not the stub in src/boost/)

…but nothing else got the fix. RPC::Server silently compiled against the stub for every previous release. This commit finally fixes it globally by adding the real boost headers to the front of the include path for every source file, and switching Server.h/Server.cpp to explicit sub-header includes as a belt-and-braces guarantee.

After this release:

• netstat -ano | findstr 14024 shows TCP 0.0.0.0:14024 0.0.0.0:0 LISTENING <pid> for the first time.
• DigiAssetCore-cli.exe version returns "0.3.0-win.31".
• DigiAssetCore-cli.exe getnodestats returns a real JSON snapshot of the node.
• Every pre-existing RPC method (version, listassets, getblockcount, getassetdata, etc.) now works from the cli because there's finally something listening.

New features (the original reason for this release)

Dashboard: Serving: row

Polls IPFS bitswap stats every 30 seconds via POST /api/v0/stats/bitswap and displays total blocks sent, rate per minute, and total bytes sent, in a human-readable form. Answers "is this node actually serving DigiAsset content out to the network?" with a direct measurement, not a guess.

Dashboard: Asset index: row

Every 10 minutes, walks /permanent/<page>.json on mctrivia's server (24 pages, ~3,442 assetIds total as of this release) and cross-checks each assetId against the local assets table. Reports local count, tracked count, and coverage percentage. 100% is strong evidence the chain analyzer is not missing any issuances, because PSP-enrolled and non-PSP-enrolled assets go through the same parse path. Missing assetIds are logged at WARNING so they're visible without flipping to DEBUG.

RPC: new getnodestats method

Returns a snapshot of buildVersion, syncHeight, assetCount, bitswap stats, and permanent-list coverage as JSON. Designed for side-by-side node comparison:

DigiAssetCore-cli.exe getnodestats

Run it on two nodes at the same syncHeight. If assetCount differs, one of them has a chain-analyzer bug. If permanentCoverage.missingCount > 0, that node is missing specific assets that the other has.

Expanded [H] help

Pressing H now prints a multi-section plain-English explanation of every dashboard row, what each number means, and what the node is actually doing. Readable by a first-time operator with no DigiAsset background.

Latent bugs fixed along the way

• Server::Server work_guard was a local variable. Changed to a member so _io stays alive. (Previously the 16 worker threads exited immediately after construction — invisible against the stub since run() was a no-op, but fatal once real boost was linked.)
• Server::Server _acceptor now initialized in the member init list with the executor. Real boost::asio::basic_socket_acceptor has no default constructor.
• Server::start() now clears AppMain::_rpcServer to nullptr when accept() returns, so the dashboard's RPC probe reports honestly if the accept loop ever dies in a future build instead of showing a green dangling pointer.
• DigiByteCore::makeConnection() prints the RPC URL to stderr when DGBCORE_DEBUG_URL=1 is set — diagnostic hook for libcurl URL-parser errors.
• Dashboard spawn-race guards for the bitswap poll and coverage scan now rely only on the elapsed >= interval check. Previously the || !_probed fallback caused the 500ms render loop to fire duplicate probe threads during the ~2s window before the first probe completed.
• cli/main.cpp drops an unused #include "RPC/Server.h" so the cli build doesn't need real boost headers at all.

Known current state

• mctrivia's pool still doesn't pay. That's a server-side bug at ipfs.digiassetx.com (HTTP 500 on the payout registration endpoint, broken since ~July 2024) and the pool operator is uncontactable. No client-side fix can change this; see the win.30 release notes for the full story. This release doesn't fix payment — but it does make the RPC server work for everything else, and the node continues to contribute storage to the network.

Files

• DigiAssetCore-0.3.0-win.31-x64.zip — both exes in a folder
• DigiAssetCore.exe — main binary
• DigiAssetCore-cli.exe — command-line helper

win.30 - PSP replace dead on-chain matching with /permanent fetcher

Gut the dead on-chain PSP matching code, replace it with a background fetcher that walks GET /permanent/<page>.json and pins every CID via local IPFS. Rewrite the dashboard in plain English.

Why

The C++ mctrivia pool code in upstream implemented an on-chain fee-matching protocol that was never deployed server-side. The 14 hard-coded pay-in addresses it was watching have not been paid in 4 million blocks of chain history. Meanwhile, mctrivia's actual payment-registration endpoint (POST /list/<floor>.json) has been returning HTTP 500 since approximately July 2024, and the pool operator is uncontactable.

This means the Windows fork's PSP pool code was implementing a protocol that never existed, while the protocol that does exist is broken on mctrivia's server and cannot be fixed client-side. After confirming this with direct HTTP probing and 700 days of chain history analysis, this release replaces the dead code path with something that at least contributes useful storage to the DigiByte ecosystem.

What this release does

• Removes the 14-address on-chain fee-matching code and the `serializeMetaProcessor` / `mctriviaMetaProcessor` paths. They always returned "" or false anyway.
• Adds a background `permanentFetcherTask` that walks `GET /permanent/.json` every 10 minutes, pins every CID in the response via your local IPFS, and persists progress to `psp1permanentpage` in `config.cfg`.
• Fires `POST /list/.json` every 30 minutes as a best-effort diagnostic probe. Expected to return HTTP 500 today. If mctrivia ever fixes their server, the dashboard will flip from yellow to green automatically with no client update needed.
• Rewrites the PSP status rows in the dashboard to stop using jargon like "pinning" and "/list HTTP 500". New wording:
  • `PSP Pool: Hosting pool files (unpaid)`
  • `Payment: unavailable - pool payment service offline`
• Emits a one-shot INFO log block at startup explaining in plain English what the node is doing and why no DGB is flowing.

Bug fixes along the way

• RPC Server row was stuck on "Off" even though the server was listening. The win.26 TCP-connect probe hit a Winsock quirk on Windows localhost where non-blocking `connect()` returns `WSAEWOULDBLOCK` and the follow-up `select()` wait for writability sometimes times out at 200ms even though the 3-way handshake has already completed. Replaced with a simple pointer check. Also added a "Checking..." tri-state so the row doesn't flash red on startup before the probe runs.
• `_secretCode` now persisted in `config.cfg` under key `psp1secret`. Previously regenerated on every startup, so the keepalive pings looked like a new identity every restart.
• `updateBadList` unbounded growth. Every 20-minute bad.json poll was pushing every bad asset twice into `_badAssets`, so the list grew without bound.
• `_pspStatus` / `_pspNodeCount` data race. These were written by a detached background thread and read from `render()` without synchronization.
• `Config::refresh` / `Config::write` silently dropped comments and blank lines on every round-trip. Now preserves original line content and ordering via a raw-lines vector.
• `getIPFS()` throws on nullptr; replaced with null-safe `getIPFSIfSet()` in mctrivia background paths to avoid shutdown-race crashes.
• Dashboard first render was crashing at "FATAL: Not available" in a brief interim build because the first render runs before `main.cpp` constructs the PSP list. Added `getPermanentStoragePoolListIfSet()` null-safe variant.
• Permanent-page rollback on error created a re-pin loop. Now stays at the current page and retries next iteration.
• `probeListEndpoint` call not wrapped in try/catch in the fetcher loop. Now wrapped.

Known current state

Payment is still offline. This release cannot fix that - it is a server-side bug on uncontactable infrastructure. Users running this node are contributing storage to the DigiByte ecosystem without receiving DGB compensation. The client is prepared to automatically resume registering for payment if mctrivia's server is ever repaired; no further client update will be required.

Files

• `DigiAssetCore-0.3.0-win.30-x64.zip` - both exes in a folder
• `DigiAssetCore.exe` - main binary
• `DigiAssetCore-cli.exe` - command-line helper

win.28 - RPC probe: fix spawn race and silence spam

Fixes two bugs introduced by win.26's RPC liveness probe. The probe was spawning dozens of threads per second because _lastRpcProbe was only written after the probe completed; now written before spawn under mutex. Also the 'empty' early-return check in the RPC server never matched because DigiByteException wraps non-JSON messages in 'Error during parsing of >>...<<'; now matches both forms. This stops the DEBUG-mode spam of 'Expected exception in RPC call #N: Error during parsing of >>empty<<'.

win.27 - PSP diagnostic logging

Adds DEBUG-level logging inside processNewMetaData to show whether the PSP serializer is actually finding matching pay-in addresses. Press [L] in the dashboard to enable DEBUG mode, then wait for an asset issuance. Log will show the computed extra string and every output address/DGB value.

win.26 - Dashboard: stop lying about RPC port and PSP

Dashboard truthfulness fixes after a long PSP debugging session. Read psp1payout instead of psp0payout (mctrivia is pool 1, not 0). Stopped showing 'awaiting registration' since map.json contains no addresses or peer IDs to check against. Probe the RPC listen socket directly instead of trusting a stale AppMain pointer that can outlive the detached accept thread.

DigiAsset Core for Windows v0.3.0-win.13

DigiAsset Core for Windows v0.3.0-win.13

Windows port of DigiAsset Core by mctrivia and contributors. Built with MSVC 2022 x64, based on upstream v0.3.0.

CRITICAL PSP PAYMENT FIX

Every Windows port user since v0.3.0-win.1 has been silently failing to register with the PSP payment pool. This release fixes it.

Root cause

Linux libcurl automatically sets Content-Type: application/x-www-form-urlencoded when posting form data via CURLOPT_POSTFIELDS. Our minimal WinHTTP stub did not.

The pool server at ipfs.digiassetx.com is an Express.js app using body-parser middleware, which silently drops the request body when no Content-Type header is present. So our keepalive POSTs arrived with empty bodies — no address, no peerId, no secret. The server then returned the misleading error "unsubscribe failed will time out anyways" for what looked like a malformed/empty registration.

Linux users get paid because libcurl auto-sets the header. Windows users got nothing because the WinHTTP stub didn't replicate that behavior.

Fix

CurlHandler::post now adds Content-Type: application/x-www-form-urlencoded automatically when POSTing form data, matching libcurl's behavior. Skipped only if the user explicitly set a Content-Type header.

This affects ALL HTTP POSTs from the Windows build, not just PSP keepalive. Any other POST endpoint that requires the Content-Type header (which is most of them) was also broken.

What you should see after upgrading

After upgrading and running for one keepalive cycle (~20 minutes), the log should show a different response from https://ipfs.digiassetx.com/keepalive — no longer the "unsubscribe failed" error. After a few hours your node should appear on the pool's network map, and payments should start flowing per mctrivia's normal schedule.

Other recent fixes

• Wrapped getSize() and PSP metadata callback in try-catch
• Detailed PSP keepalive logging (request/response visible in log)
• Bare peer ID extraction for canonical format
• Fixed missing comma in PSP pool address list (upstream bug)
• Dashboard shows PSP pool status and total network nodes
• Payout balance formatted to exactly 4 decimal places

Downloads

• DigiAssetCore-0.3.0-win.13-x64.zip - Both executables
• DigiAssetCore.exe - Main application
• DigiAssetCore-cli.exe - Command-line RPC client

Recommended config.cfg

```
verifydatabasewrite=0
pruneage=5760
psp0payout=YOUR_DGB_ADDRESS_HERE
```

DigiAsset Core for Windows v0.3.0-win.12

DigiAsset Core for Windows v0.3.0-win.12

Windows port of DigiAsset Core by mctrivia and contributors. Built with MSVC 2022 x64, based on upstream v0.3.0.

CRITICAL FIX in this release

Found a major upstream bug that broke PSP payment detection.

In src/PermanentStoragePool/pools/mctrivia.cpp line 178, two adjacent string literals in the pool address set were missing a comma:

```cpp
"dgb1qatvzudt2jey06kx8zn3a6p0nw689s9dxkjp57g" // <-- missing comma
"dgb1qfc9029kc8ptvqt2nuqe4sxtps2nd83kq7pugtm",
```

C++ string literal concatenation merged these into one 70+ character invalid address. The two real addresses were NOT in the set, so any user paying into either of them to enable PSP storage was silently ignored - the asset was never marked as part of the pool, never pinned by any node, and the operator never received credit.

This bug exists in BOTH upstream master and development branches. Reporting upstream.

Other Changes

• Wrapped getSize() calls in try-catch (prevents IPFS thread crash on lost CIDs)
• Wrapped _callbackNewMetadata in try-catch (prevents thread death on bad data)
• Detailed PSP keepalive logging for debugging
• Bare peer ID extraction for keepalive (canonical format)
• Dashboard shows PSP pool node count
• Payout balance formatted to 4 decimal places consistently

Downloads

• DigiAssetCore-0.3.0-win.12-x64.zip - Both executables
• DigiAssetCore.exe - Main application
• DigiAssetCore-cli.exe - Command-line RPC client

Recommended config.cfg

```
verifydatabasewrite=0
pruneage=5760
```

DigiAsset Core for Windows v0.3.0-win.11

DigiAsset Core for Windows v0.3.0-win.11

Windows port of DigiAsset Core by mctrivia and contributors. Built with MSVC 2022 x64, based on upstream v0.3.0.

Downloads

• DigiAssetCore-0.3.0-win.11-x64.zip - Both executables
• DigiAssetCore.exe - Main application (includes embedded web server)
• DigiAssetCore-cli.exe - Command-line RPC client

Changes since v0.3.0-win.10

• Critical PSP fix — wrapped getSize() and metadata callback in try-catch.
  Previously a single bad/lost CID would crash the IPFS thread, preventing
  any pool assets from being pinned. This is likely the reason node operators
  weren't being paid.
• Detailed PSP keepalive logging (request URL, parameters, response)
• Bare peer ID extraction for keepalive (canonical format)
• Dashboard shows PSP pool status and total network nodes
• Payout balance formatted to 4 decimal places consistently
• 63 unit tests (Blob, Config, Database, Version, Base58)
• Comprehensive test suite: unit / functional / E2E / fuzz tiers

All features

• Verified complete sync (23M+ blocks, 5,100+ assets)
• Single exe with embedded web server (port 8090)
• Console dashboard: sync progress, payout balance, PSP status, network size
• External port verification (P key) via ifconfig.co
• Interactive: Q=Quit, A=Assets, P=Port check, L=Log level, H=Info

Requirements

• Windows 10+ (x64), DigiByte Core, IPFS Desktop (optional)

Recommended config.cfg

```
verifydatabasewrite=0
pruneage=5760
```