LindeX gives room for competition?

For those too lazy to click the link, here what I find as the key part to it all.

Heh... state changes.

Yeah, their ATM code was waaaay over complicated.

There were a lot of things they could have done, that they didn't.

Eg: They should have scraped the transactions page (I've never seen any)

If they found bugs with the transactions page they should have reported them repeatedly. In fact, that's what everyone should be doing who is doing ATM code.

I'm sure if all the ATM writers scraped and reported bugs on the transactions page, we'd have a much more stable economic system.

The only secure method of checking L$ transactions is by pinging the transactions page. You're doing an https connection, so you are guaranteed a large degree of data integrity.

Unfortunately, the ATM writers seem to be rather clueless in this regard. I tried advocating this over a year or so, but for whatever reason I was ignored.

And then the hack came out, and people whined and complained.

Well, whatever - if you had been checking against a transaction page it would have worked fine. And now this leakage issue .. again, check against the transaction page.

Seems they would be losing events during state changes:

Script A receives RPC request from site B
Script A triggers timer event
Script A, still in the remote_data event decides to change state
Script A enters new state... was the timer event run or not ? Was it old state's or new state's timer event ?

If you are dealing with large volumes, pinging the https is really going to take a long time. I have never tried, but what is the update rate of the webpage anyway? I would guess that there is some delay between the inworld transaction and the updating of the webpage. If it is true that there is a state change race, then I really don't see anyway to get around that. No matter what you do, you could still have this condition.