Le vByte, abrégé vB, est une unité de taille virtuelle des transactions Bitcoin. Les différentes parties de leurs données ne comptent pas de la même façon. Le portefeuille s’en sert pour calculer les frais : une transaction plus grande ou un taux choisi plus élevé entraîne des frais totaux plus importants.
Anna veut envoyer du Bitcoin et son portefeuille propose un taux de 2 sat/vB. Sat désigne le satoshi, la plus petite unité du bitcoin ; vB indique la taille virtuelle de la transaction. Si la transaction terminée fait 127 vB, les frais à ce taux sont de 254 sat. Le taux, également appelé Fee Rate, n’est donc pas le coût total du paiement. Cet exemple explique le calcul ; il ne recommande pas un taux pour le réseau actuel. Payer des frais ne garantit pas non plus un délai précis de confirmation. [3] [5] [7]
Un portefeuille ne dépense pas son solde comme un nombre unique. Il utilise des sorties de transactions reçues auparavant et encore non dépensées, appelées UTXO. Chaque sortie utilisée ajoute une entrée ; une sortie rend aussi souvent la monnaie à votre portefeuille. Réunir de nombreux petits versements peut donc demander plus de données que dépenser un montant supérieur issu d’un seul versement. Les frais correspondent au total des valeurs d’entrée moins celui des valeurs de sortie. La signature numérique apporte la preuve de l’autorisation de dépenser les fonds sélectionnés. Avant de la créer, le portefeuille estime la taille ; seuls les frais réels et la taille finale déterminent le taux effectif. [6] [7]
L’octet est une unité courante de mesure des données. Mais pour calculer les frais d’une transaction Bitcoin, tous les octets ne comptent pas de la même façon. SegWit sépare une partie des données qui prouvent le droit de dépenser, notamment les signatures. Cette partie s’appelle witness. Un octet des données de base contribue pour 4 WU au poids de la transaction, contre 1 WU pour un octet ajouté par le format comprenant witness. WU signifie unité de poids. Les champs auxiliaires marker et flag de cette représentation bénéficient du même allègement. Les signatures restent vérifiées : un poids réduit n’autorise pas à sauter les contrôles. [1] [2]
Sérialiser consiste à écrire une transaction sous la forme d’une suite précise d’octets que les ordinateurs peuvent transmettre et lire. Appelons B sa taille sans witness et T sa taille complète. BIP 141 définit le poids par W = 3 × B + T. Les données de base sont déjà incluses dans T : la formule les compte donc quatre fois, et les données witness ajoutées une fois. Elle ne mesure ni la valeur du paiement ni le temps de calcul du processeur. [1]
La taille virtuelle est le poids divisé par 4, arrondi à l’entier supérieur : vsize = ceil(W / 4). ceil désigne cet arrondi vers le haut. Une transaction pesant 401 WU occupe donc 101 vB. L’arrondi porte sur la transaction entière. Arrondir séparément chaque entrée puis additionner peut donner un résultat différent. [1]
Prenons les tailles illustratives B = 100 et T = 208 octets. La formule donne W = 508 WU et vsize = 127 vB, la taille utilisée dans notre exemple de frais. Pourtant, la transaction complète n’a pas rétréci : sa représentation intégrale transmet toujours 208 octets. La taille virtuelle est une mesure pondérée servant à gérer capacité et frais, pas une compression du fichier. [1] [5]
Un explorateur de blocs est une application permettant de consulter les transactions et les blocs d’un réseau donné. Sans données witness, B = T, donc W = 4 × T. La taille virtuelle de base correspond alors au nombre d’octets de la transaction complète. Voilà pourquoi un explorateur affiche parfois le même nombre dans les deux champs de taille, et parfois non. Avec SegWit, on ne peut pas simplement diviser tous les octets transmis par quatre : les pondérations différentes concernent des parties précises des données. [1] [2]
Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. Bitcoin Core v29.0 utilise la taille ajustée ceil(max(W, sigop_cost × bytes_per_sigop) / 4) pour certaines règles de fonctionnement. sigop_cost représente le coût pondéré des opérations de signature ; bytes_per_sigop est un paramètre de ces règles. max retient la valeur la plus élevée. Une vérification particulièrement exigeante peut ainsi augmenter la taille utilisée. Cela ne modifie ni le poids défini par BIP 141 ni les règles de validité des blocs. C’est un détail de la version indiquée, pas un calcul supplémentaire à effectuer pour un paiement ordinaire. [1] [4]
Un paiement peut dépenser une sortie d’une autre transaction encore non confirmée. L’évaluation de ce paquet peut comparer les frais totaux pertinents à la somme des tailles virtuelles correspondantes. Une moyenne simple des taux ignorerait les différences de taille. Bitcoin Core v29.0 tient aussi compte des ajustements locaux de priorité et ne compte pas une nouvelle fois les transactions déjà présentes dans sa file d’attente. Un taux global élevé ne remplace pas les autres règles et ne garantit ni acceptation ni confirmation. [4] [8]
Avant d’envoyer, rapprochez le taux des frais totaux et de la taille estimée. Une fois la transaction créée, decoderawtransaction peut afficher les champs réels size, vsize et weight : octets, taille virtuelle et poids. Un paiement ordinaire n’exige pas de calculer les formules à la main. Attention enfin au nom CompactSize : il désigne un codage d’entier de longueur variable. Ce n’est ni un synonyme de vByte ni une méthode pour réduire la transaction. [5] [6]
Pour une vision complète, lisez aussi Block Weight, Compact Blocks, Block Propagation, Initial Block Download, Bitcoin, SegWit. Cette entrée est également citée par Compact Blocks, Pruned Node, Block Weight, Package Relay.