Transaction TRUC

TRUC est une politique de relais qu'un émetteur adopte volontairement en fixant la version d'une transaction à 3, ce n'est pas une règle de consensus. Bitcoin Core 28,0 l'a rendue standard dans le cadre du BIP 431, qui plafonne la transaction à 10 000 octets virtuels et son enfant à 1 000. Vous ne la définirez pas vous-même : le BIP 431 destine cette politique à des protocoles tels que Lightning, dont les transactions d'engagement sont pré-signées et dont les frais sont augmentés au moment de la diffusion.

Comment cela fonctionne

TRUC est un ensemble de six règles greffées sur une transaction ordinaire, et un émetteur les active toutes les six d'un coup en fixant le champ de version à 3.

La règle un rend la transaction remplaçable, qu'elle signale ou non l'ancienne méthode BIP125, une distinction que la même version a de toute façon rendue sans objet en adoptant par défaut le remplacement complet par les frais. La règle deux rend le choix contraignant : chaque ancêtre non confirmé d'une transaction TRUC doit être TRUC, et chaque descendant non confirmé d'une transaction TRUC doit être TRUC aussi, de sorte que personne ne contourne les limites en attachant un enfant ordinaire, même si les bitcoins confirmés sont exemptés dans les deux sens. La règle trois est la restriction dont le nom est tiré, un ancêtre non confirmé et un descendant non confirmé, sans dérogation CPFP. La règle quatre plafonne la transaction à 10 000 octets virtuels, contre un plafond de standardité de 100 000 pour tout le reste. La règle cinq plafonne l'enfant à 1 000 octets virtuels, ce qui, avec des entrées taproot, laisse encore de la place pour 15 entrées et 2 sorties. La règle six permet à la transaction de se situer sous les frais de relais minimaux du nœud, y compris à zéro, à condition que le paquet qui l'entoure paie suffisamment.

La raison de tout cela est l'épinglage : les déchets d'un tiers rendent votre transaction impossible à augmenter. Les règles de remplacement exigent qu'un remplacement paie plus de frais absolus que tout ce qu'il déplace, et refusent catégoriquement tout remplacement qui évincerait plus de 100 transactions. Le BIP 431 chiffre la facilité avec laquelle cela peut être abusé. Si vous voulez remplacer cinq de vos propres transactions et qu'une contrepartie a attaché 21 descendants à chacune, votre remplacement est rejeté sur le seul décompte, quel que soit ce qu'il paie. Quiconque peut accrocher des descendants bon marché à votre transaction non confirmée fixe le prix de votre propre augmentation de frais.

La limite d'enfant de 1 000 octets virtuels est la réponse directe à cela. Selon les limites de descendants par défaut, un enfant qui augmente les frais peut lui-même faire 100 000 octets virtuels, et à un satoshi par octet virtuel, c'est 100 000 satoshis ou plus qu'un remplacement doit couvrir avant de rivaliser sur le fond. Plafonner l'enfant à 1 000 réduit la borne supérieure d'un facteur cent.

Deux mécanismes accompagnent les règles. L'éviction des transactions sœurs permet à un nœud qui rencontre un second enfant mieux payé d'évincer le premier selon les règles de remplacement au lieu de rejeter le nouveau venu, et comme un seul enfant peut exister, aucun doute sur lequel écarter. Le remplacement par les frais au niveau du paquet, que Bitcoin Core 28,0 a activé pour les groupes connectés de taille deux, fonctionne alors sur les transactions TRUC parce que cette forme est garantie.

Pourquoi cela compte quand vous achetez du bitcoin

TRUC atteint un détenteur ordinaire de bitcoin à un moment précis, lorsqu'un canal Lightning doit être fermé on-chain et que les frais doivent être augmentés après la signature de la transaction.

L'achat n'est pas le point sensible. Sur les 41 avis de portefeuilles de ce site, ceux qui installent un véritable nœud Lightning sur votre téléphone sont ceux où la politique cesse d'être anecdotique. Phoenix, d'ACINQ, est noté 4,0 ici et fait tourner un nœud autonome derrière une phrase de récupération de 12 mots, et la voie d'urgence documentée par ACINQ consiste à forcer la fermeture, attendre environ 720 blocs, soit environ cinq jours, et récupérer les fonds on-chain avec un outil tel qu'Electrum. Cette fermeture diffuse une transaction d'engagement, que le BIP 431 désigne comme celle qui s'appuie sur la dérogation CPFP pour éviter l'épinglage. Une transaction d'engagement qui ne peut pas être poussée dans un bloc avant l'expiration d'un délai ne reste pas simplement là : l'argent qu'elle protégeait devient réclamable par l'autre partie.

La conservation déplace l'exposition, c'est la différence entre nos fiches. Strike, noté 4,6, vous permet de retirer via Lightning et n'ajoute aucun frais qui lui soit propre sur les transferts, mais les soldes sont conservés par la plateforme tant qu'ils restent dans l'application, donc les canaux et leurs fermetures appartiennent à Strike. Muun, noté 3,8, affiche l'on-chain et Lightning comme un seul solde et passe de l'un à l'autre par des swaps sous-marins. Plus vous détenez réellement une part d'un canal, plus une augmentation de frais fiable devient votre problème, et TRUC est la politique écrite pour en fournir une au sein de l'ensemble des nœuds qui l'exécutent.

Une fermeture forcée Phoenix, épinglée et non épinglée

Une fermeture forcée Phoenix est l'endroit le plus clair pour observer TRUC à l'œuvre, car la transaction diffusée a été signée bien avant que quiconque sache à quoi ressemblerait le marché des frais.

Prenez d'abord l'ancien dispositif. Votre engagement est une transaction ordinaire qui ne déclare pas la version 3, diffusée avec un enfant qui paie pour les deux. Votre contrepartie détient la seconde sortie d'ancrage, qui existe pour que l'un ou l'autre côté puisse augmenter les frais, et elle s'en sert pour attacher son propre enfant de 100 000 octets virtuels qui paie un satoshi par octet virtuel. Rien de ce qu'elle a fait n'est invalide. La dérogation CPFP vous laissait glisser un enfant supplémentaire au-delà de la limite de descendants, mais les règles de remplacement s'en moquent : déplacer son enfant signifie payer les 100 000 satoshis de frais qu'il porte déjà avant que vos propres frais comptent pour quoi que ce soit, et la dérogation n'accordait qu'un seul enfant supplémentaire, donc elle a échoué dès qu'un tiers a partagé la transaction. Votre fermeture est épinglée par des déchets qui n'ont presque rien coûté à leur auteur.

Fixez maintenant les deux transactions à la version 3. L'engagement est autorisé à ne rien payer du tout, car la règle six l'accepte sous le seuil de relais tant que le paquet franchit la barre, ce dont une transaction signée des mois à l'avance a besoin. Un seul enfant peut exister, et il ne peut pas dépasser 1 000 octets virtuels, donc la pire facture qu'on puisse vous présenter est le centième de l'ancienne. Si la contrepartie fait passer son enfant en premier, le vôtre l'évince en payant plus. Et la paire voyage comme une unité, car Bitcoin Core 28,0 a livré le relais de paquet un parent un enfant dans la même version, avec des parents TRUC autorisés sous le taux de frais de relais minimal.

La réserve honnête est l'adoption. Le BIP 431 indique que l'avantage anti-épinglage se limite à la mempool d'un nœud individuel, et la sécurité de votre transaction dépend de la part du réseau qui exécute la politique. La version 3 était non standard avant Bitcoin Core 28,0, donc un nœud encore sur une version plus ancienne ne la relaiera pas du tout, et les notes de version qualifient ce nouveau relais de paquet de limité et pas encore fiable dans des conditions adverses.

Transaction TRUC vs numéro de version de transaction

Le numéro de version de transaction est un champ porté par chaque transaction bitcoin, et TRUC est l'ensemble des règles qu'une valeur de ce champ achète désormais.

Fixer la version à 3 est la façon dont un émetteur l'adopte, mais ce n'est pas dans le champ que résident les règles. C'est un indicateur ; tout ce qui compte se passe dans le code de politique d'un nœud, c'est pourquoi un nœud mis à jour relaie la transaction qu'un plus ancien refuse. Le consensus n'a jamais pris position dans un sens ou dans l'autre. Le BIP 431 consigne que la version 3 était auparavant non standard sans conflit connu avec des usages antérieurs, donc ce qui a changé dans Bitcoin Core 28,0 est la relayabilité, pas la validité.

Transaction TRUC vs mempool en grappes

La mempool en grappes applique des limites de topologie à chaque transaction de la mempool d'un nœud, tandis que TRUC applique des limites bien plus strictes uniquement aux transactions qui les demandent.

Les deux sont des travaux apparentés plutôt que rivaux, et le BIP 431 le dit directement : la mempool en grappes limite la taille des grappes pour toutes les transactions, pas seulement celles qui l'adoptent, et est bien moins restrictive que les limites TRUC. Elle laisse aussi des lacunes que le BIP 431 nomme : la mempool en grappes ne résout pas l'épinglage par les frais absolus ni par le nombre de conflits, et elle est incompatible avec la dérogation CPFP sur laquelle s'appuyait l'ancienne conception des canaux Lightning. TRUC, l'éviction des transactions sœurs et le remplacement au niveau du paquet sont la voie offerte aux protocoles qui en dépendaient.