Cesium: Transactions référencant un bloc incertain (dont l'age < 6 blocs)

cesium

#30

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.


#31

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 ? :smiley:


#32

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 :stuck_out_tongue: )
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. :slight_smile:


#33

Ç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 :slight_smile:
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 : https://git.duniter.org/nodes/typescript/duniter/blob/dev/doc/Protocol.md


#34

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. :slight_smile:

Pour le moment j’ai rien. ^^
Ça cogite. :slight_smile:

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 ?


#35

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.


#36

Oui, c’est très bon ça. :clap: 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. :slight_smile:


#37

Peut être, il faut y réfléchir, oui ouvre un fil dédié c’est mieux :slight_smile:

Oui je parle du fait de chainer des TX au sein d’un même bloc :slight_smile:

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.


#38

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 ? :smiley:

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 :smiley:

Inconvénient

  • nécéssite un hardfork, vu qu’on touche au protocol.

#39

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 :

  1. 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
  2. Les clients ne pourront plus se baser dessus pour dater la transaction

#40

Tout à fait ça devrait même etre une règle protocolaire, un bloc ne peut pas contenir de TX du futur. :wink:

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.


#41

@Looarn ok tu m’a convaincus, reste a voir ce qu’en pense les autres dev :slight_smile:


#42

Ce qui poserait des contraintes pour faire des transactions contre-factuelles (une transaction ayant une periode de validité limité), rendant plus difficile l’implémentation de canaux de paiements (Lightning).


#43

Je pense à ouvrir un PRC ^^ Il y a un format standardisé, ou je le fais à l’inspi ?

Les canaux sont (si on part sur une solution à la bitcoin) sur un Layer au dessus de la blockchain, ce qui signifie que pour que des coins arrivent effectivement sur Lightning, il faut une TX depuis la blockchain qui les inscrivent en dur sur le Layer 2. A partir de la le protocole propre à Lightning prend le relais.

Sauf si vous avez une autre approche déjà documentée ? Je veux bien jeter un oeil. :slight_smile:

De souvenir il y a déjà une fenêtre de 6 jours qui rend les transactions trop vieilles invalides, moi je propose 2 mois. ^^


#44

Le layer 2 consiste à contre-signer des transactions qui à tout moment peuvent être publiées sur la blockchain, et que le sont que s’il y a un désacord entre les participants du canal. La grande majorité du temps elle ne le sont donc pas (on se base sur un fait sûr mais qui n’est pas publié => contrefactuel).

Si les transactions périment au bout de 2 mois, alors un canal doit forcement exister moins de 2 mois pour ne pas se retrouver avec une transaction contre-factuelle inutilisable.

Lightning Network : https://lightning.network/lightning-network-paper.pdf
Conterfactual states channels : https://l4.ventures/papers/statechannels.pdf


#45

Du coup si je comprends bien la fenêtre de 6 jours sur les noeuds actuel est configurable, tout comme le serai celle de 2 mois ; mais n’est pas une règle protocolaire.

Si un noeud A souhaite élaguer plus que les autres, ça ne pose pas de souci à priori. Un noeud B qui lui acceptera la transaction dans sa piscine, la publiera dans un bloc, et à partir de là, le noeud A la verra comme valide, vu que c’est une règle piscine.

Et on n’empêche pas les TX sous forme de contrat notamment celle avec une limite dans le temps.

Si je dis bien c’est tout pareil que le fonctionnement actuel non ? :thinking:


#46

Si actuellement c’est protocolaire . Si une transaction est écrite dans un block dont le temps est plus de txWindow secondes après le blockstamp que contient la transaction, alors le block est considéré invalide.


#47

Je ne m’en souvenait même pas tient … Il faudra voir si cette règle ne pourra pas être relégué à une simple “bonne pratique” pour éviter de limiter par defaut ce qu’on peut faire avec.


#48

Je pense que la règle BR_G103 peut être supprimé sans problème, mais peut être que quelque chose m’échappe quand a la raison de cette règle mise en place par @cgeek ?


#49

Le commentaire est un champ technique, destiné à permettre de porter une référence d’un système extérieur. Il permet de l’indexation, par exemple.

Mais son usage a rapidement été détourné pour y inscrire un commentaire humain. Je n’ai pas de problème avec cela, après tout pourquoi pas.

Oui c’est très efficace pour les comptes membres. J’utilise ce mécanisme pour la piscine de certifications : elle limite à 12 certifications par membre (ce qui est le max possible étant donné le délai de 5 jours inter-certifications et les 2 mois de péremption = 60 jours).

Mais ça ne fonctionne pas pour les non-membres, qui peuvent créer autant d’issuers qu’ils le souhaitent.

Le chaînage fait partie intégrante du protocole depuis le début, mais un bug faisait que celui-ci était inopérant pendant un temps (je dis cela de mémoire). Puis après correctif, un jour une remontée utilisateur m’a fait implémenter la règle de profondeur max et nous avions tranché au doigt mouillé pour une valeur de 5 avec @nanocryk visiblement.

Cette discussion est intéressante, on voit qu’elle recoupe celle que vous avez ici.

Ne modifions pas le protocole pour de mauvaises raisons :slight_smile: @elois évoquait plus haut que pour la problématique de date, Cesium+ pouvait très bien s’en occuper, pourquoi cagette.net ne pourrait-elle pas faire de même ? En plus ce serait autrement plus précis, à la nanoseconde près si ça vous chantait.

Par contre pour le rejeu en cas de fork, oui, je comprends.

Je ne vois pas d’autre raison que le spam. A priori, oui, cette règle pourrait être supprimée. En plus elle est effectivement très gênante pour du Lightning ou même du Atomic Swap (change inter-blockchain) avec de longs délais.