Y’a une erreur dans la capture
15 minutes (6 blocs)
Duniter stock déjà en base les forks connus non ?
Oui mais s’il doit prendre le temps d’aller vérifier pour chaque document qu’il reçoit s’il connaît un fork dont l’un des block a ce blockstamp c’ets très couteux. En plus un attaquant peut contourner ça en soumettant de faux blocks (que Duniter est obligé de stocker car ça peut etre un vrai fork, et Duniter ne vérifie tout le protocole que s’il applique ce fork donc il ne peut pas savoir avant).
Pour résumé, Duniter a 2 politiques possibles :
- Faire rebondir le document dans tout les cas, permet d’amplifier une attaque par denis de service, c’est pas bon.
- Faire rebondir le document uniquement si le blockstamp est dans sa chaîne locale, rapide a vérifier donc pas coûteux, et n’amplifie pas une attaque par dénis de service.
c’est sur G1-test
Ok, je savais pas que avgGenTime était deux fois plus petit.
1 Like
Il me semble qu’il y a une évolution importante du protocole qui est prévue, non ?
Pourrait-on simplement ajouter un champs “Date de transaction” qui serait purement d’affichage ? Ca permettrait d’avoir de la fiabilité (avec J-3) et de fournir l’info utile.
Je ne crois pas qu’il y ait de raison technique à ce que ces 2 infos soient liées, et j’ai l’impression que c’est assez bloquant comme problème.
(on peut imposer dans la validation de bloc que ces 2 éléments soient distants de pas trop longtemps pour éviter les bidouilles d’affichage folklorique)
Et rajouter en blockchain une donnée purement inutile au fonctionnement de la monnaie, non ça me semble être une mauvaise idée. La question de l’historique concernent les clients, a eux de stocker le nécessaire. D’autant que d’ici quelques années duniter ne stockera même plus toutes les utxo, donc de toute façon a terme il faudra que les utilisateurs stockent les données relatives a leurs sources, autant prendre les bonnes habitudes de suite.
La blockchain doit stocker le strict nécessaire au fonctionnement de la monnaie, tout ce qui peut etre stocké ailleurs devrait etre stocké ailleurs, question de scalabilité 
3 Likes
A quoi sert une date d’émission ?
Ce qui fait foi sur une blockchain c’est bien le bloc qui grave dans le marbre la TX, il s’agit de la date de reception.
En l’état, la date d’emission peut facilement etre antidaté jusque 6 jours.
De plus on ajoute ces données a mon sens inutiles (sauf pour les certifications qui pourraient être rejoué sans celà (si j’ai bien suivi ? ^^)).
La question que je souhaite poser est :
La date qui est sur le chèque que l’on signe qui la regarde finalement ? Et quelle utilité à la faire apparaître sur notre relevé de compte ?
La donnée est déjà dans la blockchain et sur les TX monétaire, je ne vois pas a quoi cela sert ? On ne peut pas rejouer la TX dans le futur, car les UTXO sont dépensées.
J’oublie qqch ? 
La problématique est intéréssante cela dit.
1 Like
Oui tu oublie le besoin d’élaguer les transactions en piscine au bout d’un certain temps pour éviter que ça ne devienne un dépôt sédimentaire, tout les documents émis par les clients doivent donc être dater au moins pour ça.
2 Likes
Je ne sais pas comment c’est codé derrière, mais ce que je sais c’est que si tu te mets à trop stresser un nœud depuis une adresse IP, il te renvoie assez rapidement du 503 (service unavailable). C’est ce qui m’empêche d’ailleurs de réellement spammer le réseau ĞTest, je suis arrivé à 51 transactions pour un bloc au maximum, bien sûr il n’y a pas beaucoup de nœuds dispo sur ĞTest mais ça donne déjà une idée. Bien sûr avec de l’IP spoofing il y a probablement moyen de contourner cette protection facilement, mais silkaj n’est pas programmé pour ça. Je fais une issue ? 
Effectivement, je ne suis pas encore arrivé à la notion d’élagage, je suis tombé 2 fois dessus sans avoir le temps de comprendre de quoi il s’agissait.
Sur bitcoin voici comment on évite la sedimentation :
Chaque nœud vide régulièrement sa piscine (je crois que c’est tous les 2 mois par défaut).
Un nœud vérifiant la validité sur la chaîne actuelle d’une TX remplira sa piscine uniquement avec des transactions valides selon sa version de l’histoire.
Pour le coté spam, les transactions avec trop peu de frais réseau ne sont pas relayées par les nœuds, c’est la responsabilité de l’emetteur de la TX “zero fee”.
On ajoute a cela que quasi aucun mineur ne mine de TX sans frais (il doit en rester 2 dans le monde 
)
EDIT: de plus les nœuds ont la possibilité de définir la taille de leur piscine (300Mo par défaut).
Dans notre cas, je trouve dommageable d’alourdir la blockchain pour stocker cette donnée, mais ça me choque moins que les commentaires adossés au TX. O_o
Vous l’aurez compris dans le débat small block VS big block je suis plutôt un “smallblockiste”. Je pense que l’espace disponible dans les blocs est précieux, mais je n’en fais pas un dogme.
Je veux bien un peu de docu sur l’elagage svp. 
1 Like
Ça me semble bien problématique, comment je fais si j’envoie une TX a un nœud et qu’elle est effacée du nœud juste après parce que ça tombe pile au moment ou il élague sa piscine et qu’il n’a pas eu le temps de faire rebondir la TX ?
Tu va me dire ben il fait un élagage sélectif et n’enlève pas les TX qui sont valides selon lui, c’est effectivement possible mais ça demande de vérifier la validité de toutes les TX en piscine, et c’est très très coûteux. Dans Duniter on a aussi la contrainte qu’il faut que tout soit faiblement énergivore, dans bitcoin il ne sont pas a ça près vu l’énergie colossale que les mineurs doivent de toute façon injecter.
Donc comment faire un élagage qui ne soit pas énergivore, qui demande donc très peu de calcul, et bien en exigeant au client de dater tout les documents via un blockstamp, ainsi il suffit d’élaguer les documents qui ont expiré, simple et rapide. Alors oui ça demande un champ de plus dans le document TX, tu vois une autre solution ?
Oui ça effectivement c’est complètement inutile
Pour le coté user-friendly les commentaires pourraient être stocker ailleurs, sur le réseau Cesium+ par exemple.
Ben y a pas de doc spécifique la dessus, tout est dans la documentation du protocole en fait : doc/Protocol.md · dev · nodes / typescript / duniter · GitLab
Non un flush c’est un flush, rien de sélectif. ^^
Alors en général sur bitcoin noeud et client sont fusionnés, mais si jamais on parle d’un client léger il doit s’assurer que sa TX est relayé.
Si c’est un noeud, alors il l’émet à 8 pairs du réseau et ça se propage, tous les noeuds ne vidant pas leur piscine en même temps ça ne pose pas de souci.
Si c’est ta TX de ton noeud, qui flush la piscine au moment où tu venais de créer la TX, elle est inscrite dans le wallet.dat et sera réémise. Donc là dessus bitcoin est relativement efficient, mais sans date d’émission, et ça, ça simplifie drôlement.
Pour le moment j’ai rien. ^^
Ça cogite.
Ta solution semble la plus simple a mettre en place. bloc courrant - 100 histoire d’être sûr de ne pas pourvoir se faire rollback.
Quid du spam dû au fait que les TX sont sans frais ?
Concernant les piscines il suffit de limiter le nombre de TX stockés par issuer.
Concernant la blockchain on limite les chaînages de TX a une profondeur de 5.
Oui, c’est très bon ça. 
Et finalement c’est de la responsabilité des noeuds et non du protocole. Ca rends invalide le besoin de date d’emission a mon sens. (NB: je ne saisie pas bien pourquoi on limite la validité d’une TX dans le temps, ça empeche a vrai dire l’utilisation du multisig dans le cas de testament ou autre, je vais surement ouvrir un topic là dessus. ^^)
Euh a première vue ça fait peur ton histoire, ça implique que des coins utilisé 5 fois ne sont plus utilisable ?
Ou tu parles du fait de chainer des TX au sein d’un même bloc ? Dans se cas la limite semble haute, je serai partisan du non chainage, il faut qu’au moins un bloc valide la TX pour que ces utxo soit utilisable.
Merci pour tes réponses.
Peut être, il faut y réfléchir, oui ouvre un fil dédié c’est mieux
Oui je parle du fait de chainer des TX au sein d’un même bloc
C’est ce qu’on faisait avant oui, on pourrait y revenir, je n’ai pas d’avis trancher sur la question, c’est @cgeek qui a proposer ça, je ne me souviens pas pour quelles raisons exactement.
En y repensant avec le truc de cagette.net, on a peut etre ici un souci de protocol en fait.
Si je change le protocol, et qu’au lieu d’un BLOCK_UID on utilise simplement un BLOCK_ID (je prefere le terme block_number mais soit).
ça nous permet deux choses :
Dater l’émission d’une transaction.
La rejouer sans contrainte en cas de fork.
C’est trop simple pour qu’il n’y ai pas d’effet de bord non ?
Coté élagage, on permet au nœuds de choisir la validité des TX, exemple une TX en piscine ne peut pas référencer un bloc trop âgé (20k blocs ~= 2 mois), une TX invalide restera donc en piscine le temps que les nœuds choisissent, si je veux un nœud très à jour niveau piscine, je réduis ma fenêtre à 100 blocs ; si je veux un nœud archive, je ne fais pas d’élagage du tout.
Avantage que j’y vois :
- réduction de la taille du document de transaction donc de la blockchain !!!
- les transactions deviennent re-jouable en cas de fork, donc personne n’est lésé comme on a pu voir par le passé (je pense au poste de @PiNguyen durant le RML11 )
- on simplifie la gestion de l’élagage coté noeud
- on permet a des nœuds de faire de l’archivage des TX invalides nativement
Inconvénient
- nécéssite un hardfork, vu qu’on touche au protocol.
Et du coup tu peut émettre une TX datée dans le futur, alors certes les nœuds peuvent décide de rejeter les TC au block number plus élevé que leur bloc courant mais :
- On peut respammer le réseau avec le même document sans avoir a régénérer la signature, ça simplifie donc les attaques
- Les clients ne pourront plus se baser dessus pour dater la transaction
Tout à fait ça devrait même etre une règle protocolaire, un bloc ne peut pas contenir de TX du futur.
Oui, par contre si la TX est déjà en blockchain, alors c’est invalide. Si un noeud insiste à propager une TX invalide, c’est de l’ordre d’un souci réseau. si elle est valide, mais que je l’ai déjà une simple comparaison du hash suffit. Je ne vois pas de souci majeur ici.
Si, tout autant qu’on peut facilement antidaté une TX aujourd’hui, si tu penses aux TX du futures alors il faut simplement faire en sorte quelle soient invalide.
Enfin ce soucis existe aujourd’hui.
1 Like