Trust me and no need to verify, take as long as you want. No need to 2 piece puzzle. You already got the env just run another test…that’s puzzling, no?
Ok, it seems that there is not much added value. I will proceed to add you to my ignore list.
Good bye.
What is Zashi? I don’t see anything in the app store with that name and a google search turns up some kind of anime-based clothing line.
Not so fast, at the top of this thread you have an environment to determine some standard and variables to give insight on this analysis.
" The performance of the Spend before Sync feature is, regrettably, not up to the expected standard."
And here:
" I have been unable to identify a scenario that clearly illustrates the superiority of Spend for Sync algorithm over Warp. zooko , should you have such a scenario in mind, I would be keen to conduct an evaluation of it."
But for whatever reason it is possible, but don’t want to test the beta that likely should have the better “standard”. So at a minimum there is no value of just running the beta against the best performer, to get the “standard” in the environment which does this, and the justification needs to be discussed on none encrypted channels. Roger.
(Another censor/block when asked questions conjectured about. Very similar behaviors and tone across many of these, rather perplexing.)
Zashi is the new shielded mobile wallet being developed at ECC. It’s not available yet on the app stores, but that is the plan after we get through some beta testing and a security audit.
1 Like
Not sure. Depends on what exactly you want to measure, I guess. Might be good to devise something when we get a little further along in the beta.
1 Like
Typically, I refrain from evaluating beta versions of software; however, upon your request, I will share my observations. In my experience, Zashi required approximately 1 hour and 40 minutes to import the same wallet.
I included a video recording for your peruse.
Throughout this duration, the funds remained inaccessible. Consequently, I am curious as to the practical feasibility of the “Spend before Sync” feature.
It is important to note that a similar outcome would likely occur following a two-month period of inactivity, considering it is the age of this wallet.
May I inquire about the various scenarios you have tested during your evaluation?
In all honesty, the advantages of the “Spend before Sync” functionality are not apparent to me at this juncture.
P.S.: Please note that the middle section of the video has been accelerated to 20x. The original time codes have been displayed for reference.
4 Likes
One caveat about the “Spend Before Sync” functionality is that wallet restoration is special-cased; we do not permit funds to be spent before wallet restore is finished, because it’s possible that notes discovered during the restore process may have later been spent, and there is no way to detect those spends without scanning for them. Note, however, that funds received at block heights greater than the height at which a restore-from-seed was started are immediately available, without having to wait for the rest of the chain to be scanned.
“Spend Before Sync” specifically handles the case where a user has an existing wallet that they haven’t used for a while, and they need to be able to spend their old funds without waiting for the wallet to sync. There are additional some possible improvements that could be made to wallet restore using the Spend-Before-Sync architecture, such as scanning blocks in reverse order; this would make all funds belonging to the wallet spendable as soon as they were discovered, at the cost of greater memory and storage usage during the reverse-direction scan.
5 Likes
Thanks for your explanation. How would you suggest we can test spend before sync in production? Once a wallet is synchronized, there is no option to bring it back to a previous block height, is there?
One interesting test would be to send new funds to the wallet under test immediately after beginning the wallet restore, and seeing how long it takes for those funds to be spendable.
Another test that’s a little contrived, but that could reveal potential problems is this: First, fully sync your test wallet, then send the full balance of the wallet back to itself. Then, start a restore, and as soon as whichever wallet you’re testing shows funds as being available, attempt to spend those funds. There should be no situation where this attempted spend results in an error. The intent here is to demonstrate that inadvertent double-spend attempts are not allowed.
These tests would demonstrate that funds that are received during a wallet restoration
are usable. Even if they may, this does not offer much real world usage benefit.
I would be interested in trying this case though.
How did your test team test that?
Initially, the Spend-Before-Sync functionality was exercised with unit tests that simulated the wallet conditions that we wanted to ensure were handled. Then, a few of us had individual wallet database files from early versions of the old ECC reference wallet that had stopped working due to the sandblasting, and we were able to migrate those database files to be used in a command-line wallet that uses the Spend-Before-Sync algorithm. Since the release of the 2.0.0 versions of the ECC wallet SDKs, we’ve gotten numerous reports of people whose wallets were restored to usability after upgrading to the latest release of their respective wallet apps.
Understood. Yet, it seems unsafe to base your conclusions entirely on anecdotal accounts, doesn’t it? There’s a lack of visibility regarding the number of users who failed to recover their wallets, as such instances often go unreported. I, for one, was never able to restore any of my old wallets.
Does this imply the absence of any replicable benchmarks from the ECC? For instance, a conceivable test scenario might involve synchronizing Zashi from a predetermined database backup to a simulated lightwalletd, which consistently reports a specific block height. Unfortunately, this is not a test that can be conducted by regular users due to the lack of import/export application state functionality.
1 Like
I have created a new wallet and deposited a small amount of funds into it. I am going to keep Zashi closed for a day. Tomorrow, I plan to transfer additional funds into it and then relaunch Zashi. The goal is to evaluate two points:
- The point in time when the newly transferred funds become available for spending.
- The moment at which the wallet displays the total balance, inclusive of the first deposit. Then check that the entire balance can be transferred.
2 Likes
Just for the record, it is possible to scan the recent notes in parallel with the old ones with WarpSync.
In short, there would be 2 syncs going on at the same time (possibly connected to different servers):
- one normal sync/rescan
- a short term sync that starts at current block - N, with N ~ 1000
The short term sync would complete in a few seconds, making the recently received funds available for spending, while the normal sync continues in the background.
The trickiness is around handling the overlap, but I think this could be managed.
I didn’t implement this method because I don’t think needing to spend incoming funds is a common scenario and it is not worth the added complexity.
However, if there is a strong demand for it, it is possible to support this use case too.
In real life, this would only happen when you want to buy something and you are short on funds. Then, you need to go to your online banking and transfer some funds from your savings account. Or maybe ask a friend to pay for you.
In the case of crypto, I never had to do that. If I had to, I think I would simply ask my friend to pay directly. With shielded transactions, there is no telling where the funds come from anyway.
What was common was having funds in a wallet that wasn’t synchronized for months. Then a quick sync is what I need.
12 Likes
Thanks for the information, it was very helpful.
I am still in the process of designing a scenario that effectively demonstrates the capabilities of SbS. Yesterday, I started a test where I created a new wallet in Zashi and then closed it for one day. After this time, I proceeded to transfer funds into this wallet without running Zashi. Then, after waiting for an hour, I launched the wallet. My expectation was that Zashi would quickly find the recent arrival of funds. But the system resumed its scanning from its previous point instead.
Maybe this is due to me having an old version of Zashi? If so, how can I get the latest one?
PS: Zashi took ~1mn, Ywallet took 3 s.
3 Likes
Why aren’t those buttons centered? 
Deeply disappointing that ECC senior devs instead of trying to beat (or improve) Warp Sync sync speed, are coming up with UX hacks and novel use cases that dont happen in the real world just to build something in house and unique.
The behavior of the Zashi wallet is perplexing to me. Each time I access my wallet, the balance initially displays as 0.0 ZEC, eventually updating to the correct amount. In an attempt to understand the sequence in which the wallet synchronizes its notes, I will leave it closed for one week. Then, I plan to transfer some funds to see how long it takes for Zashi to make them available.
However, I am baffled by the complete absence of any official performance metrics. Providing such figures should be a fundamental requirement in engineering.
In my opinion, this is a reason why the spam proved to be highly effective.
2 Likes
Hey, @refinance, thank you for your user experience issue reports. The reason we’ve shared the Zashi beta with beta testers is exactly this reason, to learn about these kinds of user experience issues so we can improve them. We’ve added both of the issues you’ve raised to our internal collection of known UX issues. We’re also working on migrating our list of issues and bugs and features and so on to github or other public repositories so that everyone can see them: Issues · Electric-Coin-Company/zashi · GitHub
I saw you mentioned in another post somewhere on this forum that you don’t like measuring beta software. I agree that it isn’t a great idea to measure beta software for the purpose of comparing it in competition to other software, or for criticizing its makers. On the other hand, it is a great idea to measure beta software for the purpose of helping its makers improve it! If you’re willing to help us improve Zashi, you’re welcome to join the Secret Zashi Beta Testers Club.
Happy Thanksgiving to you and yours, if you celebrate!
Regards,
Zooko
3 Likes