Emplacement et priorité

• settings.json (écrit dynamiquement par l’interface graphique ou certaines RPC),
• et les options modifiées via les lignes de commande.

Format et structure

Ce que le bitcoin.conf peut et ne peut pas faire

• Les paramètres purement locaux. Ils n’affectent que votre nœud : taille du cache (dbcache), mode élagué (prune), index optionnels... Ils influencent les performances de votre machine, mais pas le réseau ;
• Les politiques de relais et de mempool. Elles décident de ce que votre nœud accepte, conserve et relaie avant confirmation : seuil minimal de frais (minrelaytxfee), taille et durée de rétention de la mempool (maxmempool, mempoolexpiry), remplacement des transactions (RBF)... Ces règles ne font pas partie du consensus, donc deux nœuds différents peuvent avoir des politiques différentes et rester pleinement compatibles. En revanche, ces paramètres vont avoir une influence sur le réseau Bitcoin (comme expliqué dans la première partie, notamment avec la théorie de la percolation) ;
• La connectivité réseau. Ce sont les options qui déterminent comment votre nœud trouve des pairs, écoute, traverse un NAT, utilise Tor ou un proxy, ou limite sa bande passante. Elles façonnent votre topologie, mais n’altèrent pas le relai des transactions.

Réseau et topologie

• Les connexions sortantes, qui sont initiées par notre nœud vers un autre nœud ;

• Les connexions entrantes, qui sont initiées par un autre nœud vers le nôtre.

• addnode : ajoute un pair ami à contacter en plus de la découverte habituelle (peut-être spécifié plusieurs fois) ;
• connect : restreint strictement les connexions à l'adresse fournie (peut-être spécifié plusieurs fois). Core ne se connectera à aucun autre nœud ;
• seednode : sert uniquement à remplir l’adresse-book en se connectant à un nœud, puis se déconnecte ;
• maxconnections : définit le plafond global de connexions entrantes + sortantes. Par défaut, ce paramètre est placé à 125, ce qui signifie que votre nœud n'acceptera jamais plus de 125 connexions ;
• maxuploadtarget : plafonne l’upload pour limiter la bande passante sur une fenêtre glissante de 24 h. Ce plafond ne sacrifie pas la propagation d’éléments récents indispensables ;
• onlynet : limite les connexions sortantes uniquement aux réseaux sélectionnés (ipv4, ipv6, onion, i2p, cjdns). Par exemple, si vous souhaitez que votre nœud se connecte au réseau Bitcoin uniquement via Tor, vous pouvez activer le paramètre onlynet=onion et ne pas activer les connexions entrantes (ou bien uniquement via Tor également) ;
• dnsseed : autorise ou non la requête des DNS seeds pour obtenir des pairs quand votre réserve locale d’adresses est faible (par défaut : 1, sauf si -connect ou -maxconnections=0) ;
• forcednsseed : force la requête des DNS seeds au démarrage, même si vous avez déjà des adresses en stock (par défaut : 0) ;
• fixedseeds : Autorise l’usage des seed nodes (liste d'adresses hardcodées) si les DNS seeds échouent ou sont désactivés (par défaut : 1) ;
• dns : Autorise les résolutions DNS en général (par exemple pour -addnode/-seednode/-connect).

• onlynet=onion,
• proxy=127.0.0.1:9050,
• listenonion=1,
• torcontrol=127.0.0.1:9051,
• proxyrandomize=1,
• listen=1,
• bind=127.0.0.1,
• upnp=0,
• natpmp=0.

Politique de mempool et de relais

Paramètres de base

• maxmempool=<n> : Limite la taille maximale de la mempool locale à <n> mégaoctets (défaut : 300). Lorsque la limite est atteinte, votre nœud élève dynamiquement son seuil de frais effectif et expulse en priorité les transactions les moins rémunératrices (en fonction du taux de frais, pas de la valeur absolue) pour rester sous la borne. Vous pouvez laisser ce paramètre par défaut. L’augmenter peut s’avérer utile si vous minez en solo, ou si vous souhaitez obtenir une vision plus précise de la congestion des mempools et améliorer l’estimation des frais. À l’inverse, la réduire permet d’économiser de la mémoire vive et, de manière marginale, d’autres ressources système.
• mempoolexpiry=<n> : Durée maximale de rétention des transactions non confirmées dans la mempool (en heures, défaut : 336). Passé ce délai, les transactions sont retirées même si de la place reste disponible.
• persistmempool=1 : Sauvegarde un instantané de la mempool à l’arrêt et le recharge au redémarrage (défaut : 1). Ça permet d'accélérer la reprise après le redémarrage en évitant de réapprendre l’état par le réseau.
• maxorphantx=<n> : Nombre maximal de transactions orphelines conservées (inputs dépendants d’UTXOs pas encore vus dans l'UTXO set, défaut : 100). Au-delà de ce seuil, les plus anciennes sont supprimées pour éviter une croissance non contrôlée de ce cache.
• blocksonly=1 : Désactive l’acceptation et la retransmission de transactions non confirmées reçues des pairs (sauf permissions spéciales). Le nœud ne télécharge et n’annonce plus que des blocs. Les transactions créées localement peuvent encore être diffusées (pour utiliser votre nœud avec vos logiciels de portefeuille). Cela réduit fortement la bande passante et les besoins en RAM au prix d’une utilité moindre pour le relais et d'une méconnaissance totale de la mempool.
• minrelaytxfee=<n> : Taux de frais minimal (en BTC/kvB) en-dessous duquel les transactions ne sont pas acceptées dans la mempool du nœud et pas relayées aux pairs (défaut : 0.00001 = 1 sat/vB). Plus cette valeur est élevée, plus votre nœud filtre agressivement les transactions à bas frais.
• mempoolfullrbf=1 : Accepter les transactions RBF même sans signalisation explicite de RBF dans la transaction remplacée. Avec cette politique dite "full-RBF", une transaction offrant un taux de frais supérieur peut en remplacer une autre en mempool si les autres conditions de remplacement sont satisfaites.

Paramètres avancés et spécifiques

• datacarrier=1 : Autorise le relais et (si minage via le nœud) l’inclusion des transactions porteuses de données non financières via un output OP_RETURN (défaut : 1). Désactiver ce paramètre réduit légèrement la surface de spam de données non financières au prix d’une compatibilité moindre avec certains usages. Dans tous les cas, vous devrez accepter les OP_RETURN minés.
• datacarriersize=<n> : Taille maximale (en octets) des OP_RETURN que le nœud relaie (défaut : 83). Abaisser cette valeur restreint les charges utiles transportées via les OP_RETURN. Notez que par défaut, cette limite sera retirée dans une des prochaines version de Bitcoin Core.
• bytespersigop=<n> : Paramètre qui convertit les opérations de signature en octets équivalents pour l’évaluation des limites de relais (défaut : 20). Cela va influencer l’acceptation des transactions riches en sigops selon les règles de politique locale.
• permitbaremultisig=1 : Autorise le relais des transactions bare-multisig P2MS (défaut : 1). C'est le plus ancien modèle de script pour établir de conditions de multisignature sur un UTXO (inventé en 2011 par Gavin Andresen).
• whitelistrelay=1 : Attribue automatiquement la permission de relayer aux pairs entrants mis sur liste blanche (défaut : 1). Ces pairs voient leurs transactions acceptées au relais même si votre nœud n’est pas en mode relais général.
• whitelistforcerelay=1 : Attribue la permission "forcerelay" aux pairs whitelistés avec permissions par défaut (défaut : 0). Le nœud relaie alors leurs transactions même si elles sont déjà présentes en mempool, ce qui contourne des mécanismes d’anti-redondance.
• whitebind=<[permissions@]addr> / whitelist=<[permissions@]CIDR> : Lie une interface ou une plage d’adresses et assigne des permissions fines aux pairs correspondants : relay, forcerelay, mempool (requête de contenu de mempool), noban, download, addr, bloomfilter. Ça peut être utile pour accorder un traitement privilégié à des pairs de confiance (passerelles, LAN, services internes...).
• peerbloomfilters=1 : Active la prise en charge des filtres Bloom (BIP37) pour servir blocs/transactions filtrés aux clients légers (défaut : 0). Attention, cela augmente la charge sur vos ressources.
• peerblockfilters=1 : Sert des filtres compacts BIP157 (Neutrino) aux pairs (défaut : 0).
• blockreconstructionextratxn=<n> : Nombre supplémentaire de transactions conservées en mémoire pour reconstruire des blocs compacts (défaut : 100). Améliore la réussite des reconstructions lors des synchronisations compactes, au prix d’un peu de mémoire.

Wallets

• addresstype=<legacy|p2sh-segwit|bech32|bech32m> : Définit le format des adresses générées par le portefeuille pour la réception.
• changetype=<legacy|p2sh-segwit|bech32|bech32m> : Force le format des adresses de change (reste d'un input sur un paiement simple).
• wallet=<path> : Charge au démarrage un portefeuille existant (peut être répété pour en charger plusieurs).
• walletdir=<dir> : Répertoire contenant les portefeuilles (par défaut : <datadir>/wallets s’il existe, sinon <datadir>). Cela peut être utile si vous souhaitez stocker les wallets sur un volume dédié ou chiffré.
• walletbroadcast=1 : Diffuse automatiquement les transactions créées par les wallets chargés (défaut : 1). À mettre à 0 si vous souhaitez gérer la diffusion par un autre canal.
• walletrbf=1 : Active l’opt-in RBF pour signaler RBF sur toutes les transactions (défaut : 1). Permet d’augmenter les frais ultérieurement en cas de transaction bloquée.
• txconfirmtarget=<n> : Cible de confirmation pour la transaction (en nombre de blocs, défaut : 6). Le wallet va définir automatiquement les frais pour que la transaction soit confirmée dans ce nombre de blocs.
• paytxfee=<amt> : Taux de frais fixe (BTC/kvB) appliqué aux transactions du wallet. À éviter en général : privilégiez l’estimation adaptative via txconfirmtarget.
• fallbackfee=<amt> : Taux de secours (BTC/kvB) utilisé si l’estimateur manque de données (défaut : 0.00). Le mettre à 0 désactive totalement le fallback.
• mintxfee=<amt> : Seuil minimal (BTC/kvB) pour la création de transactions par le wallet (défaut : 0.00001). Le wallet refusera de construire une transaction en-dessous de ce seuil.
• maxtxfee=<amt> : Plafond absolu de frais totaux pour une transaction de wallet (défaut : 0.10 BTC). Protège contre des frais anormalement élevés qui viendraient détruire des bitcoins inutilement.
• avoidpartialspends=1 : Sélectionne les UTXOs par grappes d’adresses pour éviter les dépenses partielles.
• spendzeroconfchange=1 : Autorise la réutilisation d’un UTXO de change non confirmé comme entrée dans une nouvelle transaction (défaut : 1).
• consolidatefeerate=<amt> : Taux maximal (BTC/kvB) au-delà duquel le wallet évite d’ajouter plus d’inputs que nécessaire pour consolider. Cela permet des consolidations opportunistes à bas prix, et réduire les frais lorsque les frais sont haut.
• maxapsfee=<n> : Budget de frais additionnels (BTC, valeur absolue) que le wallet accepte de payer pour activer l’option "avoid partial spends".
• discardfee=<amt> : Taux (BTC/kvB) indiquant votre tolérance à jeter le change en l’ajoutant aux frais. Les sorties dont la dépense coûterait plus d’un tiers de leur valeur à ce taux sont abandonnées.
• keypool=<n> : Taille du réservoir d’adresses pré-générées (défaut : 1000). Des valeurs trop faibles augmentent le risque de restaurations incomplètes.
• disablewallet=1 : Démarre Bitcoin Core sans sous-système wallet et désactive les RPC associés. Réduit la surface d’attaque et l’empreinte si le nœud ne sert qu’à la validation/relai.

Stockage, indexation et performances

• datadir=<dir> : Définit le répertoire de données principal de Bitcoin Core.
• blocksdir=<dir> : Découple l’emplacement des fichiers de blocs (blocks/blk*.dat et blocks/rev*.dat) du datadir. Peut être utile pour mettre l’archive des blocs sur un volume différent, tout en laissant la base d’état (chainstate/) sur un support plus rapide par exemple.
• dbcache=<n> : Alloue <n> Mio au cache des bases (LevelDB) utilisées par l’index des blocs et le chainstate (défaut : 450). Plus la valeur est élevée, plus l’IBD et la validation courante sont rapides, au prix d’une consommation RAM plus importante.
• prune=<n> : Active l’élagage des fichiers de blocs et fixe une cible d’espace disque en MiB (défaut : 0 = désactivé ; 1 = élagage manuel via RPC ; >=550 = élagage automatique sous la cible). Incompatible avec txindex=1. Le nœud reste pleinement validateur, mais il ne peut plus donner l’historique ancien. Cette option est particulièrement utile si votre espace disque est limité, par exemple lorsque vous installez un nœud sur votre ordinateur personnel.
• txindex=1 : Construit et maintient un index global des transactions confirmées. Indispensable pour certaines requêtes (getrawtransaction hors portefeuille) et pour des usages d’exploration, mais augmente nettement l’empreinte disque. Incompatible avec le mode élagué.
• assumevalid=<hex> : Indique un bloc que l’on présume valide, ce qui permet de sauter les vérifications de scripts pour ses ancêtres (mettre 0 pour tout vérifier). Voir le chapitre précédent pour plus d'informations.
• reindex=1 : Reconstruit l’index des blocs et l’état (chainstate) à partir des fichiers blk*.dat présents sur disque. Reconstruit aussi les index optionnels actifs. C'est une opération longue à utiliser pour réparer une base corrompue ou activer/désactiver proprement des index lourds.
• reindex-chainstate=1 : Reconstruit uniquement le chainstate à partir de l’index de blocs actuel. À privilégier quand les fichiers de blocs sont sains.
• blockfilterindex=<type> : Tient à jour des index de filtres compacts par bloc (par ex. basic) utilisés par les clients légers (BIP157/158) et certaines RPC. Désactivé par défaut (0). Consomme de l’espace disque et du temps d’indexation supplémentaires.
• coinstatsindex=1 : Maintient un index de statistiques de l’UTXO set exploité par l’appel gettxoutsetinfo. Utile pour des audits et métriques sans recalcul coûteux. Désactivé par défaut.
• loadblock=<file> : Importe au démarrage des blocs depuis un fichier externe blk*.dat. Sert à précharger l’historique depuis une source hors ligne (copie locale, support externe) pour accélérer l’initialisation.
• par=<n> : Fixe le nombre de threads de vérification de scripts (de -10 à 15, 0 = auto, <0 = laisse ce nombre de cœurs libres). Permet d’ajuster le parallélisme CPU lors de la validation. Le mode auto convient dans la plupart des cas.
• debuglogfile=<file> : Spécifie l’emplacement du journal debug.log.
• shrinkdebugfile=1 : Réduit la taille de debug.log au démarrage (défaut : 1 quand -debug n’est pas actif).
• settings=<file> : Chemin du fichier de paramètres dynamiques settings.json.

Accès RPC et sécurité opérationnelle

• server=1 : Active le serveur JSON-RPC. Indispensable si vous pilotez bitcoind via bitcoin-cli ou une application tierce. À désactiver (0) sur un nœud purement validant qui n’expose aucune API, ou qui utilise déjà un serveur Electrum.
• rpcbind=<addr>[:port] : Adresse/port d’écoute du serveur RPC. Par défaut, l’écoute se fait seulement en local (127.0.0.1 et ::1). Ce paramètre est ignoré si rpcallowip n’est pas aussi défini. Servez-vous en pour borner explicitement l’interface.
• rpcport=<port> : Port RPC (défaut : 8332 sur mainnet, 18332 sur testnet, 38332 sur signet, 18443 sur regtest).
• rpcallowip=<ip|cidr> : Autorise des clients RPC provenant d’une IP ou d’un sous-réseau donné (peut être répété). À utiliser conjointement avec rpcbind pour n’exposer l’API qu’à un segment de confiance (LAN/VPN).
• rpcauth=<USERNAME>:<SALT>$<HASH> : Méthode recommandée d’authentification RPC (mot de passe haché). Permet plusieurs entrées et évite de stocker un secret en clair.
• rpccookiefile=<path> : Chemin du cookie d’authentification (par défaut : fichier .cookie sous le datadir/). C'est utilisé pour l’accès local d'un même utilisateur sans gérer de mots de passe persistants. Par exemple, vous pouvez l'utiliser pour connecter le logiciel de gestion de portefeuille Liana à votre Bitcoin Core sur la même machine.
• rpcuser=<user> / rpcpassword=<pw> : Authentification RPC classique avec mot de passe en clair. À éviter au profit de rpcauth ou du cookie.
• rpcthreads=<n> : Nombre de threads pour servir les appels RPC (défaut : 4). Augmentez-le si vous avez de forts pics d’appels côté monitoring/outil externe.
• rpcwhitelist=<USERNAME>:<rpc1>,<rpc2>,… : Liste blanche d’APIs autorisées. Réduit la surface d’attaque en restreignant les méthodes accessibles.
• rpcwhitelistdefault=1|0 : Comportement par défaut des listes blanches : si activé et qu’une whitelist est utilisée, les appels non listés sont refusés. Cela peut aussi forcer un ensemble vide par défaut (aucun appel permis) tant que rien n’est explicitement listé.
• rest=1 : Active l’API REST publique (désactivée par défaut). À n’exposer que sur un réseau de confiance (même prudence qu’avec JSON-RPC).
• conf=<file> : Spécifie, en ligne de commande uniquement, un fichier de configuration en lecture seule. Utile pour geler un profil d’exécution (immuable) côté ops.
• includeconf=<file> : Charge un fichier de configuration additionnel (chemin relatif au datadir/). Permet de séparer les rôles : base commune + surcharge locale sensible.
• daemon=1 / daemonwait=1 : Lance bitcoind en arrière-plan et, avec daemonwait, attend la fin de l’initialisation avant de rendre la main. Cela facilite l’intégration avec des superviseurs (systemd, runit).
• pid=<file> : Emplacement du fichier PID.
• sandbox=<log-and-abort|abort> : Active le sandboxing syscalls expérimental : seules les syscalls attendues sont autorisées.
• startupnotify=<cmd> / shutdownnotify=<cmd> : Exécute une commande au démarrage ou à l'arrêt.
• alertnotify=<cmd> : Déclenche une commande sur réception d’une alerte.
• blocknotify=<cmd> : Exécute une commande à chaque nouveau bloc.
• debug=<category>|1 / debugexclude=<category> : Active/désactive des catégories de logs détaillés (ex. net, mempool, rpc, validation...).
• logips=1 : Journalise les adresses IP dans les logs.
• logsourcelocations=1 / logthreadnames=1 / logtimestamps=1 : Ajoute respectivement les emplacements source, noms de threads et horodatages précis aux logs.
• printtoconsole=1 : Envoie les traces/debug vers la console (stdout).
• help-debug=1 : Affiche l’aide des options de debug et quitte.
• uacomment=<cmt> : Ajoute un commentaire à l’User-Agent P2P.

Mettre en place son premier nœud Lightning

Intermédiaire

4.8(80)

Comprendre, installer, configurer et utiliser un nœud Lightning

4.8(80)

ProfesseurLoïc Morel

Durée7 hours

Découvrir le cours

Mettre en place son premier nœud Lightning

Comprendre, installer, configurer et utiliser un nœud Lightning

Loïc Morel

Intermédiaire

7 heures

4.8(80)

La confidentialité sur Bitcoin

Intermédiaire

4.7(177)

Comprendre et maîtriser les principes de la protection de la vie privée dans l'utilisation de Bitcoin

4.7(177)

ProfesseurLoïc Morel

Durée16 hours

Découvrir le cours

La confidentialité sur Bitcoin

Comprendre et maîtriser les principes de la protection de la vie privée dans l'utilisation de Bitcoin

Loïc Morel

Intermédiaire

16 heures

4.7(177)