Si @cgeek a envie de le faire dans Duniter je suivrais, mais perso je ne serais pas moteur pour ces 3 propositions, car nous avons bien d’autres priorités concernant l’évolution du protocole. Je préfère donc qu’on se limitent aux changements absolument nécessaires dans un premier temps, et j’estime que tes propositions permettent concernant l’uid ne sont pas une nécessité
Je pense au contraire que la Licence Ğ1 doit expliciter l’ensemble des droits et devoir nécessaires et suffisants qui incombent a tout membre de la Ğ1, en ce sens la présence de la formule de calcul du DU me semble indispensable, c’est la formule officielle a laquelle se référer sans avoir besoin d’aller chercher dans la documentation du site web ou sur le forum
Oui c’est une bonne idée
En fait il y aurait toujours qu’un seul et unique type de certification dans le protocole. Donc c’est énormément plus simple a implémenter et énormément plus simples pour les utilisateurs finaux, qui n’auront rien de plus a savoir s’il ne calculaient pas de blocs.
Les membres forgerons n’auront qu’un seul type de certif, c’est juste qu’il devront faire preuve de plus de vigilance lorsqu’il certifieront d’autres membres forgerons. Les clients pourrait par exemple, ré-afficher la licence forgeron avec une checklist de points a vérifier chaque fois qu’un membre forgeron est sur le point de certifier une identité forgeron.
Je me suis déjà exprimé sur le fait que la proposition de 3 types de liens qu’avait soumis cgeek était beaucoup trop complexe et allait rendre illisible pour l’utilisateur final un concept déjà fort complexe a comprendre.
Cela complexifierai également beaucoup trop le protocole a mon goût, il me semble qu’un bon protocole se doit d’être le plus simple possible pour répondre a un besoin donné, car plus il est simple plus il est maintenable, réimplémentable et optimisable.
Donc si l’on peut répondre a un même besoin avec une solution technique plus simple, j’estime qu’il nous faut opter pour la solution la plus simple, conformément au principe du Rasoir d’Ockham.
Mouais, donc concrètement, ça reviens à dire qu’il y a 2 types de certifications pour l’utilisateur, il n’y a juste pas besoin de modifier le protocole pour le prendre en compte au niveau des document de certification (c’est le sigPowQty qui sert à vérifier qu’il y a bien suffisement de certification de type forgeron à forgeron), mais pour l’utilisateur, c’est une vigilance différente, des vérification supplémentaire… bref, un autre type de certification (mais pas techniquement, humainement seullement).
C’est vrai que si les forgerons, qui sont souvent des gens impliqués, restreignent leurs certifications il faudra aviser.
Ou alors afficher dans les outils (sauf dans Cesium-web) “l’identité que vous souhaitez certifier a/n’a pas droit de forgeage” pour ne pas les limiter dans leurs certifications de villageois.
Je repense à la solution d’@elois pour corriger le souci de sécurité actuel de la centralisation cesium-web.
La solution protège d’une prise de contrôle de l’écriture dans la blockchain, mais pas d’une création massive de faux comptes en cas de piratage réussi de g1.duniter.fr.
L’usage de hardware wallet, solution bien plus lourde à mettre en place, j’en conviens, résout ces deux enjeux de sécurité, et d’autres :
permet d’utiliser son compte membre pour signer des documents arbitraires sur des applications tiers sans exposer ses secrets -> exemple d’usage : vendeur identifié sur gchange ou assimilé.
libère les usagers de la nécessité de retenir un identifiant secret et un mot de passe sur les quels toutes la sécurité repose (trop complexe, ils l’oublient, trop simple, ils sont vulnérable aux attaque brute force un peu évoluée)
n’introduit pas de centralisation de pouvoir dans la capacité à écrire dans la blockchain -> conserve la pleine citoyenneté à chaque membre.
Dans les aspects moins sympa :
implique d’équiper les usager de hardware wallet.
implique de coder le nécessaire pour avoir des hardware wallet compatible avec nos besoins.
implique d’avoir un hardware wallet branché sur chaque noeud membre, à moins d’ajouter un mécanisme de délégation pour cet usage.
Je ne dit pas que c’est la solution à adopter dès demain, vu qu’elle est plus lourde à mettre en place, mais ça me semble une meilleur solution à terme car elle offre :
plus de sécurité pour tous
la conservation d’une gouvernance horizontale / d’une pleine citoyenneté pour tous.
Le principal aspect durablement gênant est le cout UNL non nul pour chaque nouvel entrant, tant que nous n’avons pas de fournisseur de hardware wallet en Ǧ1.
Une solution intermédiaire ou de transition serait de considérer les comptes (membre) actuel comme “compte découverte” avec les possibilité du N1 de la proposition de @cgeek (pas d’écriture blockchain ni de membre référent), et de considérer les comptes créés avec hardware wallet comme “compte (membre) citoyen”. Techniquement cela revient globalement à avoir des compte membre simple et des compte forgeron, mais en pratique, au lieu de diffuser le message à la communauté : votre compte membre fait l’affaire, laisser les choses importante au forgerons, ça ne vous concerne pas, on leur envoi le message : bienvenue, vous avez maintenant un compte découverte qui vous permet de gouter aux avantage d’une monnaie libre. Pour devenir pleinement citoyen, il reste un pas à faire, qui vous sécurise tout en vous donnant des droits supplémentaire, et sécurise toute la communauté.
Quelque soit la solution adoptée et les efforts pour garder une gouvernance “horizontale” par le plus grand nombre, il y aura toujours la fracture de “l’expertise”.
Il y a ceux qui “savent” :
Contribuer au code, faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
Faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
Sécuriser ses comptes, installer un client, utiliser un client.
Installer un client, utiliser un client.
Utiliser un client.
On pourra toujours faire ce qu’on veut, on aura toujours cette “fracture numérique” pour parler poliment ou une “hiérarchie par l’expertise” inévitable.
On aura beau essayer de transmettre le savoir, d’éduquer aux bonnes pratiques, (et il faut le faire !) on aura malheureusement toujours des fractures.
J’aime bien le concept de hardware wallet, mais il est plus facile à voler et aussi facile à perdre (vous n’avez jamais perdu une clef usb ?). Et comment le brancher sur un serveur hébergé ?
Il faut que ce soit un choix (je préfère les mots de passes, ou bien je préfère un fichier de clef privée).
@elois a exposé une solution qui acte de fait une fracture dans l’expertise et sépare les responsabilités.
J’y suis assez favorable.
Pour alimenter le débat entre les niveaux de certifications proposés par @cgeek et les comptes forgerons, la communauté PGP a déjà expérimenté les certifications graduelles, puis est revenue en arrière en ajoutant un mode avec moins de niveaux (le mode TOFU - Trust on First Use qui sera le mode par défaut pour rendre PGP plus accessible).
En tout cas c’est pour moi une priorité de sécurité. Pour exagérer un peu, je dirais que pour l’instant, on a un sudo chmod 777 sur tous les comptes membres…
point de vue utilisateur, ca me semble assez simple: on désactive progressivement l’authentification sur les instance cesium web (en retirant l’authent par salt & password sur les version publique )
On peut faire le test une semaine sur le g1.duniter et voir les retours obtenu. dans le pire des cas on vera d’autre instances fleurir pour combler ce manque pour les utilisateur non geek. dans le meilleur des cas une augmentation dans les installation de clients.
En parallèle, on déploies des solution d’installation facile. (plugin firefox? ),
en ce qui me concerne je penses shipper un cesium pré-configuré en local dans juniter tant que je n’aurais pas codé ces fonctionnalité dans le client lourd. Y a-t’il des install duniter incluant cesium ?
j’envisage différent mode de sync :
light : sync mes données & celles de mes potes & état actuel du reseau
keep up : stay synced, maintain indexing and forks, listen to network
compute blocks
de sorte qu’on puisse l’utiliser en client ou server, avec / sans GUI
Ya un avantage stratégique a shipper un paquet Duniter+Cesium: l’utilisateur ne fait pas la différence entre le back et le front, c’est génial!! chaque fois qu’on repousse l’authent en ligne, on stimule en même temps l’installation d’un noeud.
les cesiums en ligne existeront évidement mais s’il est d’usage de n’utiliser que “celui du copain” occasionnellement c’est déjà moins grave et plus dans l’idée de la WoT. moi je suggère de retirer l’authent depuis g1.duniter.fr. même si les gens utilisent une version “MLOccitanie” ou “le sou” de Cesium, c’est toujours mieux que le serveur “officiel” montre l’exemple. les entrant, les curieux vont arrivé par là. c’est donc sur cette page là qu’il faut initier l’utilisateur aux bonnes pratiques. en parler entre nous et chercher a palier le problèmes techniquement c’est pousser le probleme ailleurs: WoT = facteur humain => éducation.
C’était le cas à une époque, dans Duniter 1.x (mais je ne sais plus quelle version).
Mais Duniter proposera bientôt ses propres écrans de gestion de wallet / identité / certifications / adhésions, avec des utilisations avancées (nouveautés !). Cesium est bien, mais pour une utilisation basique.
Cette proposition traite qu’un des trois droits du statut de membre parmi la création monétaire, l’écriture de la blockchain et la certification.
Elle met de côté l’aspect monétaire (vol des sources de monnaie et de la création monétaire) qui n’est critique que pour l’individu. Ce choix me semble pertinent pour l’instant et moins grave que ce qui suit. Mais, je verrais mal quelqu’un perdre ses sources de monnaie quand la monnaie vaudra beaucoup.
Là où la proposition me pose problème, c’est qu’elle ignore le droit de certification. Dans le cas où cinq comptes membres sont récupérés et contrôlés par un attaquant, ce dernier peut faire ce qu’il veut : créer d’autres comptes (même forgerons), créer de la monnaie, écrire des blocs et attaque Sybil…
J’ai juste lu le post original et le reste en diagonale. Il est possible que j’aie raté des informations.
Si ma proposition est implémentée et que l’attaquant dérobe des clés privés de compte membre uniquement via instances web, alors non il ne pourra pas forger de blocs, car les membres forgerons ne peuvent pas utiliser d’instances web et qu’il n’est pas possible de devenir membre forgeron sans l’accord d’autres membres forgerons.
En revanche, l’attaquant pourra bel et bien voler des G1 a ses victime, ou/et certifier a leur place.
Cependant, les victimes vont rapidement se rendre compte que quelqu’un certifie a leur place et seront invitées a révoquer leur compte afin d’endiguer l’attaque sybil.
De plus, une attaque sybil qui ne peut pas forger, dont le seul risque est donc de créer de la fausse monnaie, devra être d’ampleur très conséquente pour avoir un impact non-négligeable sur la monnaie.
Le vrai risque des attaques sybil aujourd’hui c’est le risque de prise de controle de la blockchain par majorité de forgeron, ce que m’a proposition adresse parfaitement.
Gardons en tête que le sujet des attaques sybil est différent et doit être traité via d’autres propositions (la proposition de membres n1 et N2 de poka par exemple).
Tout ceci suit une logique de réponse proportionnée au risque ( le risque est le produit de la probabilité et de la dangerosité)
Risque de majorité de forgeron => risque très élevé => demande des règles strictes.
Risque de création de fausse monnaie par attaque sybil => risque faible => peut être traité par des règles plus souples.
Merci pour la précision, j’avais pas bien compris la proposition avec cette lecture. Je me suis rappelé de la proposition que j’avais lue lors de sa publication.
La mesure de protection me semble astucieuse. Par contre, j’ai encore un problème avec le fait que les forgerons se cooptent entre-eux. Ils utilisent la toile de confiance actuelle. Ça ne demande pas de toile supplémentaire pour gérer des liens de forgerons.
La question qui se pose est comment faire pour différencier les certifications classiques d’identification et celle de forgerons ? Si un membre souhaite devenir forgeron et qu’il ne connaît pas de forgerons, il va demander une certification classique à un forgeron qu’il ne lui aurait pas donné de certification classique en temps normal ? Ça serait contraire à la licence Ğ1. La question, alors se pose d’avoir deux toiles en parallèle pour différencier tout ça. Mais, là ça fait trop. Tu vois comment cette partie ?
Si un membre souhaite devenir forgeron il sera obligé de révoquer son compte pour créer une nouvelle identité de type forgeron. Si une identité forgeron certifie une autre identité forgeron alors la certification est d’office de type forgeron, sans qu’il y ai besoin de modifier le document certification.
Donc non ce n’est pas une certification “classique” qui sera demandée.
Non pas du tout, je crois que tu n’a pas encore saisie quelques subtilités de ma proposition
Il n’est pas nécessaire que ce soit un forgeron qui coopte un forgeron ?
N’importe quel membre peut coopter un forgeron, à condition que le receveur soit une identité forgeron ?
Dans ce cas, l’attaquant qui contrôle cinq comptes membres non forgerons peut créer un compte forgeron tous les cinq jours ?
Les certifications de types normal → forgeron ne peuvent pas permettre à elles seules d’inscrire en blockchain une identité forgeron, cela est assuré par le nouveau paramètre monétaire sigPowQty.
Les certifications émises par les anciens membres calculant ayant révoqués leur compte pour créer une identité forgeron resteront valident jusqu’à leur date d’expiration. Ainsi, les anciens membres calculant qui switche en identité forgeron peuvent continuer a renouveler leurs certifications comme avant, ceci n’aura donc aucun impact sur la toile.
En revanche, les certificateurs des anciens membres calculant devront les recertifier sur leur nouvelle identité forgeron, des certif qu’il ne pourront pas émettre vers des nouveaux, donc rien ne vas s’effondrer au contraire, la toile va juste grandir légèrement plus lentement le temps de la transition. Sachant qu’on a aujourd’hui 40 membres calculant sur 2500, seuls certains certificateurs de ces 40 personnes pourront temporairement moins certifier.
Pour minimiser cet effet déjà négligeable (je pense qu’on ne le sentira même pas dans les indicateurs), les membres forgerons peuvent demander en priorité des certifications auprès de leurs plus anciens certificateurs (ceux dont la certification va expirer a plus brève échéance).
Une simulation est toujours bienvenue évidemment, mais il me semble évident qu’il n’y a aucun risque d’effondrement de la toile, et c’est d’autant plus vrai que la proportion de membres effectivement calculant (=membres dans la fenêtre courante) ne fait que diminuer*.
*Ce qui est normal et souhaitable, on est a environ 2% contre ,0005% pour le réseau bitcoin. 2% c’est énorme, ça montre bien qu’il y a pour le moment une surreprésentation de techkos dans la G1, a long terme on sera très certainement moins de 0,1% des a calculer des blocs ce qui sera toujours infiniment plus que pour le bitcoin.
Il faut pas oublier que pour être forgeur Bitcoin, il faut avoir une puissance de calcul considérable pour trouver des blocs. C’est aussi une raison qui différencie le nombre proportionnel de forgeurs entre ces deux cryptomonnaies. Peu de forgeur Ğ1 pourrait se permettre d’être forgeur Bitcoin aujourd’hui.
Ça me semble un bon plan de transition.
Si on part dans cette direction, ça m’embête que les membres forgerons doivent révoquer et créer une nouvelle identité. Cette tâche est assez lourde et doit être effectuée par minimum 53 (sur les 5 000 derniers blocs) à 206 (toute la chaîne) forgerons aujourd’hui.
Je propose que les membres qui souhaitent devenir membres forgerons puissent publier un document d’identité forgeronne entre t1 et t2. Lors du passage de l’étape t2, le logiciel transforme les identités qui ont demandé transformation à être transformées en identité forgeronne. Ça mettrait en place une sorte de migration plus douce et non cassante qui pourrait être fatal si on se rate.
Pour les membres ayant raté cette période de transition pour changer d’identité, ça devra se faire de manière cassante : révocation et nouvelle publication.
@Moul en fait la révocation obligatoire des anciens compte membre des forgerons fait parti pleine et entière de la fonctionnalité : le but est de repartir sur de bonnes bases en terme de crédentials.
Il faut d’abord mettre en place le chiffrement systématique des trousseaux de clé (format DEWIF). Et ensuite chaque membre forgeron souhaitant rester forgeron devra changer de credentials pour repartir sur des bases saines.
On a déjà des clés privées exposées en clair sur le disque chez de nombreux membres forgerons (au moins tous ceux qui arrivent a redémarrer automatiquement), garder les mêmes credentials pour ces forgerons là me semble une mauvaise idée.
Il faudra d’ailleurs que la licence spécial forgeron (a rédiger), précise l’engagement au respect de ces bonnes pratiques de sécurité.
J’ai toujours dans ma TODO List de rédiger une spec détaillée pour cette proposition, mais en creusant je me rend compte qu’il y a d’autres prérequis a mettre en place avant (DEWIF, mnemonic, etc).
Cette proposition de moyen terme prendra du temps, on ne pourra hélas pas échapper à la fermeture temporaire des instances web
On peut éventuellement discuter de la récupération de l’uid, mais un tel mécanisme est risqué pour l’utilisateur final (quiconque dérobe sa clé privée pourrait lui “voler” son uid en le transférant a un nouveau compte).
Il faudrait que la récupération de l’uid soit limitée a certains membres, je pensais par exemple aux membres du bloc genesis.
Il y a d’autres subtilités dont je n’ai pas parlé, notamment concernant l’initialisation de cette “sous-toile”, j’y ai beaucoup réfléchi cette semaine, je posterai ça prochainement.
