/vt/ - Virtual Youtubers

>ahh the transaction, transaction. you know the transaction? the nooo one. i always, i always place the, the transaction. history transaction and without transaction. i always make the history and without transaction. transaction! i like transaction, yeah. i always, i always reverse the, the reverse- reverse transaction. ahh how can i explain? i can explain by my spreadsheet! i always place like the transaction that it has confirmation on here, this part, the server response. response of websocket. and then, i place- wh- when i place the next transaction, the transac- it always have a reversal on t- on the response, but i pick up these... away! cause i detect it. and then i redo the transaction. okay? you understand? understandable! reversal! yes.

>>8212729
>>8115536

About transaction reversals (I think "dupe" is a misnomer)
So i've sifted through the logs and found a chain of transactions that can hopefully illustrate what I suspect causes the issue, i've opted to format it in a spreadsheet since the actual log, even if trimmed is way too long for an image.

TL;DR: the TX (transaction) history is unreliable, and transactions can be "reversed" by the server, hopefully this helps people write autotraders that donít bog the server / devs to fix the issue

How to read picrel, Iíll link it to my conclusion in a separate post, feel free to read that first (5k post limit):
Timestamps trimmed to the last 4 digits
PrevBal is calculated from Price and Balance
Time(Tx) is the transaction timestamp
Time(Wallet) is the cooldown timestamp on the wallet returned in the CFM packet
txTime is the time difference between the 2 timestamps

An excerpt of the wallet from the CFM pkt is shown, with each coin's timestamp and amt in the packet
A green entry represents a successful TX
Red represents reversed data
Yellow represents a TX that was CFM'd by the server, but ultimately reversed down the line

The other colors in Bal and Timestamp exist to highlight identical values for reference later

The transactions:
The first and last (nana and calliope) exist to show a before and after
As established before, Time(Tx) (Tx receipt time) should be always earlier than Time(Wallet) (Tx confirmation time)
In a valid ledger, the prevbal will always equal the balance of the previous transaction
For most normal transactions, the Time(Wallet) of the previous TX should always be earlier than the Time(TX) of the current transaction. Reversals tend to happen when this isn't the case.

The moona, fauna, and kronii transactions have Time(Tx)s BEFORE the choco Time(Wallet), those transactions essentially didn't happen, call it reversed, ghosted, whatever
When the sana TX is done, it basically only applied the sana TX to whatever was on the choco TX, as evidenced by the 9755 correctly being brought over from the choco transaction. Also as a result of using the choco TX's base numbers, the reversed transactions didn't happen, as evidenced by the fact that the yellow timestamps are never to be seen again (until a completely separate request was sent to correct for this, the separate request also has a new timestamp)
--To be continued--