IMHO niekde okolo riadku 42, +- tri riadky



edit: got it ! ked som v predsilvestrovskom zmatku pred nultou K-party do addTransaction metody implementoval obmedzenie dane MAXIMAL_WALLET_AMOUNT, zaniesol som v bloku zacinajucom na riadku 42 nasledovnu chybu:


Popis chyby

V pripade ze niekto chcel dat K node cloveka ktoreho wallet vlastnil viac ako je povolenych MAXIMAL_WALLET_AMOUNT (e.g. blurec ci maniac), dane K sa automaticky presmeruje na Ganeshu. Takze sa v riadku 44 vykona $receptor_id=GANESH_ID.

Bug nastal v tom, že v bloku sa sice zmenila hodnota premennej $receptor_id, ale nie zodpovedajuce hodnoty premennych $(pre|post)transaction_receptor_wallet_amount. Tie teda zostala na hodnote povodneho adresata (t.j. napr. blureca ci maniaca). O par riadkov sa potom vykona kriticky atomicky insert do ledgeru s tou pokazenou hodnotou.


Q.E.D.

Transakciou 3270540 bolo udelene 🪶 maniacovej node "Re: ssh snake" (node_id=9118230). Transakcia 3270540 obsahuje memo "9118230 owned by 192". Na maniacovom (user_id=192) receptor_wallete je pred transakciou 137670 🦆. Po vykonani tej transakcie je take iste mnozstvo 🦆 aj na Ganeshovom wallete.


Fix

Pridat na riadok 45
$receptor_wallet_amount=Kybchain::getWalletAmount(GANESH_ID);
https://git.kyberia.sk/kyberia/kyberia2/commit/16eb2d01575d9b346ba41dd803cd3d3ee6038ad9


Moral of the story

Hodinu pred K-party sa jadro ledgeru neprogramuje, obzvlast ked do toho skacu Zena, Matka, deti a pudel.

Takze zda sa ze Tebou pozorovane diskrepancie mozno rozdelit do styroch tried:

1) nezrovnalosti v seeding transakciach - vsetko po riadok 3720 - zanedbatelne mnozstva, myslim ze mozeme odignorovat

2) situacia kedy recipient == sender ... tam ziadna diskrepancia nieje kedze balance == previous_balance, tu je Tvoja analyza prilis prisna ...

3) ked transakcia typu P nasleduje po transakcii typu D ... tam sa tiez zda ze je Tvoja analyza prilis prisna kedze previous_balance riadku 1 == balance riadku 2

4) od riadku 3844 (cca od transakcie 3247442) transakcie typu K kde receptorom je Ganes - tam je zjavne bug ktory treba najst a identifikovat ale dobra sprava je ze sa tyka len bota

Ahoj, fajna analyza, vdaka. Ale napr. transakcia 252864 ziadnu diskrepanciu nevykazuje kedze som v nej testoval ako bude reagovat give ked sender == receiver a balance sa v tom pripade naozaj rovna expected_balance.

Jednu vec co som zabudol povedat je, ze ked sa realizuje transakcia, informacia o hodnotach na wallete sa berie z najaktualnejsieho riadku kde sa dany sender (resp. recipient) vyskytol