Rédaction d'un whitepaper

Du coup je l’ai tourné comme ça (j’ai pas mal reformulé cet article, notamment pour faire des phrases plus courtes) :

extrait

… De toutes manières, le WP aura besoin d’une relecture attentive, sur le fond comme sur la forme.

2 Likes

Nickel, merci beaucoup :+1:

On continue.

Contrairement à de nombreux projets de cryptomonnaies, on a pas de frais de transaction. Les dispositifs anti-spam sont donc à justifier fortement, et c’est la partie que je dois écrire moi-même :wink:

J’ai retenu quelques mesures anti-spam de transactions, mais je n’en suis pas toujours très sûr et je ne sais pas toutes les sourcer / justifier. Je vous les soumet avant d’écrire des sottises, pouvez-vous me les confirmer/infirmer/sourcer si nécessaire ? En oublié-je ? Merci d’avance !

Limite basse des outputs à 100*unitbase

Ceci évite qu’un attaquant crée e trop nombreuses sources pour remplir les indexes. Prévu en DUBP v12.

chaînage maximal de 5 tx dans un bloc

On peut avoir une profondeur de chaînage des tx de 5 dans un même bloc au max. Ceci permet de bloquer un attaquant qui voudrait créer énormément de sources différentes et faire grossir la BC trop vite. (source, justification ?)

Seuils de dépense

Pour des montants d’un même ordre de grandeur, il y a une limite du nombre de montants dans un même bloc. Quelles sont les seuils limites, les ordres de grandeur, peuvent-ils évoluer ?

Ceci avait été proposé par @nanocryk, ça a été implémenté ?

Nombre de tx maximales pour un même portefeuille

Un même portefeuille a une limite dans le nombre de tx qu’il peut enregistrer dans un bloc (c’est un souvenir que j’ai, mais pas de source). Est-ce vrai ? Si oui, où puis-je trouver cette info ?

Taille dynamique des blocs (problématique de montée en charge)

BR_G07
BR_G50

La taille maximale d’un bloc (en octets) est max(500, 1.1*(moyenne des issuersFrame derniers blocs)), sauf pour le bloc 0. Ceci limite le nombre de transactions sur le réseau tout en autorisant une montée en charge progressive. Ceci suit une progression exponentielle.

1 Like

Tu peux y ajouter les mesures anti-spam des nœuds eux-mêmes qui bloquent très rapidement s’ils sont inondés de connexions. Bien sûr, cela n’empêche pas un petit malin d’avoir son propre nœud débridé auquel il soumettrait des millions de transactions… à essayer pour voir comment se comportent les autres nœuds dans ce cas-là…

PS : je pensais me coller à la rédaction, mais je suis un peu sous l’eau, là… :confused:

Mouaif… Pour moi les mesures des nœuds sont hors-champs concernant le spam, si un noeud malhonnête peut bloquer les nœuds honnêtes sous l’afflux de transactions…


Bref. J’ai rédigé un premier brouillon, et j’ai quelques questions. J’ai surtout compilé, relu et parfois reformulé les articles de @elois et @cgeek. La partie concernant le spam et le scaling est tout de mon cru.

  • le brouillon est accessible ici en html
  • la MR (pour commenter) est ici. Je ne sais pas si tout le monde peut commenter, dites-le moi sinon, je changerai.

Il y a plusieurs XXX (TEXTE) XXX dans le texte, pour pointer des endroits où j’ai besoin d’un apport théorique / référence / confirmation. De même, j’ai pu conserver quelques anciens paragraphes commentés dans les fichiers Markdown pour référence.

Je vous suggère d’utiliser la MR pour commenter. Toutes les remarques sont pertinentes, sur le fond comme sur la forme (formulation anglais, ponctuation, normes d’un WhitePaper…)

**Questions sur l'article WoT**

Les questions supplémentaires concernant la WOT:

source : Duniter | Deep-dive into the Web of Trust


The Duniter WoTs - one per currency - works with a set of eight fundamental
rules enforced through eleven different parameters. Ten of
these parameters are set within the genesis block, the eleventh one -
msPeriod- having being hard-coded in the Ğ1’s code subsequently.

in new versions of Duniter, is msperiod a parameter written in the genesis block ? Or is creating a currency not a feature of Duniter in its current state ? Or is this pointless for the WP ?


I miss clues to understand this graph.

  • I read that abscissa are honest members number, and ordinates Sybil number percentage.
  • Why do the 3 curves have a common part ? Is it due to the simulation choices ? Or is it that the Sybil regions reached a “maximum” extension, then identities expire ?
  • The 3 vertical lines show the point when the Sybil region is 200% of the honest region.

The paragraph points a “growth speed”. But ther is no time I read on the graph, so I have no speed to read.

What I read on this graph is that a Sybil Attack can reach 200% of the honest WoT with the value of sigPeriod = 5 days. I hope that I am mistaken.


Many sociology studies have shown that we all know an average of fifty
people.

Which ones ? :wink:

Reference practices : there are many links to Wikipedia articles. I don’t think Wikipedia is a good source for the Whitepaper (?). I leave inline reminders when another source is necessary (forum posts or RML conferences might suit me if they point to these external references )

3 Likes

@matograine : Étant plus précis dans la langue de Molière, je préfère te répondre en français :slight_smile:

Aucun des 3, ça restera un paramètre en dur pour toute nouvelle monnaie. On pourrait faire le dev nécessaire pour le mettre dans le bloc genesis, mais Duniter est dédié a la G1, donc on ne le fait pas.
Duniter ne permet pas de créer une nouvelle monnaie autre qu’en DUBP v10, le jours ou ça sera un besoin on changera peut-être ça (ou pas).

Non l’abscisse c’est le nombre de jours.

Il n’y a pas d’expiration dans cette simulation. C’est purement lié au paramètres de la simu. Une fois que la région sybil a atteint sa taille maximale, elle ne peut plus grandir, mais le nombre de membres honnêtes continu de grandir au même rythme.

J’avais fait cette simu il y a longtemps, c’était par rapport a la règle du tiers exclu des membres calculant. L’analogie n’est valable que si 100% des membres sont calculant, dans cette hypothèse si la région sybil atteint 200% des membres honnêtes alors l’attaquant peut contrôler toute la blockchain.
Dans la réalité c’est moins puisque tous les membres honnêtes ne calculent pas, disons que c’est la borne supérieur ou on est sûr que c’est foutu.

J’avoue avoir repris les propos de @Galuel ici sans lui avoir demander ces sources. @Galuel tu avait parlé d’études qui montrent que l’on connaît bien 50 personnes en moyenne. Je n’arrive plus a retrouver le post en question, même si je pense que c’est peut-être dans ce thread : Étude de la WoT - #39 by Galuel

@HugoTrentesaux a part toi je sais pas qui d’autre dans la communauté connaît bien les règles des papiers scientifiques, n’hésite pas a les tagger ici. En tous cas je pense qu’on a besoin de tes retours sur la forme :slight_smile:

1 Like

Oui, je suis curieux de savoir comment le réseau réagirait?

Il suffirai d’appliquer les mêmes mesures anti-spam sur les endpoint WS2P que sur les endpoints BMA, c’est aussi simple que ça…

Juste pour être sûr, les mesures anti-spam s’appliquent au nœud avec sa clé privée, non à l’adresse IP, c’est bien ça ? Parce que changer d’adresse IP à chaque envoi de données, c’est très facile. :slight_smile:

Aujourd’hui il n’y en a pas il me semble, mais oui il faudrait les appliquées par pubkey :slight_smile:

1 Like

On parle bien de la transmission inter-noeuds ? Effectivement, si le noeud attaquant doit changer ses IP + fiche de pair toutes les 5 minutes pour continuer à transmettre des txs en masse, ça lui met des bâtons dans les roues.

Mais ceci peut encore être contourné par l’utilisation simultanée de plusieurs noeuds “miroir” malveillants. Ca augmente toujours le coût de l’attaque :smiley:


En revanche, limiter le nombre de tx en piscine par pubkey me semble inutile, vu que l’attaquant peut déjà créer autant de comptes qu’iel le souhaite.

2 messages ont été scindés en un nouveau sujet : Frais de transaction

Les autres scientifiques comme @MatthieuLatapy et @NicolasGensollen. Mais en ce moment on est tous assez investis dans les mobilisations de l’enseignement supérieur et de la recherche en réponse à la loi sur les retraites et à la loi sur la recherche donc on (en tout cas je) lève le pied sur la ML. La rédaction d’un whitepaper est un peu descendue dans la liste de priorités.

2 messages ont été scindés en un nouveau sujet : Choix de vie vs ğréférentiel

@Galuel, Peux-tu donner une source sur ce nombre de 50 connaissances moyennes que tu avances ? Je trouve Dunbar comme source, qui estime le nombre de relations proches entre 100 et 200.

On est dans le bon ordre de grandeur avec le choix de 100 certifs, mais la justification n’est pas du tout la même. Si tu ne donnes pas de source, je partirai sur Dunbar en changeant la justification dans le WhitePaper.

1 Like

Oui c’est après une discussion avec Antonio Casilli rencontré via @OAuber (lors d’une rencontre à Paris il y a un moment déjà). Sa page wikipedia est là : Antonio Casilli — Wikipédia

Il me semble qu’il y avait un article de blog qui parlait de ça.

Donc ta source est “une discussion” ? As-tu un document publié à citer, ou une conférence enregistrée ?

A.Casilli est peut-être expert dans son domaine, et particulièrement pertinent dans le cadre de la toile d’identification de Ğ1, à cheval sur les relations physiques et numériques, mais sans document à indiquer sur le WhitePaper, la source n’est pas suffisante.

Dunbar, effectivement, parle dans cette conférence ( de 4:20 à 5:00)de seuils d’intimité de “5, 50, 150” personnes, ce qui correspond aux chiffres que tu donnes en premier lieu (50 à 150 connaissances).

2 Likes

J’ai donné ma source oui, je crois que j’ai été clair !