/wallet
TensorCash Core.
Een Qt-desktopwallet voor de TensorCash-blockchain — afgeleid van Bitcoin Core, met ondersteuning voor native assets en een ingebouwde JSON-RPC-console. Bouw hem zelf uit de publieke broncode (met Docker of native), of download hieronder een binary die door een weldoener is gepubliceerd.
Rondleiding
Dezelfde opzet als Bitcoin Core, met TensorCash-specifieke tabbladen voor native assets en uitgifte. Klik op een afbeelding voor de volledige resolutie.
Bouwen vanuit broncode
Het canonieke artefact is de bronboom in services/core-node/bcore/. De Qt-wallet wordt gebouwd uit hetzelfde CMake-target als de headless daemon — geef -DBUILD_GUI=ON mee bij configure. Twee routes: een Dockerfile die de volledige stack in één keer bouwt (eenvoudigst, sandboxed), of native afhankelijkheden op je host (snellere iteratie, kleinere image footprint).
Route 1 · Docker (aanbevolen)
De repository levert een meerfasige Dockerfile die in één keer de cosign-bridge Rust-binary, de ChiaVDF Python-wheel en de volledige bcore daemon + Qt-wallet bouwt. Je hoeft alleen Docker op de host te hebben. De container bevat ook Tor voor hidden-service-netwerken en een VNC-server, zodat je de GUI desgewenst in de container kunt draaien.
Dockerfile: services/core-node/tor.Dockerfile
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash
docker build \
-f services/core-node/tor.Dockerfile \
-t tensorcash-core:dev \
.Na het bouwen start je de container met de RPC-poort van de wallet open, en (optioneel) VNC voor GUI-toegang:
# Headless daemon, RPC reachable on host:18332.
docker run --rm -p 18332:18332 \
-v $HOME/.tensorcash-data:/data \
tensorcash-core:dev
# With the Qt GUI exposed via VNC on host:5900 (default password in the
# container's vnc.sh — change before any non-localhost binding).
docker run --rm -p 5900:5900 -p 18332:18332 \
-v $HOME/.tensorcash-data:/data \
tensorcash-core:devRoute 2 · Native build
Gebruik deze route als je native binaries op je host wilt zonder container. Getest op macOS 13+ (arm64 / x86_64) en Ubuntu / Debian; Fedora en Arch staan gedocumenteerd in doc/build-unix.md van de bcore-submodule.
Klonen
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcoreAfhankelijkheden installeren — macOS
Eerst Xcode Command Line Tools, dan Homebrew-pakketten.
xcode-select --install # if not already installed
brew install \
cmake boost pkgconf libevent \
qt@6 qrencode \
zeromq \
capnp # optional, only if you want -DENABLE_IPC=ONAfhankelijkheden installeren — Linux (Ubuntu / Debian)
Zelfde idee, andere pakketbeheerder. Fedora en Arch staan in upstream doc/build-unix.md, in de repo zelf.
sudo apt-get install -y \
build-essential cmake pkgconf python3 \
libevent-dev libboost-dev libsqlite3-dev libzmq3-dev \
qt6-base-dev qt6-tools-dev qt6-l10n-tools qt6-tools-dev-tools libgl-dev \
libqrencode-devAfhankelijkheden installeren — Windows (cross-compile)
Native Windows-builds lopen via MSVC (zie doc/build-windows-msvc.md). De snellere route die de meeste bijdragers kiezen is cross-compileren vanuit een Linux-host (of WSL) met de Mingw-w64-toolchain en het meegeleverde depends-systeem. NSIS heb je alleen nodig voor het .exe-installatiedoel.
# On a Linux host (or WSL inside Windows):
sudo apt-get install -y g++-mingw-w64-x86-64-posix nsis
# Build the depends tree once.
gmake -C depends HOST=x86_64-w64-mingw32 -j$(nproc)Configureren + compileren
Op macOS / Linux is de configuratiestap één CMake-aanroep. Op Windows geef je het toolchain-bestand mee dat door de depends-boom is gegenereerd.
# macOS / Linux
cmake -B build -DBUILD_GUI=ON
cmake --build build -j$(getconf _NPROCESSORS_ONLN 2>/dev/null || nproc)
# Windows (cross-compile from Linux/WSL)
cmake -B build --toolchain depends/x86_64-w64-mingw32/toolchain.cmake -DBUILD_GUI=ON
cmake --build build -j$(nproc)
cmake --build build --target deploy # produces the .exe installer via NSISVeelgebruikte configure-vlaggen: -DBUILD_GUI=ON (Qt-wallet), -DENABLE_WALLET=OFF (alleen chain-node), -DWITH_ZMQ=ON (ZMQ pub/sub-topics). Voer cmake -B build -LH uit voor de volledige lijst.
De cosign-bridge bouwen
Cosign-functies in de wallet (paired-device signing, federated multisig) praten via een lokale socket met een sidecar Rust-binary, cosign-bridge. De Docker-route bouwt deze automatisch; voor native builds maak je hem met cargo:
# Rust 1.85+ required.
cd services/core-node/cosign-bridge
cargo build --release --bin cosign-bridge --bin cosign-local-relay
# Binaries land in target/release/. Run cosign-bridge alongside the wallet.Uitvoeren
De Qt-wallet binary belandt in build/bin/. De eerste synchronisatie met mainnet duurt uren en schrijft een chainstate van meerdere GB; voor een snelle rooktest wijs je hem in plaats daarvan naar een regtest-datadir.
# Smoke test on a private chain — no real coins, no peers, no IBD.
build/bin/bitcoin-qt -regtest -datadir=$HOME/.tensorcash-regtest
# Production: starts initial block download against the live network.
build/bin/bitcoin-qtBijbehorende services
TensorCash Core is de wallet plus een kleine set sidecar-services waarmee hij praat. De Docker-build hierboven bundelt ze allemaal; bouw je native, dan is dit wat je naast de Qt-binary opzet — afhankelijk van welke functies je nodig hebt.
| Service | Bronpad | Functie | Nodig voor |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | Lokale Rust-sidecar die cosign / federated-signing-koppeling afhandelt (SPAKE2 + Noise over WebSocket). Verzorgt paired-device-flows vanuit de Qt-wallet. | Cosign-functies (multi-device signing, federated multisig) |
| ChiaVDF | shared-utils/chiavdf/ | Verifiable Delay Function voor ketenvalidatie. Gebouwd als Python-wheel tijdens de daemon-build. | Validatie van elk blok (mainnet, testnet of regtest) |
| core-node REST | services/core-node/src/ | Klein REST-oppervlak naast de JSON-RPC-server. Geeft toegang tot modelmetadata en node-metrics. | Provider-integraties; de wallet zelf heeft dit niet nodig |
| verification-api | services/verification-api/ | OSS-verificatieservice. De wallet roept deze niet direct aan — bcore doet dat, wanneer -validationapi=real is ingesteld. | Echte (niet-mock) blokvalidatie in productie |
| miner-api | services/miner-api/ | Brug tussen de blockchain en de inference-engine (llama.cpp / vLLM). Producent van het inference-bewijs dat onderdeel wordt van een blok. | Mining (inference serveren + blokken produceren) |
Weldoenerbinaries
Bouwen uit de broncode is de canonieke weg. Als service voor de gemeenschap publiceren weldoeners hun eigen builds van dezelfde bronboom. Het project produceert, ondertekent of distribueert zelf geen binaries — dit zijn onafhankelijke publicaties van derden, hier puur ter referentie vermeld. Verifieer elke weldoenerbuild tegen je eigen build vanuit broncode, of vergelijk builds van meerdere weldoeners met elkaar.
| Weldoener | Platforms | PGP-sleutel | Opmerkingen |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | Gebouwd vanuit de publieke bronboom. Elke release bevat een SHA-256-manifest en een losgekoppelde PGP-handtekening naast de binaries. |
Om als weldoener vermeld te worden: bouw vanuit een getagde bronrelease, publiceer een SHA-256-manifest van je artefacten plus een losgekoppelde PGP-handtekening, en open een pull request die een rij toevoegt aan deze tabel.
Een weldoenerbuild verifiëren
Twee controles. De eerste koppelt de claim van de weldoener aan de binary die jij hebt gedownload; de tweede koppelt diezelfde binary aan de broncode.
Hash + handtekening
Elke weldoener publiceert een SHA256SUMS-bestand met een losgekoppelde SHA256SUMS.asc-handtekening. Controleer dat het bestand dat je hebt gedownload overeenkomt met het manifest, en dat het manifest is ondertekend met de gepubliceerde PGP-sleutel van de weldoener.
# 1. Manifest matches the binary you have on disk.
shasum -a 256 -c SHA256SUMS --ignore-missing
# 2. Manifest is signed by the benefactor's key.
gpg --verify SHA256SUMS.asc SHA256SUMSKruisreferentie
Eén weldoenerhandtekening bewijst alleen dát zij voor de binary instaan — niet dat die binary ook bij de broncode hoort. Twee manieren om dat gat te dichten: zelf vanuit broncode bouwen en hashes vergelijken, of vergelijken met het manifest van een tweede weldoener voor dezelfde release-tag. Publiceren twee of meer onafhankelijke builders identieke SHA-256-hashes voor hetzelfde artefact, dan heb je bewijs dat de build reproduceerbaar is vanuit publieke broncode.
Volgende stappen
- regtest-handleiding — lokale ontwikkelsandbox met mock-validatie, plus walkthroughs voor modelregistratie en asset-uitgifte.
- JSON-RPC-referentie — de ingebouwde console in de wallet spreekt elke methode uit deze referentie.
- Doe mee — alle andere manieren om bij te dragen: instellingen, providers, ontwikkelaars, verifiers, onderzoekers.