just wanted to try out YWallet and “Warp Sync” as described on Warp Sync :: YWallet. Given that this should process 10.000 blocks per second, and given a total of roughly 2 million blocks so far, it should take ~4 minutes.
Initially, syncing proceeds quickly, but then gets stuck somewhere last summer - and now shows ~6 hours left.
What am I doing wrong? Do I have to enable “Warp Sync” somehow? I’m using a Pixel 6 Pro and the latest YWallet version from the Play Store.
Maybe you have a slow internet connection? regardless, try syncing with nighthawk or zecwallet lite, and you will see why warp sync is faster than the rest of the pack
Hello everyone,
I apologize for interrupting, but my issue is also related to YWallet. Because of the extremely slow syncing in zecwallet lite and nighthawk, I restored from the seed phrase in YWallet, and while the first sync had to be okay as I managed to send a small portion of the funds, now the sync process is slow again and does not reach completion, and when attempting to send ZEC, I get the following error - 18: bad-txns-sapling-duplicate-nullfier.
Therefore I have two questions (if you could be so kind as to help me):
Do you know any way to solve this problem?
If I received this error every time I attempted to send my funds, is it possible that those “sent” funds are lost? Or should they still be on my address? (I am unable to check due to the syncing process that cannot complete).
A user could also fully sync their wallet on a desktop client then create a tx that sends all of their funds to themselves, so they’d only need to sync a mobile wallet from the send date of that new tx.
Yes that’s the equivalent of a migration where you move all of your funds from one particular address to another and effectively abandoned the old version and/or history.
Slow sync with Ywallet is most of the time related to network performance. Make sure you have a good internet connection (>1 Mb/s) and use the Zecwallet server because it will download less data.
bad-txns-sapling-duplicate-nullfier: indicates you are trying to spend funds that were spent already (but not synced yet). The network rejected your tx, that’s all.
Better to run your own node + lightwalletd so that you’re not trusting a third-party with your tx metadata.
lightwalletd uses a warrant canary to instill some degree of trust that their remote node(s) has not been compromised. Does Zecwallet provide a privacy policy or canary for their services?
lightwalletd is under active development, some features are more stable than others. The code has not been subjected to a thorough review by an external auditor, and recent code changes have not yet received security review from Electric Coin Company’s security team.
Developers should familiarize themselves with the wallet app threat model, since it contains important information about the security and privacy limitations of light wallets that use lightwalletd.
See the Wallet App Threat Model for more information about the security and privacy limitations of the wallet.
It seems a bit problematic that virtually all light wallet users appear to be centralized around 2 lightwalletd providers. Running one’s own services is rarely promoted and made more complex by not bundling zcashd with lightwalletd.
Is there any intent to bundle Zebra with lightwalletd?
(Sounds weird but in general there seems to be a somewhat noticeable difference in performance with the temperature of your device and when it syncs, it gets hot. Having it on the charger will add to that heat so consider charging it up and then taking it out of the case if it’s in one and sticking it in the refrigerator if the wifi is strong i did that once seemed to help, it’s weird told you)
It could be done and I imagine without much difficulty, especially as a docker image and then the internal server wouldn’t even have to be fully incorporated into zebra and still be a nice little bundle. The internal server would be straightforward but there would be some added complexity (though not very difficult to implement) with exposing the port for connection from a mobile device like setting up a public server in general and generating the x509. Exposing the port may not necessarily be what the user wants and so there may be a more secure method of remotely connecting the wallet to the server, food for thought.
The method for setting up lightwalletD with zebra is very well documented. The main issue to me seems to be with installing go Lang itself, seems somewhat complex and error prone especially if you already have some existing version. The workaround I used was to install the go snap package, it’s old but new enough for lightwalletD and it was a single command to install it with no extra setup.
Spam on the blockchain, the oldest accounts when synchronizing must go through all that spam so that their wallets are up to date.
Users do not worry about learning how to use their wallets and thus mitigate the problems that were in the blockchain regarding spam.
YWallet is a wallet with many features, including encrypted batch backup, server switching, AntiSpam filter, and other important features when syncing.
We need more education, worry more about learning about what we use and not blindly navigate, a long way to go, but it is being done through communities, ZecHub, Contributors, etc.
Well, spam is also a bit relative. Sure spam filtering is important, but we need to keep in mind that even with the spam, the transaction volume last year wasn’t particularly high. For example, see here the comparison with XMR (ZEC never came close to XMR):
