[Idée] Clé déléguée au calcul de blocs

clédéléguée
revocation

#1

Comme vous le savez sûrement, seules les clés privées de membres peuvent calculer de nouveaux blocs. C’est-à-dire que pour calculer un bloc, votre nœud doit être en possession de votre clé privée d’individu membre de la Ğ1.

C’est une fonctionnalité voulue, qui permet notamment un calcul très efficace en énergie pour la preuve de travail, comparé au Bitcoin et autres altcoins qui font la course à la puissance.

Cela apporte également une sécurité générale, car il ne suffit pas d’avoir une armée de machines pour venir casser la monnaie. Et même avec une telle armée, si seul 1 individu est derrière, alors l’impact relatif de ces machines n’est que de (1 / nombre de membres calculant).

De plus, il est dangereux de donner sa clé privée : celui qui la possède peut récupérer toute la monnaie de votre compte, se faire passer pour vous, certifier n’importe qui et révoquer votre compte. Donc partager sa clé privée avec d’autres personnes est risqué pour soi-même. C’est sur ce principe que Duniter pose le postulat 1 utilisateur = 1 voix, et que sa voix ne peut être transmise à un tiers. Ou si transmission il y a, que ça ne soit pas à grande échelle.

Il reste le problème que la clé privée est disponible sur la machine dont le nœud calcule des blocs. Elle est a minima dans la mémoire, au pire en clair sur le disque dur. Ce n’est pas très rassurant en termes de sécurité, le vol est tout à fait possible, et avec un peu de malchance si la révocation n’a pas été sauvegardée quelque part, le voleur peut se faire passer pour vous et repart avec la cagnotte !

La clé déléguée

L’idée de la clé déléguée consiste à pouvoir déléguer le calcul des blocs à une sous-clé, afin de mettre le trousseau principal en sécurité.

Cette idée est présente depuis longtemps, mais nous n’avions pas encore trouvé de solution assez satisfaisante pour l’implémenter. Pourquoi ? Parce que si je suis capable de créer une clé qui calcule sans risque pour mon propre compte, alors je peux très bien la filer à Google qui s’occupera de calculer à ma place. Et ce même Google de réitérer l’opération avec plein d’autres membres (moyennant quelques UNL), qui dispose alors d’une armée de clés et de machines pour calculer tous les blocs, et donc prendre le contrôle de la blockchain Ğ1. Autant dire qu’il a pouvoir de vie ou de mort sur la monnaie.

Mais l’idée qui m’est venue que l’on pourrait avoir comme règle :

Une clé déléguée peut révoquer le compte membre qui lui est associé.

Voilà, c’est simple, clair, limpide. Créer une clé déléguée permet de calculer des blocs avec cette clé, et donc de sécuriser la clé privée du compte membre en la retirant de la machine. Mais la corruption de la clé déléguée (vol par quelqu’un d’autre, don à Google) reste risqué pour soi, car notre compte peut être révoquer contre notre gré : adieu la production du DU, la certification de membres, et le calcul de blocs. Il faut tout recommencer.

A noter que la monnaie présente sur le compte ne peut pas être volée, tout comme il n’est pas possible de certifier des individus ni faire perdurer le compte. La clé déléguée peut seulement calculer des blocs au nom du membre à qui elle est associée, ou révoquer le compte du membre.

Il y aussi l’idée que l’on peut changer à tout moment de clé déléguée, afin d’annuler la précédente. Ce peut être parce qu’on pense sa clé corrompue par exemple.

Effet bénéfique également : on dispose de 2 clés pour révoquer son compte : la clé principale, et la clé déléguée. On double les chances de pouvoir révoquer son compte en cas de pépin.

Voilà, je laisse cette idée mûrir, et vos commentaires la juger.


Évolutions du protocole pour Duniter 2.0
Proposition d'un modèle de portefeuilles "HD"
De la lecture sur Proof Of Stake
#2

On dirait un travail pour les hierarchical deterministic wallet - https://bitcoin.stackexchange.com/questions/718/what-is-a-deterministic-wallet ?


#3

Si la clé déléguée peut révoquer le compte elle ne sert pas à grand chose. Il faut au moins qu’elle permette de miner des blocs, et pourquoi pas de signer des transactions et faire des certifs. Mais en aucun cas elle ne doit permettre de révoquer le compte. Sinon si elle est compromise ton compte est à risque, ce que la clé dérivée est sensée empêcher.


#4

@nanocryk en fait je fais référence a un autre type de clé déléguée dont nous avions intensément discuter sur le salon il y a plusieur mois : l’objectif est de sécuriser un noeud membre en n’y exposant pas sa clé privée de membre.

Mais il faut que la clé qui a le pouvoir de calculer des blocs reste non cessible, d’où le pouvoir de révocabilité.

Pour ton besoin de clés membres délégués capables de certifier ou/et effectuer des transactions dans les deux cas je suis contre :

  1. Les transactions peuvent être faites avec des comptes simple portefeuille, la monnaie du compte membre peut sans problème n’être utilisée que sur une machine sur puisque c’est comme un compte épargne, on n’y touche rarement.

  2. A mon sens le pouvoir de certification doit être non cessible tout autant que le pouvoir de calcul des blocs, si tu ne peut pas certifier quelqu’un parce que tu n’a pas accès a une machine sur, rien ne t’empêche de stocker sa clé publique sur ton tel et de le certifier plus tard quand tu est de retour chez toi.

EDIT : En revanche, quand ça concerne les clés simples portefeuilles là je suis pour :slight_smile:


#5

En effet je suis d’accord. Du coup il ne faut pas que cette clé puisse révoquer le compte en lui même, sinon ça serait la meme chose que d’exposer sa clé privée.

D’accord pour les certifications, mais pour les blocs tu te contredis non ? Tu veux sécuriser un noeud membre sans exposer la clé privée (avec une clé déléguée du cou), mais elle ne permet pas de miner. Ca ne sert a rien du coup.

A minima la clé déléguée permet de sécuriser un noeud membre et donc de miner des blocs. Rien d’autre. Il faudra utiliser la clé normale pour définir cette clé déléguée, ainsi que pour certifier ou révoquer son compte.


#6

haha faut que je te rééxplique tout les tenants et aboutissants de la discussion comme ce n’étais pas sur le forum :slight_smile:

En fait non se faire révoquer son compte et se faire dérober sa clé privée de membre c’est incommensurablement différent.
La révocation est une procédure normale déjà utilisée pour changer ses pass par exemple, tu ne perd pas ta monnaie et tu ne perd que quelques jours/semaines* de DU le temps de redevenir membre, c’est quoi quelques semaines dans 80 ans de vie ?
*En effet si tu était membre c’est que tu avait suffisamment de certifications il te suffit donc d’informer tes anciens certificateurs de la révocation de ton compte et de leur donner ta nouvelle clé, après avoir vérifier que c’est bien toi qui est a l’origine de la demande via plusieurs moyens de confirmation (coup de tel, ou se voir IRL quand c’est possible) à ils te recertifierons sans problème :wink:

Se faire dérober sa clé de membre en revanche, c’est très grave, car le voleur peut te dérober ta monnaie et certifier a ta place, ce qui compromet la confiance du réseau !

Si elle permettrais de calculer des blocs, relis moi tu à mal compris :wink:

EDIT : Je pense que c’est le concept de “non-cessible” que tu a mal interprété. Il signifie que l’on ne peut pas céder ce droit a quelqu’un d’autre, pas que l’on ne peut pas le déléguer a une autre clé. Mais si cette autre clé ne permet pas de révoquer le compte, alors elle est cessible, car le membre n’a pas grand chose a perdre a céder sa clé, l’idée c’est que la révocabilité permet la non cessibilité !


#7

J’exposais la contradiction que tu avais fait, bien évidement qu’elle permet de miner les blocs. Du coup je pense que ton edit ne change rien à ce que je disais.

Evidemment, je n’ai jamais dis ça.

En utilisant la clé déléguée pour calculer, ça t’empêche d’avoir ton compte a risque si la machine qui calcule est compromise. Tu délègue sur une nouvelle clé et le voleur ne peux plus miner à ta place. Et comme ce n’était pas la clé privée de ton compte membre, il ne peut rien faire d’autre. C’est tout.
En effet si tu veux changer ton pass tu révoque ton compte et tu en créé un autre en redemandant tes certifications.

Donc, je résume à nouveau :

  • Le couple clé publique/privé de compte membre actuel permet toujours de faire ce qu’elle permet aujourd’hui, avec en plus la possibilité de désigner une clé déléguée (chaque nouvelle désignation invalide l’ancienne,de sorte qu’une seule est valide)
  • Le couplé clé publique/privé déléguée permet uniquement de calculer des blocs (et donc de sécuriser un nœud membre)

Tu peux confirmer que c’est ça, sinon redéfinir ce que peuvent faire les 2 paires de clés.

Ce n’est pas mon besoin particulier. J’y ai pensé quand j’ai proposé l’idée des HD wallets, et du coup ça rejoignait une idée que vous aviez déjà et qui était plus permissive, donc tant mieux.


#8

Je n’ai pas fait de contradiction, c’est ton interprétation ça :wink:

Dans Duniter on ne mine pas on calcule c’est un point de langage important !

Dans ce cas qu’est ce que je risque a donner ma clé déléguée a google pour qu’ils calculent plein de blocs pour moi ?
Comme expliquer plus haut, il faut que cette clé déléguée soit non cessible, et pour ça le seul moyen c’est quelle est un pouvoir que l’on a pas envie de céder : le pouvoir de révoquer le compte membre associé.

Rien n’a été graver dans le marbre encore donc je ne sais pas, ce qui faisaient consensus en tout cas c’est le besoin de non cessibilité de la clé déléguée grâce a son pouvoir de révocation, c’est le point fondamental, sur le reste on peut discuter :slight_smile:

entendu :slight_smile:


#9

@nanocryk I find ! @cgeek avait eu la bonne idée de créer un post suite a notre discussion sur le salon xmpp :

https://forum.duniter.org/t/idee-cle-deleguee-au-calcul-de-blocs/2698


#10

À archiver :wink:


#11

Ca me semble plus être un détail. Depuis que la Proof of Work existe, on appelle le fait de tester de nombreux hash “miner”. Tu peux appeler ça “calculer” si tu veux, mais corriger à chaque fois que quelqu’un utiliser le mot “miner” n’est pas très utile car c’est non ambiguë et tu comprends qu’on parle de la même chose. Ce n’est pas parceque tu dis “pain au chocolat” que je ne peux pas dire “chocolatine”, je principal est de savoir qu’on désigne la même chose. J’essaye de faire attention et d’utiliser le terme “calculer”, des fois j’oublie, et c’est fatiguant de se le faire rappeler à chaque fois :confused:

Je comprend ça, mais je vois le problème sous un autre angle. J’ai un serveur dédié qui tourne h24, et sur lequel je veux mi…calculer. Actuelement, ma clé privée membre est dessus, et du coup si quelqu’un pénètre dans mon serveur, mon compte membre est à risque. C’est pour ça que je propose une clé qui permette de miner sans prendre de risque pour son compte membre, même sur une machine qui pourrait être comprise. Si ça arrive, je remplace cette clé déléguée et l’attaquant ne peux plus rien faire avec l’information qu’il avait.

Tu peux donner ta clé a quelqu’un d’autre, le réseau ne sera pas en danger grâce à la difficulté personnalisé qui empêche d’avoir une puissance trop grande par rapport au reste de réseau.
Si la clé dérivée permet de révoquer mon compte, je ne vois pas l’intérêt de l’utiliser au lieu de ma clé personnelle. Et je ne pense pas que ceux qui ont mis pas mal de temps pour être certifiés seront content de devoir refaire leurs certifications.

C’est justement suite a ce post que j’ai fait le lien avec les HD wallets.
Par contre il parle de la “multiplication” des clés hors du contrôle de l’utilisateur. Hors si seul la clé privée membre permet de définir quelle est la clé déléguée, la clé déléguée ne permet pas de se rependre. Quand je met ma clé sur mon dédié, je fais “confiance” à mon hebergeur pour qu’il ne vienne pas fouiner. Avec une clé déléguée ne pouvant que calculer, si je vois un comportement anormal (comme une machine différente qui calcule avec ma clé), je peux simplement la remplacer avec une autre. Et ceux sans jamais avoir mon compte membre en danger.


#12

Le problème est que si ce quelqu’un d’autre possède N clés, la difficulté personnalisée ne peut plus faire grand chose contre sur capacité à calculer la majorité des blocks.


#13

Ça ne l’est pas. Surtout avec l’aberration écologique du bitcoin qui commence a avoir de plus en plus mauvaise presse, à raison d’ailleurs. Dés que tu prononce “minage” tout perd direct toutes les personnes ayant une sensibilité écologique, je l’ai bien vu lors des apéros sur le terrain :wink:

Le fait de mettre en avant qu’avec la Ğ1 on ne mine pas c’est très important, alors si après les intéressés vont faire un tour sur le forum et vois le terme minage ils vont se sentir trompés !

En fait non tu ne le réalise pas mais pouvoir céder sa clé de calcul des blocs c’est signer l’arrêt de mort de la monnaie !


#14

Comme dit au dessus, il ne peut pas posséder N clés, car seule la clé privée du compte membre permet de définir la clé déléguée, et seule la dernière définie est valide. Donc si une clé se retrouve dans la nature, il ne peux y en avoir qu’une seule, et elle deviendra inutilisable dès que le membre la remplacera.


#15

Pourquoi la remplacerait-je si la personne a qui j’ai céder cette clé ne peut rien faire sur mon compte (car calculer des blocs ce n’est pas une action sur le compte)


#16

Mais quelqu’un qui va calculer ne va pas volontairement donner sa clé. C’est si elle est compromise à cause d’un problème de sécurité qu’il est nécessaire de pouvoir la changer pour se protéger.
Du coup je ne vois pas d’intérêt d’utiliser les clés déléguées si mon compte membre est exposé.


#17

Je parle de N clés de membres différents. Si les utilisateurs n’ont aucun risque à laisser quelqu’un calculer pour eux, c’est la porte ouverte à ce qu’ils laissent leurs clés chez un prestataire, qui pourrait alors prendre le contrôle du réseau, ou en tout cas fortement endommager sa décentralisation.


#18

Pourquoi réserve tu la génération de clé déléguée a quelqu’un qui va calculer ?
Si le clé déléguée n’a aucun pouvoir de révocation alors n’importe quel membre lambda peut se générer une clé déléguée et la vendre. le système doit être conçu pour résister a ce type de comportement aussi.


#19

Justement parce que c’est un danger pour la monnaie de permettre à quelqu’un d’autre de le faire.

D’ailleurs c’est pour ça qu’a la base je proposait que la clé déléguée permette aussi de certifier par exemple. Le compte en lui meme n’est pas en danger, par contre la personne qui se fait voler la clé va vouloir empecher la personne malveillante de certifier ceux qu’il veut. Il a donc un interet à la changer s’il veut respecter là license.

C’est bien pour ça que je voulais permettre les certifications avec la clé déléguée. Il devient dangereux d’avoir sa clé déléguée qui fui (car des non membres peuvent certifier, ce qui ne va pas avec la license; mais elle ne permet pas de révoquer le compte en lui même, ce qui limite les risques de calculer sur une machine dont on a pas le controle absolu)


#20

Nous on en a conscience par ce que l’on maitrise le fonctionnement technique, met toi a la place de la majorité des utilisateurs qui ne sont pas informaticiens, rajoute a cela le passage a l’échelle qui fait que nous n’aurons pas que des profils bienveillants dans la Ğ1 … et tu obtient une future prise de contrôle de la monnaie. Si nous passons a l’échelle nous aurons des ennemis il nous faut l’avoir en tête !