/wallet
TensorCash Core.
Un wallet desktop Qt per la chain TensorCash — discendente di Bitcoin Core, con supporto agli asset nativi e una console JSON-RPC integrata. Compilalo dai sorgenti pubblici (con Docker o in locale), oppure scarica un binario pronto all'uso pubblicato da un benefattore.
Tour
Stessa struttura di Bitcoin Core, con tab specifici per gli asset nativi e l'emissione. Clicca su un riquadro per vedere l'immagine ad alta risoluzione.
Compila dai sorgenti
L'artefatto canonico è l'albero dei sorgenti in services/core-node/bcore/. Il wallet Qt si compila dallo stesso target CMake del daemon headless — basta passare -DBUILD_GUI=ON in fase di configurazione. Due percorsi: un Dockerfile che compila l'intero stack (più semplice, isolato), oppure le dipendenze native sull'host (iterazione più rapida, immagine più leggera).
Percorso 1 · Docker (consigliato)
Il repository include un Dockerfile multi-stage che compila il binario Rust cosign-bridge, la wheel Python ChiaVDF e il daemon bcore completo con il wallet Qt in un unico passaggio. Serve solo Docker sull'host. Il container include anche Tor per la rete hidden-service e un server VNC per eseguire la GUI dentro al container.
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 \
.Dopo la build, avvia il container esponendo la porta RPC del wallet e (opzionalmente) VNC per l'accesso alla GUI:
# 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:devPercorso 2 · Build nativa
Scegli questa strada se vuoi binari nativi sull'host senza container. Testato su macOS 13+ (arm64 / x86_64) e Ubuntu / Debian; Fedora e Arch sono documentati nel doc/build-unix.md all'interno del sottomodulo bcore.
Clone
git clone --recurse-submodules https://github.com/tensorcash/tensorcash.git
cd tensorcash/services/core-node/bcoreInstalla le dipendenze — macOS
Prima Xcode Command Line Tools, poi i pacchetti Homebrew.
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=ONInstalla le dipendenze — Linux (Ubuntu / Debian)
Stessa logica, gestore di pacchetti diverso. Fedora e Arch sono nel doc/build-unix.md upstream all'interno del repository.
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-devInstalla le dipendenze — Windows (cross-compilazione)
Le build native per Windows passano per MSVC (vedi doc/build-windows-msvc.md). Il percorso più veloce, usato dalla maggior parte dei contributor, è la cross-compilazione da un host Linux (o WSL) con il toolchain Mingw-w64 e il sistema depends incluso. NSIS serve solo per il target installer .exe.
# 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)Configura + compila
Su macOS / Linux la configurazione è una singola invocazione CMake. Su Windows passa il file toolchain generato dall'albero depends.
# 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 NSISFlag di configurazione comuni: -DBUILD_GUI=ON (wallet Qt), -DENABLE_WALLET=OFF (nodo solo chain), -DWITH_ZMQ=ON (topic ZMQ pub/sub). Esegui cmake -B build -LH per la lista completa.
Compila il cosign bridge
Le funzionalità Cosign nel wallet (firma tra dispositivi accoppiati, multisig federato) comunicano con un sidecar Rust chiamato cosign-bridge tramite un socket locale. Il percorso Docker lo compila automaticamente; per le build native lo produci con 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.Esegui
Il binario del wallet Qt si trova in build/bin/. La sincronizzazione iniziale con la mainnet richiede ore e scrive gigabyte di chainstate; per un test rapido, puntalo su un datadir regtest.
# 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-qtServizi di supporto
TensorCash Core è il wallet, più un piccolo gruppo di servizi sidecar con cui dialoga. La build Docker li include tutti; se compili in modo nativo, questi sono i componenti da affiancare al binario Qt in base alle funzionalità che ti servono.
| Servizio | Percorso sorgente | Funzione | Necessario per |
|---|---|---|---|
| cosign-bridge | services/core-node/cosign-bridge/ | Sidecar Rust locale che gestisce il pairing cosign / firma federata (SPAKE2 + Noise over WebSocket). Gestisce i flussi tra dispositivi accoppiati dal wallet Qt. | Funzionalità Cosign (firma multi-dispositivo, multisig federato) |
| ChiaVDF | shared-utils/chiavdf/ | Funzione di Ritardo Verificabile (VDF) usata dalla validazione della chain. Compilata come wheel Python durante la build del daemon. | Validazione di qualsiasi blocco (mainnet, testnet o regtest) |
| core-node REST | services/core-node/src/ | Piccola interfaccia REST a fianco del server JSON-RPC. Espone metadati del modello e metriche del nodo. | Integrazioni con i provider; il wallet stesso non ne ha bisogno |
| verification-api | services/verification-api/ | Servizio di verifica OSS. Il wallet non lo chiama direttamente — lo fa bcore, quando -validationapi=real. | Validazione reale (non mock) dei blocchi in produzione |
| miner-api | services/miner-api/ | Fa da ponte tra la chain e il motore di inferenza (llama.cpp / vLLM). Produce la prova di inferenza che diventa parte di un blocco. | Mining (inferenza + produzione di blocchi) |
Binari dei benefattori
Compilare dai sorgenti è il percorso canonico. Per comodità, i benefattori della comunità pubblicano le proprie build dallo stesso albero sorgente. Il progetto non produce, firma né distribuisce binari — si tratta di pubblicazioni indipendenti di terze parti, elencate qui a solo titolo informativo. Verifica qualsiasi build di un benefattore confrontandola con la tua build dai sorgenti, oppure incrociala con quella di un altro benefattore.
| Benefattore | Piattaforme | Chiave PGP | Note |
|---|---|---|---|
| TensorCash | macOS (arm64, x86_64) · Linux (x86_64) · Windows (x86_64) | pending | Compila dall'albero sorgente pubblico. Ogni release include un manifesto SHA-256 e una firma PGP separata accanto ai binari. |
Per essere elencato come benefattore: compila da una release sorgente con tag, pubblica un manifesto SHA-256 dei tuoi artefatti e una firma PGP separata, poi apri una pull request aggiungendo una riga a questa tabella.
Verificare una build di un benefattore
Due controlli. Il primo collega la dichiarazione del benefattore al binario scaricato; il secondo collega il binario ai sorgenti.
Hash + firma
Ogni benefattore pubblica un file SHA256SUMS e una firma SHA256SUMS.asc separata. Verifica che il file scaricato corrisponda al manifesto, e che il manifesto sia firmato con la chiave PGP pubblicata dal benefattore.
# 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 SHA256SUMSIncrocio
La firma di un singolo benefattore dimostra solo che lui si fa garante del binario — non che il binario corrisponda ai sorgenti. Due modi per colmare questa lacuna: compilare dai sorgenti e confrontare gli hash, oppure confrontare con il manifesto di un secondo benefattore per lo stesso tag di release. Quando due o più builder indipendenti pubblicano SHA-256 identici per lo stesso artefatto, hai la prova che la build è riproducibile dai sorgenti pubblici.
Da qui in poi
- guida regtest — sandbox di sviluppo locale con validazione mock, walkthrough per registrazione del modello ed emissione di asset.
- Reference JSON-RPC — la console integrata nel wallet supporta ogni metodo di questa reference.
- Partecipa — tutti gli altri modi di partecipare: istituzioni, provider, sviluppatori, verificatori, ricercatori.