Est-il possible de n’exclure qu’1/3 des noeuds tout en améliorant la distribution des blocs ? (cf mon commentaire plus haut, dans les réseaux distribués, il faut tenter d’avoir toujours 2/3 du réseau qui peut travailler…)
edit : ma réponse était pour @inso, mais avec le déplacement de sujet, ça indique que c’est pour Moul.
1/3 des membres qui calculent, c’est-à-dire ceux qui ont émis un bloc dans la fenêtre courante.
Ça paraît beaucoup, mais ça veut aussi dire que les 2/3 restant calculent en permanence. A quelques variations prêt bien sûr, il y en a qui arrêtent et d’autres qui se mettent à participer.
Mais pour résumer, on a 2 visions :
- une qui consiste à dire que n’importe quel participant devrait avoir la capacité de poursuivre la blockchain tout seul s’il le souhaite (1)
- une qui consiste à dire que ce bien est commun et qu’on ne peut pas en prendre le contrôle soi-même, mais que des semblables sont nécessaire à la poursuite de l’aventure (2)
A noter que 1) est en réalité toujours possible, on peut forker la blockchain quand on veut par exemple pour changer la difficulté et faire passer une blockchain du mode 2) vers 1).
J’étais parti pour 2) jusqu’à la 0.4, j’ai voulu tenter 1) depuis la 0.5.
edit 2 : mais en effet, le problème majeur que l’on avait c’était les forks, mais ces forks ont aussi leurs raisons : notamment parce que je propageais la nouvelle version du protocole de façon instantanée et non coordonnée, contrairement à la 0.5 qui a été planifiée, où il n’y a eu aucun fork majeur.
Si l’on sait éviter les forks majeurs, alors il n’y a pas vraiment de problème à avoir un algo à la 0.4.
2 Likes
en fait je ne comprends pas 
Pour moi cela ne corrige pas le problème, imaginons un vol de 6 identités membres (clef privée/publique) qui n’ont jamais minée (=> pow min et non exclu) il est alors possible de miner 6 blocs consécutifs grâce à chacune de ces 6 identités.
Avec le system de POW personnalisé (ou exclue) cela réduit drastiquement la complexité moyenne de la blockchain et permet de créer une nouvelle version de la blockchain bien plus facilement.
plus j’y réfléchis, plus j’ai peur de la POW personnalisé.
Oui, mais ça ne dure que 6 blocs. Sur 200 nœuds calculant, c’est 3% du temps qu’ils peuvent monopoliser. Et encore, cela suppose que le super calculateur soit largement plus puissant que les 194 nœuds restants, cela a un coût non négligeable pour une gêne assez infime, tout en sachant que la fonction de hashage reste aléatoire.
Par ailleurs, rien ne nous empêche, nous non plus, de calculer des blocs vides ou des blocs qui ne contiennent que des données qui nous intéressent personnellement. Nous avons alors un comportement similaire au super calculateur, sans avoir sa capacité de calcul. Si tout le monde agit en ce sens, la monnaie fonctionnera tout aussi mal, voire très mal.
Au final donc, ce n’est pas tant le super calculateur le problème (sauf en 0.5, là oui c’en est un) que la volonté des membres de sécuriser sa monnaie en démultipliant le nombre de nœuds pour la faire fonctionner.
C’est une fausse peur, car quand tu regardes Bitcoin ou les altcoins à base de PoW, là c’est clairement la voie royale pour avoir un contrôle centralisé. D’ailleurs c’est déjà le cas, il y a des “pools”. Et l’inquiétude grandit chaque jour, car l’intérêt pour le minage baisse (moins de coins à miner) ce qui va à terme signifie la mort de la monnaie (voir le cas de Auroracoin qui est mort justement par manque de puissance de calcul faisant balance à un attaquant).
D’ailleurs Bitcoin peut dores et déjà être tué : il suffit de voir qu’il y une puissance globale au réseau et que celui qui le veut peut investir un gros paquet de blé dans un super-calculateur et s’amuser à créer des blocs vides. Et avec les banques qui peuvent créer de la monnaie à volonté, c’est tout à fait faisable. Bitcoin est laissé vivant, il faut bien en avoir conscience.
Alors que dans un système qui réduit les possibilités d’écritures à des membres identifiés, avec un algorithme s’assurant d’une certaine rotation, là ça pose beaucoup plus de difficultés.
A mon humble avis.
1 Like
Je ne parle pas d’un déni de service, qui lui reste effectivement tout à fait limité (et peu d’intérêt a mon sens, sauf peut être pour les banques en place) mais je parle plus dans le cas d’une place de marché qui échange la monnaie libre contre d’autres monnaies. Où le but de l’attaquant est de supprimer de la blockchain le transfert de monnaie envoyé à la place de marché qu’il a effectué précédemment. (possibilité de dépensé plusieurs fois la monnaie de l’attaquant)
un ti exemple ici:
http://www.gldcoin.com/documents/GoldCoin_0.7_51percent_defense_october_11_2013.pdf
Ah oui, mais non, pour plusieurs raisons :
- déjà le principe des crypto-monnaies des 6 blocs d’assurance du transfert : on considère un bloc comme entériné à partir de 6 autres blocs au-dessus. Si dans Duniter c’est plus, hé bien il suffira de dire que c’est plutôt 8, 15 ou 30. C’est moins bon que dans Bitcoin, mais ce n’est pas le plus important.
- dans Duniter, pour que le réseau suive un fork, il faut 6 blocs au-dessus de la branche actuelle, donc là il faudrait au minimum 12 blocs consécutifs à l’attaquant pour annuler la transaction (en réalité, il y a aussi une contrainte de 30 minutes d’avance, mais l’attaquant peut donner une accélération momentanée pour y palier). [1]
[1] A noter qu’aujourd’hui ce “6 blocs + 30 minutes d’avance” est une valeur en dur, totalement arbitraire et qui n’a rien à voir avec le protocole. On pourrait tout à fait la changer pour dire “suis la branche qui a plus de [1/3 x nombre de calculateurs] de blocs supplémentaires”. Le suivi d’un fork est alors conditionné à ce que cette branche soit réellement suivie par plus d’un tiers des calculateurs.
Pour supprimer une transaction de la blockchain aujourd’hui il faut 6 bloc (+30 min) pour qu’elle soit acceptée par le réseau.
Les blocs supplémentaires ne sont que la contrainte que le vendeur impose. Donc oui ça peut être 6 blocs de plus ou 8, 15 ou 30 mais c’est un choix du vendeur, je doute que la boulangerie du coin me demande d’attendre 30bloc avant de partir avec ma baguette ^^.
oui, c’est peu être dans ce sens qu’il faut réfléchir,
mais si on cherche à avoir [1/3 x nombre de calculateurs] de blocs supplémentaires
les fork risques de durée vraiment longtemps du coup…
Je ne suis pas là pour critiquer, mais juste que l’on réfléchies ensemble au risque potentiel et les moyens d’y remédier (si risque il y a). Car c’est la première fois qu’une POW personnalisée est mise en place, il faut faire attention.
Pas plus qu’il ne veut bien attendre 6 blocs Bitcoin non plus 
Les places de change, tout comme le boulanger, peuvent utiliser d’autres mécanismes pour réaliser des opérations rapides. La blockchain n’est que l’endroit où l’on consigne finalement les opérations résultantes, un peu comme les banques ne réalisent pas systématiquement des transferts de monnaie interbancaires, mais plutôt le résultat de fin de journée.
Ça dépend du niveau de fork et de sa nature (en 0.4 j’entends).
Imaginons 100 calculateurs : si 2 d’entre eux forkent, pour les 98 autres c’est comme si rien ne s’était passé. Si 20 forkent, cela devient plus long. Mais on peut imaginer d’autres cas extrêmes :
- 33% forkent, mais ces 33% sont aussi le 1/3 exclu de la preuve de travail, ils sont alors bloqués, et finiront par rejoindre les 2/3 non exclus.
- 50% forkent, dont le 1/3 exclu. Il reste alors 17% des nœuds capable de calculer la suite, face au 50% de nœuds n’ayant pas forké.
- 66% forkent, dont le 1/3 exclu. Il reste alors 33% de nœuds sur la branche “principale” face au fork. C’est du 33% face à du 33%, c’est le pire des cas.
Alors c’est vrai, il est possible d’attaquer la blockchain, ce d’autant plus que le nombre d’attaquants est proche ou supérieur à 1/3 des calculateurs.
Donc parmi les solutions possible à ce problème en 0.4 : augmenter le nombre de nœuds pacifiques, de façon à éloigner le plus possible l’attaquant d’une prise de contrôle par 1/3 bloquant.
Je n’en doute pas au contraire j’apprécie de ne pas être le seul à me pencher sur ce problème, j’ai aussi besoin d’aide pour orienter le projet vers ce qui nous conviendra le mieux.
Juste pour confirmer si j’ai bien compris ce que tu proposes,
imaginons qu’il y a 5000 noeuds qui calcule les blocs (comme actuellement pour le bitcoin, même si ce n’est pas demain que l’on aura autant de noeuds)
imaginons qu’il n’y a que 1 seul noeud qui fork
celui-ci devra attendre 1667 blocs (5000/3) avant de rejoindre la branche principale?
Si l’on ne met pas d’autre condition, oui.
1667 blocs * 5 minutes par bloc = 8335 / (60 * 24) = 5,78 jours
Un nœud qui forke tout seul, ou même un gros groupe aurait besoin de 5-6 jours pour résorber le fork. Pour une monnaie importante (5000 nœuds), cela ne me choque pas, l’inertie est grande.
Après, il est toujours possible d’intégrer d’autres conditions :
- déjà en ajoutant des capteurs “je suis bloqué” et “les autres avancent”
- en choisissant tel fork plutôt que tel autre, par exemple en sélectionnant celui qui a le moins d’émetteurs (pour contrer une attaque de nouveaux calculateurs)
- …
Mais ce qui est bien, c’est qu’on n’a pas besoin de changer le protocole pour ça.
Oui cela fait 5-6 jours dans le cas où il n’y a qu’un nœud qui fork, mais si c’est un gros split, la complexité moyenne de la blockchain va faire ralentir chacune des branches…
Après je ne sais pas sur combien de blocs précédant tu te bases pour faire la moyenne de la complexité.
Mais à première vu je trouve ça super long pour trouver un consensus.
Et du coup les commerçants ne devraient-ils pas attendre cette même règle avant de valider une transaction? Afin d’être sûr que la branche où a été écrite la transaction soit validée par consensus?
Pour l’instant en tout cas, on reste sur la formule “6 blocs + 30 minutes d’avance”. C’est un problème qu’on pourra résoudre plus tard, hors protocole, on a le temps d’y repenser.
J’ai déjà répondu :
Par exemple, tu peux avoir un compte dans une banque en monnaie libre qui peut servir pour les paiements instantanés, ou encore en utilisant une version papier de la monnaie. Il y a plein de façons de faire, et la blockchain n’a non seulement pas à répondre à toutes ces problématiques, mais en plus n’est pas la meilleure pour toutes les situations.
Cela viendra au fur et à mesure. En attendant, tu peux demander à ton boulanger de te faire une ardoise !
J’ai bien compris, mais je voulais seulement montrer quand la banque réalise la transaction en fin de journée, elle ne peut pas être plus laxiste que la méthode de consensus du protocole lui-même.
ici 1667 blocs (pour 5000 noeud)
Que signifie “laxiste” ici ? Si tu veux dire que la banque ne peut pas réaliser des opérations plus vite que la blockchain, alors je réponds : si, justement elle le peut, fork en cours ou pas.
Qu’est-ce qui empêche la TX d’etre envoyée vers chaque fork ?
C’est une évolution que je vais faire dans Cesium. Voici comment :
- Récupération de noeuds des différents fork (pas tous, mais sélectionné parmi les 2 branches pincirpales)
- Mise ne cache de certains noeuds (pour éviter l’analyse couteuse du réseau)
- Envoi d’une TX à plusieurs noeuds de chaque fork. Ce point est plus délicate qu’il parait, car les sources sont potentiellement différentes. C’est donc bien des TX différentes qui seront envoyées… à moins bien sur que les sources consommées soient toutes dans les forks.
Pour optimiser les points 1 et 2 (notamment sur les terminaux légers) j’utilisera sans doute des noeuds spécialisées, capables de retourner directement les infos dont Cesium à besoin. Voir même un service d’envoi, pour délguer l’envoi aux différents noeuds.
Si tu te pose la question des commercants, il y a plusieurs points à voir (à mon avis) :
- Payer avec un terminal externe (qui n’est pas à toi), n’est pas très sécurisant, surtout si tu utilises ton compte membre : le terminal peut très bien enregistrer tes identifiants…
- Par ailleurs saisir tes identifiants (salt+mot de passe) est interminable ! imagines à l’heure de pointe chez un boulanger.
Le mieux me semble donc :
- d’avoir un compte externe (comme indique @cgeek), dont l’administration est laissée à un tiers (un banque libre dont tu es le client).
- d’utiliser une terminal de paiement, avec par exemple une carte de paiement (style “sans contact” et/ou avec simple code pin). Ensuite, la demande de transaction est envoyée à l’opérateur tiers (la banque libre) qui elle peut :
- confimrer directement au comemrcant que la demande de paiement sera fait (ou non, si tu n’as pas les fonds)
- savoir exactement quel est le terminal qui fait la demande (donc qui est le commercant), en cas de triche de la part du commercant. Bref c’est tracable.
- avoir une assurance en cas de problème pour payer malgré tout au commercant, mais si la blockchain a connu des fork, etc.
- De ton côté :
- tu n’as qu’à remplir ce compte tiers à partir de ton compte DU (que tu ne délègues à personne).
- Comme tu paies pour ce service (compte tiers + carte de paiement) tu ne t’occupes pas de savoir si la TX a été bien faite. C’est à ton prestataire de paiement de de se débrouiller pour refaire le virement pour le commercant, si besoin.
- et si ton prestataire de paiement (qui à plein accès à ton compte tiers) se met à tricher… et ben tu change de cremerie !
Bref, rien de neuf sous le soleil, finalement. On ne change quasiment au système de paiement actuels (MasterCard, etc) sauf que : tout reste à faire quand même… mais c’est cà qu’est drôle, non !?
++
Exactement, c’est d’ailleurs pour ça qu’on le paiera, pour qu’il se débrouille et qu’on ait la vie tranquille pour produire nos valeurs.
Si, quand même : la monnaie sera libre
edit : et aussi, on n’est pas forcé d’utiliser une banque.
1 Like
Oui, je parlais bien sûr exclusivement des systèmes de paiement. Là, avec Duniter, nous sommes au niveau interbancaire, sachant que la banque c’est chacun de nous 
1 Like
qui te dit que tu n’a pas un gros split d’internet? 
Edit:
de plus, que ce passe-t-il si j’envoie en même temps 2 TX différent avec le même coin a 2 personnes différentes à travers 2 noeuds les plus éloignés possible?
il faut bien attendre qu’un consensus soit trouvé sur le réseau…
(je cherche seulement a faire reflechir tt le monde a ces questions )
Oui justement ! On ne sait pas si on a pas un gros split d’Internet, si des volcans en activité vont bientôt raser la moitié du réseau, ou si au contraire tout va bien.
On ne peut pas chercher à tout contrôler, c’est impossible. Mais on essaye quand même au maximum, notamment le cas d’une attaque d’un super-calculateur (ou d’un amas de nœud, ce qui est pareil) qui est une méthode simple qui, si on la gère pas, est la voie royale pour tout casser (tu as réussi à me mettre sérieusement le doute sur la 0.5, la solution de la 0.4 était quand même assez safe).
Oui mais ça, c’est le rôle de la preuve de travail : établir un protocole de communication permettant un dialogue de type broadcast, et évitant les collisions. De sorte qu’en général, un seul bloc est partagé à la fois, et à tous les nœuds.
selon moi c’était le sujet depuis le début, trouver un protocole de preuve de travail/méthode de consensus
pour éviter:
- le déni de service.
- la double dépense par l’envoi de 2 TX simultanés sur 2 nœuds différent.
- la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable.
Récapitulatif (de mon point de vue):
-
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.