Ca marche, merci pour ces infos, bon je je fais les virements pour lesquels je me souviens, tant pis pour le reste. Hé oui pendant les RML c’est ultra chaud 
Bon courage les mecs et merci pour ce que vous faites. Respect
Have a nice day !
Sur Bitcoin il y a une pseudo régle d’usage, attendre que la TX soit validé par au moins 6 blocs, avant de la prendre pour argent comptant.
Peut etre qu’on pourrait émettre une recommandation en ce sens aussi ?
Je compte réutiliser cette règle pour mon appli :
- Toto envoi une TX vers mon service
- La TX est ajouté dans 1 bloc (i.e. 1ère confirmation par le réseau)
- Un bloc est forgé par dessus (i.e. 2ème conf par le réseau)
- etc pour x blocs (6 dans mon cas soit en temps humain 30 minutes)
- Je crédite le compte de Toto sur mon service
On pourrait, raccourcir cela si on a un détecteur de fork solide au niveau noeud, mais à l’instant t, le noeud est aveugle d’une partie du réseau il me semble.
My 2Cts,
Oui, nous en avions déjà parlé, mais ce fil actualise ce besoin.
Dans Cesium, je pourrais afficher un marqueur “en attente de validation” quand la TX date de moins de 6 blocs.
Le second souci est l’importance de dater la TX avec le hash du bloc courant.
ça me parait etre une mauvaise pratique, en cas de fork, le hash courant du bloc est invalide sur l’autre chaine, donc la TX, n’est pas “transférable”.
Le fait à mon avis de prendre le hash du bloc n-6 corrigerai pas mal de souci de TX perdu dans le “petits fork”, non ? 
Plus généralement à quoi ça sert ?
Je me pose moi même la question 
Le blockstamp pour les documents de WoT, je comprends bien, mais pour les TX… ? Il y a probablement une raison que j’ai oublié. @elois @cgeek
Oui c’est déjà ce que je fait pour mon service de mail payable automatiquement en Ğ1, j’ai un script qui passe régulièrement et qui n’active le service que si la tx a été inscrite il y a plus de 6 blocs 
C’est nécessaire sinon on vas se retrouver avec un dépot sédimentaire de toutes les anciennes TX qui n’ont pas été inscrite pour X ou Y raison, les document tx ont une durée de vie limitée en piscine (1 semaine pour la Ğ1), au delà elles expirent et sont supprimer.
Donc créer une TX datée a J-3 ça lui donnerai quand même 4 jours pour etre écrite ce qui est largement suffisant
En revanche créer une tx a t -6 blocks non c’est totalement insuffisant et ça ne changerait rien pour le type d’incident qu’on a eu ce dimanche.
1 Like
Désolé mais je ne vois pas le souci avoir des TX qui ne sont pas fonction du temps.
Si des TX ne sont pas inscrites, c’est qu’elles sont soit en attente et donc on s’attend a les voir inscrite un jour. Soit invalides et donc filtrées par les noeuds, j’oublie qqch ? 
Du côté de Cesium, j’utilise le dernier block comme référence simplement pour avoir une date utilisateur proche de la réalité. (sauf qu’il y a un décalage de 50 min). On pourrait décaler encore, remarques… à voir.
La solution propre serait (pour moi) de rendre le nombre de blocs (6 par défaut) paramétrable dans Cesium. Les dates dans l’historique des TX pourraient être corrigées en conséquence.
Alors si je comprends bien c’est une problématique d’usage pour l’utilisateur, on doit choisir entre :
1/ Avoir des TX datées au temps de l’opération (et non de la validation : ajout dans le bloc)
2/ Le risque d’invalidité de la TX en cas de fork
J’aurai tendance à vouloir limiter le risque au détriment du confort utilisateur.
C’est un peu la question du chèque en banque, ce n’est pas la date qui figure sur le chèque qui est retenu par la banque mais bien la date de l’encaissement du chèque. Peut être que pour le coup ce sont les banques qui on qqch a nous apprendre. 
2 Likes
On peut aussi émettre des transactions qui sont invalides à l’instant (t) mais valides à l’instant (t+1)
C’est le cas des transactions chainées (on émet une chaine de transaction, toutes les transactions en fin de chaines sont pourtant invalides tant que la première n’est pas validée)
Après vérification, Cesium ne broadcast pas la transaction à tout les forks.
Je pense que c’est d’abord là dessus qu’il faut travailler. Une tx valide sur tout les forks en cours a peu de risque d’être invalidé ensuite…
1 Like
A condition de la signer avec un bloc valide pour toutes les branches.
On perd donc l’horodatage de l’emission de la TX sur le réseau anyway.
En fait on prend tout les HEAD courants connu et on broadcast. La branche qui gagne aura bien un horodatage correct, et la transaction y sera bien inscrite.
C’est assez simple à patcher dans cesium si quelqu’un veut contribuer !
- On récupère les heads courant via l’url suivante
ws2p/heads(exemple : http://g1.duniter.org/network/ws2p/heads ) - On récupère les endpoints BMA via l’url suivante :
network/peers(exemple : https://g1.duniter.org/network/peers) - On construit le doc de transaction avec tous les blockstamp potentiels et on broadcast
Question @elois ; @cgeek : est-ce que le blockstamp est vérifié avant insertion en piscine ? Si non, on peut potentiellement éviter l’étape 2 et donner tout les blocks construit au noeud de référence de Cesium. Ce noeud se chargera de broadcaster le document au réseau ensuite.
1 Like
Honnêtement je n’en sait rien je n’ai jamais eu a travailler sur cette partie du code, il faut regarder dans le code
J’ai envie de dire qu’un noeud qui souhaite s’économiser, mettra en piscine uniquement les TX valide par rapport à sa version de l’histoire (comprendre sa blockchain).
Donc l’ordre serai :
1/ Je reçois une TX
2/ Je la vérifie
3/ Je l’ajoute a ma piscine pour post traitement
@cgeek sur la signature des TX avec le hash du bloc courant, tu peux nous dire si on oublie qqchose ?
Je ne vois rien de grave personnellement, au final il n’y avait que 5-6 nœuds sur 40 qui ont forké, soit à peine 15% du réseau (c’est même encore moins si l’on compte les nœuds miroirs).
Mais que dire du fait que Cesium se fie à un nœud qui n’est pas d’accord avec les 85% restants du réseau, sans prévenir l’utilisateur ? Duniter est par nature P2P. Se fier à un seul nœud est dangereux, surtout quand on n’a pas la main dessus.
Cesium ne prévient pas l’utilisateur, historiquement c’est compréhensible car le réseau était petit. Désormais le réseau grandit, et cet événement est simplement l’occasion de bien retenir la leçon.
Je le répète il n’y a rien de grave, nous sommes à peine 1100 membres.
Ben perso mes 3 nœuds membres avaient forké ce qui n’étais encore jamais arrivé, et mes 2 noeuds mirroirs ont forkés aussi, donc c’était bien plus que 15% du réseau a mon avis !
Non j’avais bien regardé, il n’y avait que quelques nœuds désynchronisés. Et je ne te compte que pour 1.
Ben j’ai vraiment pas eu de chance sur ce coup la, 5 nœuds sur 5 qui tombent sur la mauvaise branche, c’est une première 
Ils sont tous sur le même serveur ? Si oui ça aurait pu participer du temps de propagation, et vu qu’il y a de toute façon un bug sous-jacent (sinon ils auraient fini par basculer sur la branche majoritaire), ça pourrait être une explication.
Quand au nombre de membres “forkeurs”, j’en veux pour preuve ma sauvegarde : tout nœud collecte tous les blocs valides qu’il reçoit (seule la PoW est vérifiée, pour éviter le spam), et donc on a en BDD un semblant d’historique du comportement du réseau à ce moment là. Je trouve dans cette sauvegarde qu’il y a, au bloc #123034 qui est notre bloc de fork, seulement 3 émetteurs différents :
select
number,
count(distinct(issuer))
from block
where
fork
and number = 123034
Mais si je regarde un peu plus largement ce qui se passe aussi au-dessus du bloc 123034, je trouve au maximum 4 émetteurs différents.
Or à ce bloc là la fenêtre contenait 39 émetteurs. Donc c’est même moins de 10% des membres qui ont forké.
Si vous voulez la sauvegarde, je peux vous la fournir (200Mo…). Je n’ai pas eu le temps de la traiter pour comprendre le bug de résolution.