Merci pour tes éclaircissements.
Ta réponse au point (1) "KeyA ne se trouve pas dans la blockchain" et au point (3) "KeyA apparait dans le redeem script" me semblent se contredire. Quand au point (2) je continue à ne pas comprendre. KEyA s'utilise comme un label puisque tu est d'accord que l'on va pas signer quoi que ce soit puisque on n'a pas besoin d'avoir cle secrète. Pourquoi alors une multisignature 2-3? Je ne comprends pas le sens.
EN effet Je confirme que KeyA ne se trouve pas dans la blockchain, au moins jusqu'au dépouillement.
Je répète ici les étapes du process qui répondent (je crois) à ta question:
KeyA n'apparait dans un "redeem script " que lorsqu'on récupère les coins stockés sur les adresses multisig, ce que seul l'organisateur peut faire, après la période de vote, en utilisant les clés privées A et C .
Les clés privées C sont idéalement fournies indépendamment par chaque candidats, après les élections. Avant les élections , le candidat fournit seulement les clés publiques à l'organisateur. En pratique, c'est l'application qui va sans doute générer les paires de clés.
Ces clés A et C sont différentes pour chaque électeur.
Elles doivent être envoyées aux électeurs dans un ordre aléatoire et secret pour éviter d'associer un électeur à une de ces clés.
La racine de Merkle de l'arbre binaire constitué des clés A est publiée avant les élections. De même pour les clés C.
Tout électeur (qui reçoit une clé et sa branche de l'arbre) peut donc vérifier que sa clé est reliée par sa branche à la racine.
L'anonymat des votes n'est pas compromis par la blockchain. Il n'est pas fondamentalement amélioré car il faut encore une base de données temps réel gérée par l'organisateur pour enregistrer les votes en temps réel (une sorte de base de données tampon avant l'enregistrement dans la blockchain).
L'amélioration fondamentale tient à la possibilité de vérifier le résultat des votes a posteriori et de manière totalement indépendante.
L'usage d'une adresse multisignature pour construire une adresse à partir de 3 clés est standard. Ta suggestion de placer un label dans un "message incrusté" ne l'est pas (wallet spécifique ?).
Cependant tu as raison de considérer KeyA comme un identifiant de l'électeur pour l'élection en cours. L'arbre binaire des clés A doit avoir exactement autant de feuilles que la liste électorale comporte de noms.
