Topic: [ANN] Atomic Trade New Virtual Currency Exchange USD BTC - page 7. (Read 44373 times)

thanks for the update, please keep us informed, trying not to panic here hope we can be back on the site soon.

also is there any action or dispute you can take with microsoft azure as its seem to me they should be doing bit more then apologies for their failure to provide the level of service that would be reasonable to expect?

I have a suggestion for the future. Kind of a rough patch for last-case backup of account data. Why not allow users to export a copy of their personal ledgers, GPG-signed by Atomic Trade. Most people wouldn't bother, but folks with larger balances might. Then we have the comfort of holding some tangible proof of AT's obligations to depositors.

That said, anything that encourages people to be lazy and not withdraw balances from the account is potentially dangerous. No matter how trustworthy the operator, there is *always* a possibility for data loss. I just don't think it is possible to protect fully against damage from possible wallet loss or theft. Any representation to the contrary is irresponsible.

Maybe it's time to go a step further, and actively encourage fund withdrawals. Say, for any balance over some de minimis amount, the site would charge "interest" on deposits (except for deposits that are subject to an open order). Ouch, I know. But it would sure get people to w/d their funds in a timely fashion.

The data is in the process of being transferred to the new server... 160gb... may take some time

A new server is up and being prepped for the data. I will post back soon with my progress.

I hope the site back online soon ! I had about 70$ there 

ByronP, previously, when the exchange will recover work? Losses big?

Good points-- something to consider in the future, but this won't help with the current situation.

Personally, I'm fine with the lost trades, if the balances are restored according to each blockchain.

I'm shocked and still processing.  What about the status of ATP and CCS we have?  How can Microsoft get away with such a poorly designed service, surely before their maintenance they would have some protection in place to recover if something wrong without needed to access the data itself like backup images of VM/VHDs?   They say 99.9% available on all their azure services here https://azure.microsoft.com/en-us/support/legal/sla/
Why can't they restore the site to as it was before the maintenance began?

Best to take time and minimize errors. There will be a rush to make withdrawals as soon as the site is back up, so either make sure the balances are as accurate as they can get, or else have to freeze w/d until they are. Don't want to end up with an overall deficit like Vircurex.

Nice backup system admin.

means I lost 20+ referrals and some ATP investments?

Very true Mog good point no need to add to the confusion. So I will bring up the backup first thing and see what I can do about scanning the deposits and withdrawals.

What is status of ATP and CCS, 2 weeks old also?

Well the odds are low (but not 0) that you won't lose all your data again before moving to new servers.

Bring Atomic up on current sys with old data will allow you to deal with all our screams of agony then work on moving to new system and then deal with pain of the move.

Going straight to new sys means listening screams here then mass confusion as we get a an unknown UI and old data at the same time.

For me this even worse because many coins I did not loose from a Trojan attack on home PC I sent to AT this week.

A good majority of this could have been avoided.

Exchange owners need to quit relying on their databases and start using the wallets features to their advantage.

Trader creates an account on the website: web server either assigns them a unique customer id number or uses their email address or other unique identifier, calls getaccountaddress "userid" and tells the customer to send to that address to fund their account.

Trader receives coins to fund their account: web server isn't involved.

Trader is shown their current balance: getbalance "userid" 6 to get their 'confirmed' balance, and subtracts it from getbalance "userid" 0 to get their 'unconfirmed' balance.

Show the trader a list of transactions: listtransactions "userid"

Trader sends coins to another bitcoin address: sendfrom "userid"

- This prevents the server wallet balance from getting drained by an individual user, ask Cryptsy or Coinex about that one.

Trader transfers coins to another trader: move "userid1" "userid2"

Trader is charged a fee for use of the service: move "userid" "FEES" (using special accounts like "FEES" can make your application's logic much simpler)

This way when your database takes a shit but you still have the wallet you will be able to correlate user account names and their account balances.

I've seen it happen several times and I have seen the damage from sending funds from the server wallet using "sendtoaddress" AKA sending from their main wallet instead of using "sendfrom" which will only allow people/users to move/withdraw available funds.

Using "sendtoaddress" is what caused a lot of exchanges to get their entire server wallet drained, when if they would have used "sendfrom" the most that could ever be sent/withdrawn from a user account is what was actually in their account.

This would be helpful in this situation because even if you didn't know the trades that occurred you would know that all the users balances are correct.

Basically I would be happy if you get my account back up and it has my old balance, plus BTC I deposited since then. (And for folks who deposited alt coins, should have their alt coins). Since we deposit to static addresses, even the old backup should still have the deposit add'ys, and those can be matched with public blockchain data. Thus the only loss is whatever we made or lost trading since last backup. And given the low volume on the site, it's guaranteed to be pretty low numbers provided we don't lose deposits.

Yes, we can't trust our private keys to other folks. Yet we do, b/c we want to buy and sell alt coins and we're too lazy to join Bitcoin WoT, or to deal directly.

Interesting idea the wallets are all fine they back up 3 times a day to an encrypted redundant storage system. I could probably write a script to reprocess all the wallet transactions but this wont account for the amounts traded and may make things worse... I will have to think about this one and how it would work and yes I am extremely unhappy with the way they are operating and the contempt show in there responses but that is probably no surprise what does surprise me is there complete and utter lack of responsibility since from my reading this has happened to many people. At least the private rack is already in place and awaiting the final software to bring the new site online.

Exchanges are not a safe place to store your crypto. We should have learned from CryptoRush's crash.  thankfully I did and will only have lost $85 from this. I will still trade on Atomic when It come back online    Good luck ByronP with this issue




-Sid

I'm not sure what this means. I think it means that you still have the private keys for wallets in cold storage, but just don't have any account / trade data since the last backup. If that's the case, perhaps the right way to deal with this is:

(1) start with the last backup

(2) measure deposits / withdrawals since the last backup, based on blockchain data (surely you at least know the static addresses involved)

(3) apportion the net difference between accounts based on the verifiable deposits and withdrawals of each user since the last backup

Let's say for simplicity that there's 10 BTC in cold storage for all of Atomic Trade, and total deposits since last backup were another 10 BTC. If my user account balance 2 weeks ago was 1 BTC, and I deposited 1 BTC since then as verified on the blockchain record, I would receive a total adjusted balance of 2 BTC.

This really sucks though. I would expect to see a more active approach to M$. I'd be happy to help with a demand letter, etc. If you don't have any funds in cold storage offline, though, I would just say don't do anything crazy!

Z

At approximately 10:49 AM EST on Aug 23 2014 the Virtual Machine (VM) and its associated Virtual Hard Drives (VHD) that resided on Microsoft's Azure platform and contained our customer data for lack of a better term went poof. Microsoft's official word on this is as follows “Thank you for your update. I understand your frustration regarding your deleted data. Unfortunately, as I have mentioned in my previous email, we do not the tools to restore customer data due to security, privacy and compliance reasons. There is nothing that I can do at this point to restore your data”.

Due to the overwhelming size of the database our backup structure is one designed to only minimize the damage in the event of such a catastrophic failure. Daily backups resided on one of the afflicted VHD's while monthly offsite backups are still available. Our last monthly offsite backup is approximately 2 week’s old meaning we have lost about 2 weeks of trade data, balances, registrations, deposits, withdrawals, etc. Such a loss is something I hoped never would happen however despite my plea to Microsoft to try and restore the data they contend the following "Azure cloud storage does not function in the same way as conventional SAN on premise storage solution, we do not have the ability to access storage directly and recover specific data".

It saddens me very much to have lost faith in the idea of cloud computing and its ability to reliably store data.

In light of this I have decided it best to offer everyone 2 options:

• We continue using the current site and infrastructure as planned until we switch over to our private servers.
• I break my back and try and get the new system up and running as fast as possible while leaving the site offline.

Both solutions still mean we have to deal with the loss of data. This will mean a loss for some and a gain for others. As I have no way of knowing any balances, trade data, deposits, withdrawals, new accounts, etc. after the last offsite backup. I am open to any and all suggestions so please feel free to include your constructive input.