Messages signés et chiffrés
Toutes les signatures n’ont pas besoin d’une transaction. Un message signé prouve que vous détenez une clé sans déplacer d’argent et sans payer de frais ; un message chiffré ne peut être lu que par son destinataire. Cette page traite des deux, ainsi que de deux signatures apparentées que l’API du nœud accepte.
Prouver que vous contrôlez une adresse
Un site web qui veut savoir si vous contrôlez une adresse ZooBC vous envoie un défi aléatoire. Vous le signez avec zbc-cli sign-message, ou avec la même fonction dans n’importe quel portage des outils en ligne de commande publics, et le site vérifie la signature par rapport à votre adresse. Pour une adresse native ZBC_, l’adresse est la clé publique elle-même ; rien d’autre n’est donc nécessaire. Envoyer un paiement prouverait aussi le contrôle, mais c’est une transaction, et elle coûte des frais. Ne donnez en aucun cas votre clé privée à la place.
Le schéma s’appelle ZBC-MSG-v2. Il signe, avec Ed25519 :
SHA3-256("ZBC-MSG-v2" ‖ genesis hash ‖ message)Deux éléments de ce condensé comptent :
- L’étiquette. Les transactions sont signées sous une autre étiquette, « ZBC-TX ». Une signature de message ne peut donc jamais être valide comme transaction, ni une signature de transaction comme message.
- Le hachage de genèse. Il lie la signature à un seul réseau : un message signé pour le devnet ne se vérifie jamais sur le testnet ni sur le mainnet (signatures liées à la chaîne).
Pendant une période de transition, la commande verify-message des outils accepte aussi l’ancienne forme sans chaîne, ZBC-MSG-v1 (SHA3-256 de « ZBC-MSG » et du message). Cette période prend fin à une échéance fixée dans les outils ; passé celle-ci, seule la forme ZBC-MSG-v2 se vérifie.
La signature de messages est une convention des outils publics et des services qui l’adoptent, et non une fonctionnalité de la chaîne. Rien n’est stocké sur la chaîne, et les nœuds n’ont aucun point d’accès pour cela.
Messages chiffrés
Chaque transaction peut porter un message (enveloppe de la transaction). Un message en clair fait au plus 256 octets. Un message chiffré commence par le marqueur « ZBE1 », suivi d’une boîte scellée (sealed box) libsodium adressée à la clé du destinataire, que seule la clé privée du destinataire peut ouvrir. Un message chiffré peut atteindre 320 octets, ce qui laisse de la place pour 268 octets de texte au plus.
Seul le message est chiffré. Le reste de la transaction, comme son expéditeur, son destinataire et son montant, reste aussi public que celui de n’importe quelle autre.
Requêtes API signées
L’essentiel de l’API du nœud consiste en lectures ouvertes, et une transaction n’a besoin d’aucune clé API, car elle porte sa propre signature. Lorsqu’une requête doit elle-même être signée, il s’agit d’une signature Ed25519 sur le texte METHOD:PATH:TIMESTAMP:BODY, valable 300 secondes. Un client qui échoue à 20 authentifications signées en 5 minutes est bloqué pendant 300 secondes.
Annuler une transaction en attente
Une transaction qui attend dans le mempool d’un nœud peut être retirée de ce nœud avec DELETE /api/v1/transactions/pending/ suivi de son hachage. La requête porte une signature sur :
SHA3-256("ZBC-CANCEL" ‖ genesis hash ‖ transaction hash)Elle ne retire la copie que du mempool de ce nœud. D’autres nœuds qui détiennent déjà la transaction peuvent encore l’inclure dans un bloc ; une annulation est donc une demande, pas une garantie.