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

[drizzle2405]

What's the coin count that was double spent and perma lost?...  Value of SSD should be going up!!!  Less coins in circulation...

[1715243718]

1715243718

[boopy265420]

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.

After having a look at the chat between both of you (Dev and c-cex) everything is very clear the fault is of that from C-Cex as he showed greed too in mode of staking. He is (C-cex)that the responsible for this loss.

[ExD]

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

Your example is not relevant to the case.

Wallet after migration returned addresses that were used before migration, for example:
sc7zK5PrZUbTTfM2ZKrQ3Q6rnxmLtDr858
scSHt3SGSVFuZP6aBP5UiUzYHfWBy5hu7a

After migration and salvaging wallet, it returned the same addresses, presumably in the same order, my bet that's bug is related to key pool queue, it's developer job to determinate exact cause, I'm not going to look through every step to find exact line of code which cause this. My time isn't free and I'm not going to waste it on this, thanks. If someone has better explanation why it was happened and why addresses were reused, you can post your version of events.

[argakiig]

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

Your example is not relevant to the case.

Wallet after migration returned addresses that were used before migration, for example:
sc7zK5PrZUbTTfM2ZKrQ3Q6rnxmLtDr858
scSHt3SGSVFuZP6aBP5UiUzYHfWBy5hu7a

After migration and salvaging wallet, it returned the same addresses, presumably in the same order, my bet that's bug is related to key pool queue, it's developer job to determinate exact cause. If someone has better explanation why it was happened and why addresses were reused, you can post your version of events.

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

I think I know what would have happened though.

As you can see in the pastebin the wallet was corrupted and the most recent backup they had was 8 days prior. When reverting to this backup the keypool was taken back to the previous state. This would allow addresses that had already been assigned to be reassigned.

[cryptodruti]

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

Your example is not relevant to the case.

Wallet after migration returned addresses that were used before migration, for example:
sc7zK5PrZUbTTfM2ZKrQ3Q6rnxmLtDr858
scSHt3SGSVFuZP6aBP5UiUzYHfWBy5hu7a

After migration and salvaging wallet, it returned the same addresses, presumably in the same order, my bet that's bug is related to key pool queue, it's developer job to determinate exact cause. If someone has better explanation why it was happened and why addresses were reused, you can post your version of events.

OK, fucking c-cex everyone that knows anything about cryptos knows that your exchange is shit, and this isn't the first time you have been accused of stealing peoples coins. No one is going to believe anything you say because there has been countless claims of you stealing costumers coins in the past (and deleting their accounts to try to cover it up).

[crazywack]

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.

Got em arg! Not to mention staking customer coins! Lol wouldn't expect anything less from them....

[lpl258]

So LESS coins exist now?

[CryptoPiero]

C-CEX is a scam. I've heard numerous times to trade with caution and here we are again.

[zeerobje]

I feel sorry for the person who lose The best coins ever, but we had also problem in the first weeks of xst one guy lose 150k xst by a  another way.... something with a wallet that i not discuss. I help him to give some coins. So i give also 1000 ssd to that person wo lose a lot on c-cex. Why because i like this coin. I help only one person i know wo it is... But help me wo i will give 1000 ssd....


Sorry for my Englisch

[tx42]

After migration and salvaging wallet, it returned the same addresses, presumably in the same order, my bet that's bug is related to key pool queue, it's developer job to determinate exact cause, I'm not going to look through every step to find exact line of code which cause this. My time isn't free and I'm not going to waste it on this, thanks. If someone has better explanation why it was happened and why addresses were reused, you can post your version of events.

Address generation is deterministic on purpose. That is a feature added to BTC wallets long ago. If you generate address #X from a new private key, it will always be the same address.

Holy smokes, dude. If you are going to review something, know your business.

[edit]

This is how you can take an old backup of a wallet and recover new transactions that produce their own change addresses.

[crazywack]

So LESS coins exist now?

I don't think so... Unfortunately... Users will just be reign used at less than 1/4 value for c-cex's screw up.

[tx42]

C-CEX is a scam. I've heard numerous times to trade with caution and here we are again.

Some people never learn.

[cryptodruti]

So LESS coins exist now?

no, everyone's just mad that their coins doubled.

[CryptoMan2014]

C-CEX is a scam. I've heard numerous times to trade with caution and here we are again.

This is the SONIC thread, please move your scam comments to the right thread.
Dev, next time you release something, can you put down a date and a country? Cause a lot of us where past the 23rd when you released your app. That created some confusion.

[tx42]

C-CEX is a scam. I've heard numerous times to trade with caution and here we are again.

This is the SONIC thread, please move your scam comments to the right thread.
Dev, next time you release something, can you put down a date and a country? Cause a lot of us where past the 23rd when you released your app. That created some confusion.

It's the right thread. C-CEX has effectively caused people to lose SSD coins through incompetence or malfeasance.

Get your shilling for C-CEX on the right thread.

[ExD]

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

I think I know what would have happened though.

As you can see in the pastebin the wallet was corrupted and the most recent backup they had was 8 days prior. When reverting to this backup the keypool was taken back to the previous state. This would allow addresses that had already been assigned to be reassigned.

Addresses should've been taken out from the key pool if they had been used in transaction, blockchain was synced, so queue shouldn't contain those addresses, at least in theory.

[tx42]

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

I think I know what would have happened though.

As you can see in the pastebin the wallet was corrupted and the most recent backup they had was 8 days prior. When reverting to this backup the keypool was taken back to the previous state. This would allow addresses that had already been assigned to be reassigned.

Addresses should've been taken out from the key pool if they had been used in transaction, blockchain was synced, so queue shouldn't contain those addresses, at least in theory.

If synced on the right chain, you mean where the original transactions exist.

They didn't update. The key generation/keypool selection hasn't changed since this lineage of coins was forked from litecoin. This explains so many problems with C-CEX. They don't know what they are doing.

[bangomatic]

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.

Got em arg! Not to mention staking customer coins! Lol wouldn't expect anything less from them....

C-Cex staking coins is just asking for a fork...they know better...  

[argakiig]

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

I think I know what would have happened though.

As you can see in the pastebin the wallet was corrupted and the most recent backup they had was 8 days prior. When reverting to this backup the keypool was taken back to the previous state. This would allow addresses that had already been assigned to be reassigned.

Addresses should've been taken out from the key pool if they had been used in transaction, blockchain was synced, so queue shouldn't contain those addresses, at least in theory.

If you can point to me where this bug is I will correct it as I have stated before. That's the beauty of open source, anyone is welcome to look at it and post changes that can/should be made.

[ExD]

After migration and salvaging wallet, it returned the same addresses, presumably in the same order, my bet that's bug is related to key pool queue, it's developer job to determinate exact cause, I'm not going to look through every step to find exact line of code which cause this. My time isn't free and I'm not going to waste it on this, thanks. If someone has better explanation why it was happened and why addresses were reused, you can post your version of events.

Address generation is deterministic on purpose. That is a feature added to BTC wallets long ago. If you generate address #X from a new private key, it will always be the same address.

Holy smokes, dude. If you are going to review something, know your business.

[edit]

This is how you can take an old backup of a wallet and recover new transactions that produce their own change addresses.

I'm not talking about address generation, I said that the same address has been reused despite it had been used in transaction and shouldn't exist in the queue. Read carefully next time.