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
Hey @zooko, I conducted a test that in my opinion would have demonstrated the value of SbS. However, in fact, Zashi behaved differently than I expected.
Setup:
- Creation of a wallet, followed by the transfer of some funds into it.
- Subsequently, the wallet was closed for a duration of approximately ONE WEEK.
- After this period, I initiated a self-transfer from a different wallet application, which resulted in the wallet losing the transaction fees but receiving a fresh note.
Test
Open Zashi and record a video.
Expectations
My expectation was that Zashi would promptly detect the recent self-transaction and display the incoming funds as readily available for use.
Actual Outcome
Initially, Zashi displayed a balance of zero. This was then followed by the appearance of the balance originating from the initial funding. After approximately one minute of synchronization, Zashi accurately reflected the total balance, inclusive of the self-transaction.
The observed behavior closely resembles that of a standard synchronization processâŚ
1 Like