[SSD] Sonic - 1st TOR with functional anon send - Steganography based Anon App

[thcmakaveli]

Hello Everyone,

We have finished our investigation of the recent SSD issue and found the exact reasons for this. It was not a fork as SSD dev thought, or as we thought a double spend attack.
C-CEX had many withdraws and deposits showing on the blockchain that prove we were never on the wrong fork occuring between the 10th and the 21st of September and I know many of you were stating this to us as well.   http://www.argakiig.us/blockchain/ssd/

After the wallet upgrade that we did on the 20th, resync and rescan did not find any discrepenacies of the wallet balance and actual user's balances.
The reason why people were unable to withdraw coins in the past couple days was actually due to a wallet issue that allowed it to generate pre-existing wallet addresses after we upgraded and recompiled.
Due to this we had 19 duplicate addresses that belonged to 38 accounts which were sharing deposits. When deposits came to these addresses it was being credited to both accounts on our exchange as these accounts had duplicate wallet addresses. This is how people started selling coins that were being credited to their account despite them not actually depositing them. Of course it is human nature to take advanatge of the situation and If I was a normal trader I probably would have sold coins that did not belong to me too so I do not blame those people. I will say it would have been "nice" if someone had alerted us they were receiving SSD that were not theirs but again I understand. This however, led to our wallet getting emptied of SSD.

This generation of addresses is normally turned off on the upgraded wallet it was left in the code. We have not encountered this issue in over 300 wallets from the past so this is an isolated problem.


Now this puts all of us in a bit of a bind because this was a wallet issue and nothing more. I do value everyone who uses our exchange though (everyone I've worked with knows this) and In the effort to keep those affected from completely losing coins/btc we are going to give 300 satoshi per coin lost in the form of a BTC credit. I repeat this does not mean C-CEX did anything wrong I simply do not want people upset with nothing to show for. The btc will be distributed over the next 7 days to the accounts affected.

If anyone who did receive coins that were not theirs and wishes to give them back to those affected by this that is up to their good nature at this point. I am truly sorry this issue happened and we have implemented an extra check in our system to safeguard from this type of thing happeneing again.


-Pride of C-CEX

I tried to withdraw 17 K SSD and They were pending, then I tried to withdraw 1 SSD and it was in my wallet in less than a minute. Second, I didn`t deposit any SSD, but instead I deposited BTC to buy SSD. Third, you just compiled the wallet but not check it ? Why bittrex didn't have the same problem ? Because your exchange is shit, litteraly, and you didn't, don't and won't succedd in any further actions. Instead of returning the real investment of the people, you just made a joke with them and give them 70 % less valued coins... Bye C-cex !

[LordPiccolo]

you know what's really sad, I won't be trading SSD/sonic any further and i certainly won't be using c-cex any further.

I'm not sure who's fault this is, but if an exchange needs to put in extra safeguards then surely they admit screwing up.

I didn't have many ssd but some people have lost a fair few bucks/quid which is a real shame.

The offer of 300 sats on a coin is something I guess but to me that just says 'we're taking the piss and you can't do anything about it'


edit - so this is the fault of the dev team according to Price from c-cex

[tx42]

edit - so this is the fault of the dev team according to Price from c-cex

It's the fault of anyone who trades at C-CEX. They do this stuff over and over.

If you lost money it's your fault for being dumb. Period.

[tx42]

If you lose money at C-CEX, it's your fault.

[ExD]

Ok, I'm @CryptoRussian on twitter and C-CEX asked me to look into coin source to help with analyzing problem.  

I haven't found something suspicious or intentional in the code, at least where I looked, but bug certainly exists. C-CEX used rpc call to get new addresses for deposits(just like any other exchange) and after migration to the new version(with instructions provided by the developer), wallet started to behave strangely, instead of generating new addresses for deposits - it returned previously used addresses from the key pool. I'm waiting to hear developer explanations on this issue, I presume migration wasn't really tested extensively and there are some other issues in the code that can blow up eventually.

C-CEX had their mistake with assumptions about the addresses being unique, well, call to getnewaddress assumes that you get new address instead of old one. Unfortunately this lesson wasn't free.

As for price and loosing your coins.. well, developers should test features before releasing them, traders/miners should expect to loose coins due to bugs in the wallet, nothing new.

[argakiig]

Ok, I'm @CryptoRussian on twitter and C-CEX asked me to look into coin source to help with analyzing problem. 

I haven't found something suspicious or intentional in the code, at least where I looked, but bug certainly exists. C-CEX used rpc call to get new addresses for deposits(just like any other exchange) and after migration to the new version(with instructions provided by the developer), wallet started to behave strangely, instead of generating new addresses for deposits - it returned previously used addresses from the key pool. I'm waiting to hear developer explanations on this issue, I presume migration wasn't really tested extensively and there are some other issues in the code that can blow eventually.

C-CEX had their mistake with assumptions about the addresses being unique, well, call to getnewaddress assumes that you get new address instead of old one. Unfortunately this lesson wasn't free.

As for price and loosing your coins.. well, developers should test features before releasing them, traders/miners should expect to loose coins due to bugs in code if the wallet has problems, nothing new.

No contact has been made. And why is C-Cex the only exchange to have experienced this issue? Please enlighten me as to where the issue would be so I can fix it if it does infact exist

[tx42]

Ok, I'm @CryptoRussian on twitter and C-CEX asked me to look into coin source to help with analyzing problem.  

I haven't found something suspicious or intentional in the code, at least where I looked, but bug certainly exists. C-CEX used rpc call to get new addresses for deposits(just like any other exchange) and after migration to the new version(with instructions provided by the developer), wallet started to behave strangely, instead of generating new addresses for deposits - it returned previously used addresses from the key pool. I'm waiting to hear developer explanations on this issue, I presume migration wasn't really tested extensively and there are some other issues in the code that can blow up eventually.

C-CEX had their mistake with assumptions about the addresses being unique, well, call to getnewaddress assumes that you get new address instead of old one. Unfortunately this lesson wasn't free.

As for price and loosing your coins.. well, developers should test features before releasing them, traders/miners should expect to loose coins due to bugs in code if the wallet has problems, nothing new.

You are full of shit. Try again.

Code:

14:23:30
getnewaddress
14:23:30
scjDCfCAFwhPh5CrrntZM4n2irM3EXmKWp
14:23:32
getnewaddress
14:23:32
seF4pdfCKwH4kppNnJowbuRSh3ZkH34FAX
14:23:36
getnewaddress 'account'
14:23:36
sRFS3cT1qmAYtsVg5miGaQia6skRJjdZA9
14:23:39
getnewaddress 'account2'
14:23:39
saYKAi5SgvwZvWJDSVqavarBpzHs8QwYj5
14:27:13
getnewaddress 'account2'
14:27:13
shFxZ2D7dpULoos2bd9BU7TZ7yUfzLkEV6

[c-cex]

Ok, I'm @CryptoRussian on twitter and C-CEX asked me to look into coin source to help with analyzing problem. 

I haven't found something suspicious or intentional in the code, at least where I looked, but bug certainly exists. C-CEX used rpc call to get new addresses for deposits(just like any other exchange) and after migration to the new version(with instructions provided by the developer), wallet started to behave strangely, instead of generating new addresses for deposits - it returned previously used addresses from the key pool. I'm waiting to hear developer explanations on this issue, I presume migration wasn't really tested extensively and there are some other issues in the code that can blow eventually.

C-CEX had their mistake with assumptions about the addresses being unique, well, call to getnewaddress assumes that you get new address instead of old one. Unfortunately this lesson wasn't free.

As for price and loosing your coins.. well, developers should test features before releasing them, traders/miners should expect to loose coins due to bugs in code if the wallet has problems, nothing new.

No contact has been made. And why is C-Cex the only exchange to have experienced this issue? Please enlighten me as to where the issue would be so I can fix it if it does infact exist

Not true. We chat yesterday on skype and today I wrote several times to You - You did not respond.

[ahmedshawezi]

Haven't we been here before with exchanges blaming code i.e. Mark Karpeles.

[tx42]

Ok, I'm @CryptoRussian on twitter and C-CEX asked me to look into coin source to help with analyzing problem. 

I haven't found something suspicious or intentional in the code, at least where I looked, but bug certainly exists. C-CEX used rpc call to get new addresses for deposits(just like any other exchange) and after migration to the new version(with instructions provided by the developer), wallet started to behave strangely, instead of generating new addresses for deposits - it returned previously used addresses from the key pool. I'm waiting to hear developer explanations on this issue, I presume migration wasn't really tested extensively and there are some other issues in the code that can blow eventually.

C-CEX had their mistake with assumptions about the addresses being unique, well, call to getnewaddress assumes that you get new address instead of old one. Unfortunately this lesson wasn't free.

As for price and loosing your coins.. well, developers should test features before releasing them, traders/miners should expect to loose coins due to bugs in code if the wallet has problems, nothing new.

No contact has been made. And why is C-Cex the only exchange to have experienced this issue? Please enlighten me as to where the issue would be so I can fix it if it does infact exist

Not true. We chat yesterday on skype and today I wrote several times to You - You did not respond.

If you lose coins at C-CEX it is your own fault.

[argakiig]

RE C-CEX, Would you like to see the chat between them and I?

[tx42]

Haven't we been here before with exchanges blaming code i.e. Mark Karpeles.

GOXed

C-CEXed

[godda04]

[LordPiccolo]

RE C-CEX, Would you like to see the chat between them and I?

I suppose someone admitting they screwed up would be something. We are getting a small amount of btc back which is something.

As for the person who keeps saying it's our faults for using c-cex, maybe he is right but as a customer, i should be able to purchase any coin from any exchange and not have to worry about whether i'm going to lose them due to it not being my fault.

[pm1978]

SONIC Supporters RT !

https://twitter.com/sadochismo/status/514872632681181184/photo/1

[argakiig]

http://pastebin.com/TDy4WQ5P

for your enjoyment. Every Correspondence between C-Cex and I. I can screenshot any part if you don't believe it.

[CryptoTV]

Still getting this error for line 557 and cant compile on linux.

/root/Sonicscrewdriver/src/rpcrawtransaction.cpp:557: undefined reference to `decryptsonictxt(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)'
collect2: ld returned 1 exit status
make: *** [Sonicd] Error 1

Dev, can you please address this call in rpcrawtransaction.cpp so that I can compile your wallet.   

[argakiig]

Still getting this error for line 557 and cant compile on linux.

/root/Sonicscrewdriver/src/rpcrawtransaction.cpp:557: undefined reference to `decryptsonictxt(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)'
collect2: ld returned 1 exit status
make: *** [Sonicd] Error 1

Dev, can you please address this call in rpcrawtransaction.cpp so that I can compile your wallet.   

That is because the make file is not fully setup yet. its still missing headers.

[argakiig]

Also if you find a bug feel free to post it, I will gladly admit if I am wrong and fix it.

[CryptoTV]

Still getting this error for line 557 and cant compile on linux.

/root/Sonicscrewdriver/src/rpcrawtransaction.cpp:557: undefined reference to `decryptsonictxt(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)'
collect2: ld returned 1 exit status
make: *** [Sonicd] Error 1

Dev, can you please address this call in rpcrawtransaction.cpp so that I can compile your wallet.   

That is because the make file is not fully setup yet. its still missing headers.

OK, well when it's done, I'll open up a blackjack game here for sonic.