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.

DCA, Dollar-cost averaging, consiste à acheter régulièrement pour le même montant. Par exemple, 500 couronnes tchèques par mois achètent davantage de bitcoin quand le prix baisse, et moins quand il monte. Il n’est plus nécessaire de deviner le meilleur moment à chaque achat. Cela ne garantit ni gain ni protection contre une baisse.

À 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 que tous les UTXO sélectionnés seront dépensés ensemble dans une transaction ultérieure. La consolidation les réunit dès maintenant en une seule sortie. Chaque transaction modélisée comporte exactement une sortie du même type que ses entrées ; aucune sortie supplémentaire n’est ajoutée pour restituer le solde non dépensé.

La taille virtuelle correspond au poids de la transaction entière divisé par 4, puis arrondi à l’entier supérieur. Les compteurs CompactSize ainsi que les champs marker et flag des données witness sont inclus. Le montant des frais est égal à la taille en vB multipliée par le taux correspondant, puis arrondi 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): —

Données récupérées (UTC): —

L’offre de Bitcoin est limitée car les règles du réseau réduisent progressivement le nombre de nouvelles unités. Personne ne peut en ajouter arbitrairement et obliger les autres à les accepter. Le calendrier d’émission est donc connu à l’avance ; 21 millions en est le résultat arrondi. Cette limite apporte de la prévisibilité, mais le prix dépend aussi de la demande.

Lorsqu’un mineur produit un bloc valide, sa première transaction peut réclamer les nouvelles unités autorisées et les frais des paiements inclus. Cette transaction s’appelle coinbase, sans rapport avec la plateforme du même nom. Les frais transfèrent du bitcoin existant et n’augmentent donc pas l’offre totale.

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 · Données récupérées: —

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 correspond au poids de la transaction entière divisé par 4, puis arrondi à l’entier supérieur. Les compteurs CompactSize ainsi que les champs marker et flag des données witness sont inclus. Le montant des frais est égal à la taille en vB multipliée par le taux correspondant, puis arrondi 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

Données récupérées: —

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.

Proof of Work aide le réseau à s’accorder sur l’ordre des transactions valides. Les mineurs cherchent un résultat de calcul acceptable pour un nouveau bloc, un lot de transactions. La recherche coûte de l’électricité et du temps ; la vérification est facile. Réécrire l’historique exige donc de refaire le travail et de rattraper la chaîne que le réseau continue d’allonger. Imaginez un tirage où chaque tentative consomme un peu d’énergie. Le mineur prend l’en-tête du bloc, un résumé de ses données, et applique deux fois SHA-256 pour calculer un hash : une empreinte numérique. Le résultat n’est pas prévisible de manière fiable. Il modifie le Nonce, un nombre auxiliaire de l’en-tête, ainsi que d’autres données, puis recommence. Le hash doit être inférieur ou égal à la cible. Les autres refont ce calcul pour le vérifier. 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.