Pages:
Author

Topic: [SSD] Sonic - 1st TOR with functional anon send - Steganography based Anon App - page 94. (Read 284877 times)

hero member
Activity: 742
Merit: 500
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.  Cheesy Cheesy Cheesy
hero member
Activity: 742
Merit: 500
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.
ExD
member
Activity: 107
Merit: 10
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.
hero member
Activity: 742
Merit: 500
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;
member
Activity: 117
Merit: 10
Quote
[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
Quote
[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
Quote
[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?
hero member
Activity: 742
Merit: 500
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.
hero member
Activity: 700
Merit: 501
1000% ROI Masternode Coin
CCEX, there is a reason it isn't in the top 10 exchanges... That is all I am going to say.
hero member
Activity: 728
Merit: 500
Quote
[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...
sr. member
Activity: 296
Merit: 250
ExD
member
Activity: 107
Merit: 10

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).
hero member
Activity: 560
Merit: 500
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;
legendary
Activity: 1876
Merit: 1005
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.
hero member
Activity: 742
Merit: 500
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.
hero member
Activity: 742
Merit: 500
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.
ExD
member
Activity: 107
Merit: 10
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.
sr. member
Activity: 658
Merit: 257
★Bitvest.io★ Play Plinko or Invest!

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.
legendary
Activity: 1246
Merit: 1000
ARK Team likes to ban and delete posts in reddit.
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...  Angry
hero member
Activity: 742
Merit: 500

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.
ExD
member
Activity: 107
Merit: 10

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.
hero member
Activity: 742
Merit: 500
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.
Pages:
Jump to: