• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

My coins disappear after darksend mixing

stani83kl

New member
My coins disappear after darksend mixing.

In begining i have ~1600 dash coins start mixing them after 36h i comeack
and see that i have only 130 dash mixed (darksend coins)

Then i run dashcoin-qt -salvagewallet after comand complete i was shoked ... only my balance was 500 dash coins

Please Help me what to do!

edit

I run comand again now i have only 350 coin damm!!

What happend !

My wallet is not encripted please HELP!
 
Last edited by a moderator:
This has never ever happened before !
There sure is a good plan to recover this

Please supply some details
What system
What wallet
....
 
Last edited by a moderator:
i run Debian 8 LXDE and dashcore 0.11.2.23

Download tar from officeial site

It seems that dashcoin-qt -salvagewallet not work.

Im sure my coins are in my wallet.

Someone to tell me how to recover from this ?
 
i run Debian 8 LXDE and dashcore 0.11.2.23

Download tar from officeial site

It seems that dashcoin-qt -salvagewallet not work.

Im sure my coins are in my wallet.

Someone to tell me how to recover from this ?

Do not worry
The pros will be on soon and sort you out
 
Tryed alredy 3 times not help

comand dashcoin-qt -salvagewallet broke my coins :(

Never use this before is fixed!!

When i tryed first time i have ~1600 dashcoins ~130 in dark send

After comand runed one time my walet show me 540 !!!! and ~ 44 in darkcoins

Second run and more lost coin --> balance now is 350

Don`t want to run again!

Someone from support to help me this is ~ 3500 USD lost!!!

Wallet is not encrypted!
 
Hello there,

1) restore procedure
salvagewallet command should create a copy of your current wallet.dat in a file named wallet.timestamp.bak (timestamp is actual timestamp not just the word) on every run inside you datadir folder ( ~/.dash/ by default). If you run 0.11.2.23 you should also have backup folder inside your datadir folder with 10 latest wallet.dat-s backups that wallet creates and rotates automatically on every start.

2) issue itself
That's a very strange behavior that shouldn't happen. Could you please send me debug.log? [email protected]
 
Thx for helping me

I restored my backup fail and now my coins are vidible again :)))

But it seems that comand dashcoin-qt -salvagewallet not work very well.

I will send you logs for shure to help this not happend to other people.


Why mixing coin take so much time ? i read that algoritam require more users that

mixing coins also but this why some auto mixing bots t be funded and be awis online?

Where to read more about how mixing works ?
 
If you run 0.11.2.23 you should also have backup folder inside your datadir folder with 10 latest wallet.dat-s backups that wallet creates and rotates automatically on every start.
I restored my backup file and now my coins are visible again :)))

I knew this would be helpful one day :smile:

Where to read more about how mixing works ?

http://wiki.dashpay.io/display/DRK/Darksend
and
https://www.dashpay.io/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
 
Hello there,

1) restore procedure
salvagewallet command should create a copy of your current wallet.dat in a file named wallet.timestamp.bak (timestamp is actual timestamp not just the word) on every run inside you datadir folder ( ~/.dash/ by default). If you run 0.11.2.23 you should also have backup folder inside your datadir folder with 10 latest wallet.dat-s backups that wallet creates and rotates automatically on every start.

2) issue itself
That's a very strange behavior that shouldn't happen. Could you please send me debug.log? [email protected]
Please tell us how this could happen after you find out. Thanks.
 
Could it be the DS was checked and only DS balance was showing in the Send tab?

In anycase, they can't simply disappear. Proof of that is the backup restored the coins. it's impossible to revert tx. In this case i suspect -zapwallettxes would have cleared the issue
 
crowning thx for info :) if backup function is your work

I send logs to mail hope to be fixed cos -salvagewallet option not work good.

I will read all documentation hope to find answer why mixing coins take so much time.

Some people run some vps as services "masterdobe if i remeber corectly" is that mixing machine

and how this will help to mix faster ?
 
stani83kl thank you so much for reporting this issue and for debug.log you sent me, really appreciate you help.

Well, moli yidakee I have some bad news - I was able to reproduce wallet corruption by salvagewallet command for unencrypted wallet.
Even in freshly salvaged wallet (i.e. no db incompatibilities, wallet was written by the same code version which tries to read it) I have constantly random errors every next salvagewallet run.
Code:
WARNING: CWalletDB::Recover skipping key: Error reading wallet database: CPubKey/CPrivKey corrupt

Good news is I was unable to reproduce any failure for encrypted wallet. I tried my "old" wallet and the one I created and filled with keys specifically for testing and it works fine for me, no issues so far.

Strange thing is that we (Dash) changed nothing in how public key => private key pairs are stored in wallet afaik and I wonder if Bitcoin has the same issues too. I guess I need to compile it, sync (omg.. that will take a looong time :eek:) and try to reproduce this problem. I see nothing wrong/interfering in our code so far btw.

Pinging crowning - I guess you might be interested in that ^^^ info too, please take a note


To whom it may concern. :wink:

Regarding questions about DS mixing speed - we have several problems right now I'm aware of:

1) Wallet hit ORPHAN blocks quite often (could be a day, could be few hours) and can't proceed without restart. Even if your wallet still had no ORPHANs it might be some other wallets who could mix with you but they can't because they stuck. I'm trying to figure it out for almost a week now. I though I've found the problem in our (Dash) code and the solution for it few days ago but it was not enough https://github.com/dashpay/dash/pull/341 I spent last days debugging and trying to catch it - hours or days is quite often in terms of mixing but still too rare to easily debug and sometimes it was "healing" itself, sometimes not. :confused: I think I finally found it now (just a half day ago, still testing) and it's a general Bitcoin node P2P problem, will test a bit more and hope it will be fixed in next version.

2) While I'm intensively debugging problem #1 I see that there are quite a few faulty masternodes on network who are not synced. What happens is when you want to mix you send them collateral and (because they are unaware of tx collateral was created? see problem #1) they reject your collateral and mixing session fails.That doesn't help mixing for sure... We have no solution for this yet, I guess we would need to implement few other PoSe checks to kick such masternodes out of list too.
 
UdjinM6,
This will be interesting, if you spot an error in the bitcoin code that they presumably haven't seen, so basically the encryption gets round a rare error somehow.
 
stani83kl thank you so much for reporting this issue and for debug.log you sent me, really appreciate you help.

Well, moli yidakee I have some bad news - I was able to reproduce wallet corruption by salvagewallet command for unencrypted wallet.
Even in freshly salvaged wallet (i.e. no db incompatibilities, wallet was written by the same code version which tries to read it) I have constantly random errors every next salvagewallet run.
Code:
WARNING: CWalletDB::Recover skipping key: Error reading wallet database: CPubKey/CPrivKey corrupt

Good news is I was unable to reproduce any failure for encrypted wallet. I tried my "old" wallet and the one I created and filled with keys specifically for testing and it works fine for me, no issues so far.

Strange thing is that we (Dash) changed nothing in how public key => private key pairs are stored in wallet afaik and I wonder if Bitcoin has the same issues too. I guess I need to compile it, sync (omg.. that will take a looong time :eek:) and try to reproduce this problem. I see nothing wrong/interfering in our code so far btw.

Pinging crowning - I guess you might be interested in that ^^^ info too, please take a note


To whom it may concern. :wink:

Regarding questions about DS mixing speed - we have several problems right now I'm aware of:

1) Wallet hit ORPHAN blocks quite often (could be a day, could be few hours) and can't proceed without restart. Even if your wallet still had no ORPHANs it might be some other wallets who could mix with you but they can't because they stuck. I'm trying to figure it out for almost a week now. I though I've found the problem in our (Dash) code and the solution for it few days ago but it was not enough https://github.com/dashpay/dash/pull/341 I spent last days debugging and trying to catch it - hours or days is quite often in terms of mixing but still too rare to easily debug and sometimes it was "healing" itself, sometimes not. :confused: I think I finally found it now (just a half day ago, still testing) and it's a general Bitcoin node P2P problem, will test a bit more and hope it will be fixed in next version.
UdjinM6, I just checked my debug.log for the mixing that was done a few weeks ago... and sure enough I also have a bunch of "ORPHAN blocks". Here are the first few in the log:

"2015-05-10 12:42:33 ProcessBlock: ORPHAN BLOCK 1, prev=000000000001ac05091c90e9dd59c1466a9bc4ac64473ecae6e8b87b093d26bc
.....
2015-05-10 12:44:49 ProcessBlock: ORPHAN BLOCK 2, prev=00000000000b843e4c4a53a27bf0fee1b8a856806b0a719a86f5ff4ac9ae5566
.....
2015-05-10 19:49:25 ProcessBlock: ORPHAN BLOCK 0, prev=00000000001461216d5b58bbf67b78fb8758aa42aa472f0d2edefbe67a99e320
.....
2015-05-10 19:49:46 ProcessBlock: ORPHAN BLOCK 1, prev=00000000000a8d6c84c776d4d6acf9bcbe2bc68926d59d553d75a1609c510601
.....
2015-05-10 19:51:22 ProcessBlock: ORPHAN BLOCK 0, prev=00000000001018216b3af483ff8e61a4daac0657af14082e6a808dbb2a4ca710
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 0, prev=00000000000afb670857ce8de1ca2bab638a8305acb084524d783689f0aedc05
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 1, prev=00000000000eff3b7d0ecdb4b4296bc9a1de4177b8a042c6f6f25055d9148b1d
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 2, prev=0000000000077d6df50e0539bb23b57127fdbdf686f0cd5deff88b1b6b040f02"

Note the last 3, they happened at the same exact time. These are just a few, there's still a bunch more down the log.

2) While I'm intensively debugging problem #1 I see that there are quite a few faulty masternodes on network who are not synced. What happens is when you want to mix you send them collateral and (because they are unaware of tx collateral was created? see problem #1) they reject your collateral and mixing session fails.That doesn't help mixing for sure... We have no solution for this yet, I guess we would need to implement few other PoSe checks to kick such masternodes out of list too.
Is this why my wallet got stuck a lot because the denom amounts got locked and would not open unless I restarted the wallet or unlocked them in the Coin Control?

ALSO, Do we need to stop mixing for now until this is resolved?
 
UdjinM6, I just checked my debug.log for the mixing that was done a few weeks ago... and sure enough I also have a bunch of "ORPHAN blocks". Here are the first few in the log:

"2015-05-10 12:42:33 ProcessBlock: ORPHAN BLOCK 1, prev=000000000001ac05091c90e9dd59c1466a9bc4ac64473ecae6e8b87b093d26bc
.....
2015-05-10 12:44:49 ProcessBlock: ORPHAN BLOCK 2, prev=00000000000b843e4c4a53a27bf0fee1b8a856806b0a719a86f5ff4ac9ae5566
.....
2015-05-10 19:49:25 ProcessBlock: ORPHAN BLOCK 0, prev=00000000001461216d5b58bbf67b78fb8758aa42aa472f0d2edefbe67a99e320
.....
2015-05-10 19:49:46 ProcessBlock: ORPHAN BLOCK 1, prev=00000000000a8d6c84c776d4d6acf9bcbe2bc68926d59d553d75a1609c510601
.....
2015-05-10 19:51:22 ProcessBlock: ORPHAN BLOCK 0, prev=00000000001018216b3af483ff8e61a4daac0657af14082e6a808dbb2a4ca710
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 0, prev=00000000000afb670857ce8de1ca2bab638a8305acb084524d783689f0aedc05
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 1, prev=00000000000eff3b7d0ecdb4b4296bc9a1de4177b8a042c6f6f25055d9148b1d
.....
2015-05-11 18:46:09 ProcessBlock: ORPHAN BLOCK 2, prev=0000000000077d6df50e0539bb23b57127fdbdf686f0cd5deff88b1b6b040f02"

Note the last 3, they happened at the same exact time. These are just a few, there's still a bunch more down the log.


Is this why my wallet got stuck a lot because the denom amounts got locked and would not open unless I restarted the wallet or unlocked them in the Coin Control?

ALSO, Do we need to stop mixing for now until this is resolved?

Nope, inputs locking is another problem I forgot to mention, it's not connected to ORPHANs...

It's safe to mix now but wallet could stuck sometimes because of ORPHANS and/or mixing could be incomplete in case of inputs locking.
 
Good news is I was unable to reproduce any failure for encrypted wallet. I tried my "old" wallet and the one I created and filled with keys specifically for testing and it works fine for me, no issues so far.

Strange thing is that we (Dash) changed nothing in how public key => private key pairs are stored in wallet afaik and I wonder if Bitcoin has the same issues too. I guess I need to compile it, sync (omg.. that will take a looong time :eek:) and try to reproduce this problem. I see nothing wrong/interfering in our code so far btw.

Pinging crowning - I guess you might be interested in that ^^^ info too, please take a note

UdjinM6 , I have a full node laying around here, so I can do some Bitcoin tests.

Is all I have to do create an not-encrypted wallet and start it twice with -salvagewallet?
 
UdjinM6 , I have a full node laying around here, so I can do some Bitcoin tests.

Is all I have to do create an not-encrypted wallet and start it twice with -salvagewallet?
I believe you need non-encrypted wallet with few thousands addresses/txes, not sure about this yet - small wallets (100-200 addresses) looks ok so far. I had 30k+ addresses in wallet on Dash mainnet that had this error. Now I'm playing on bitcoin testnet with 3k+ addresses/txes wallet (sent hundreds small txes from one wallet to another few times by rpc first to generate used change addresses) and I got the same error after salvaging it on bitcoin 0.10.2. Code there is literally the same as for bitcoin 0.9 so it should apply to Dash 0.11 and 0.12 as well imo. However balance didn't change after salvaging but I guess I just need to split funds to lots of receiving addresses instead of sending to the same one to emulate hundreds of utxo from DS mixing properly.
 
I have only 4 address in my dash wallet so i think that is not the problem.
well...you have many more... if you mixed your coins go to debug and write this command: listaddressgroupings
you`ll see how many addresses you have already there ;)
 
Back
Top