>>8218202--Continued--
Nomenclature and shorthands: (Refer to data from previous post)
Events:
ACK, the server acknowledges the receipt of the request via websocket, (NOT the http200 / success:true), this is sent even if the coin is on cooldown, it's what triggers the "pending" popup on the webclient
CFM, the server confirms the transaction, and sends back an updated wallet, a separate broadcast to the public ledger is made, that broadcast is what shows up on the history list, this event causes the "confirmed" popup on the webclient
Others:
TX, transaction, any buy or sell
REV/Reversal, not an actual event, but happens when the server sends the CFM packet, but further TXs down the ledger don't reflect the changes of the CFM packet, be it cooldown, balance, or coin amt. It is as if the TX didn't happen, bar the leftover history generated.
What causes the reversals?
Server side: Race conditions, high server load
Client side: Network congestion
Race conditions:
My speculation is the server isn't correctly queueing incoming transactions, so when a new tx arrives while one is already processing, a new thread is created, outdated data is read and processed, essentially creating 2 versions of the wallet, thus when the data is written, only 1 copy stays and any changes made to the other copies are essentially lost
High server load:
>when a new tx arrives while one is already processingThis window increases as the server load increases. There's a time difference between the tx timestamp and the actual coin's cooldown timestamp (~10, up to to 100+ during high loads), perhaps the tx timestamp is made when the server gets the tx, supported by the fact is returned in the ACK packet and the same TX timestamp is reflected in the CFM packet. The coin's timestamp is calculated later, when the checks are done and the server is about to write to disk (and subsequently sent back in the CFM packet). I believe the time difference between the TX and coin timestamps are indicative of server load, and is shown in the TXTIME column. The takeaway is this makes the aforementioned race conditions more likely to happen.
Network congestion:
Networks aren't reliable, and will tend to buffer connections, especially on shoddy wireless networks. The takeaway is that there is no point attempting to fix this issue clientside, since any network congestion will cause the packets to bunch up, arrive out of order etc.
Implications?
Anyone that bogs the server will negatively affect those using autotraders that don't detect reversals.
Just because you sent the trade, the server confirmed it and you can see the new coins/balance, it does NOT mean it actually went through. Double check using a future transaction, and keep in mind any attempts to apply a ledger to a local wallet will eventually go out of sync.
Ideally this is fixed serverside, but without knowing how the server currently works I can't tell how much work would be required, and none are straightforward enough to explain in a 4chan post.
On the client's end, solutions DO exist, I suspect the people who repeatedly sent invalid transactions used it as a way to counter reversals, or repeatedly fetching the wallet to ensure things went through.
Ideal solutions that don't require this DO exist, although getting CFM packets at the same time / out of order, causes the client to run into the same problems the server does. Solvable, but once again not going to fit in a 4chan post.
Quick fixes?
Sever+Client side? Allow clients to batch up multiple buy/sell requests in 1 api call, no multithread = no race condition
Client side? Don't shit up the server, it makes the problem worse for everyone else. The focus should be on detecting reversed transactions, not sending requests until it works.
Rope inducing fixes (its jork, but i'm surprised itís not been brought up yet)?
User spam score:
Start at -1000, clamp between -1000 and +10, resettable via captcha on webui
Every invalid tx increases the score by 1, every valid tx reduces it by 10
when score > 0 fine the user (score*coinprice) for the invalid transaction, and require a captcha via webui at +10
Display this score on the top bar
A money sink that penalizes users that somehow generate 10x invalid transactions than valid ones.
inb4 thread dies before anyone reads