P2WSH

Pay to witness script hash est la sortie SegWit de version 0 pour tout ce qui est plus compliqué qu'une clé unique, écrite sous la forme d'une adresse bc1q de 62 caractères. Bitcoin Core relaie une dépense dont le script témoin atteint 3 600 octets et dont le témoin contient jusqu'à 100 éléments de pile, là où un script de rachat P2SH s'arrête à 520 octets. C'est cette place supplémentaire qui a fait migrer les contrats sérieux vers ce format.

Comment cela fonctionne

Une sortie P2WSH est l'octet 0x00 pour la version de témoin 0 suivi d'un push de 32 octets, soit 34 octets au total. Ces 32 octets sont un simple SHA-256 du script témoin sérialisé, et non le RIPEMD-160 d'un SHA-256 utilisé ailleurs dans bitcoin.

Ce choix est délibéré. Un engagement de 160 bits offre environ 80 bits de résistance aux collisions, ce qui est inconfortable lorsqu'une contrepartie participe au choix de ce qui entre dans le script et pourrait chercher deux scripts partageant un même hachage. Un engagement de 256 bits écarte cette inquiétude. Le P2WPKH à clé unique conserve le hachage plus court parce qu'une seule partie choisit la clé, et l'adresse reste de ce fait plus courte de 20 caractères.

La dépense pousse les arguments sur la pile du témoin et se termine par le script sérialisé. Un nœud hache ce dernier élément, le compare à l'engagement, puis exécute le script avec ce qui reste. La politique de relais de Bitcoin Core fixe les limites dans policy.h : 3 600 octets pour le script, 100 éléments sur la pile et 80 octets par élément.

Les frais expliquent cette migration. Une dépense 2-sur-3 ici coûte environ 104,5 vbytes, parce que les signatures et le script entier de 105 octets voyagent dans le témoin à une unité de poids par octet. La même politique sous P2SH coûte environ 297 vbytes. Le plafond de consensus de 20 clés sur OP_CHECKMULTISIG devient également accessible, puisque vingt clés occupent moins de 700 octets.

Où le voir

Chaque canal Lightning est alimenté par une sortie P2WSH 2-sur-2, ce qui en fait l'un des types de script les plus courants sur la chaîne, même si peu de gens tapent un jour l'adresse. La conservation institutionnelle, les politiques miniscript et les clauses d'héritage à verrouillage temporel y font aussi appel.

Dans un explorateur de blocs, une sortie P2WSH non dépensée est une chaîne bc1q de 62 caractères et rien de plus. Elle a la même apparence, qu'elle protège deux clés ou vingt, et les conditions n'apparaissent que lorsque les bitcoins bougent.

Les sauvegardes doivent inclure le script. Une phrase de récupération régénère des clés, pas des scripts quelconques : conservez donc le descripteur ou les octets exacts du script à côté de la phrase de récupération et vérifiez que vous pouvez restaurer à partir d'eux avant que l'adresse ne contienne de l'argent réel.

P2WSH vs script témoin

P2WSH est la sortie ; le script témoin est le contenu auquel elle s'engage. La sortie contient 32 octets de hachage et rien d'autre : elle ne transmet donc aucune information sur les conditions attachées, et aucune partie du script n'apparaît on-chain avant qu'une dépense ne le publie. L'obligation est de ce fait déséquilibrée. Un expéditeur n'a besoin que de l'adresse et peut payer sans rien comprendre. Le destinataire a besoin des octets exacts du script pour toujours, car les perdre rend les bitcoins impossibles à dépenser, quel que soit le nombre de clés privées qui subsistent.