You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sibling of #381 (Monero view-only payout confirmation), for the other half of the merge-mine. The Tari case is arguably more valuable: Tari merge-mining here is solo — the whole block reward lands at once when your hashrate finds a Tari block (~72 days apart at current prod hashrate per the v1.3.1 earnings headline), so a payout is a rare, large event the operator really wants ground-truth confirmation (and an alert) for. Today nothing checks one ever landed: TARI_WALLET_ADDRESS is handed to p2pool's --merge-mine (docker-compose.yml:246), the coinbase goes to that address, and the dashboard only shows the time-to-block estimate.
minotari_console_wallet supports read-only wallets: created from the private view key + public spend key (menu option 3, "Create a read-only wallet using a view key"); the main wallet exports both via minotari_console_wallet --base-path <dir> export-view-key-and-spend-key. A view-only wallet watches received funds and cannot spend.
The console wallet exposes gRPC (grpc_enabled = true in its config.toml) with GetCompletedTransactions() in wallet.proto — the dashboard already speaks Tari gRPC (client/tari/), so the client shape exists.
To verify before implementation ([TODO: verify upstream])
That a view-only wallet detects p2pool merge-mine coinbase outputs specifically (the exchange doc confirms one-sided deposit watching; coinbases to wallet_payment_address should scan the same way, but prove it on a testbed before building).
Non-interactive creation: option 3 is an interactive menu — find the scriptable path (CLI flags / init file) for container automation, or an FFI route.
Which image ships minotari_console_wallet (the stack pins quay.io/tarilabs/minotari_node; a sibling wallet image likely exists — pin by digest like the node).
Tests per the four tiers: client parsing + table round-trip + alert edge (tier 1), a canned wallet-gRPC fake (tier 2), gouda live view-only wallet syncing against the local node (tier 4). Patch ≥90%.
Acceptance
Keys unset: no new container, dashboard unchanged.
Keys set on a local-node stack: wallet container healthy and synced view-only; a (testnet or historical) coinbase to the payout address appears as a confirmed row and fires one alert; restart replays nothing.
The view key never appears in logs, docker inspect, or apply output.
Depends on / interacts with: #381 (shared payouts table + alert event), #196 (payout series), #255/#377 (container hardening patterns), #103 (remote-tari would gate the feature off, like #381's remote-mode rule).
Sibling of #381 (Monero view-only payout confirmation), for the other half of the merge-mine. The Tari case is arguably more valuable: Tari merge-mining here is solo — the whole block reward lands at once when your hashrate finds a Tari block (~72 days apart at current prod hashrate per the v1.3.1 earnings headline), so a payout is a rare, large event the operator really wants ground-truth confirmation (and an alert) for. Today nothing checks one ever landed:
TARI_WALLET_ADDRESSis handed to p2pool's--merge-mine(docker-compose.yml:246), the coinbase goes to that address, and the dashboard only shows the time-to-block estimate.Verified upstream mechanics (tari.com exchange-integration lesson, checked 2026-07-11)
minotari_console_walletsupports read-only wallets: created from the private view key + public spend key (menu option 3, "Create a read-only wallet using a view key"); the main wallet exports both viaminotari_console_wallet --base-path <dir> export-view-key-and-spend-key. A view-only wallet watches received funds and cannot spend.grpc_enabled = truein its config.toml) withGetCompletedTransactions()inwallet.proto— the dashboard already speaks Tari gRPC (client/tari/), so the client shape exists.To verify before implementation ([TODO: verify upstream])
wallet_payment_addressshould scan the same way, but prove it on a testbed before building).payout_scan_heightanalogue).minotari_console_wallet(the stack pinsquay.io/tarilabs/minotari_node; a sibling wallet image likely exists — pin by digest like the node).Proposal (mirrors #381's structure)
tari.view_key(secret) +tari.spend_public_keyin config; both unset (default) = feature off, nothing new runs. Local tari node only (remote tari doesn't exist yet — Evaluate a remote Tari base-node option (tari.mode: remote), mirroring Monero remote #103 is v1.6).tari-walletservice: view-only console wallet + gRPC bound loopback-only, non-root (Run containers as a non-root user (drop root inside the container) #255), read-only rootfs + tmpfs (Extendread_only: truerootfs to the six remaining services #377 pattern), wallet data on a named volume. Talks ONLY to the local tari node — no new egress, Tor posture unchanged.GetCompletedTransactions; slow poll; persist to the samepayoutstable Confirm payouts on-chain with a view-only wallet (monero-wallet-rpc against the local node) #381 adds — key it(chain, txid)so one table serves both chains (coordinate the schema with Confirm payouts on-chain with a view-only wallet (monero-wallet-rpc against the local node) #381; whichever lands first creates it that way).payout_confirmedalert (shared event from Confirm payouts on-chain with a view-only wallet (monero-wallet-rpc against the local node) #381) carries the chain.config.json/.env; handled likenode_password(never logged/echoed, BOTSECRET test pattern). The renderedTARI_VIEW_KEY/TARI_SPEND_PUBLIC_KEYenv keys must stay off the Stack config editor: change any setting from the dashboard, applied via pithead (incl. P2Pool mode hot-swap) #33 dashboard-editable allowlist (default-deny covers them, but the allowlist comment should name them deliberately).Acceptance
docker inspect, or apply output.Depends on / interacts with: #381 (shared payouts table + alert event), #196 (payout series), #255/#377 (container hardening patterns), #103 (remote-tari would gate the feature off, like #381's remote-mode rule).