Calculateurs et modèles
aux hypothèses expliquées.

Utilisez un point ou une virgule pour les décimales et une espace pour les milliers.

Le DCA, ou Dollar-cost averaging, consiste à acheter pour un montant fixe en monnaie locale à intervalles réguliers, plutôt que chercher un unique moment idéal. Il réduit les décisions de timing et peut limiter les transactions émotionnelles, mais ne garantit aucun profit, n’empêche pas les pertes et ne règle pas la garde.

À chaque achat modélisé, nous divisons le montant par le prix historique. La somme de ces fractions donne le total de BTC, valorisé au dernier prix de la série. Les versements sont le montant multiplié par le nombre d’achats ; la variation en pourcentage est (valeur / versements − 1) × 100. Ce rendement n’est pas annualisé.

Une année représente ici 365 jours. Le premier achat utilise la première observation disponible. Le modèle hebdomadaire choisit la suivante au moins sept jours après l’achat précédent ; le modèle mensuel, la première de chaque mois UTC, y compris les mois partiels aux extrémités. Le nombre peut donc différer de 52 ou 12 par an.

Nous utilisons CoinGecko, puis Yahoo Finance en secours. Pour les monnaies autres que l’USD, le modèle Yahoo peut combiner BTC/USD au dernier taux USD de la monnaie disponible au plus tard à la date du point, âgé de sept jours au maximum. Les données peuvent être en cache. La série doit commencer et finir à moins de sept jours des bornes demandées et ne comporter aucun trou de plus de huit jours ; sinon aucun résultat n’est produit. Les dates extrêmes réelles et la source sont affichées.

Le modèle exclut spread, frais, impôts et coûts de garde. Il calcule des fractions mathématiques de BTC ; l’affichage est arrondi et les achats réels en satoshis entiers peuvent différer. C’est un calcul historique, pas une prévision ni une consigne d’achat.

Le DCA répartit les achats dans le temps, mais ne rend pas le bitcoin sans risque et ne garantit aucun rendement.

Utilisez un point ou une virgule pour les décimales et une espace pour les milliers.

Saisissez un nombre entier d’entrées de 1–500 et des taux de 0–1 000 000 sat/vB. Les champs vides ou invalides masquent le résultat.

Différence nette = frais sans consolidation − somme des deux frais avec consolidation. Un résultat positif indique une économie modélisée ; négatif, un surcoût. Avec une entrée, aucune entrée n’est regroupée.

Les deux scénarios supposent dépenser tous les UTXO choisis ensemble dans une transaction ultérieure. La consolidation les réunit aujourd’hui en une sortie. Chaque transaction modélisée a exactement une sortie du même type que les entrées ; aucune sortie de monnaie supplémentaire n’est incluse.

La taille virtuelle est le poids de la transaction entière divisé par 4, arrondi au supérieur. Les compteurs CompactSize et witness marker/flag sont inclus. Chaque frais est la taille en vB multipliée par le taux correspondant, arrondie au satoshi supérieur.

Nous supposons des clés publiques compressées et des signatures ECDSA de 72 octets, sighash inclus. P2SH désigne ici uniquement P2SH-P2WPKH. Taproot utilise key path, une signature de 64 octets avec sighash par défaut et sans annex ; script path et multisig sont exclus.

Vous fournissez les taux : ce ne sont ni des estimations en direct ni des garanties de confirmation. Zéro et le plafond sont des limites du modèle, pas des règles réseau. Les valeurs UTXO sont inconnues : fonds, dust et acceptation du portefeuille ne sont pas vérifiés. Les signatures et la construction réelles peuvent modifier la taille.

Regrouper des entrées peut relier leur propriété pour un observateur et réduire la confidentialité. Une différence positive de frais ne suffit pas à recommander la consolidation.

Le calcul s’exécute dans le navigateur sans demander de données réseau. L’outil ne crée ni ne diffuse de transaction et ne nécessite ni adresse ni clés.

Utilisez un point ou une virgule pour les décimales et une espace pour les milliers.

Saisissez une hauteur entière de 0–6 930 000. Un champ vide ou invalide masque le résultat.

Chargement…

Source de la hauteur chargée: —

Heure de préparation de la réponse réseau (UTC): —

Dernière réponse (UTC): —

L’offre de Bitcoin est limitée parce qu’un bloc valide ne peut créer de nouvelles unités que selon un calendrier décroissant de subvention de bloc. Chaque nœud entièrement validant contrôle cette règle lui-même. Les célèbres 21 millions sont le résultat arrondi de ce calendrier, et non un nombre conservé dans la base de données d’une entreprise.

Un mineur peut inclure une transaction coinbase dans un bloc valide. Le total de ses sorties ne doit pas dépasser la subvention d’émission autorisée à cette hauteur de bloc, augmentée des frais de transaction. Les frais transfèrent des bitcoins existants ; seule la subvention crée de nouvelles unités. Un bloc dont la récompense coinbase est excessive est invalide.

Sur le réseau principal, la subvention commence à 50 BTC et est divisée par deux tous les 210 000 blocs, avec troncature au satoshi entier. Le dernier bloc à subvention positive est à 6 929 999 ; dès 6 930 000 elle est nulle. Le restant utilise le total théorique exact, pas les 21 millions arrondis.

La somme comprend chaque subvention autorisée de la hauteur 0 jusqu’au bloc choisi inclus. Ce n’est ni l’offre circulante ni dépensable : elle inclut les 50 BTC non dépensables du bloc genesis et ne retranche ni subventions non réclamées ni pièces perdues. Les frais ne sont pas une nouvelle émission.

La date n’est estimée que pour la hauteur chargée : heure de préparation de la réponse plus blocs restants multipliés par 10 minutes. Ce n’est ni l’heure de minage du bloc ni une échéance fixe. Les données mempool.space ou de secours Blockchain.com peuvent être en cache ; les intervalles réels varient.

Utilisez un point ou une virgule pour les décimales et une espace pour les milliers.

Saisissez des nombres entiers : entrées 1–500, sorties 1–50 ; taux 0–1 000 000 sat/vB. Les champs vides ou invalides masquent les résultats.

Cours de référence pour 1 BTC: Chargement…

Source non indiquée · Dernière réponse: —

Toutes les entrées et sorties utilisent le type choisi. Comptez les sorties destinataires et de monnaie rendue ; l’outil n’en ajoute aucune automatiquement. Les types mixtes et autres scripts sont hors modèle.

La taille virtuelle est le poids de la transaction entière divisé par 4, arrondi au supérieur. Les compteurs CompactSize et witness marker/flag sont inclus. Chaque frais est la taille en vB multipliée par le taux correspondant, arrondie au satoshi supérieur.

Nous supposons des clés publiques compressées et des signatures ECDSA de 72 octets, sighash inclus. P2SH désigne ici uniquement P2SH-P2WPKH. Taproot utilise key path, une signature de 64 octets avec sighash par défaut et sans annex ; script path et multisig sont exclus.

Vous fournissez les taux : ce ne sont ni des estimations en direct ni des garanties de confirmation. Zéro et le plafond sont des limites du modèle, pas des règles réseau. Les valeurs UTXO sont inconnues : fonds, dust et acceptation du portefeuille ne sont pas vérifiés. Les signatures et la construction réelles peuvent modifier la taille.

Valeur des frais en devise = frais en satoshi / 100 000 000 × cours de référence par BTC. Le cours ne modifie ni le taux sat/vB saisi ni les frais en satoshi.

La conversion monétaire est indicative : le cours peut être en cache et exclut spread, frais et prix réel d’exécution. L’affichage utilise les décimales de la monnaie ; l’arrondi ne remplace pas un décompte exact. Rechargez le cours avec le bouton. L’heure indique la réception de la réponse, pas la mesure du prix.

Utilisez un point ou une virgule pour les décimales et une espace pour les milliers.

Saisissez des nombres finis non négatifs ; frais de pool 0–100 %. Le hashrate de l’appareil ne doit pas dépasser celui du réseau chargé. Les valeurs invalides masquent le résultat ; un prix électrique vide ne vaut pas zéro.

Le prix électrique par défaut n’est qu’un paramètre du modèle. Nous le conservons dans la devise de sa dernière saisie manuelle, puis le convertissons avec les cours de référence disponibles. Sans cours, le champ reste vide jusqu’à votre saisie. Ce n’est pas une offre de fournisseur.

Chargement…

Hashrate réseau estimé: —

Hauteur de bloc chargée: —

Subvention de bloc utilisée: —

Cours de référence pour 1 BTC: — · Source non indiquée

Dernière réponse: —

1 TH/s = 10¹² H/s. La part de hashrate de l’appareil est multipliée par 144 blocs par jour, la subvention chargée et (1 − frais de pool / 100). Énergie = W / 1 000 × 24 heures. Différence = valeur BTC attendue − électricité ; 30 jours valent trente fois cette même journée.

Nous supposons un fonctionnement continu, 10 minutes par bloc en moyenne et des paramètres constants. Revenus de frais de transaction, matériel, amortissement, refroidissement supplémentaire, impôts et arrêts sont exclus. Paiements et variance dépendent du pool ; l’espérance mathématique n’est ni une promesse de versement ni un bénéfice net complet. L’affichage est arrondi et peut représenter des fractions de satoshi.

Le hashrate réseau est déduit des blocs, pas mesuré sur chaque appareil. mempool.space ou Blockchain.com peuvent utiliser des fenêtres différentes ; la source de hauteur est distincte. Données et cours peuvent être en cache. L’heure de réponse n’est pas celle de mesure de chaque donnée.

La conversion monétaire est indicative : le cours peut être en cache et exclut spread, frais et prix réel d’exécution. L’affichage utilise les décimales de la monnaie ; l’arrondi ne remplace pas un décompte exact. Rechargez le cours avec le bouton. L’heure indique la réception de la réponse, pas la mesure du prix.

Le mineur cherche un hachage d’en-tête ne dépassant pas la cible. Une preuve de travail valide ne suffit pas si le reste du bloc enfreint les règles. Le créateur du modèle sélectionne les transactions. Dans un pool, l’opérateur remplit souvent ce rôle ; le propriétaire du matériel de hachage ne contrôle pas nécessairement la sélection. Le minage consomme de l’électricité et du matériel. La récompense comprend l’émission nouvelle et les frais ; les recettes ne sont pas le bénéfice et les versements du pool dépendent de ses conditions.

Curseurs : n de 2 à 7, m de 1 à n et L de 0 à n. Réduire n ramène aussi m et L à n si nécessaire. Ce sont les limites du simulateur, pas une limite générale de Bitcoin ; m = 1 illustre un seuil d’une seule signature.

Clés disponibles A = n − L. Le seuil est atteint si A ≥ m ; la marge restante vaut max(0, A − m) et le déficit max(0, m − A). Les clés sont supposées distinctes et tous les détenteurs disponibles capables et disposés à signer. Une autre copie de sauvegarde de la même clé n’ajoute pas de signature indépendante.

Exemple 2 sur 3 : sans perte, la marge est de 1 clé ; avec 1 clé indisponible, le seuil reste atteint mais la marge est de 0 ; avec 2 clés indisponibles, il manque 1 signature. L’indisponibilité peut être temporaire ; elle ne signifie pas automatiquement une perte définitive des fonds.

La restauration exige aussi la configuration correcte du portefeuille : seuil, clés publiques de tous les participants, leur ordre ou règle de tri, type de script et éventuels chemins de dérivation. Un Output Descriptor peut consigner ces informations. Disposer d’assez de clés privées peut ne pas suffire à restaurer les adresses ; la configuration publique ne remplace pas les signatures.

Le modèle exclut les clés volées, les causes de défaillance communes, les autres conditions de script et la compatibilité des portefeuilles. Des signatures disponibles ne garantissent pas une protection contre le vol. Aucune clé réelle n’est saisie ; le simulateur ne crée pas de portefeuille, ne signe ni ne diffuse de transactions et ne nécessite pas de données en direct.