Help,please,coins disappeared!


t1fuV1Et39tZbJHcia64pV22C8HywFR1JpE is my wallet number, couldn’t the attacker send coins to my number ?:wink:


no, the transaction is to a shielded wallet number beginning with z, yours is a transparent one as it begins with t. Just in case it was an attacker of course.

@adityapk00 is the dev/creator of the wallet, so i would wait for his final conclusion, but i allready had suspected after reading your first post that it mostly is a compromised wallet, but i’am not an expert for zec wallets.

Did you access/install the wallets bevor on other PC’s? Cell phone? Accessed from a shared PC maybe? Do other persons have access to your devices? Did you check your PC/device log files to see if someone has access it? Any info could be helpfull…

What OS version is this where it writes in russian “free version, not for commercial use?” just out of curiousity what OS and device you are running.


I don’t think a corrupt wallet.dat can result in an outgoing transaction. It can only cause corrupted balances, which can usually be fixed with a rescan.

Another reason is that with Zcash, transactions have a expiry height, so you cannot send a transaction unless zcashd is running and synced. In this case, since the wallet and zcashd was not running on Apr 5th, the most likely explanation is that the transaction was created from outside the machine, which means that the private key was most likely compromised.


I looked at the transaction link you posted and it appears that 100% of the funds went as a mining fee. Maybe you entered the amount in the fee box by accident? :frowning:


I would definitely consider the private key of address t1fuV1Et39tZbJHcia64pV22C8HywFR1JpE compromised. You should never use this address again.

Create a new address from within ZecWallet and don’t share it with any other app or device.


Note that if the address was compromised because the wallet.dat was stolen, generating a new address in the same wallet.dat is a bad idea. A pool of around 100 transparent addresses is cached inside wallet.dat, so until that pool is exhausted, an adversary that steals a wallet.dat will “generate” the same addresses as the user. Meanwhile, Sapling addresses are deterministically-generated from a seed, so if the wallet.dat is stolen, the adversary will always be able to generate every future address that the user would.


Good info, i personally wasn’t aware of that pool of 100 transparent adresses cached!


It’s inherited from Bitcoin Core:


Just out of curiousity, is this optimal for Zcash? Or what is the reason this wasn’t changed/modified/enhanced/whatever?


I am glad that you noticed it, also drew attention to it, first began to doubt, but then rechecked, and realized that the mining commission is fixed, and it is impossible to change it!


Dear adityapk00, thank you for your help, but the problem remains unsolved! Unfortunately, my message limit has been reached, and I could not write for 15 hours! Can this screenshot help solve the problem? How can the mining commission be 100% , if the wallet has a fixed rate of 0.0001, and it is impossible to change it in this version of the wallet! And even if it was an intruder, how could he address his wallet address to the commission and specify 100%? And why he didn’t steal everything, left me 3.5 coins if you think my wallet was hacked …!


str4d, is it possible that the commission was 100%? How could an attacker do this ???


@enerdjizer2008 Sorry to hear that your message limit was reached, I have bumped your trust level so you can post more.

If you have any other issues please message me or the rest of the mod team @ moderators


This now looks more like a bug or mistake than an attack :slightly_frowning_face:

An adversary would have sent the funds to some other address, because they have no way to ensure they would gain any transaction fees. If the transaction definitely has no outputs at all, then this could be:

  • A transaction created manually by wallet software using createrawtransaction etc. that has mistakenly set no outputs, resulting in all the inputs being used as fee.
  • A bug in some piece of the software stack that had access to the key material.

Are you certain that you did not create any transactions on or shortly before April 5th? Or interact with your wallet in some other way?

Assuming the Zchain output is correct, and your inputs were entirely spent as fee, a possible avenue to recover your funds would be to contact the mining pool that mined the block your transaction was part of, and ask them to send it back to one of the input addresses.

EDIT: See below, there is a shielded output in the transaction, so ignore this post.


I checked the tx on different explorer, it shows the fee as 0.0001 and one shielded output.

Here’s the link :-


Has it been updated for Sapling? Here is the result of decoderawtransaction

  "txid": "5c4df2d87884f46fc4bcbd722420bb5a7d72843a4a21688e33a7849ea5cab74a",
  "overwintered": true,
  "version": 4,
  "versiongroupid": "892f2085",
  "locktime": 0,
  "expiryheight": 510130,
  "vin": [
      "txid": "48105149746230321d510147f5b2b32d3fc9014e3863a38c05918a4144e3e69f",
      "vout": 0,
      "scriptSig": {
        "asm": "30450221009be69350350d2dddfc5aefcf62589d8eb2932579da1d583ec6ac7eebf3a7313f02206199fd0bfa210704f2e02d188c0898cfc138a96df688f02abe60adb66d43ab07[ALL] 02bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a",
        "hex": "4830450221009be69350350d2dddfc5aefcf62589d8eb2932579da1d583ec6ac7eebf3a7313f02206199fd0bfa210704f2e02d188c0898cfc138a96df688f02abe60adb66d43ab07012102bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a"
      "sequence": 4294967295
      "txid": "3b585bb2e7d7643ddc5234ec9eedeec0080ac61a5f624171edb9bbb57dd53e67",
      "vout": 1,
      "scriptSig": {
        "asm": "3044022029f88e604a998b598c48dc5e77bcbc6d567501967fd90aa820308831d500936b02202675514f64a724fc5d27ca28b364c0161950d294ddb225da56adbadf0fc1c18c[ALL] 02bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a",
        "hex": "473044022029f88e604a998b598c48dc5e77bcbc6d567501967fd90aa820308831d500936b02202675514f64a724fc5d27ca28b364c0161950d294ddb225da56adbadf0fc1c18c012102bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a"
      "sequence": 4294967295
      "txid": "f107cd18a1ec3e2dc3c9ba640cb5c5806c59d8fbefcadd190bbf3dcd4af3311c",
      "vout": 2,
      "scriptSig": {
        "asm": "304402202fd952bd735fa18b7f2474bbb69d4a1aeebb70e2f11ab780b14f65e89b9bdec002201eab6f5609b2d5d72b3900c18ca9f2e6c1cbe512c04095869eb9cae2fb6e3722[ALL] 02bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a",
        "hex": "47304402202fd952bd735fa18b7f2474bbb69d4a1aeebb70e2f11ab780b14f65e89b9bdec002201eab6f5609b2d5d72b3900c18ca9f2e6c1cbe512c04095869eb9cae2fb6e3722012102bdc79ddd76626d1cdc087ba587479ac037d90d5d7710d936944acbc33164ee2a"
      "sequence": 4294967295
  "vout": [
  "vjoinsplit": [
  "valueBalance": -10.06611282,
  "vShieldedSpend": [
  "vShieldedOutput": [
      "cv": "1b589bdd6b02fa316739c2c40fd6327fe992fe2ce47657679e7ce556538e1ef0",
      "cmu": "3cf37434301d93fa2bc64e56e5f8cc2067d31170f1586711683fafdcc88dfab3",
      "ephemeralKey": "6e090a5302884c26b2272736a25513772cbe8987166211d9ed99d67a8a525475",
      "encCiphertext": "a54c450bfc8d8a69f0715f666877c0ee956e5a312d86ae7272dcb49fd92e48f0307d337ac9392536d572f52b89d186d85bf11db69bb8cbe9e4408fff9984d8db3881f1c10b719f980e8fa709c2009411cda33dc3f5a5ea0e6429296b2c79e8ad650f30319eedd83948c7865ce19cb3e61fd04622c4dcf54d8c1be499d0473eaa9be7c865983e77434a5433cfb2da1f0a1b219a30d2e80a3b52435ca1839fecc30ec1230618c980714e2028c811ec81ccbdf46d84d7b5c75c17a26ac172e95ba74356640609d66b9035759cccbb75014f8b3bbf43089bdbb8b2dcd4417ae36dc8a826ec157799eecaf685fba4463d5010117a291dc23c520aacfb482023d5f97dfdc6d39d1c2f52fb9cfef271137b352557cbcd0f1ad0b9511bf01ccbeab9f91db4fc8c0880f5b37ff1951528f30fbc269c9aa8cf2dcebfd2339918975ced68e10404ea81c7e78a2a35c0403e6d5fb1120d07c388b879280de07cd6d78cee1d139951d0cb1332aba48b033aa2d39eaa3b0898140d1adb7ad32b1c8cee7dbec0805b057e52e9c60219229c52886ddc4a28b55b297afd01e6fedc0c784baaa4a19948e211b5124817e62a33cde655102e6e159ae33a639ce3dbe4a71a55c50c89a7413b8adbbe5d718263830e03de74b4dd8e234fa0f15cee8ad4e8d1f5e7dcb982e11cbfc5353a65f35a6a6c1368382c51e6f0f1e0f4aca25e463f61571f604eb2fe0a11a6dd64503a19b889b584d14c92fa48dfbbaaf0392749004328410b6ac3f361cc0ed92a25e83bb8034132ae352f8f57ef0ec38ed1831cefde03b9bb3a8b382947c9",
      "outCiphertext": "bccf5001acce00d251a5f1821da03a504f9f4d749437cc7e10609b0a4f3cc9a37e6e6ddc268fafaeefa5f821e5b0246a28787a216c752e11a09c9efe117ffeb59b3d6428c62e73c38b6cb6276a06427a",
      "proof": "964b9c49ddc2f3217699d61bc185e8d14af1f113cc2ce9a9db6b62ab91ad50028560d934caa5170f4106e4e5cdb738ccad190971e709d63f1b60111fbe0b91709c291b77a8ce46698c0fdd3950f01b7e440b606d0cfd9be8fbd3566c14df7a8303e517e4f183e6af3aabb3afaf028330dfa280d08fafbb95d98e9068d3f8356f138791d94db153af27a8856d3b7df665a02bcb515362f3bf18f5d3ff8236e191981cb4bae11468033bdd3cf55f8a4487ffb03a4355b592dcf6c3f974fdb304e2"
  "bindingSig": "07a130bca51ca417141e4367911613e1f095bb6ece1b3b732ee71ba0ca6a68546f8414b5585e67c6d6d1949407bb5cc464a333a6da380a394b0a2e4fe3307604"

edit looks like @ChileBob pointed this out in the post above but see:


Undeleted… wasn’t completely sure at the time & didn’t want to add confusion.


So I’m not sure either (as indicated by all those edits :confounded:) as decoderawtransaction doesn’t have updated documentation for Sapling but summing those inputs is 10.06621282 and the valueBalance has been decreased by 10.06611282 so I think that latter explorer is correct and it’s a 0.0001 mining fee and the rest has been sent to a Sapling address.


It looks like the ZCHAIN explorer is wrong, and that the fee was in fact 0.0001 ZEC and the rest was sent to a sapling address.

I would definitely consider the entire wallet.dat compromised, and all the addresses within it as well.


Thanks again for all the help!The situation is starting to clear up,but what is Public input?