Package Relay permet aux nœuds Bitcoin de transmettre et d’évaluer ensemble des transactions liées, encore non confirmées. Cela sert notamment lorsque la première offre trop peu de frais et qu’une autre, qui dépense sa sortie, en ajoute assez pour les deux. Leur validité et les règles locales restent obligatoires ; l’examen du paquet ne garantit pas sa confirmation.
Anna attend un paiement en bitcoin. L’expéditeur a choisi des frais faibles et la demande d’espace dans les blocs a augmenté depuis. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. Certains nœuds refusent donc la transaction dans leur mempool, leur ensemble local de transactions non confirmées. Anna souhaite ajouter des frais grâce à une transaction suivante. Mais celle-ci dépense des fonds dont le nœud ayant refusé la première ne connaît pas encore l’arrivée. Package Relay aide à combler ce manque : il fournit le contexte nécessaire pour ne pas examiner seulement la première transaction, peu rémunératrice, de manière isolée. [1] [6]
La première transaction est le parent ; celle qui dépense sa sortie est l’enfant. Anna peut créer un enfant si elle peut satisfaire les conditions de dépense d’une sortie du parent, c’est-à-dire d’un montant précis pouvant être dépensé. Elle pourrait transférer les fonds reçus vers une autre de ses adresses et en consacrer une partie aux frais. C’est le principe de CPFP (Child Pays for Parent) : les frais plus élevés de l’enfant peuvent favoriser la confirmation des deux. Package Relay facilite leur transmission et leur examen ; il ne paie rien, ne signe rien et ne donne pas accès aux fonds d’autrui. [1] [5]
Prenons un parent de 200 vB payant 200 sat et un enfant de 100 vB payant 1300 sat. Le vByte (vB) mesure la taille virtuelle d’une transaction, couramment utilisée pour calculer les frais ; le sat est une petite unité de bitcoin. Ensemble, ils paient 1500 sat pour 300 vB, soit 5 sat/vB. Ce n’est pas la moyenne simple des taux individuels de 1 et 13 sat/vB. Nous supposons uniquement ces deux transactions pas encore acceptées, sans autre ancêtre non confirmé ni ajustement local des frais. Un nœud ne recompte pas les transactions déjà acceptées : l’ensemble exact des dépendances examinées compte. [5] [3]
Une entrée de l’enfant désigne une sortie du parent. Les examiner ensemble peut être utile, mais ne permet pas d’ignorer un historique manquant. Dans la liste, chaque parent inclus précède son enfant : c’est l’ordre topologique. Les signatures et toutes les autres règles de validité restent vérifiées. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Deux transactions dépensant les mêmes fonds ne deviennent pas compatibles grâce à des frais supplémentaires. Les limites de nombre, de taille et de structure du paquet bornent aussi le travail du nœud ; elles n’autorisent pas une chaîne arbitrairement longue. [5] [3] [7]
Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. La réception signifie que le nœud a obtenu les données. L’acceptation signifie qu’il les a admises dans son mempool selon ses règles. La confirmation exige l’inclusion dans un bloc. Chaque nœud possède son propre mempool ; un succès local ne dit rien de la décision du voisin. Dans Bitcoin Core 28.0, le taux combiné peut dépasser le seuil variable d’un mempool encombré, sans supprimer généralement le minimum distinct exigé pour le relais. Cette version prévoit une exception pour TRUC Transactions, un type soumis à des restrictions particulières. Un enfant très rémunérateur ne sauve donc pas n’importe quel parent. [2] [5] [8]
BIP 331, de Gloria Zhao, décrit la négociation de la prise en charge et les messages permettant de demander des informations sur les ancêtres puis les transactions. C’est une proposition plus large. Bitcoin Core 28.0 documentait l’association limitée d’un parent avec un enfant via le protocole réseau existant. Son interface de programmation locale RPC pouvait aussi accepter un enfant avec plusieurs parents indépendants, sans que cela implique le même relais entre nœuds. Ces précisions concernent cette version ; pour une autre, il faut vérifier sa documentation et les capacités du pair. [1] [2]
La commande submitpackage de Bitcoin Core 28.0 soumet un paquet préparé au nœud local. Elle attend un enfant et ses parents non confirmés, sans dépendances entre ces parents, avec l’enfant à la fin. Il faut lire package_msg avec les différents tx-results. Le nœud peut accepter une partie du paquet : une erreur n’annule pas automatiquement ce qui a déjà été accepté. Même un succès global ne prouve ni la propagation sur le réseau ni la confirmation. Ce n’est pas un service universel d’accélération : il faut fournir des transactions correctement construites, pas seulement des adresses. [3]
Dans un environnement de test séparé, testmempoolaccept vérifie l’acceptation sans diffusion. Si une autre transaction échoue, allowed peut manquer parce que la transaction concernée n’a pas été entièrement validée. L’appel de test et submitpackage n’appliquent pas non plus exactement les mêmes conditions. Notez la version, les réglages, les dépendances, les tailles et les frais, puis observez séparément l’acceptation par un autre nœud. Les transactions soumises à des délais dans Lightning Network demandent toujours une réaction à temps : Package Relay ne supprime à lui seul ni la congestion, ni l’irrégularité des blocs, ni le pinning, l’exploitation délibérée des règles du mempool pour entraver la hausse des frais. [4] [2] [1]
Pour une vision complète, lisez aussi Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. Cette entrée est également citée par CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.