Bonjour,
Mettons que j’ai sur mon compte 400 Ḡ1. Si je crée un simple portefeuille qu’est-ce qui m’empêche de coder un système qui soumet 400 paiements de 1 Ḡ1 vers ce portefeuille puis 400 paiements de 1 Ḡ1 de ce portefeuille vers mon compte, en boucle. Sans frais de transaction, je ne vois pas comment empêcher ce type d’attaque qui ne coûte rien …
La discussion citée n’explique pas comment lutter contre le spam de transactions…
Elle explique que les fees ne seront pas inclus dans le protocole, bon certes, mais comment lutter contre le spam de transaction alors?
(je connais la réponse, @elois nous en a parlé en OFF aux RML10, mais as-tu une explication détaillée @Inso pour @regisg du système de limite de taille de block par rapport aux précédent (est-ce 20%)? )
C’est aussi une question que je me pose en travaillant sur ma RFC du protocole. En effet il sera possible de faire des conditions beaucoup plus complexes, voir avec une autre RFC en cours de réflexion de faire des contrats à plusieurs étapes (potentiellement Turing-Complet mais très limité). Pour l’instant ce n’est pas trop un problème sachant que nous sommes peu, mais ça va le devenir quand il y aura plus de mondes ainsi que plus des usages de ces contrats. Il serait donc bon d’avoir des frais basés sur la taille de la transaction (en octets).
Un des mécanismes possibles est décrit dans le post (priorité en fonction de l’âge des sources).
Les frais sont une implémentation économique qui abime la neutralité de la monnaie, sans résoudre parfaitement un problème avant tout technique. D’où le fait qu’on préfère les éviter, et utiliser d’autres solutions.
Un autre nœud ne pourra pas vérifier qu’il a mit en priorité les sources anciennes vu que les piscines n’ont pas de consensus.
je suis d’accord que les frais abîme la neutralité de la monnaie, il faut alors trouver une alternative viable 
Les spams et les grosses transactions seront forcement des problèmes quand la monnaie va connaître plus du succès.
L’âge de la source dépend de la blockchain, pas de la piscine ?
Rien n’indique que le nœud calculant possède ou non une transaction ayant une source plus ancienne. Je ne peux donc pas refuser son bloc parce qu’il a mis une transaction avec une source plus récente qu’une transaction que j’ai dans ma piscine.
De manière générale, on ne peux pas définir d’ordres ou de filtres parmi les transactions en piscine, car elle n’est pas consensuelle (c’est le but de la blockchain).
Une idée que j’avais proposé dans la review de ma RFC2 était de séparer les transactions en différentes catégories selon leur poids, et autoriser un certain nombre (variable au cour du temps pour s’adapter à la demande). Ça c’est bon. J’avais par contre proposé de pouvoir mettre plus de transaction d’une certaine tranche si les autres ne sont pas pleine. Mais ça, personne ne peux le vérifier, car on ne connait pas le contenu des piscines des autres. Pas moyen donc de savoir s’il n’a pas rempli la tranche parce qu’il n’avait plus de transactions ou parce qu’il veut faire d’autres transactions.
Je pense qu’une limite par catégorie de tailles peu être intéressante, après il faut voir si elle règle les problèmes et si on peux la contourner.
Cette règle n’est pas une règle de blockchain, c’est juste un comportement des noeuds : ils écrivent dans la chaîne les transactions utlisant les sources les plus anciennes qu’ils ont en piscine, dans la limite de la taille du bloc.
L’idée est intéressante oui !
Mais si tu peux, c’est simplement que tu ne pourras pas empêcher d’autres nœuds de ne pas respecter cette règle. Et si la majorité des nœuds applique cette règle, alors le spam sera de fait endigué la majeure partie du temps (pour ce qui concerne cette règle de priorisation).
En tout cas je réfléchissais justement au spam des transactions ce midi (coïncidence !). Je me disais qu’il y a au moins une chose qu’on peut limiter immédiatement : l’enchaînement de plus de X transactions dans un même bloc. Par exemple si on limitait à 5 le nombre de transactions chaînées dans un bloc, alors un spammeur possédant N comptes qui s’amuse à envoyer X unités à son compte C1, qui envoie vers C2, qui envoie vers C3 … serait limité à 5 transferts par bloc pour ce montant.
On pourrait me rétorquer “oui mais l’attaquant peut aussi paralléliser les transferts, afin de réaliser N attaques simultanées”. C’est vrai. Mais aujourd’hui il peut déjà le faire avec 1 seul compte et spammer un seul bloc.
En vérité, plus que d’essayer de définir des limites (qui seront de toute façon contournable du fait du nombre infini d’adresses possibles), je pense qu’il vaut mieux définir des priorités.
L’age des sources de transaction étant variable possible de la fonction “priorité”, mais ce n’est pas la seule que l’on peut imaginer.
Non car le nombre d’unités de monnaie n’est pas infini, lui. A tout instant il existe un maximum d’unités qui peuvent être envoyées, qui correspond au nombre total d’unités dans le système.
Et aussi, la limite dont j’ai parlé plus haut tu peux tout à fait sentir qu’elle est absolument nécessaire dès maintenant. C’est une faille béante qu’on a là.
En tout cas l’âge des sources est une variable particulièrement légitime, car plus une source est ancienne, moins l’utilisateur sollicite le système et donc plus il le préserve/l’économise.
Maintenant pour éviter la parallélisation de l’attaque, la solution évidente qui me vient est d’avoir également un poids fonction du montant de la transaction par rapport aux autres montants concurrents.
Et donc au final, d’avoir une priorité fonction de ces 2 éléments.
Du coup oui c’est sur chaque membre peu appliquer cette règle, mais elle ne fait donc pas partie du protocole. C’est déjà une bonne piste.
Une idée est de suivre le graphe des sources et de prendre en compte l’âge des transactions sur plusieurs pas. Une transaction après 5 mins apres 5 mins serait moins prioritaire qu’une après 1 semaine après 1 semaine.
Je ne savais pas que l’on pouvait effectuer des transactions chaînées dans un seul bloc. Il n’y a pas forcément besoin de les interdire, mais avec la règle au dessus ils seront très handicapés et ne passeront que s’il n’y a pas d’autres en attente.
J’ai créé le ticket#1242 avec priorité#0 (cc @elois) à cet effet car oui, cette faille devient particulièrement urgente avec le nombre de membres qui augmente constamment. Tôt ou tard les ennemis vont se montrer, mieux vaudra avoir colmaté ce genre de faille avant leur arrivée.
Si, c’est nécessaire de les interdire passé une certaine longueur (par exemple 5), sinon un spammeur peut faire artificiellement grossir la blockchain jusqu’au buffer overflow et détruire la monnaie. En effet il peut, à l’aide de 2 comptes qu’il possède, chaîner des transactions ping-pong et les soumettre au réseau. Au premier bloc il peut atteindre la taille max du bloc, et s’il continue la blockchain va augmenter la taille des blocs de 10%, puis 10%, puis 10%, … c’est juste une énorme erreur de ma part de ne pas avoir codé cette règle plus tôt. Il faut cette limite, rapidement.
Encore une autre suggestion : prioriser les transactions qui réduisent le nombre de sources.
La limite de bloc pourrait monter de façon logarithmique.
Sinon il faudrait mettre une limite en effet. Dans quel cas on a besoin de publier une suite de transactions dans un même bloc ? Je vois une utilité dans le cadre des smart contracts, mais pas avec de simples transactions à première vue.
Quand tu fais du change par exemple : besoin de rassembler des sources avant dépense car trop nombreuses. Ça arrive très régulièrement déjà dans la Ğ1.
D’accord je vois. 5 me semble largement suffisant du coup 
Oui et l’augmentation logarithmique me parait bien aussi.
Bonjour @regisg
concernant le spam j’y ai mis mon grain de sel
sinon pour la consommation des sources,
il est envisageable de se mettre d’accord coté application client pour qu’une transaction consomme l’ensemble des sources verrouillées par simple signature. *
ce qui peut d’une certaine manière eviter le spam dans le sens où il faut attendre que duniter traite et valide en blockchain la transaction et rend "indisponible " pendant ce laps de temps l’accès a ces sources pour de future transaction.
le point positif c’est que ca réduit les sources a une seule pour une future transaction simple signature.
le point négatif c’est que l’on soit contraint d’attendre la validation de la blockchain pour en effectuer une autre qui soit acceptée…
nb: a defaut de le faire sur l’ensemble des sources et pour pallier a ce dernier point,
peut etre faire cette selection <=>nombre de sources a consommées, en proportion du nombre de sources disponibles (toujours dans le cas simple signature) sachant qu’un utilisateur qui n’effectue aucune transaction sur 1 mois va disposer à minima + ou - de 30 sources (1DU par jour)
Quelle différence entre faire plein de petites transactions vers des petits comptes ?