t1fuV1Et39tZbJHcia64pV22C8HywFR1JpE is my wallet number, couldn’t the attacker send coins to my number ?
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?
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!
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!
@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
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 usingcreaterawtransaction
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 :-
https://zcashnetwork.info/tx/5c4df2d87884f46fc4bcbd722420bb5a7d72843a4a21688e33a7849ea5cab74a
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: https://zcashnetwork.info/tx/5c4df2d87884f46fc4bcbd722420bb5a7d72843a4a21688e33a7849ea5cab74a
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 ) 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.