Et notamment connaître l’ampleur du fork et sa légitimité (sur ce dernier point @Moul tu sembles avoir investigué mais je n’ai pas compris les conclusions : le fork majoritaire est-il dans l’erreur d’un point de vue protocolaire ou pas ?).
Les inputs de cette transaction sont des sources qui n’existeraient pas selon mes investigations :
Mon nœud qui est actuellement au bloc 191945, dit ne pas avoir ces deux sources :
curl duniter.moul.re/tx/sources/DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg
{
"currency": "g1",
"pubkey": "DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg",
"sources": [
{
"type": "T",
"noffset": 1,
"identifier": "2D9679448680654A4694B52F855F44E57A2E99D86A2FA3BD48028E99B98D1F42",
"amount": 5400,
"base": 0,
"conditions": "SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg)"
},
{
"type": "T",
"noffset": 1,
"identifier": "8D28C0AEB4B651B584312737AE25D79FAD1455FA149CDFD23C4B1B9A176E7E03",
"amount": 2000,
"base": 0,
"conditions": "SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg)"
}
]
}
Il faudrait vérifier rigoureusement que ces sources n’existent pas.
Il respecte surement la règle BR_G47, mais pas le fait d’accepter une transaction avec une source inexistante. Ce qui me semble être un non-respect du protocole.
Il y a bien un fork qui refuse cette transaction qui se développe :
Issuers for last 5 blocks from block n°191943 to block n°191947
| block | gentime | mediantime | hash | uid |
|---------+-----------+--------------+------------+-----------|
| 191947 | 04:51:38 | 02:28:50 | 0000002D60 | BnimajneB |
| 191946 | 04:40:21 | 02:17:33 | 000008397D | Mententon |
| 191945 | 04:29:11 | 02:06:23 | 000000A9F4 | ji_emme |
Avec #191945 comme bloc commun.
2 Likes
Tant qu’on a pas connaissance de la cause du problème il est préférable de ne rien faire quant au fait de choisir une branche ou une autre.
2 Likes
Bon au final, c’est un mini-fork incluant 3 membres et Remuniter.
D’après le test suivant, je dirais que le fork majoritaire a eu raison d’accepter la transaction.
-
Synchroniser au point de fork (dernier bloc commun)
bin/duniter sync g1.cgeek.fr --nointeractive 191945 -
Dumper le s_index (table de protocole contenant les sources de monnaie).
N.B. : il faut ajouter un peu de RAM (ici 4GB) car le dump est un peu rudimentaire (voire bourrin), ici j’utilise donc directement le fichierbin/duniterpour pouvoir forcer NodeJS.node --max-old-space-size=4096 bin/duniter dump table s_index > sindex -
Afficher l’état des sources consommées :
$ head -n 3 sindex && grep 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 sindex
┌────────┬──────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────┬────────┬─────────────────────────────────────────────────────────────────────────┬─────────┬──────┬──────────┬──────────┬───────────────────────────────────────────────────┬───────────┐
│ op │ tx │ identifier │ pos │ created_on │ amount │ base │ locktime │ consumed │ conditions │ writtenOn │
├────────┼──────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────────────────┼─────────┼──────┼──────────┼──────────┼───────────────────────────────────────────────────┼───────────┤
│ UPDATE │ 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 │ 5E97C80CF04C0D7955AC86052E549D56DEC69881436639A5566F5B1095789CAA │ 0 │ 191736-000000BF7BAC15770F91FAF69A304C5D0EC909080839EF54CBD2A3ECA878C414 │ 2000 │ 0 │ 0 │ 1 │ SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg) │ 191738 │
│ CREATE │ 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 │ 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 │ 0 │ NULL │ 1000 │ 0 │ 0 │ 0 │ SIG(6vjF4vk9UiGWk7b12yPx2NXWQ4QaVDDesZXdpactihMR) │ 191738 │
│ CREATE │ 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 │ 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35 │ 1 │ NULL │ 1000 │ 0 │ 0 │ 0 │ SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg) │ 191738 │
$ head -n 3 sindex && grep 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 sindex
┌────────┬──────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────┬────────┬─────────────────────────────────────────────────────────────────────────┬─────────┬──────┬──────────┬──────────┬───────────────────────────────────────────────────┬───────────┐
│ op │ tx │ identifier │ pos │ created_on │ amount │ base │ locktime │ consumed │ conditions │ writtenOn │
├────────┼──────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────┼────────┼─────────────────────────────────────────────────────────────────────────┼─────────┼──────┼──────────┼──────────┼───────────────────────────────────────────────────┼───────────┤
│ CREATE │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 0 │ NULL │ 6000 │ 0 │ 0 │ 0 │ SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg) │ 191739 │
│ CREATE │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 1 │ NULL │ 40 │ 0 │ 0 │ 0 │ SIG(6vjF4vk9UiGWk7b12yPx2NXWQ4QaVDDesZXdpactihMR) │ 191739 │
│ UPDATE │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 3D16393A3FD5562AA8EABD6CEB15D132D2A0C3E100736937987BAAFEAA2CDDB1 │ 0 │ 191737-00000009E740868AB2B1B99D69C962638A0A42C748A6CBA2E30070E7C2B17C00 │ 1000 │ 0 │ 0 │ 1 │ SIG(6vjF4vk9UiGWk7b12yPx2NXWQ4QaVDDesZXdpactihMR) │ 191739 │
│ UPDATE │ 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5 │ 79A50223071F72AB919F1D80C25DA56CDE89E2F5261D659A9E09FFF26C3A5759 │ 1 │ 191737-00000009E740868AB2B1B99D69C962638A0A42C748A6CBA2E30070E7C2B17C00 │ 5040 │ 0 │ 0 │ 1 │ SIG(6vjF4vk9UiGWk7b12yPx2NXWQ4QaVDDesZXdpactihMR) │ 191739 │
Ici nous sommes donc positionnés avant la transaction provoquant le fork. On voit que les deux sources invoquées :
- 94FD41FA2A256A20F2689B2AF2BB8BB370C7896F0F4E7E6A0F9A622DD6969A35:1
- 0D3A680DBAC4CA50036EBD336CC16197B9952E25BDE1E53160A60ACA48A2FEF5:0
sont effectivement disponibles, car :
- la source 94F…35:1 est créée (dernière ligne du premier dump, op = CREATE et pos = 1, amount = 1000) et jamais consommée (pas de op = UPDATE avec le même identifier + op = 1)
- la source 0D3…F5:0 est créée (premier ligne du second dump, op = CREATE et pos = 0, amount = 6000) et jamais consommée (pas de op = UPDATE avec le même identifier + op = 0)
En conclusion, les nœuds ayant forké auraient dû accepter le bloc. Reste à comprendre pourquoi, selon eux, ces deux sources étaient déjà consommées.
5 Likes
Mon identité et mes nœuds sont également sur cette branche mais isolés de la PoW.
Et juste une petite faute : c’est pos = 0.
Ça semble être une bonne nouvelle. Attendons de voir pourquoi ces quatre nœuds ont refusés cette transaction.
Souhaites-tu un dump ou Remuniter te satisfait amplement ?
1 Like
Bien vu 
Pour le dump, je regarde celui de Remuniter. J’espère que l’élagage n’a pas déjà supprimé l’historique …
edit : malheureusement je ne trouve plus les enregistrements des 2 sources, ni de leurs consommations. L’élagage est déjà passé par là.
J’ai quand même une idée de ce qui a pu se passer, la cause implique sûrement la résolution de fork. Ticket #1336 créé.
4 Likes
Bon du coup, on ne saura pas ce qu’il s’est passé. Cet élagage a dû aussi avoir lieu sur ces quatre autres nœuds ? Il a lieu quand cet élagage ? J’ai un nœud qui a crashé dans la nuit, que j’ai relancée autour de midi. Peut-être a-t-il cette information ?
Je vais synchroniser un de mes nœuds sur la branche majeure.
Est-ce que je fais bien de notifier Nicole, Mententon et BnimajneB de se synchroniser sur la branche majeure ?
Bonjour à tous
DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg c’est moi.
Je me suis amusé cette nuit pour tester un projet de boutique en ligne et j’ai remarqué a un moment que ca semblait partir en quenouille sur la blockchain…
4 Likes
Merci de t’être dénoncé on va pouvoir te donner des fessés 
C’est super intéressant de lire ce forum au passage, continuez ce bon boulot 
5 Likes
@nicole, @Mententon03 et @Junidev (BnimajneB), vous pouvez synchroniser vos nœuds sur la branche principale que vous pouvez retrouver sur g1.duniter.org.
Nos nœuds ont subi un bug.
Merci, j’attendais le feu vert.
Bonjour,
Je ne m’y connais pas trop en technique mais je viens remonter un problème qui me fait penser à ce fork.
J’ai tenté d’utiliser le système de paiment par sms (http://qo-op.com/fr/aide?q=%2Faide) ce matin. J’ai créé un portefeuille via sms dont la clef est AeejF5Byz4XChEmG1ipv6bixhnS4UyzUxanZL5Jd4H6f
J’y ai fait un virement de 20G1 ce matin qui est maintenant effectif.
Quand je vais sur cesium via (cesium.mlmtp.fr) j’y ai bien 21G1 mais quand je fais S via mon téléphone j’ai 1 G1 seulement dessus 
Un rapport avec ce fork ?
Si ce n’est pas le cas, désolé pour le dérangement !
Surement que le nœud que tu consulte est désynchronisé (sur un autre fork) et n’a pas encore cette transaction.
silkaj balance AeejF5Byz4XChEmG1ipv6bixhnS4UyzUxanZL5Jd4H6f
Total amount of: AeejF5Byz4XChEmG1ipv6bixhnS4UyzUxanZL5Jd4H6f
----------------------------------------------------------------
Total Relative = 2.1 UD Ğ1
Total Quantitative = 21.04 Ğ1
J’ai tenté une synchro sur le miroir principal (Interface graphique) mais il n’était pas dispo ensuite sur le miroir secondaire “g1.duniter.org:80” mais je suis resté bloqué à “download”: 34% et “apply” 33%.
Je me suis ensuite synchronisé sur ton nœud “duniter.moul.re:80” c’est bon en 15mn. Il semble que j’ai rejoint la branche principale.
Oui, G1sms utilise g1.duniter.fr qui ne répondait plus…
En utilisant le noeud de @Moul “duniter.moul.re”, “443” cela fonctionne à nouveau.
Par contre, j’ai un soucis avec Cesium+ (aucun des nœuds ne répond)
Nœud de données g1.data.duniter.fr injoignable ou adresse invalide.
Voulez-vous temporairement utiliser le nœud de données g1.data.le-sou.org ?
@kimamila, y’a-t-il une façon pour récupérer la liste des pod actifs??
Je suis en tester une nouvelle version des Pod Cesium+, qui publie automatiquement leur état au réseau, afin d’etre plus facilement installable et configurable.
Je referai un post bientot la dessus.
On va enfin pouvoir un réseau résilient de Pod
4 Likes
Tu me vends du rêve
Vous me vendez tous du rêve les gars, vraiment, c’est génial.
1 Like