De ce que je comprends, l’introduction de mon serveur de gamer de récup avec 8 cœurs fout le brin dans le système parce qu’on est pas assez nombreux.
Il semble que je ne suis pas assez souvent exclus du fait de ma puissance (Aie vil konkire ze veurld maille frained ! Ouahaha !), et que j’augmente trop la difficulté commune.
A tout prendre, je préfère que l’algo de difficulté fonctionne sur la Ğ1 et patine sur la Ğ1-test que l’inverse.
Je ne sais pas si les problèmes de connexions de mon serveur avec les pairs (dû à Docker ou pas) rentrent en jeu ici.
Mon ordi est aussi plus puissant qu’un Rasp, et nos deux noeuds se sont passé la balle un moment.
Mais ceci ne peut-il vraiment pas se produire sur Ğ1 ? Si un ou deux noeuds malveillants mettent en place du hachage sha256 par GPU ou ASIC, peuvent-ils faire grimper la difficulté commune de la même manière et exclure les noeuds plus lents ?
L’article sur la preuve de travail me ferait plutôt dire que le principe est sécurisé de ce coté-là, tant que les noeuds “moins puissants” sont en nombre suffisant pour que les “surpuissants” soient exclus suffisamment longtemps.
Il me semble que c’est la constante dtDiffEval qui gère la réévaluation de la difficulté. Elle est de douze blocs pour les deux monnaies. Il faut attendre douze blocs pour que la difficulté soit réévaluée. Je sais pas si elle peut chuter autant qu’elle veut, ou de un en un max. Genre de 92 à 91 après douze blocs et ainsi de suite, ou bien passer de 92 à 88. Ça semble être de cinq en cinq max. C’était 97 avant, maintenant 92. Puis il devrait y avoir une difficulté de 88 dans quelques blocs.
Hum… Je pose une hypothèse à la hauteur de mon incompétence dans le domaine… La version « rouillée » de Duniter gère-t-elle bien la redescente de difficulté ? Il doit y avoir une majorité de noeuds GTest avec Duniter-oxyde ?
Je vais réinstaller la version originale, voir ce que ça donne.
Voici une discussion en rapport au sujet qui permettra de répondre en partie à cette question. On peut imaginer un blocage similaire sur la Ğ1 avec une trentaine de CPU avec un ou plusieurs GPU/ASIC. Ce blocage pourrait se produire, dans le cas où les CPU n’arrivent pas à trouver de blocs et être dans la fenêtre courante pour donner un handicap au(x) GPU/ASIC. C’est ce qui c’est passé avec vit2 qui nous a fait sortir de la fenêtre courante et a pu prendre le contrôle de l’écriture de la chaîne.
Uniquement la partie qui effectue les calculs relatifs à la toile de confiance (wotb) a été oxydée dans la version présentée par Éloïs. La règle du protocole ne serait pas respectée si la difficulté commune powMin ne changeait pas. Et, je doute que l’oxydation a touché aux règles du protocole, et encore moins à celle du calcul de la PoW.
Mon nœud Duniter (non oxydé) cherche toujours. Je ne vois pas d’erreur relative à un blocage dans les journaux (logs).
Pour relancer et permettre un déblocage, il faut trouver encore quelques blocs pour faire chuter la difficulté et ça devrait repartir à pleine vitesse pour rattraper le retard. @TestSmith, rajoutez vos nœuds avec une faible difficulté si possible sinon on va repartir dans le même blocage, une fois le retard rattrapé. @vit, peux-tu rajouter ton nœud avec un cœur et ou une faible puissance pour aider à débloquer.
J’ai rajouté le champ de la difficulté commune dans la commande d’analyse de blocs de Silkaj
Mon nœud a une difficulté personnelle élevée, car il a récemment trouvés plusieurs blocs dans les derniers blocs, malgré sa puissance dédiée using 1 cores, CPU 10%. Faut pas trop compter sur lui pour l’instant.
cgeek qui a trouvé le dernier bloc, n’est pas encore affiché dans la fenêtre courante, c’est un « bug » de Duniter :
Current block: n°546850, generated on the 2020-04-09 13:37:29
Generation of next block n°546851 possible by at least 5/5 members
Common Proof-of-Work difficulty level: 92, hash starting with `00000[0-3]*`
| uid | match | Π diffi | Σ diffi |
|-------------------+--------------+------------+-----------|
| vit2 | 000000[0-9]* | 1.0 × 10^8 | 102 |
| moul-test | 000000[0-E]* | 1.7 × 10^7 | 97 |
| matograine-G1Test | 000000* | 1.7 × 10^7 | 96 |
| Elois | 00000[0-3]* | 1.3 × 10^7 | 92 |
| Elois-2 | 00000[0-3]* | 1.3 × 10^7 | 92 |
Je découvre dans mes logs au niveau `debug` un autre fork en parallèle
2020-04-18T13:45:16+02:00 - info: Block resolution: 0 potential blocks after current#546852... ┤
│2020-04-18T13:45:16+02:00 - info: Fork resolution: 101 potential block(s) found... ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546855-0874590F -> 546955-120F5E56 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546854-006DA363 -> 546954-1C22A9BD out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546853-02FDEEBE -> 546953-120A8CB2 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546852-0565A5D3 -> 546952-0E4AD078 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546851-0453C713 -> 546951-120951E7 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546850-003E9179 -> 546950-09618F8C out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546849-0633E0CD -> 546949-114F5E2D out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546848-03BCE161 -> 546948-1B65AB8A out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546847-0351B4B1 -> 546947-03D4CE8D out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546846-07441E47 -> 546946-05AE5E58 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546845-04B6B757 -> 546945-00B71275 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546844-027D2BC5 -> 546944-095D9993 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546843-01CE9482 -> 546943-0FE03BEB out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546842-027F3149 -> 546942-05E4F12D out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546841-000D7BA5 -> 546941-017AC3D9 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546840-06014C57 -> 546940-0E459FFD out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546839-059BEE92 -> 546939-0DDFE2D0 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546838-06F5D553 -> 546938-08D696EB out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546837-002BB460 -> 546937-08475602 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546836-01F05DC4 -> 546936-0BB11C0C out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546835-062CE89C -> 546935-033766D5 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546834-03FB2CBD -> 546934-0725B031 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546833-00DE14A4 -> 546933-0C6141EA out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546832-02C644B8 -> 546932-0E84EE5C out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546831-052754D8 -> 546931-0AE3F39D out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546830-0639FB28 -> 546930-083E26D1 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546829-062895B2 -> 546929-044F64B9 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546828-04823072 -> 546928-0C2C7195 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546827-04908190 -> 546927-0C69517E out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546826-01C8FB46 -> 546926-0969462E out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546825-00573A21 -> 546925-04058C58 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546824-010AA90F -> 546924-0DE8F221 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546823-05327654 -> 546923-01E619BB out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546822-0288B480 -> 546922-0D8EB6BC out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546821-054D050E -> 546921-0BAA0644 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546820-0398991E -> 546920-09170606 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546819-0435F116 -> 546919-061082DA out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546818-037EF831 -> 546918-0C25E549 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546817-05AC93CC -> 546917-08814076 out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546816-04EE5E10 -> 546916-0C29D58D out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546815-043D4B77 -> 546915-09D3302B out of fork window ┤
│2020-04-18T13:45:16+02:00 - debug: Suite #546814-03D8403D -> 546914-0AF0D726 out of fork window
Quelqu’un sait où se trouve ce fork ?
Quelqu’un peut rajouter un nœud avec un peu de puissance pour débloquer. Puis, une fois l’accélération lancée faudra baisser la puissance pour que ça ne reparte avec une trop grande difficulté. J’ai un peu augmenté la puissance de mon nœud.
En fait on y arrivera pas, il faut qu’un noeud avance tout seul jusqu’à que la diff commune de sa branche soit remontée au moins au-dessus de 50.
Quand la diff commune est trop faible le réseau est ultra instable, il faudrait qu’on instaure une diff commune minimale dans DUBPv13 pour ne plus avoir ce problème à l’avenir. Toute la question est de trouver la bonne valeur, je pense que 60 est une bonne valeur.
Le phénomène est pire qu’avant car la version oxydée de Duniter effectuée la PoW avec une meilleure efficacité (environ 20 à 30% plus rapide, avec les mêmes ressources cpu).
