Je pense que @cgeek pourra t’en dire plus avec son backup mais j’ai peu d’espoir là : il y a des données qui ont semble-t-il été effacées du réseau par le rollback bloqué par le bug rencontré sur une période assez longue. C’est un incident technique particulièrement grave (et en plein RML pour couronner le tout)
Ce que je conseille à l’avenir :
Si vous gérez une entreprise, ou que vous vendez un grand nombre d’objets, faites comme pour l’euro et tenez une caisse qui suit vos échanges (surtout si vous faites beaucoup d’échanges en un temps restreint). C’est laborieux mais ça vous protège contre ce type de bug logiciel (vous pourrez alors recontacter la personne qui pourra reproduire le transfert)
Il faudra communiquer sur ces incidents et demander à chacun de vérifier son historique de transactions
Pour les gros virements, attendez que la chaine valide la transaction avant de valider l’échange !
Il faudra éduquer les utilisateurs pour les faire utiliser le plus possible des noeuds autre que le noeud par défaut. Il faut en parler aux apéro
On va apprendre du bug et voir qu’est-ce qu’on peut faire pour rendre tout ça plus robuste…
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.
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 ?
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.
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.
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)
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 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.
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 !
(et en plein RML pour couronner le tout)
