Signet permet de tester ensemble des logiciels Bitcoin. Il possède sa propre chaîne et des pièces de test. En plus des règles habituelles et de Proof of Work, les nouveaux blocs doivent respecter une condition particulière, fondée sur une signature dans le Signet par défaut. Cela facilite les essais, avec un modèle de confiance différent du réseau principal.
Anne veut voir ce qu’affiche un nouveau portefeuille après l’envoi d’un paiement, puis après sa confirmation dans un bloc. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Sur Signet, elle utilise des pièces de test, par exemple obtenues auprès d’un faucet, un service qui les distribue pour les essais. Ce ne sont pas des BTC de mainnet, le réseau principal, et le protocole ne les échange pas contre de vrais bitcoins. Attention aussi aux adresses : Signet partage certains formats de test avec Testnet. Leur apparence ne suffit donc pas à identifier le bon réseau. [1] [2] [8]
Karl-Johan Alm et Anthony Towns ont rédigé BIP 325 (le document technique décrivant Signet) ; Bitcoin Core v0.21.0 a introduit Signet. Le logiciel propose un réseau public par défaut, mais une équipe peut choisir sa propre condition de création des blocs et ses participants. Dire « nous utilisons Signet » ne suffit donc pas : les deux parties doivent utiliser le même réseau. L’identifiant des messages réseau découle de cette condition, pas du nom du projet. [1] [3] [4]
Un Full Node, un nœud qui vérifie lui-même les règles, contrôle toujours les transactions et Proof of Work, le résultat du calcul nécessaire à la production d’un bloc. Il vérifie aussi la condition supplémentaire de Signet. Sur le réseau par défaut, miner ne suffit donc pas : la signature appropriée est également nécessaire. L’en-tête, le résumé compact du bloc, ne remplace pas ce contrôle ; les données requises sont à l’intérieur du bloc. [1] [9]
Une signature numérique permet de vérifier qu’un message a été approuvé par le détenteur de la clé privée correspondante, une valeur numérique secrète, sans révéler cette clé. La personne capable de satisfaire la condition de signature influence la production des blocs. Elle peut retarder sa signature ou limiter les transactions incluses. Cela ne lui donne ni les clés privées d’Anne ni le pouvoir de contraindre son nœud à accepter une transaction invalide quelconque. Les autres règles restent applicables. Cette participation contrôlée est utile aux essais et explique aussi pourquoi Signet ne reproduit pas le modèle de sécurité de mainnet. [1] [9]
Un seul paiement réussi ne suffit pas au développement. L’équipe doit savoir comment l’application réagit si les blocs s’arrêtent ou lors d’une réorganisation : le nœud remplace alors des blocs récents par une autre branche valide. Un essai coordonné peut créer cette situation et vérifier que le portefeuille actualise correctement les confirmations. Signet ne promet pas un service ininterrompu ; il rend aussi les échecs plus prévisibles à tester. [1] [5] [6]
Sur Testnet, la production de blocs est ouverte et ses variations peuvent compliquer une expérience commune. Regtest permet au contraire de créer facilement des blocs à la demande, ce qui convient aux tests automatiques d’un développeur. Il peut relier plusieurs ordinateurs ; ce n’est pas nécessairement un programme isolé. Signet répond à un autre besoin : une collaboration durable entre participants indépendants avec des conditions convenues pour produire les blocs. Aucun de ces modes ne remplace tous les autres essais. [1] [2]
La condition appelée challenge est un script, un petit programme qui décrit ce que le bloc doit démontrer. Elle peut exiger une signature ou Multisig, un nombre convenu de signatures provenant de plusieurs clés. Un Signet personnalisé peut aussi employer OP_TRUE, une condition satisfaite sans signature. Une solution vide suffit alors. Il faut donc parler d’une condition de script supplémentaire, plutôt que d’affirmer que chaque Signet exige toujours un signataire. [1] [9]
BIP 325 place la solution non vide dans des données particulières de la Coinbase Transaction, la première transaction du bloc. Ce terme n’a ici aucun rapport avec la plateforme d’échange homonyme. Ces données complètent l’engagement cryptographique (commitment) de BIP 141, qui lie le bloc à ses données witness, notamment les signatures, et portent la marque 0xecc7daa2. Ce n’est pas un paiement ordinaire supplémentaire au signataire. Une condition trivialement satisfaite permet d’omettre la solution supplémentaire, pas d’ignorer automatiquement les autres règles. [1] [9] [10]
Si le message signé contenait cette même signature, il y aurait une dépendance circulaire. La vérification utilise donc une empreinte modifiée des transactions où la solution est vidée, ainsi que deux transactions virtuelles. Elles servent au calcul et ne sont pas diffusées comme des paiements supplémentaires. La signature exclut aussi le nonce de l’en-tête, le nombre modifié lors de la recherche de Proof of Work. Le changer n’exige pas de nouvelle signature, sans pour autant autoriser une modification libre du reste du bloc. [1] [9]
Anne vérifie d’abord que son portefeuille, son nœud et son explorateur de blocs utilisent le même réseau de test. Un explorateur de blocs est une application permettant de consulter les transactions et les blocs d’un réseau donné. Dans Bitcoin Core, getblockchaininfo et le champ signet_challenge indiquent la condition configurée. Elle observe ensuite une véritable confirmation, et pas seulement le message « envoyé », en utilisant un portefeuille de test séparé. Un essai réussi montre le comportement de l’application dans ces conditions ; il ne garantit ni la sécurité des fonds ni la résistance à un attaquant sur mainnet. [7] [8]
Pour une vision complète, lisez aussi Nakamoto Consensus, Block Propagation, Initial Block Download, Block Weight, Bitcoin, Bitcoin Core. Cette entrée est également citée par Testnet, Miniscript, Dead Man’s Switch.