[ANN] Atomic Trade New Virtual Currency Exchange USD BTC

[teknohog]

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.

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.

[1715227316]

1715227316

[gaalx]

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

[saeeds255]

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

[ByronP]

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

[pineapples]

ha.
what you need is to store all your data in a seperate blockchain.



--

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" <address> <amount> - 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" <amount>

Trader is charged a fee for use of the service: move "userid" "FEES" <amount> (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.

[ByronP]

ha.
what you need is to store all your data in a seperate blockchain.



--

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" <address> <amount> - 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" <amount>

Trader is charged a fee for use of the service: move "userid" "FEES" <amount> (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.

thats actually a good idea :-)

[ByronP]

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

[Zeke_Vermillion]

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.

[digit]

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

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?

[ByronP]

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

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'm sure M$ has there ass covered but first thing tomorrow the dogs will be on it anyway as it is due diligence on my part to pursue them.

[ByronP]

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.

Interesting ideas :-)

[ByronP]

Please keep in mind (not to downplay the situation) that we are talking about 2 weeks of data not lost or stolen wallets. Once we switch to our own servers we can keep lots of DB backups since the transfer is to local devices where as the problem with using the cloud is the time it takes to transfer such large amounts of data prohibits keeping too many onsite backups.

But let me just thank you all for continuing to support my work as we move forward and take these problems in stride and continue to evolve into the best exchange possible.

[Ignatius]

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

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'm sure M$ has there ass covered but first thing tomorrow the dogs will be on it anyway as it is due diligence on my part to pursue them.

Can we add proper backup policies to the "due diligence" to-do list?  

[ByronP]

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

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'm sure M$ has there ass covered but first thing tomorrow the dogs will be on it anyway as it is due diligence on my part to pursue them.

Can we add proper backup policies to the "due diligence" to-do list?  

It already is... there were daily backups on a vhd and monthly offsite backups. It is very hard to keep more backups than that using the cloud since transferring 160+gb of data takes forever... I believe this is in part due to network rate limiting on there part. However like I said this will not be an issue with the new system. Which will also allow for complete reporting functions without the need to detach the database.

[gaalx]

ByronP, when recover exchange work?

[ByronP]

ByronP, when recover exchange work?

Yes (it just takes ages to transfer and load up all the data)

[Winst69]

Byron please dont think im trying to interfere. I know you're busy getting things sorted, but a landing page with a breif whats happened and links to here and twitter would be good.

[favdesu]

since my account is younger than 2 weeks and I invested in ATP: https://blockchain.info/tx/e542e6736c12fe6bba03ea7f234c90842783d80054ae9713991125c61154ab9e here's the TX. expecting everything back.

thanks.

[cinnamon_carter]

Byron please let us know who at microsoft is responsible for not taking care of you.
I really don't take kindly to anyone or a  corporation trying to screw people or it's customers over.
If my accounts lost some coins I will accept it since your exchange has been very supportive of listing Photon and the other blake coins.
I suggest you persue whatever solution is best for the long term success of the exchange and preservation of most customers funds.

Some action may have to be taken against who is deemed the parties responsible for this eventually.

[ByronP]

since my account is younger than 2 weeks and I invested in ATP: https://blockchain.info/tx/e542e6736c12fe6bba03ea7f234c90842783d80054ae9713991125c61154ab9e here's the TX. expecting everything back.

thanks.

Any accounts that are not in the current system should be recreated then you can send me your addresses or txid (via a support ticket) and I should be able to recreate the balances.