I believe this is another instance of the same wif key issue. The user describes it starting with a 5, just like this. The discord link is to the original discussion as mentioned above
I have a question: what information can be extracted from a ātransaction IDā when it involves two shielded addresses?
1 Like
Hi,
I am trying to send 50 ZEC from my ledger and I see that i would be charged 4 ZEC in fees! Those 50 ZEC in my wallet come from mining and most mining transactions received were 0.1 zec but some are only 0.01ZEC. Do you think I would be charged 4 ZEC because of all those UTXO in my wallet? Is there a way to avoid those crazy fees?
Thanks
Zip 317 fee rules dictate that every note input (or output, whichever theres more of (we call them actions)) costs 0.00005000. To incur a fee of 4 zec, the tx would combine ~80,000 notes which is way off. If all the notes were 0.01 of the 50, then it actually should only be a 0.25 fee.
This is because Ledger uses an older fee mechanism based on the tx size and not the most recent changes to consensus rules. You can try importing your Ledger seed into Zkool or Ywallet which support proper fees and move the funds from out of there.
2 Likes
@ceb9ceb4ceb9cf89cf84 Txid just points to the transaction on chain. The only information revealed in a full shielded tx is the Fee and the number of inputs/outputs that went into the tx.
A partially shielded tx is when funds move between Sapling and Orchard. Same as above except you also see the amount, per the turnstile. Shielded addresses do not appear on chain, in any instance.
Forgive me for the beginner questions. So if I use an Orchard address and transfer to a unified address, the transaction ID doesnāt show anything? Isnāt it possible to know the wallet or the amount? In a transaction like this, what information can be collected?
The term āUnified addressā can be confusing. Usually it refers to an encoding of multiple addresses like Transparent+Sapling+Orchard combined into one great, big U address. But, single Orchard addresses by themselves are still also sometimes called Unified. The walletsā mechanics of automatically selecting which address to send to, by default, will always select Orchard and so the terminology generally works, though its good to be aware that we (currently) have 3 main adress types and 6 ways (+ 1 less common way for transparent only) of encoding combinations of them: S, O, T+S, T+O, S+O, T+S+O.
Ok, Orchard to Unified implies Orchard to Orchard and correct, it doesnāt show anything related to your amount transferred, addresses or wallet info. Only the fee value, the amount of notes (not their values) and obviously a timestamp. All the other info amounts to encrypted gibberish. The Memo field applies to shielded txs only and is never visible on chain, you would need a view key. Thereās no memo functionality with txs with any transparent component (some folks are using this OP_RETURN thing for the Near bridges to send text but thats transparent).
But, as you can see, some unified addresses do not have an Orchard address (called āReceiversā) and so the wallet would not be able to automatically select it, like mentioned, and it would select Sapling instead. Same thing except now the value transferred is visible. Still, all other info is encrypted, still far better than transparent (still!). Wallets sometimes have settings for receiver preferences and may otherwise warn before you make a sub-optimal tx.
You can always check the receivers of a unified address with a supported block explorer. Just paste the address in the search bar
1 Like
hey so thereās no way to restore from a 5K key? did you find a solution?
1 Like
Not for now.
Iām waiting for a response in the zec forum.
Anyway I think there should be an update which allows to import such private keys.
2 Likes
The problem, to my understanding, is that the key you received is āuncompressedā, whereas the key that librustzcash wants is ācompressedā. The main issue is core developer bandwidth, they are extremely indisposed currently due to other priorities but hopefully can address this soon.
1 Like
NEED: Someone to run one z_sendmany command
I have 270,000 UTXOs (0.1457 ZEC) that need shielding.
Private key and z-address ready.
Command:
zcash-cli z_sendmany āt1dRdgyJcxpwF57HNToszQFPi8EPTNkhbfsā ā[{āaddressā: āzs14knah2pxeq5svcvr6v24n2zcztu4c3paeaqw9mf3emutx67esq3gufxz62ha5cyw4jsg5f09594ā, āamountā: 0.1457}]ā
Will tip 0.03 ZEC (~$8-9). Takes 20 minutes.
That transaction fee for combining that many notes will be 13.5 zec according to zip317 and the current base action fee 0.00005 x 270k.
Also, I highly doubt a tx with that many notes will fit in a single block.
2 Likes
shielding coibase deposits cost nothing, I thought
Hi!
I have an old wallet.dat file from 2017 which I canāt run on the newest Zcash version. I get an error saying that the wallet file is corrupt and I know it isnāt, as I can open it and read the content. Is there any way of salvaging this wallet, as it has Zcash in it?
Thanks!
If you can open and read the file, then it may be possible for you to extract the private keys, re-import them into a fresh zcashd and rescan. zcashd also has a āsalvagewallet flag that you could attempt.
Thanks @Autotunafish!
I have tried -salvagewallet, but I always get an error that a new wallet backup file canāt be created (although permissions are fine).
Failed to rename wallet.dat to wallet.1760186584.bak
Is there any other way?
1 Like
My initial thought was maybe you do not have permissions to write and it was suggested that you check to see if you have write permission in the parent directory.
hey all, i am trying to create a simple transparent tx and testing out things before i dive full fledged in to building. I am facing numerous issues while broadcasting. I am not sure where i am going wrong.
These are my logs:
=== RPC Call Debug ===
URL: http://65.21.194.121:18232
Method: sendrawtransaction
Request body: {
ājsonrpcā: ā1.0ā,
āidā: āztest2ā,
āmethodā: āsendrawtransactionā,
āparamsā: \[
ā050000800a27a726f04dec4d00000000000000000199963b681bacf2330b5f4d3a0b6f666502a12bc76160e0d2f578d65a34cf0c85000000006a47304402204dd10c15868bfe44e4249b4761fc505c63218cf49096da0fbd07f9ced6c93b6c02202a9ba5ba69f106a18c76bdc1a7aa524ed01b4c818b8a1880d34770517c881496012102c4b4c57f911104ad953edbb36a109df6b8170fc9d6c7ea16dfe01108b6b089bbffffffff0239270000000000001976a91443412cf05de155fb2b821ae0c0e60eba54ec62c088acff750700000000001976a91417440b39f8cb6b64e0e9010700c95a6e72a41b9e88ac00000000ā
\]
}
Raw response: {ājsonrpcā:ā1.0ā,āidā:āztest2ā,āresultā:null,āerrorā:{ācodeā:-25,āmessageā:āfailed to validate tx: WtxId("private"), error: transaction did not pass consensus validation: could not find a mempool transaction input UTXO in the best chainā}}
Parsed response: {
āresultā: null,
āerrorā: {
ācodeā: -25,
āmessageā: āfailed to validate tx: WtxId("private"), error: transaction did not pass consensus validation: could not find a mempool transaction input UTXO in the best chainā
}
}
if i call the getaddressutxo method then it is able to pickup the utxo perfectly fine
in fact i am creating the entire tx programmatically, nothing is being hardcoded except the priv key, receiver address, and the amount
Zust wanted to say welcome to the folks around here. Iām fairly new in Zcash community and figured I might be utilizing Zcash blockchain to build some funny/useful stuff. Rn Iām working on Hash.town, an anonymous X.
(If Iām not allowed to post here, please, apologize).
Iād be happy to take all critics and suggestions you might have, as itās still in development phase.
With testnet, there is a greater possibility of ending up on a fork. Which version of Zebra are you running?