"Maybe if you weren't such a whiny bitch people would acknowledge you." is a direct quote form your previous post, and is pretty straightforward example of dismissing newcomers, isn't it?
And I'm one of the people who needed direct intervention from a dev on this thread after having no success with a linux wallet. They discovered they had made a mistake, admitted it, and provided me with a solution, which I'm satisfied with. But that help was not available on the website. Glad you had first time success with a wallet. Hope you 'LOVE' that I didn't.
I just read the backposts and saw this. I also found where the dev helped you: https://bitcointalk.org/index.php?topic=681725.msg8920755#msg8920755A dev of a 1 M market cap coin took the time to make a linux build on your request and you want out that coin because it's getting trolled too much for your sensibilites? Man I bet you lose money at this game. |
|
|
|
I fucking hate this thread. What a vicious, shitty little community.
It's been non stop trolls here from butthurt cloak fanboys. They do it on purpose to drive wussies like you out. |
|
|
|
Wow, such a hype about this coin: reddit, voting, long run, mintpal, etc. and still impossible to download an official wallet for the last 4 days. WTF?! I asked in twitter, I asked for a wallet here, and nobody seems to give a fuck. The only download option for the most hyped coin is some nobody on reddit with a questionable link. Put your shits together. Unbelievable...
Koontas is a dev here to mac: https://mega.co.nz/#!n1l3QAKY!Hgoir-IZn1Mx8VKj0rfZlr4UnVkGGoafIlbywPeWZn0 and here to windows: www.short.cc/Install-Stealth-Qt-1.2.0.2-Win.exeAnywhere to check the official checksum? Or I should just trust a stranger on the net with a precompiled binary? Is this the best this "community" can provide? They are both signed executables. Run the windows exe and you'll get a yellow shield, just like you do with adobe acrobat. |
|
|
|
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. |
|
|
|
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.  |
|
|
|
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. |
|
|
|
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: 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? 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? 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.
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;
}
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;
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
C-CEX is a scam. I've heard numerous times to trade with caution and here we are again.
Some people never learn. |
|
|
|
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. |
|
|
|
Haven't we been here before with exchanges blaming code i.e. Mark Karpeles.
GOXedC-CEXed |
|
|
|
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. |
|
|
|
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. 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
 |
|
|
|
 If you lose money at C-CEX, it's your fault. |
|
|
|
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. |
|
|
|
C-cex.com Scamed their customers with SSD. As far as I know, about 20 btc worth in SSD has been "lost" . Just to tell you guys, be carefull with this exchange ! Scam alert !
I wonder if these will be recoverable??? If not, won't that have an impact on the outstanding # of coins? Less coins, more value... Anyone know the status on C-cex.com SSD lost coin recovery? Dev stated they did not update, so it is all C-cex to blame for the incident. Yes. Anyone who trades on C-CEX is in danger of losing coins. It happened to me, 1 BTC worth. |
|
|
|
|
Show Posts
