@hanh thanks for informing me about that. I’ve generated it from WalletGenerator.net years ago.
Do you know an app that supports them? Your site is a paper wallet.
@hanh Sorry for the late response. I don’t know which apps support the format I own.
But did you put funds into this address without checking if it can be withdrawn?
@hanh I remember it was possible through ZecWallet, a lightweight version when I created the paper wallet.
But the app is not working properly now.
That’s surprising because the low-level rust library that zecwallet uses (librustzcash) does not support uncompressed keys. I think you’ll need to ask the protocol core team.
Likely referring to zecwallet fullnode or the accompaning zecwallet paper wallet? ![]()
I had a question @hanh (and feel free to DM if it’s better). I’m trying to recover a former ZecWallet wallet. I used the Ywallet key tool to derive 60 extra shielded addresses and resynced, but it still doesn’t show the whole balance. All apps show the same incorrect/too small balance, except Zingo shows a higher balance (but still not the full expected amount).
If I already used the key tool for a generous number of addresses, is there any reason it still isn’t seeing all funds?
There is the possibility that it showing the balance less the fee? The two wallets in question both work, but differently and so they could show a different pre-calculated, spendable balance wrt to the forseen fees per the number of held utxo’s, they all individually cost the same to spend.
Also, just to clarify, you’re talking about zecwallet LIGHT, and not zecwallet fullnode, correct? (Its a reasonable assumption)
You could potentially try out the latest Ledger
fork of zecwallet light which supports an initial server selection screen so you can open it, import the seed, and then set about generating new addresses, which will be the old addresses you are trying to get. Now, I haven’t tried it just yet, it got pushed only a few days ago. The old one (on desktop, not mobile, that’s a whole different thing) could open with a change to its config i.e. type in a good server in the file before it starts. BUT it was never updated to support the new base fee and zip317, hence it really probably wont transact. However, it should recovery your data and eventually(
) sync at least as a method to cross-check. Be sure to try to get them all regenerated before you start the sync, otherwise it will just compound the overall time it will take.
The thing with this (as well zingo pc) is it requires you to setup yarn. Yarn is enabled with corepack, which ships with NPM, and the easiest way to get that is with NVM. So,
1 install NVM,
2 use NVM to get the latest (lts) NPM (these first two are the medium article),
3 use NPM to install yarn (the corepak link),
4 enable corepack (the installation link, I know confusing!).
After that (also you need Rust
), follow the normal installation instructions. I will try it out and let you know.
.
.
.
.
.
Update: this doesn’t (immediately) compile in UB 24. I actually incurred the same issue with zingo-pc just yesterday after a dist-upgrade
so I’ll boot an older version and try. More info here Discord
Could it be because you have some funds in the transparent addresses?
I understand not finding all your funds. But how can you get more funds in Zingo? Or do you mean higher but still too low?
More funds (by about 300 ZEC), but still too low.
It’s possible some are in transparent addresses, I can check again on Zingo to be sure. Are they not displayed at all on Ywallet?
Interesting, I may try that, at least to see.
Yes it was ZecWallet mobile and the balance difference is a few hundred ZEC.
Depending on the version of Ywallet, you may have to scroll or tap the QR code to see the transparent balance.
Should be the latest desktop version.
I synced and looked and there’s no funds in the transparent address part of Ywallet.
I tried to sweep the next 100 t-addrs, but I got an “insufficient funds for the transaction fee” error. What exactly does that mean? Or is it just a stand-in for “no transparent funds found to sweep”?
The expected transaction fee is based on the number of actions of a transaction, which for most cases, is inputs. All of your notes, individually, cost 0.00005 to be included in a transaction. Hence, any note less than that value actually costs more to spend than it is worth and the estimated fee reflects this.
Future wallet best practices will include the prevention of the creation of values < 0.00005 ( and > 0), at least while the current base fee values apply. It would probably be helpful to you to see the addresses on an explorer and get an idea of these values and whether or not they can be considered worth recovery. The issue of notes of micro-quantities being lost after the new fee structure goes into full effect has been long foreseen, with the idea of some method of sweeping these funds probably needing to be developed (after the creation of sub-par values is prevented).
That error means that that funds aren’t enough to pay for the rx fee. Most of the time it is because there are no funds .
btw, did you turn off the spam filter?
“There are no funds” where though? The wallet itself has hundreds of ZEC (and surely much more than that once we find the extra addresses with missing funds). Do you mean in each of the transparent addresses attempted to sweep?
I did not turn off the spam filter.
Yes, the transparent sweep came empty handed.