Voici un sujet remonté par @Inso sur le ticket #1002 : intégrer le paiement vers une adresse plutôt qu’une clé publique.
J’aimerais intégrer cette fonction dans Duniter 1.4. La fonction n’entrerait en vigueur qu’à une date précise, par exemple à la rentrée 2017 pour laisser le temps aux calculateurs de se mettre à jour.
Qu’est-ce qu’une adresse ?
C’est une autre représentation d’une clé publique, qui a subit une transformation.
Quel avantage à utiliser des adresses plutôt que des clés publiques ?
Selon l’algorithme choisit pour la fonction ADRESSE(), la nouvelle représentation en adresse peut permettre :
de raccourcir l’identifiant du compte : ici l’adresse fait 34 caractères pour une clé publique de 44 caractères
d’inclure des contrôles de saisie : il existe une cohérence mathématique dans les caractères de l’adresse, permettant de nous prévenir en cas d’erreur
d’identifier le réseau compatible, en préfixant l’adresse : par exemple, une adresse qui commence par “1” serait une adresse Ğ1, une adresse commençant par “9” serait une adresse Ğ1-Test.
On peut imaginer d’autres mécanismes et avantages, tout dépend de l’algorithme utilisé pour la fonction ADRESSE().
Une petite remarque/question : pourquoi borner la taille d’une adresse à 34 caractères ?
Quitte à réduire la taille de la clef, n’y aurait-il pas moyen de faire bien moins ?
Avec 6 caractères (min+maj+chiffres = 62 possibilités), on arrive à 56 milliards de combinaisons possibles, soit beaucoup plus que le nombre d’humains attendus d’ici les 100 prochaines années (je ne m’avance pas plus pour la suite ^^).
Admettons qu’on a 2 caractères de préfixe et 3 de contrôle, ça fait une adresse de 11 caractères et donc BEAUCOUP plus lisible/user-friendly/retenable.
J’imagine qu’il y a d’autres restrictions, mais je ne vois pas trop lesquelles ?
Hello,
Moi j’avais bricolé autour du protocole existant de duniter pour rajouter ces fonctionnalités comme le checksum.
Je ne peux donc qu’encourager la venue de cette fonction.
Pour répondre à barbichette, il faut bien plus de possibilités pour qu’il soit quasiment impossible d’obtenir des collisions , pour éviter que plusieurs clefs privées obtiennent la même adresse.
Pour simplifier, il faut qu’aucun ordinateur ne soit en mesure de générer même 0.1% de toutes les adresses possibles, car cela lui permettrait de vider tous les comptes utilisant ces mêmes adresses.
edit: petit lien kdo
Sinon je vais réfléchir un peu dans mon coin avant de donner mon avis sur l’implémentation de cette fonction (principalement le “G1” ou “GT” au début car ça fait beaucoup de Bit de perdu en Base 58)
je reviens vers vous rapidement
J’entends ton argument, mais pourquoi 34 ? Est-ce parce que cette fonction est déjà utilisée “ailleurs” et qu’on souhaite la réutiliser simplement ?
Si on tire jusqu’à 8 caractères aléatoires (+préfixe +contrôle), on arrive à 218 340 milliards combinaisons.
Je ne sais pas trop quelle marge il faut prendre pour éviter les collisions, mais on a ici un ratio de 3 897 adresses “vides” pour une “occupée”, ça me parait pas si mal.
Je me pose cette question parce que je vois des personnes qui s’extasient sur une fonction qui réduit 44 caractères aléatoires" à 34 caractères aléatoires et cela me parait vraiment disproportionné D’où l’idée d’essayer d’optimiser un peu.
Quand j’ai lu ici la notion d’adresse, j’ai pensé soit à une chaîne de caractère plus “lisible” que de l’aléatoire, soit à une sorte d’alias qui pourrait regrouper plusieurs clefs publiques pour rassembler les comptes portefeuilles d’un même membre.
Ces 2 possibilités m’auraient semblé utiles d’un point de vue utilisateur. Là, je ne comprends pas vraiment l’objectif réel.
Merci Tortue pour le lien, c’est très clair
Et merci cgeek pour l’explication.
Du coup, l’idée de réduire le nombre de caractère c’est que ça permet de faire moins d’erreurs à la recopie, mais on ne réduit pas trop pour ne pas avoir de collisions trop fréquentes.
Cool
edit : et ceci dit, “vite” c’est pas forcément vrai, car le temps de développer la 1.6 puis d’attendre la date d’activation de la fonction, c’est peut-être pas avant fin septembre tout ça !
C’est surtout l’implémentation du CRC à l’intérieur de la clef qui nous intéresse (cela vérifie que les caractères précédemment saisis de l’adresse corresponde au CRC, un peu comme les 2 derniers caractères d’un RIB)
il y a également la possibilité d’identifier si la clef est utilisée sur le réseau G1 de production ou le réseau de Test.
Donc même en ajoutant toutes ces données à l’intérieur de l’adresse, grâce à une fonction de hachage de la clef publique, on arrive à réduire encore un peu le nombre de caractères de l’adresse, tout en conservant une bonne sécurité
Sur le prefixe : Pour moi le prefixe n’a pas grand chose à faire dans le document de transaction
Sur l’algo de bitcoin : Je suis pour le réutiliser sauf si quelqu’un a mieux à proposer.
D’où l’idée d’essayer d’optimiser un peu.
