Multisignature

Curiosité

1. Pourquoi un script nécessitant deux signatures retire-t-il trois éléments de la pile ?
2. Comment une chaîne d’octets vide peut-elle être une règle de consensus et non une simple convention ?
3. Qu’est-ce qui change lorsque dix clés s’agrègent en une seule signature impossible à distinguer de celle d’un signataire unique ?

Explorer

1. Les scripts multisignatures exigent qu’au moins m signatures soient valides au regard des n clés publiques listées. Le script de verrouillage liste m, les n clés publiques et n ; OP_CHECKMULTISIG dépile n, les n clés, m, puis m signatures, qui doivent correspondre aux clés dans l’ordre listé. Si moins de m signatures valides sont fournies, la dépense est invalide.
2. Une erreur de programmation dans l’implémentation d’origine fait que OP_CHECKMULTISIG dépile un élément de plus que les signatures requises. Cet élément « factice » (dummy) est ignoré lors de la vérification cryptographique mais doit être présent ; s’il manque, la pile est épuisée prématurément (stack underflow) et la transaction échoue. Les premiers utilisateurs employaient OP_0 comme valeur de remplissage, une convention qui a perduré pendant des années parce que les nœuds acceptaient n’importe quelle valeur à cet emplacement.
3. Le BIP147 (NULLDUMMY), activé avec SegWit en août 2017, a neutralisé ce vecteur de malléabilité au moyen d’une règle de consensus. L’élément factice doit désormais être un tableau d’octets vide. Toute valeur non vide, même un seul octet nul, fait échouer le script. Cela a supprimé la possibilité de modifier les identifiants de transaction en changeant le contenu de l’élément factice, ce qui stabilise le hash de la transaction pour toutes les confirmations ultérieures.
4. Les règles de standardité déterminent quels scripts multisig les nœuds relaient. Selon la politique par défaut de Bitcoin Core, les sorties multisignatures nues (bare) sont limitées à trois clés. Encapsulé dans un P2SH, le multisig peut utiliser jusqu’à 15 clés (limite imposée par le script de rachat de 520 octets) ; en P2WSH, jusqu’à 20. Cette distinction permet à des configurations complexes de trésorerie d’entreprise de fonctionner sans alourdir la couche de transaction de base.
5. Deux outils plus récents remplacent les schémas multisig traditionnels. MuSig2 (BIP327, 2023), un protocole distinct reposant sur les signatures Schnorr de Taproot, agrège plusieurs clés publiques en une seule clé et produit une signature Schnorr standard ; on-chain, la dépense est indiscernable d’une dépense Taproot ordinaire à clé unique. Tapscript, qui fait partie de Taproot, ajoute OP_CHECKSIGADD, qui permet une vérification incrémentale des signatures sans le bug de dépilement ni la limite de 20 clés des anciens opcodes.
6. Pour examiner ces mécanismes, ouvrez un explorateur de blocs et repérez une transaction multisig nue antérieure à SegWit. Observez le scriptSig : il commence par OP_0 suivi des signatures. Comparez-le à une dépense multisig P2WSH, où le witness contient un élément vide, les signatures et le witness script listant les clés. Notez la différence de nombre d’octets, qui reflète le coût d’inclusion de la liste complète des clés dans la sortie plutôt que dans l’entrée.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts