Block issuance distribution

Suite à notre discussion sur le chat, je reprends les trois points de tortue qui me semblent corrects :

  • le déni de service lui est réglé par le fait que seuls les membres peuvent miner + le protocole d’exclusion de la 0.40.

  • la double dépense par l’envoi de 2 TX simultané doit être réglé par un mécanisme de consensus plutôt rapide (et pas 1667 bloc) afin d’être sur que tout le réseau est OK pour dire que ces coins reçus sont bien a moi (6 blocs me semblent bien)

  • la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable, est le gros point noir d’aujourd’hui. Car facilement réalisable avec le piratage de la clef de quelques identités membres, et extrêmement facilité par la preuve de travail personnalisé qui réduit fortement la complexité moyenne de la blockchain.

Et je cite cgeek :

Ce peut être tout simplement ça l’algorithme : rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre). Aujourd’hui Duniter n’a pas de vision du réseau façon Sakia, mais c’est assez simple à ajouter.

Qui d’un algo de la forme suivante :

  • Quand un noeud ajoute un block sur son HEAD, il broadcast le block ET ajoute sa signature au broadcast
  • Quand un noeud reçoit un block d’un fork différent, il switch si les signatures accumulées sur ce block sont plus nombreuses

Dans cette forme, pas besoin de connaître tous le réseau pour observer la majorité : le broadcast de signatures et leur accumulations permet de savoir de manière isolée quel block est majoritaire dans le réseau.