Nœud spécialisé pour visualiser salle d'attente des futurs membres Ğ1

Networks Ğ1
87

Une identité c’est en fait 3 champs :

  • UID (pseudo)
  • clé publique
  • blockstamp (date)

Donc tu peux effectivement avoir plusieurs identités avec le même UID ou la même clé publique ou la même date, mais une identité A qui aurait les mêmes 3 champs qu’une identité B voudrait simplement dire que A = B.

Ceci n’est pas vrai en blockchain : tout UID ou clé publique inscrit en blockchain est réservé. Il ne peut pas y avoir une nouvelle identité en blockchain qui réutiliserait le même UID ou la même clé publique.

Le hash dont parle Eloïs, c’est l’empreinte du document d’identité (= SHA256(identité)), donc l’empreinte des 3 champs.

2 Likes
88

C’est un petit peu chiant de s’entendre dire “t’as qu’a forker” à toute proposition! Je ne vais pas forker ton bébé pour renommer 1 ou 2 pages enfin!! Surtout que moi aussi je m’en fiche complet du nom! C’était une idée comme ça après avoir parcouru le topic sur les propositions de nom pour ḡ1, donc j’était très dans les noms…

Sérieux qu’est ce qui est compliqué?

DiG: Tu veux pas trouver un nouveau nom?
elois: non

Basta! Pourquoi balancer à la gueule un “t’as qu’à te débrouiller par toi même” ? Et alors si je te propose un css pour ces pages tu va me répondre de forker aussi? L’open source c’est pas “TG et fork” hein! :wink:

Je vais me faire un noeud spé, mais pas pour faire de la requette en DB! Ca ne m’interesse pas, je suis plus front moi :slight_smile: Par contre @elois, je veux bien quand même un github, pas pour forker, mais plus pour étudier comment on fait un noeud spé… j’ai pas pu venir aux RML8 où a été présenté la spécialisation de noeud…

89

Merci @cgeek pour les précisions… Mais je comprends encore pas la “clé publique” c’est pas ce tas de char qui est généré à l’aide du couple passphrase et mot de passe?
Dans ce cas, 2 fois le même couple produit bien la même clé c’est bien ca?
Donc 2 personnes, qui ne se connaissent pas, peuvent (par hasard) choisir la même passphrase, le même mot de passe et le même psudo, il ne seront différent que de par leur date d’inscription ?

90

Si, par exemple la tienne c’est pnSrZARn2gL5T5BLFGvLWFdWQ4RSLpQf8tJvBrK1GGE.

Si je prends l’identité associée à cette clé (je n’en vois qu’une seule en piscine), je peux même te donner plus d’infos :

  • Clé publique: pnSrZARn2gL5T5BLFGvLWFdWQ4RSLpQf8tJvBrK1GGE
  • UID: dig
  • Date: 6102-000000D655C4857D12C080E5FB278F481F4E03CD54C330F49B245CE5338BABCC
  • Empreinte (hash) : 05BA7DB3397259B898FAC10D3B5782E36F63371F6C882646F5482643AC4F1391
  • Signature: 7gPe2dLG6ufgp6JngcwZNaOhzIGvw7+LlnHbfxWvjGkqPdmHsaV61fmzOA/vFWgF/V3Dg3aAwd7Z9EiAVAh1Aw==

Exactement. Et ce sera suffisant pour les différencier.

91

Oui mais s’il s’en rendent compte l’un et l’autre peuvent se connecter respectivement au compte de l’autre >_< !

92

Le principe de base c’est de considérer que personne ne va choisir les mêmes phrases de protection que toi, même « par hasard ». C’est le cas dans Duniter, Bitcoin, etc.

Notamment avec quasiment autant de clés possibles que d’atomes dans l’univers observable, si l’on utilises des méthodes conseillées, alors le risque devient tellement faible qu’on le considère négligeable.

1 Like
93

Autant un nom je m’en fiche, autant tu me propose un css je prend :slight_smile:

2 Likes
94

Allez! Give me your github! :wink:

1 Like
95

github? gitlab?

96

git whatever ! :slight_smile:
MAIS PAS CVS! >_<

97

Je crois qu’il est là : GitHub - duniter/duniter-currency-monit: This specialize duniter node monitoring the state of currency and web of trust

3 Likes
98

Je crois que willMembers est down.

99

Yep! Down aussi:

502 Bad Gateway

nginx

100

Oui mon noeud spé s’est arrêter inopinément, je viens de le relancer :wink:

Je ne sais pas si la cause de l’arrêt viens de mon code ou du code du duniter mais voici les traces log :

{}
127.0.0.1 - [05/Apr/2017:14:59:06 +0000] GET /willMembers HTTP/1.0 200 148518 - 19385.423 ms
{ d: '65',
  sort_by: 'creationIdty',
  order: 'asc',
  lg: 'fr',
  hideIdtyWithZeroCert: 'yes' }
127.0.0.1 - [05/Apr/2017:15:01:42 +0000] GET /willMembers?d=65&sort_by=creationIdty&order=asc&lg=fr&hideIdtyWithZeroCert=yes HTTP/1.0 200 41676 - 52600.270 ms

<--- Last few GCs --->

1000341626 ms: Mark-sweep 1394.5 (1389.5) -> 1394.4 (1387.5) MB, 2706.0 / 0.0 ms [allocation failure] [GC in old space requested].
1000344770 ms: Mark-sweep 1394.4 (1387.5) -> 1394.2 (1354.5) MB, 3143.8 / 0.0 ms [last resort gc].
1000347396 ms: Mark-sweep 1394.2 (1354.5) -> 1393.7 (1348.5) MB, 2626.2 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x703be05cfb51 <JS Object>
    1: /* anonymous */ [/home/duniter/duniter-g1-special-node-members/node_modules/duniter-prover/lib/blockGenerator.js:266] [pc=0x703bfd7d186d] (this=0x703be05e6111 <JS Global Object>)
    2: next [native generator.js:21] [pc=0x703bfd5991ea] (this=0x703b5eaa01e9 <JS Generator>,i=0x703be0504201 <null>)
    3: onFulfilled [/home/duniter/duniter-g1-special-node-members/node_modules/co/index.js:65...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x1096a4c [node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [node]
 6: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape, v8::internal::HashTableKey*>::New(v8::internal::Isolate*, int, v8::internal::MinimumCapacity, v8::internal::PretenureFlag) [node]
 7: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape, v8::internal::HashTableKey*>::EnsureCapacity(v8::internal::Handle<v8::internal::StringTable>, int, v8::internal::HashTableKey*, v8::internal::PretenureFlag) [node]
 8: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [node]
 9: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [node]
10: v8::internal::Runtime::SetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode) [node]
11: v8::internal::Runtime_SetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [node]
12: 0x703be0d092a7
Abandon
101

J’avais remarqué que ton nœud était devenu un peu plus lent dernièrement, et là effectivement c’est beaucoup plus rapide d’afficher la page.

C’est possible qu’il y ai des fuites dans Duniter, tout cela reste à analyser. Si tu investigues, hésites pas à me tenir au courant :slight_smile:

102

J’ai une 502 Bad Gateway cette fois.

Ah, c’est revenu.

103

tu t’est connecté pile pendant la mise à jours !
Voile mon nœud spé tourne sur la 1.2.1

2 Likes
104

Une amélioration possible : afficher avec une couleur spéciale les certifications en erreur, par exemple en orange.

Ce sont les certifications dont le blockstamp (la date de référence) n’existe plus du fait d’un fork. Tu peux prendre l’exemple de ta certification à KennySLB @elois, son blockstamp est 8931-000007E256 alors que dans la blockchain on a 8931-00001784.

1 Like
105

ha c’est donc à cause des fork que Kenny n’est pas devenu membre dans la nuit, moi qui pensais voir enfin écrite ma 1ère certif…

C’est bon je viens de coder la vérif du blockstamp : https://github.com/librelois/duniter-special-node-members/commit/36aa26a8c6c6cedde33c5eb5e211663004a91cd8

je n’ai pas mis à jours la légende par contre, je ferais ça plus tard !

3 Likes
106

Excellent !