Tous les systèmes opérationnels 21 cryptomonnaies acceptées · Monero bienvenu Politique sans KYC
ChainVPS

Crypto · sans KYC

Hébergez Bitcoin Core (bitcoind) sur un VPS offshore

Faire tourner votre propre nœud complet Bitcoin Core est le seul moyen de vérifier la chaîne vous-même plutôt que de faire confiance au serveur de quelqu'un d'autre, et un VPS offshore sans KYC vous permet de le faire sans y associer votre identité.

Ce que c'est

Bitcoin Core (bitcoind) est l'implémentation de référence du protocole Bitcoin : il télécharge et valide indépendamment chaque bloc et chaque transaction, les relaie aux pairs, et expose une interface JSON-RPC à laquelle votre wallet ou vos applications peuvent faire confiance. Un nœud complet vous offre une validation de niveau self-custody, une confidentialité vis-à-vis des explorateurs de blocs publics, et un backend pour wallets, nœuds Lightning, serveurs Electrum (Fulcrum/electrs) ou BTCPay Server.

Pourquoi l'héberger en offshore

L'adresse IP de votre nœud est visible par chaque pair auquel il se connecte : l'exécuter depuis un VPS payé en crypto et sans identité le garde totalement dissocié de votre connexion personnelle et de votre nom. ChainVPS est sans KYC et propose une bande passante illimitée, ce qui compte car le téléchargement initial de la chaîne (IBD) et le relais continu vers les pairs font transiter des centaines de gigaoctets qui feraient exploser un quota limité.

Le déploiement

Une configuration de référence fonctionnelle

Copiez ceci sur une nouvelle instance ChainVPS. Remplacez les paramètres, puis lancez-la.

docker-compose.yml
# docker-compose.yml — Bitcoin Core full node (pruned by default for a small VPS)
# 1) Generate an RPC credential first (do NOT store a plaintext password):
#      curl -sSL https://raw.githubusercontent.com/bitcoin/bitcoin/master/share/rpcauth/rpcauth.py \
#        | python3 - bitcoin
#    It prints an rpcauth=... line and a matching password. Paste the rpcauth line below.
# 2) docker compose up -d   then follow IBD:  docker compose logs -f
services:
  bitcoind:
    image: bitcoin/bitcoin:28.1
    container_name: bitcoind
    restart: unless-stopped
    stop_grace_period: 2m
    user: "1000:1000"
    ports:
      - "8333:8333"                 # P2P — public, lets you serve/accept peers
      - "127.0.0.1:8332:8332"       # RPC — bound to localhost ONLY, never expose
    volumes:
      - ./bitcoin-data:/home/bitcoin/.bitcoin
    command:
      - -printtoconsole
      - -server=1
      - -listen=1
      - -prune=10000                # ~10 GB of blocks; set -prune=0 -txindex=1 for a full archival node
      - -dbcache=1024               # MB; raise to 2048-4096 on bigger boxes to speed IBD
      - -maxmempool=300
      - -maxconnections=40
      - -rpcbind=0.0.0.0            # binds inside the container; host mapping keeps it on 127.0.0.1
      - -rpcallowip=172.16.0.0/12   # docker bridge range, so host-side tools can reach RPC
      - -rpcauth=bitcoin:REPLACE_WITH_GENERATED_HASH   # <-- paste rpcauth output here
      - -disablewallet=1            # node-only; drop this line if you want the built-in wallet
# First run needs ./bitcoin-data owned by uid 1000:  mkdir -p bitcoin-data && sudo chown 1000:1000 bitcoin-data

Pare-feu

Ports à ouvrir

PortProtocoleObjectif
8333TCPBitcoin P2P — accepter et servir les pairs ; le seul port qui doit être accessible publiquement
8332TCPInterface de contrôle JSON-RPC — à lier uniquement à 127.0.0.1, à joindre via un tunnel SSH ou un réseau privé
28332/28333TCPNotifications ZMQ optionnelles de blocs/transactions pour un nœud Lightning ou un serveur Electrum ; localhost uniquement
9050TCPProxy SOCKS Tor local optionnel si vous faites tourner bitcoind via Tor pour une confidentialité au niveau des pairs

Dimensionnement optimal

De quel forfait vous avez besoin

Léger — nœud élagué (pruned)

VPS Small (2 vCPU / 4 GB RAM / 60-80 GB NVMe)

prune=10000 conserve environ 10 GB de blocs plus les ~10 GB de chainstate ; valide l'intégralité de la chaîne, idéal comme backend wallet/Lightning lorsque vous n'avez pas besoin des données de blocs historiques.

Moyen — nœud complet non élagué

VPS Pro ou Storage VPS (4 vCPU / 8 GB RAM / 1 TB de disque)

prune=0 stocke chaque bloc (~650 GB et en augmentation constante en 2026) ; les offres Storage apportent la marge de disque volumineux à bas coût, et la bande passante illimitée couvre l'intégralité de l'IBD et du relais vers les pairs.

Lourd — archive + txindex / serveur Electrum

Serveur dédié ou VPS Storage de grande capacité (8+ vCPU / 16-32 GB RAM / 1.5-2 TB NVMe)

txindex=1 associé à Fulcrum/electrs ajoute un large index d'adresses et sert de nombreux clients wallet ; nécessite du NVMe rapide et de la RAM pour le dbcache et la reconstruction des index.

Meilleurs emplacements : N'importe laquelle des 15 localisations convient puisque la bande passante ChainVPS est illimitée, ce qui est exactement ce dont ont besoin l'IBD de plusieurs centaines de GB d'un nœud et son relais continu. Pour une exploitation sans identité, choisissez les localisations de la gamme privacy — Islande, Suisse, Moldavie, Pays-Bas, Roumanie ou Luxembourg — où le nœud n'a aucun lien avec votre nom ; des juridictions comme l'Islande et la Suisse sont aussi de bons choix si vous prévoyez de le faire tourner via Tor et souhaitez un hébergement stable et respectueux de la vie privée pour un nœud de longue durée.

Verrouillez-le

Liste de vérification du durcissement

  • N'exposez jamais le port 8332 sur Internet. Gardez le mapping RPC sur 127.0.0.1 comme indiqué et accédez-y via `ssh -L 8332:127.0.0.1:8332 user@server` ; un RPC accessible avec des identifiants faibles ou devinables est la façon classique dont les nœuds se font vider ou détourner.
  • Utilisez -rpcauth (un hash salé) plutôt que -rpcuser/-rpcpassword afin qu'aucun mot de passe en clair ne se retrouve dans le fichier compose ou la liste des process ; changez-le si la machine est un jour partagée ou snapshotée.
  • Faites tourner le nœud via Tor pour une confidentialité au niveau des pairs : installez tor sur l'hôte et ajoutez -proxy=127.0.0.1:9050 -listen=1 -bind=127.0.0.1 ainsi qu'un service onion, afin que les pairs voient un .onion au lieu de l'IP de votre VPS. Combinez avec -onlynet=onion si vous ne voulez aucun pair en clearnet.
  • Verrouillez le pare-feu avec ufw : n'autorisez en entrée que le 22 (SSH, idéalement en clé uniquement + port déplacé) et le 8333, refusez tout le reste. bitcoind ouvre de toute façon ses propres connexions sortantes vers les pairs.
  • Surveillez le disque. Un nœud élagué reste stable autour de ~20 GB, mais un nœud non élagué grossit en continu — mettez en place une alerte d'utilisation disque et une marge suffisante, car un disque plein arrête la validation et peut corrompre le chainstate en cas de crash brutal.
  • Définissez stop_grace_period (2m ci-dessus) et utilisez `docker compose stop`, jamais un kill brutal — bitcoind a besoin de temps pour vider proprement son chainstate LevelDB, sinon vous risquez un reindex lent au prochain démarrage.

Questions

Hébergement Bitcoin Core (bitcoind) — FAQ

De combien d'espace disque ai-je vraiment besoin ?

Un nœud élagué (prune=10000 dans la config) reste autour de 15-20 GB et valide malgré tout l'intégralité de la chaîne. Un nœud d'archive complet stocke chaque bloc, soit environ 650 GB en 2026, avec une croissance d'environ 50-70 GB par an ; prévoyez donc 1 TB ou plus. Ajouter txindex=1 ou un serveur Electrum vous pousse plutôt vers 1.5-2 TB de NVMe rapide.

Combien de temps prend le téléchargement initial de la chaîne (IBD) ?

Sur un VPS moderne avec bande passante illimitée et dbcache=2048+, comptez de quelques heures à environ une journée pour synchroniser et valider entièrement depuis le genesis, selon la vitesse du CPU et du disque. Augmenter -dbcache pendant la synchronisation initiale est le levier d'accélération le plus efficace. C'est un coût ponctuel ; ensuite, le nœud ne télécharge plus que les nouveaux blocs.

Puis-je faire tourner un nœud Lightning ou un serveur Electrum avec ce nœud ?

Oui. Activez ZMQ (ajoutez -zmqpubrawblock et -zmqpubrawtx sur les ports 28332/28333) et pointez LND, Core Lightning, Fulcrum ou electrs vers les endpoints RPC et ZMQ via le réseau Docker local. Notez que Fulcrum/electrs nécessitent txindex=1, vous ne pouvez donc pas les associer à un nœud élagué.

Un nœud élagué est-il moins sécurisé ou moins privé ?

Non. Un nœud élagué effectue exactement la même validation complète de chaque bloc et transaction qu'un nœud d'archive — il se contente de supprimer les anciennes données de blocs après les avoir vérifiées. La sécurité et la confidentialité de votre wallet sont identiques. Vous perdez uniquement la capacité de servir des blocs historiques à d'autres pairs ou de rescanner d'anciennes transactions arbitraires.

L'IP de mon nœud sera-t-elle visible ?

Oui — par conception, chaque pair auquel vous vous connectez voit l'IP de votre nœud. C'est exactement pour cela qu'un VPS offshore sans KYC est utile : l'IP appartient à un serveur sans aucun lien avec votre identité ou votre connexion personnelle. Pour une confidentialité complète au niveau des pairs, faites tourner bitcoind via Tor comme décrit dans les conseils de durcissement, afin que les pairs ne voient qu'une adresse .onion.

Déployer Bitcoin Core (bitcoind)
dans les 60 prochaines secondes.

Bande passante illimitée · DDoS inclus · 21 cryptomonnaies · sans KYC.