SIGHASH_ALL

C'est l'indicateur que votre portefeuille utilise, et c'est la raison pour laquelle approuver une transaction sur l'écran d'un portefeuille matériel a un sens. Sa valeur est 1, et vous pouvez la voir comme le dernier octet de presque toutes les signatures sur un explorateur de blocs. Taproot a renommé la valeur par défaut en SIGHASH_DEFAULT et a cessé d'écrire l'octet, ce qui économise un octet par signature.

Comment cela fonctionne

Sous SIGHASH_ALL, l'empreinte couvre la version de la transaction, chaque outpoint dépensé, chaque numéro de séquence, chaque montant de sortie, chaque script de sortie et le locktime.

Modifiez un seul satoshi d'une seule sortie et toutes les signatures de la transaction meurent. Ajoutez une entrée, supprimez une sortie, réordonnez-les, décalez le locktime : même résultat. C'est ce que l'on veut dire quand on affirme qu'une transaction bitcoin signée est définitive dans son contenu avant même d'être diffusée. La seule décision qui reste à quiconque est de l'envoyer ou non.

Une chose est délibérément exclue : les scripts de déverrouillage des autres entrées. Si l'empreinte les couvrait, alors dans une transaction à deux signataires chaque signature devrait être faite après l'autre, ce qui est circulaire et impossible. Les laisser de côté est ce qui permet à des parties indépendantes de signer la même transaction dans l'ordre qu'elles veulent.

L'encodage varie selon le type d'entrée. Sur une entrée legacy ou segwit version 0, l'octet 01 est ajouté à la signature encodée en DER, d'où le total familier de 71 ou 72 octets. Sur une dépense Taproot par chemin de clé, le BIP341 définit une valeur de zéro comme SIGHASH_DEFAULT, ce qui signifie une couverture identique sans qu'aucun octet soit écrit, la signature faisant donc exactement 64 octets. Écrire 01 explicitement sur une entrée Taproot reste valide et produit la même empreinte, cela coûte simplement un octet de plus pour rien.

Où le voir

SIGHASH_ALL est utilisé presque partout : Bitcoin Core, Electrum, Sparrow, tous les portefeuilles matériels et tous les moteurs de retrait de plateforme d'échange signent ainsi par défaut, et aucun d'eux ne propose de réglage pour le changer.

La conséquence pratique est celle que vous ressentez quand un paiement reste bloqué. Comme les frais correspondent à ce qui reste entre les entrées et les sorties, et que les sorties sont toutes signées, vous ne pouvez pas retirer quelques milliers de satoshis d'une sortie pour augmenter les frais. La transaction doit être reconstruite et signée à nouveau depuis le début, ce que seul le portefeuille qui détient les clés peut faire. C'est pourquoi le remplacement par des frais plus élevés est une fonction de portefeuille émetteur plutôt qu'une opération qu'une plateforme d'échange ou un explorateur de blocs peut effectuer pour votre compte, et pourquoi le mécanisme child-pays-for-parent existe comme porte de sortie lorsque l'expéditeur est injoignable.

C'est aussi ce qui transforme l'écran d'un portefeuille matériel en contrat plutôt qu'en suggestion. L'appareil affiche la destination, le montant et les frais, et comme la signature qu'il produit ensuite couvre ces trois éléments, aucun logiciel en aval ne peut en modifier un seul sans jeter cette signature. Approuvez ce que l'écran indique et rien d'autre ne peut se produire.

SIGHASH_ALL vs SIGHASH_NONE

SIGHASH_ALL engage la liste complète des sorties ; SIGHASH_NONE n'en engage aucune. L'écart entre les deux est l'écart entre un paiement et une simple autorisation de déplacer un bitcoin vers un endroit non précisé. Les deux indicateurs sont séparés d'une valeur, de sorte qu'une bibliothèque de signature qui accepte l'indicateur comme paramètre entier est à une faute de frappe de transformer le retrait d'un client en un bitcoin que quiconque surveille la mempool peut rediriger. Le code de signature de production devrait coder la valeur en dur plutôt que de la prendre en entrée.