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

[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.

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.

Addresses are taken from the keypool. The keypool caches addresses from a deterministic generator. They re-generated the same keypool twice, probably by using their trading database to construct new transactions before the chain was fully synced.

Case closed.

[1714815227]

1714815227

[1714815227]

1714815227

[1714815227]

1714815227

[1714815227]

1714815227

[tx42]

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.

And if you knew as much as you pretend to, you'd show a diff of the relevant parts of the code.

[boopy265420]

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.

Addresses are taken from the keypool. The keypool caches addresses from a deterministic generator. They re-generated the same keypool twice, probably by using their trading database to construct new transactions before the chain was fully synced.

Case closed.

+1 very logical and same simple explanation . I think that should accept now.

[Altcoin4life]

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.

Addresses are taken from the keypool. The keypool caches addresses from a deterministic generator. They re-generated the same keypool twice, probably by using their trading database to construct new transactions before the chain was fully synced.

Case closed.

+1 very logical and same simple explanation . I think that should accept now.

This assumes a lot, sorry but it does. Do you know this without a shadow of a doubt "They re-generated the same keypool twice, probably by using their trading database to construct new transactions before the chain was fully synced." Because you really don't know thats how it worked.

For ExD is this the piece of code you were looking for?


bool CWallet::GetKeyFromPool(CPubKey& result)
{
    int64_t nIndex = 0;
    CKeyPool keypool;
    {
        LOCK(cs_wallet);
        ReserveKeyFromKeyPool(nIndex, keypool);
        if (nIndex == -1)
        {
            if (IsLocked()) return false;
            result = GenerateNewKey();
            return true;
        }
        KeepKey(nIndex);
        result = keypool.vchPubKey;
    }
    return true;
}
в ssd вcтaвлeнo:
bool CWallet::GetKeyFromPool(CPubKey& result, bool fAllowReuse)
{
    int64 nIndex = 0;
    CKeyPool keypool;
    {
        LOCK(cs_wallet);
        ReserveKeyFromKeyPool(nIndex, keypool);
        if (nIndex == -1)
        {
            if (fAllowReuse && vchDefaultKey.IsValid())
            {
                result = vchDefaultKey;
                return true;
            }
            if (IsLocked()) return false;
            result = GenerateNewKey();
            return true;
        }
        KeepKey(nIndex);
        result = keypool.vchPubKey;
    }
    return true;

[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.

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.

Hard to trace this bug and it will probably take loads of time to find it, it might be not related directly to your code and could be introduced in coin you forked from. I'm not part of the community, my participation was limited to find probable cause and ensure it wasn't intentional(it wasn't).

[BillTech]

thanks exd

[MemoryShock]

[9/20/2014 6:57:10 AM] argakiig: how long was your vacation?
[9/20/2014 6:57:33 AM] C-CEX.com: 3 weeks
[9/20/2014 6:58:00 AM] C-CEX.com: "blocks":21599 synced?
[9/20/2014 6:58:01 AM] argakiig: and you didn't have anyone checking anything while you were gone. TBH doesn't seem that smart to me

Sums it up for me.

Kind of bad form to try and pass off ineptitude on the dev...plenty of examples in the pastebin that indicate that argakiig was the one doing the directing.

As well, there is no way that one can trade on C-Cex now with any kind of confidence...

[dandruff1138]

CCEX, there is a reason it isn't in the top 10 exchanges... That is all I am going to say.

[tx42]

Hard to trace this bug and it will probably take loads of time to find it, it might be not related directly to your code and could be introduced in coin you forked from. I'm not part of the community, my participation was limited to find probable cause and ensure it wasn't intentional(it wasn't).

Dude, do your due diligence and research a topic before you spout off about it. Someone already pasted the code, not that you would understand what you are seeing.

[Zikka]

[9/23/2014 7:26:53 AM] argakiig: just to confirm though all coins are gone corret?
[9/23/2014 7:27:34 AM] C-CEX.com: yes, I have to have 1464924 SSD coins
[9/23/2014 7:27:46 AM] C-CEX.com: but wallet balance is 8.32

[9/20/2014 6:57:10 AM] argakiig: how long was your vacation?
[9/20/2014 6:57:33 AM] C-CEX.com: 3 weeks
[9/20/2014 6:58:00 AM] C-CEX.com: "blocks":21599 synced?
[9/20/2014 6:58:01 AM] argakiig: and you didn't have anyone checking anything while you were gone. TBH doesn't seem that smart to me

[9/23/2014 8:52:26 AM] argakiig: http://puu.sh/bKLiy/bbf27f9597.txt
[9/23/2014 8:52:41 AM] argakiig: that is a listing of the balances on the addresses you sent me
[9/23/2014 8:52:47 AM] argakiig: shows transactions
[9/23/2014 8:53:25 AM] argakiig: you were staking users coins ...
[9/23/2014 8:59:29 AM] C-CEX.com: yes, so what's in result?
[9/23/2014 9:00:40 AM] argakiig: still looking into it
[9/23/2014 9:00:58 AM] argakiig: and I had asked you when the wallet was setup to not stake customers coin
[9/23/2014 9:01:01 AM] argakiig: that's dirty

Holy shit! CCEX, what are you doing??? 3 weeks vacation??? You lost 1.5 millions of SSD!
Maybe you should cancel all your next vacations and make a full BTC refund to all your customers affected to your negligence?

[tx42]

This assumes a lot, sorry but it does. Do you know this without a shadow of a doubt "They re-generated the same keypool twice, probably by using their trading database to construct new transactions before the chain was fully synced." Because you really don't know thats how it worked.

For ExD is this the piece of code you were looking for?

Why are you asking him? It would take him "hours" to understand it.

Let's look at this code and see where these two snippets deviate (pasted at the bottom of this post).

The difference between the two is the potential for "reuse". Let's see where that function is called in the entire codebase:

Code: (grep output)

init.cpp:        if (!pwalletMain->GetKeyFromPool(newDefaultKey, false))
main.cpp:            pwalletMain->GetKeyFromPool(mapReuseKey[pfrom->addr], true);
rpcwallet.cpp:    if (!pwalletMain->GetKeyFromPool(newKey, false))
rpcwallet.cpp:    if (!pwalletMain->GetKeyFromPool(newKey, false))
rpcwallet.cpp:        if (!pwalletMain->GetKeyFromPool(account.vchPubKey, false))
wallet.cpp:                if (GetKeyFromPool(newDefaultKey, false))

Hmm. Not much thinking required here. The only place where "reuse" is true is in main.cpp. When does that happen?

Code: (main.cpp snippet)

    else if (strCommand == "checkorder")
    {
        uint256 hashReply;
        vRecv >> hashReply;

        if (!GetBoolArg("-allowreceivebyip"))
        {
            pfrom->PushMessage("reply", hashReply, (int)2, string(""));
            return true;
        }

        CWalletTx order;
        vRecv >> order;

        /// we have a chance to check the order here

        // Keep giving the same key to the same ip until they use it
        if (!mapReuseKey.count(pfrom->addr))
            pwalletMain->GetKeyFromPool(mapReuseKey[pfrom->addr], true);   <<== HERE ###

        // Send back approval of order and pubkey to use
        CScript scriptPubKey;
        scriptPubKey << mapReuseKey[pfrom->addr] << OP_CHECKSIG;
        pfrom->PushMessage("reply", hashReply, (int)0, scriptPubKey);
    }

Interesting, what function is this part of?

Code: (ProcessMessage)

bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)

So the only time this difference is applicable is when a different node (different computer) makes a message called "checkorder".

The RPC commands are different from peer messaging. RPC commands are done in the appropriately named module called "rpcwallet.cpp". So this "reuse" flag does not apply to RPC commands as ExD might claim upon seeing but not understanding this code.

Code: (unknown source)

bool CWallet::GetKeyFromPool(CPubKey& result)
{
    int64_t nIndex = 0;
    CKeyPool keypool;
    {
        LOCK(cs_wallet);
        ReserveKeyFromKeyPool(nIndex, keypool);
        if (nIndex == -1)
        {
            if (IsLocked()) return false;
            result = GenerateNewKey();
            return true;
        }
        KeepKey(nIndex);
        result = keypool.vchPubKey;
    }
    return true;
}

Code: (Sonic)

bool CWallet::GetKeyFromPool(CPubKey& result, bool fAllowReuse)
{
    int64 nIndex = 0;
    CKeyPool keypool;
    {
        LOCK(cs_wallet);
        ReserveKeyFromKeyPool(nIndex, keypool);
        if (nIndex == -1)
        {
            if (fAllowReuse && vchDefaultKey.IsValid())
            {
                result = vchDefaultKey;
                return true;
            }
            if (IsLocked()) return false;
            result = GenerateNewKey();
            return true;
        }
        KeepKey(nIndex);
        result = keypool.vchPubKey;
    }
    return true;

[ExD]

Hard to trace this bug and it will probably take loads of time to find it, it might be not related directly to your code and could be introduced in coin you forked from. I'm not part of the community, my participation was limited to find probable cause and ensure it wasn't intentional(it wasn't).

Dude, do your due diligence and research a topic before you spout off about it. Someone already pasted the code, not that you would understand what you are seeing.

It piece of code from Skype chat between me and C-CEX, it was removed from bitcoin long ago, but remain present in litecoin forks and litecoin itself. Didn't jump into conclusions yet, but found some evidence it could cause behavior with the key pool: https://github.com/bitcoin/bitcoin/pull/2904 . In that case allmost all litecoin forks are affected, just blowed up on SSD.

[tx42]

It piece of code from Skype chat between me and C-CEX, it was removed from bitcoin long ago, but remain present in litecoin forks and litecoin itself. Didn't jump into conclusions yet, but found some evidence it could cause behavior with the key pool: https://github.com/bitcoin/bitcoin/pull/2904 . In that case allmost all litecoin forks are affected, just blowed up on SSD.

Look at my analysis. fReuse is always false except in one case, when a peer sends the message "checkorder".

It's false everywhere else and ABSOLUTELY NOT RELEVANT to RPC commands.

[edit]

Time to find a new red herring ExD.

[tx42]

It piece of code from Skype chat between me and C-CEX, it was removed from bitcoin long ago, but remain present in litecoin forks and litecoin itself. Didn't jump into conclusions yet, but found some evidence it could cause behavior with the key pool: https://github.com/bitcoin/bitcoin/pull/2904 . In that case allmost all litecoin forks are affected, just blowed up on SSD.

And, I debunked your stupid ass before you even made the claim. 

[ExD]

The RPC commands are different from peer messaging. RPC commands are done in the appropriately named module called "rpcwallet.cpp". So this "reuse" flag does not apply to RPC commands as ExD might claim upon seeing but not understanding this code.

I checked where reuse was used, I'm aware that it was called with "false" param and that's why I haven't pasted code that Altcoin4life pasted in the thread. But you seems to be smartass telepath here, assuming lots of things about what people think or understand.

[tx42]

The RPC commands are different from peer messaging. RPC commands are done in the appropriately named module called "rpcwallet.cpp". So this "reuse" flag does not apply to RPC commands as ExD might claim upon seeing but not understanding this code.

I checked where reuse was used, I'm aware that it was called with "false" param and that's why I haven't pasted code that Altcoin4life pasted in the thread. But you seems to be smartass telepath here, assuming lots of things about what people think or understand.

I understand enough: you don't do your research before you spout off. That's all I need to know.

[Autodidact]

Well, I think I know what is going on here.  I'm thankful for tx42, the dev, all the people who have helped, and I will be staying far away from CCEX!!

Can't wait to see more detail/instruction on this app!  I'd like to know more about it.

[crazywack]

Well, I think I know what is going on here.  I'm thankful for tx42, the dev, all the people who have helped, and I will be staying far away from CCEX!!

Can't wait to see more detail/instruction on this app!  I'd like to know more about it.

+1 looking forward to POC and more details of the app!

[hrshak462]

Tough day.  Hopefully everything works out.  The app looks fairly fascinating.

[whymine]

Downloaded your android app but encounter some issues.

How to send SSD coin to android when no SSD address on wallet?
What is the 2FA for ?

On Window Wallet, an error message appear.

The procedure entry point of EVP_aes_128_ctr could not be located in the LIBEAY32.dll  ??

SonicVortex has finally arrived

http://puu.sh/bLLeq/db62ad8b39.jpg   http://puu.sh/bLLfl/4253a555ab.jpg

Android App (To follow on Playstore shortly)

Accompanying QT
Windows Manual
Windows Automatic
Mac DMG

Source

Relays
Source
Windows
Mac Inbound Tomorrow

Jar Needed for Relay
F5-Steganography Library

Directions and Daemons are forthcoming


SonicVortex is a way to hide encrypted transactions by steganography.
You take a picture, author a transaction, then SonicVortex embeds the encrypted transaction in a picture.  It uses the f5 steganography algorithm, which uses matrix encoding to hide the picture, making it almost impossible to detect that any hidden communication is present.
Moreover, the encryption is state-of-the-art AES/GCM encryption, suitable for banks and governments. So even in the highly unlikely event that any communication becomes suspected, it is impossible for an adversary to ascertain the nature of the communication. Thus, your transaction is hidden and protected from even the most powerful adversaries.
Additionally, AES/GCM protects against any changes to the encrypted, hidden transaction. If just one pixel of the picture is changed, it will be detected and the transaction rejected.