GBot feeback on G1-test

Archives Discussion
,
1

Ola,

J’ai mis en route un process automatique hier soir vers 21h30 / 22h et arrêté vers 00h/00h30

J’ai effectué pas mal de transactions entre les comptes ^^.

Je fais une remonté du résultat ce matin, de la “vue” sur http://g1-test.duniter.fr/#/app/home
et je m’interroge sur les calculs de prise en compte du solde,
étant donné les différences entre les 2 urls sur le site:

app/wot/tx/key/uid <=> correspond au retour des montants sur tx/sources/pubkey
app/wot/key/stats <=> ?

58
58729×100 11.2 KB

https://g1-test.duniter.org/tx/sources/7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
https://g1-test.duniter.org/tx/history/7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY

si je calcul bien le montant total restant de mes sources et la requête tx/sources sur laquelle je me base pour calculer le solde disponible, il y a des G1tests ( 25,24 - 22,99 => 2,25 ) qui sont probablement perdus au fin fond de la galaxie du numérique :stars: au travers du nombres de transactions stockées dans les tableaux “sending” et “pending” que l’on voit sur les requetes tx/history

par ailleurs

“time”: null,
“block_number”: null,

sont a nulls uniquement dans les champs pending et sending, pas “sent”
les champs à null sont ils critiques ? je suppose qu’ils sont remplis une fois validés par la blockchain
du coup, qu’elle est la différence fondamentale entre les tx stockées dans “sending” et “pending” ?

1 Like
2

Ah oui en effet :slight_smile: excellent test !

image
image451×984 63.1 KB

Les tableaux “pending” et “sending” réfèrent aux transactions qui ne sont pas passées en blockchain, donc qui ne sont pas officielles et qui ne valent rien en elles-mêmes. Les GT (je vais abréger pour Ğ1-Test, c’est trop long) qui sont dépensés par ces transactions sont toujours officiellement disponibles.

Cela veut simplement dire que ces transactions ne sont pas écrites, car ils sont remplis en fonction du bloc qui intègre ces transactions, les officialise.

Dans “sending” tu vois les GT que tu dépenses mais qui n’ont pas encore été encaissés par le destinataire (car la transaction n’est pas encore officiellement écrite en blockchain). Même chose pour “pending”, concernant les GT que tu vas recevoir.

3

Ok, compris, merci pour les explications :slight_smile:

Je vais refaire tourner la machine :hammer_and_wrench:

4

A priori les "sending " et “pending” bloque toute futurs transactions,

je me demande si elles vont être consommées et apres quelle periode ?
j’ai que des ucode:

{
“ucode”: 1010,
“message”: “The transactions’ sandbox is full. Please retry with another document or retry later.”
}

5

Chaque nœud a une taille limite de piscine, pour les transactions c’est une piscine globale limitée actuellement à 200 entrées.

Pour contourner la limite, 2 solutions :

  • soit envoyer les transactions depuis un compte membre vers le nœud membre correspondant, car bien sûr notre propre nœud accepte toujours nos propres documents
  • soit envoyer des transactions de plus gros montant, car la piscine a une notion de priorité et accepte tout de même les transactions de montant plus important que celles qu’elle possède déjà

Ceci dit c’est quand même pas terrible d’avoir une piscine « globale », ce serait plus malin d’avoir une piscine par émetteur de transaction tout comme on a une piscine limitée à 12 entrées par membre pour les certifications.

6

Une piscine par clé émettrice je le sens pas, ça permettrais une attaque de spam massive assez facilement, ou alors il faut vraiment des protections solides avec par exemple un pré-traitement rapide du document avant de décider de le stocker en piscine :
refus systématique des clés émettrices qui n’ont pas de sources dispo
un timer avec refus de plus de x documents par minute par exemple.

Sinon on peut garder une piscine globale mais dont la taille est dynamique en fonction du nombre de tx inscrites dans le dernier bloc, par exemple quelque chose comme txSandboxMaxSize = MAX (200;1.1*countTxLastBlock)

1 Like
7

Exemple ?

8

Ben il est facile pour un attaquant de disperser sa monnaie et de la monnaies de complices sur des millions de clés puis de se mettre d’accord pour envoyer 1 document tx de chaque clé en même temps, une sorte de DDos qui plomberai tout le réseau même avec 1 seul document par clé.

9

Eh bien alors c’est facile, il suffit d’avoir des piscines par montant (]0; 10], ]10; 50], …) , et refuser par exemple X fois le même émetteur au sein d’une petite piscine par exemple, tout en ayant une taille maximale générale pour chaque piscine.

Le coup des piscines par clé me paraît bien au niveau des membres par contre.

5 Likes
10

Effectivement très bonne idée, a condition que les tranches soient calculés relativement au DU courant pour que le système reste pertinent sur long terme. On peut choisir par exemple :

Pour les émetteurs non-membres uniquement :
]0; 10 DU] : maxi 2 tx par émetteur
]10 DU; 50 DU] : maxi 3 tx par émetteur
]50 DU; 100 DU] : maxi 4 tx par émetteur
]100 DU; +inf] : maxi 5 tx par émetteur

Chaque tranche ayant par ailleurs une taille totale maximale de MAX (200;1.1*countTxLastBlock)

Pour les émetteurs membres : 5 tx par émetteur quelque soit le montant.

Ce n’est qu’une proposition :slight_smile:

11

Oui sur le principe ça me paraît mieux de compter en DU.

Sinon pourquoi le facteur 1.1 ?

12

Parce que c’est le facteur que tu a déjà choisi pour la taille des blocs il me semble, 110% de la taille du bloc précédent au maximum, c’est bien ça non ?

13

Oui mais c’est une fonction récursive pour la taille du bloc, j’ai fait en sorte qu’il puisse y avoir une augmentation de 10%. Tandis que là, le 1.1 ne fait rien. D’où mon interrogation !

Donc, retirons-le et mettons directement countTxLastBlock.

1 Like
14

ok, voila le ticket : https://github.com/duniter/duniter/issues/1152

1 Like
15

Je le laisse à qui voudra, ce n’est pas extrêmement urgent de toute façon. Bon faudrait pas que ça traîne 1 an non plus …

En tout cas, je suis quand même inquiet car la piscine sur le nœud est toujours pleine. Elle ne semble pas se libérer et ça devient donc bloquant :confused: :

https://g1-test.duniter.org/node/sandboxes


{
  "identities": {
    "size": 5000,
    "free": 4993
  },
  "memberships": {
    "size": 5000,
    "free": 4995
  },
  "transactions": {
    "size": 200,
    "free": 0
  }
}

A bien y regarder, en fait les transactions polluantes vont traîner 1 semaine dans la piscine de ce nœud :

https://github.com/duniter/duniter/blob/dev/app/lib/dal/fileDAL.ts#L694

16

j’ai envie d’ajouter que sur les requêtes de l’api BMA,

un timeout lié à l’adresse IP de la connexion entrante me semble on ne peut plus pertinent, j’ai envoyé à un certain moment environ 3 requêtes toutes les 2/3 secondes,

rejeter le traitement de la requete au + tôt dans le processus au dela de X requetes dans une periode P, appliquer cela a minima sur la fonction concernée par l’URI tx/process…