Calculateur de frais de transaction Bitcoin

Comment sont calculés les frais de transaction Bitcoin

Les frais sont le produit de deux nombres : fee = size in vBytes × fee rate in sat/vB. C'est toute la formule. Le reste de cette page explique d'où vient la taille, car le taux de frais est un choix que vous faites, tandis que la taille est ce que la transaction vous impose.

Ce qui n'apparaît nulle part dans la formule, c'est le montant envoyé. Une transaction qui déplace 0,001 BTC et une qui en déplace 50 coûtent la même chose si elles ont la même forme. Bitcoin facture l'espace de bloc, pas la valeur, ce qui explique pourquoi un rail de paiement construit dessus ne se comporte en rien comme un système basé sur un pourcentage.

Un taux de frais est une enchère. Les mineurs remplissent le prochain bloc avec les transactions au sat/vB le plus élevé dont ils disposent, si bien que le taux détermine votre position dans la file d'attente et que la taille détermine ce que cette position vous coûte. Augmenter le taux sur une grosse transaction est coûteux en termes absolus ; le même taux sur une petite transaction est bon marché. Les deux se confirment en même temps.

Pourquoi des vBytes et non des octets

Avant SegWit, un bloc était plafonné à 1 Mo de données de transaction sérialisées, et chaque octet comptait de la même façon. SegWit a remplacé ce plafond par une limite de 4 millions d'unités de poids et a attribué des poids différents aux deux parties d'une transaction : les données de base (tout sauf le witness) comptent 4 unités de poids par octet, les données du witness comptent 1. La taille virtuelle est le poids divisé par quatre, soit vsize = (base bytes × 3 + total bytes) / 4.

L'effet concret : les signatures ont migré dans le witness, et les signatures constituent l'essentiel d'un input. Un input P2PKH classique (legacy) porte sa signature et sa clé publique dans le scriptSig, qui sont des données de base à poids plein, pour un total d'environ 148 vB. Un input P2WPKH porte le même contenu dans le witness à un quart du poids, pour environ 68 vB. Les octets qui transitent sur le réseau ont à peine changé. Ce qui a changé, c'est la part du bloc qu'ils consomment.

Comme la réduction du witness divise par quatre, les tailles virtuelles sont souvent fractionnaires. Le marker et le flag SegWit représentent deux octets de witness, soit un demi-vByte. Le calculateur arrondit le total au vByte entier supérieur, ce qu'un nœud fait également lorsqu'il indique le vsize.

Tailles des inputs et outputs par type d'adresse

Voici les estimations à signature unique utilisées par le calculateur. Les inputs varient d'un facteur proche de trois entre le type le plus ancien et le plus récent ; les outputs varient beaucoup moins, et les outputs Taproot sont les plus grands des trois.

Au-dessus des inputs et outputs s'ajoute un overhead fixe : la version, les compteurs d'inputs et d'outputs, et le locktime. Cela représente 10 vB pour une transaction legacy et environ 10,5 vB une fois le marker et le flag SegWit inclus. Le chiffre de 57,5 vB pour l'input Taproot n'est pas un nombre rond parce qu'une signature Schnorr fait 64 octets et tombe sur un demi-vByte après la division par quatre.

Exemples concrets

Prenons la forme la plus courante en pratique : un input, deux outputs, où le second output est votre propre adresse de monnaie rendue (change).

Tout en legacy, cela donne 10 + 148 + 2 × 34 = 226 vB. À 10 sat/vB, les frais s'élèvent à 2 260 sat, soit 0,00002260 BTC.

Tout en SegWit, 10,5 + 68 + 2 × 31 = 140,5 vB, arrondi à 141. Au même taux, cela donne 1 410 sat, une réduction d'environ 38 % pour un paiement identique. L'économie provient presque entièrement de l'input.

Tout en Taproot, 10,5 + 57,5 + 2 × 43 = 154 vB, soit 1 540 sat. Taproot perd face à SegWit sur cette forme, car ses outputs coûtent 12 vB de plus chacun alors que son input n'économise que 10,5 vB. Inversez la forme et le classement s'inverse avec elle : deux inputs et un output donnent 169 vB pour Taproot contre 178 vB pour SegWit. Taproot devient rentable quand vous dépensez de nombreuses pièces, pas quand vous en créez beaucoup.

Passons maintenant à une consolidation. Vingt inputs P2WPKH regroupés en un seul output donnent 10,5 + 20 × 68 + 31 = 1 401,5 vB, arrondi à 1 402. À 3 sat/vB, cela coûte 4 206 sat. Le même wallet, effectuant un paiement ordinaire à partir d'un seul de ces inputs, paierait environ 423 sat. Dix fois la taille pour un dixième du taux, voilà le compromis d'une consolidation, et il n'a de sens que tant que la mempool est calme.

Un même motif traverse ces quatre cas : le nombre d'inputs est le terme dominant. Un wallet ayant reçu une centaine de petits paiements détient une centaine d'UTXO, et les dépenser coûte cent inputs, quelle que soit la faible valeur de chacun. En dessous d'un certain taux de frais, un UTXO coûte plus cher à dépenser qu'il ne contient.

Ce que l'estimation ne couvre pas

Les tailles ci-dessus supposent des dépenses à signature unique et un type d'adresse uniforme sur tous les inputs et outputs. Trois éléments font varier le chiffre réel :

La longueur de la signature varie. Une signature ECDSA encodée en DER fait généralement 71 ou 72 octets, parfois 70, si bien que chaque input legacy ou P2WPKH peut différer d'un octet par rapport à l'estimation. Les signatures Schnorr font un nombre fixe de 64 octets, ce qui explique pourquoi les dépenses Taproot sont les seules dont la taille est exactement prévisible à l'avance.

Les types mixtes sont courants. Les wallets dépensent souvent un input legacy tout en envoyant vers une adresse bech32 avec une monnaie rendue bech32. Calculez chaque partie avec la ligne correspondante du tableau et n'ajoutez l'overhead qu'une seule fois ; le calculateur applique un seul type à l'ensemble, ce qui est le bon modèle pour une transaction à wallet unique et une approximation pour tout le reste.

Les dépenses multisig et par script forment une catégorie entièrement différente. Un input P2WSH en 2-sur-3 fait plusieurs fois la taille d'un input à signature unique, et une dépense Taproot par chemin de script porte le script et le bloc de contrôle dans le witness. Aucun des deux n'est couvert ici.

Lire et payer les frais depuis votre code

Une estimation de frais n'est utile qu'à côté d'un taux actuel, et ce taux provient de la mempool, pas d'une formule. Les endpoints Bitcoin de Chaingateway vous déchargent de ce taux : POST /api/v2/bitcoin/transactions accepte un speed valant fast, medium ou slow et sélectionne les frais en conséquence, ainsi qu'un flag subtractfee qui retire les frais du montant envoyé au lieu de les ajouter par-dessus. Ce flag compte plus qu'il n'y paraît : c'est la différence entre un destinataire qui reçoit exactement ce que votre facture indiquait et un destinataire qui reçoit un peu moins.

La liste complète des endpoints, y compris les blocs, les wallets et les webhooks de transaction, se trouve sur la page API Bitcoin. Les autres calculateurs et outils de référence sont regroupés sous Outils.

Questions fréquentes

Comment calcule-t-on les frais d'une transaction Bitcoin ?

La taille en vBytes multipliée par le taux de frais en satoshi par vByte. Une transaction de 141 vB à 10 sat/vB coûte 1 410 sat. Le montant envoyé n'entre jamais dans le calcul.

Qu'est-ce qu'un vByte ?

Un octet virtuel, l'unité dans laquelle les blocs sont mesurés depuis SegWit. Le poids d'une transaction compte les données de base pour 4 unités par octet et les données witness pour 1, et la vsize est ce poids divisé par quatre. Les octets witness coûtent donc un quart du prix des octets de base.

Quelle est la taille typique d'une transaction Bitcoin ?

Pour un input et deux outputs : environ 226 vB en tout Legacy, 141 vB en tout SegWit, 154 vB en tout Taproot. Chaque input supplémentaire ajoute 148, 68 ou 57,5 vB selon le type, ce qui explique pourquoi le nombre d'inputs pèse plus sur les frais que tout le reste.

Le montant envoyé change-t-il les frais ?

Non. Bitcoin facture l'espace bloc. Envoyer 0,001 BTC ou 50 BTC coûte pareil si les deux transactions ont le même nombre d'inputs et d'outputs et les mêmes types d'adresse.

Pourquoi plus d'inputs rend-il une transaction plus chère ?

Chaque pièce dépensée est un input distinct qui porte sa propre signature, et une signature représente l'essentiel de la taille d'un input. Dix petits UTXO coûtent dix inputs à dépenser. C'est pour cela que les wallets consolident pendant les périodes calmes, quand le taux sat/vB est assez bas pour rendre une grosse transaction ponctuelle bon marché.

Que signifie sat/vB ?

Satoshi par vByte, le prix que vous proposez pour l'espace bloc. Un satoshi vaut 0,00000001 BTC, donc 100 000 000 sat font un BTC. Les mineurs classent la mempool selon ce taux, c'est pourquoi c'est le taux, et non les frais totaux, qui détermine la rapidité de confirmation d'une transaction.

Taproot est-il moins cher que SegWit ?

Seulement quand la transaction compte beaucoup d'inputs. Un input P2TR pèse environ 57,5 vB contre 68 vB pour P2WPKH, mais un output P2TR pèse 43 vB contre 31 vB. Un input et deux outputs donnent 154 vB avec Taproot et 141 vB avec SegWit ; deux inputs et un output inversent ce résultat, 169 vB contre 178 vB.

Pourquoi mon wallet affiche-t-il des frais légèrement différents ?

Trois causes habituelles. Les signatures ECDSA varient entre 70 et 72 octets, donc chaque input Legacy ou P2WPKH peut différer d'un octet par rapport à l'estimation. Les wallets mélangent souvent les types d'adresse entre les inputs, l'output de paiement et l'output de monnaie. Et un wallet choisit son propre taux de frais à partir de sa propre vue de la mempool, alors que ce calculateur utilise le taux que vous saisissez.