pour le dossier de build j’hésitais à le mettre en ignore. mais il a l’avantage de pouvoir rendre lisible le résultat dans gitlab sans avoir à compiler le projet.
un build de la CI de gitlab pourrait faire ce job et publier une page d’ailleurs.
bon c’est chouette tout ça on va avoir des formules propres !
j’ai pas du tout lu le contenu des chapitres, du coup aucune idée si les infos sont bien à jour. (vivement une version fr, n’ayons pas peur de l’utiliser)
gare aussi aux infos de copyright en bas de document, je doute qu’un whitepaper soit publié avec une licence « tous droits réservés »
j’ai fait une première traduction en français avec Linguee, il faudra relire plein de choses avant que ça soit bon, mais ça traduit mille fois mieux que google.
@tykayn La plus grande partie du texte existe déjà en Français. Ce descriptif technique est, pour sa majeure partie, une compilation des articles cités en début de fil. Il y a quelques précisions et reformulation, l’intro et la partie 1 qui sont tout de mon crû mais le reste existe déjà en français.
edit pour ajouter les liens :
Le premier, theoretical n’est vraisemblablement plus dispo en francais. J’ai encore une version .md du texte
pour la traduction j’ai un contributeur à Fedora qui propose qu’on utilise le weblate de chez eux et de le relier au dépot du whitepaper pour que les fichiers md soient automatiquement mis a jour quand de nouvelles traductions sont approuvées, au lieu de devoir gérer notre propre weblate.
How is difficulty applied?
''''''''''''''''''''''''''
The numeric value of difficulty is taken from an array of possible
hashes out of all possible hashes. In DUBPv13 the hash of a block is its
sha256 hexadecimal hash.
To understand the difficulty, we make a euclidiean division of the
difficulty by 16.
Here’s an example with a difficulty value of 70:
.. math::
:label: eucl_division
70 / 16 = 4 with a remainder of 6.
The valid hashes are the ones starting with four zeros and with the
fifth character less than or equal to 9 (6 in hexadecimal notation). The
valid hashes are then written as starting with: ``0000[0-9]``. This is
a bit different from Bitcoin, where the difficulty is only ruled by the
number of zeroes.
Si je comprends ce qui est dit, pour une difficulté de 70, le hash attendu devrait être 0000[0-6], et l’exemple est faux.
Si j’observe comment la difficulté est mise en place, le dernier caractère correspond non pas au reste exprimé en hexadécimal, mais à (15 - reste) exprimé en hexadécimal.
ex. sur la GT :
diff = 75
75/16 = 4 et reste 11
15-11 = 4
hash attendu : 0000[0-4]
| jyt-test | 0000[0-4]* | 7.2 × 10^5 | 75 |
edit - c’est la règle BRG_62 qui correspond à ma compréhension.
@matograine non je parle du texte que tu à cité en premier dans ton précédent message. Le texte sur le site officiel de Duniter est bien correct et conforme à la règle BRG_62
@matograine je parle de ce texte là, celui à partir duquel tu posais ta question. Je ne l’ai jamais vu avant, je ne sais pas qui l’a écrit ni où tu l’as trouvé. En tout cas ce texte comporte deux erreurs :
1 - 9 se représente bien 9 en notation hexa, je ne sais pas pourquoi l’auteur de ce texte a ajouté cette précision fausse entre parenthèses
2 - La difficulté dans le bitcoin ne dépend pas uniquement du nombre de zéros, de plus le texte ne précise pas si l’on parle de zéros binaires ou hexa, c’est très différent car dans le 2ème cas la granulométrie est 16 fois plus fine… Quant au bitcoin il ne se base pas vraiment sur un nombre de zéros (ça c’est ce que tout le monde dit en vulga pour simplifier), la réalité est bien plus compliquée : Difficulty - Bitcoin Wiki
Bon. Cette fois, je crois qu’on est presque « ça-y-est ».
J’ai râlé, pesté, attendu parce que :
je n’arrivais pas à mettre les sources à la fin du document PDF.
je n’arrivais pas à faire en sorte que la table des matières ne soit pas dépliée (html)
J’ai laché prise . Donc ceusses qui voudront ces améliorations bienvenue sont librement invité.e.s à les réaliser.
Améliorations :
le script de génération est prêt pour de futures traductions
le PDF n’a plus de chapitre « sources » vide à la fin
le script génère un fichier .epub
Voici donc le descriptif technique, en .html et .pdf.
Pour moi j’ai fini. J’ai mis @elois, @cgeek et @inso comme co-rédacteurs, vu que j’ai compilé leurs oeuvres. Je vous laisse faire des remarques s’il y en a. Je ne sais pas bien s’il faut publier une version 1.0, je vais attendre d’avoir eu des derniers retours pour le faire.
Je pense que @HugoTrentesaux en particulier sera intéressé pour le futur site web de Duniter. Je pense que l’annonce d’un WP devrait être faite en même temps que le futur site.
Houla ok alors attend mato, faut que je relise tout ça au peigne fin, surtout si je suis co-auteur, je mets ça dans ma TODO list mais ça va pas pouvoir être pour tout de suite !
En effet, si on a un whitepaper qui fait l’unanimité, on peut l’annoncer en même temps que le nouveau site. Mais pas avant une relecture très attentive de la part de toutes les personnes impliquées ! Pour ma part, j’aurais quelques modifications à apporter aux figures, avec la rédaction de ma thèse, j’y ai été très entraîné !!
@matograine j’ai enfin terminé ma 1ère relecture, j’ai soumis une série de correctifs dans une MR :
Certains correctifs concernent les articles sur la WoT et la PoW que j’avais rédigé en français, et dont je n’avais pas relu suffisamment attentivement les traductions.
La comme c’est dans le cadre d’un whitepaper qui va devenir THE référence je suis obligé d’être plus exigeant dans la relecture, mais ça prend plus de temps aussi, cette première relecture m’a demandé 6h de travail !
Globalement c’est bien, un seul point m’a vraiment choqué :
The RTM proposes a formula to calculate the exchange rate between two
currencies, that could be used to create automatic exchanges for a
member travelling away from their community.
Ha bon ?! Je n’en connais pas l’existence. En tous les cas nous n’avons pas à administrer un taux entre 2 monnaies selon une quelconque loi, partie à supprimer (ce que je fais dans ma MR, et je reformule en même temps).
Aussi pour un whitepaper ça ferait plus sérieux que les auteurs soient écrits par leur Nom et Prénom plutôt que par leur pseudo, si @cgeek et @Inso veulent bien évidemment
Enfin une fois que tu auras traité tous nos retours @matograine laisse encore du temps. Une fois tous les retours traités j’aimerai faire une ultime relecture pour être bien sûr !
Ouah, la relecture était plus que nécessaire, merci du boulot !
Pour être précis, c’est une comparaison des densités relatives de monnaie, qui donne une bonne approximation du taux de change. Plus de précisions dans la TRM..
Cependant tu as raison, c’est hors-sujet pour ce qui concerne le WP de Duniter. J’enlève ces quelques phrases.
mais le reste existe déjà en français.
. Donc ceusses qui voudront ces améliorations bienvenue sont librement invité.e.s à les réaliser.