[bug?] Source à condition complexe manquante

Support Duniter-v1
,
1

Je continue mes tests (g1-test) sur les conditions complexes.

La première transaction, faîtes il y a une semaine, était présente dans les sources.

Elle a même été utilisée après le délai d’une semaine comme source d’une nouvelle transaction à moi-même. J’ai ainsi récupéré le montant de la dépense précédente.

La seconde ne l’est pas ! Du coup, impossible de la récupérer…

Le transaction effectuée est la 7ème dans les sent :

http://g1-test.duniter.org:10900/tx/history/HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb

hash : "CC60CABF8991B7C5B742ED983D542C26E33D34EE725900BC591A846D2321ACA9"
blockstamp: "541949-0005E0C3E2D48E178C2ACC43FC5E375840F311CB31E5BB5ABB8E6C438C68E0E3"
commentaire: "1 gt en CSV(une semaine)"

Mais on ne la trouve pas dans les sources, seulement la monnaie en retour.

http://g1-test.duniter.org:10900/tx/sources/HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb

Une idée ? Un changement en 1.7.21 :blush: ?

[edit]

Un indice ?

Seul changement par rapport à la transaction précédente, le montant était de 100 base 2 :

"100:2:SIG(AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK) || (SIG(HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb) && CSV(604800))"

maintenant il est de 1 base 2:

"1:2:SIG(AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK) || (SIG(HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb) && CSV(604800))"

J’ai relancé deux transactions complexe, une à 2 gt et une à 100 gt, verdict :

La transaction à 2 gt n’apparaît pas dans les sources !
La transaction à 100 gt apparaît !

Cela semble dépendre du montant (et de la base ?).

2

Un rapport avec https://forum.duniter.org/t/bug-dans-la-gestion-de-unitbase/6929 et non avec l’usage des conditions CSV ?

3

Oui sûrement, j’ai édité le post.

A 1 gt, 2gt, pas de sources.

A 100 gt, une source !

Ticket ouvert: https://git.duniter.org/nodes/typescript/duniter/-/issues/1397

4

Sur la GT, comme on est en base 2,100 est le montant minimal pour qu’une source apparaisse sur un compte vide. Comme 1G1 sur le réseau principal.

Reste à voir ce que Duniter considère comme « compte vide ».

La source apparait-elle sur le compte AhRMHU… ? Il n’était pas vide hier.

5

Ce n’est pas cohérent.

1 gt * 10² = 100 centi-gt

soit le minimum de 1 gt requis sur un compte vide. Ou alors je ne comprends pas le principe de la “base”.

Les transactions n’apparaissent pas non plus dans les sources du destinataire.

Je croyais que la destruction de monnaie n’était plus possible, mais là elle semble non récupérable…

6

~~Si, c’est la n°39 des received dans http://g1-test.duniter.org/tx/history/AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK.~~

Si, c’est cohérent.
en base 2, le “centi-gt” est de 1*10² centi-gt(bloc 0)

BR_G106 :

If `BALANCE < 100 * POW(10, HEAD.unitBase)` , then for each `SOURCES AS SRC` add a new LOCAL_SINDEX entry:

SINDEX (
    op = 'UPDATE'
    identifier = SRC.identifier
    pos = SRC.pos
    written_on = BLOCKSTAMP
    written_time = MedianTime
    consumed = true  ## Source consommée ?!
)

Reste donc à savoir si (SIG(HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb) && CSV(604800)) est un compte vide pour Duniter.

Par ailleurs, peux-tu réessayer avec cette condition (parenthèses supplémentaires) :

( SIG(AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK) || (SIG(HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb) && CSV(604800)))

7

Les transactions n’apparaissent pas non plus dans les sources du destinataire.

http://g1-test.duniter.org:10900/tx/sources/AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK

Essaie donc de dépenser une transaction reçue qui n’est pas dans tes sources… Je suis curieux de voir ça ! :wink:

8

Avec un script python utilisant levelpy, j’ai analysé le SINDEX de mon node Duniter local pour g1-test.

J’obtiens la même liste de sources pour AhRMHUxMPXSeG7qXZrE6qCdjwK9p2bu5Eqei7xAWVEDK.
Ce n’est donc pas BMA qui filtre.

Ainsi, dans Duniter 1.7.21 : les outputs inférieures à 100 base 2 ne sont pas ajoutées aux sources dans l’index.

Je peux donc détruire de la monnaie en envoyant des montant inférieurs.

1 Like
9

Ce problème sera réglé en DUBP v13 avec la disparition de la règle BR_G106, étant donné que la G1 ne changera pas de base avant 120 ans, ce bug ne sera pas corrigé dans DUBP12, il faudra attendre le passage en v13 :slight_smile:

4 Likes