The wallet in question was created approximately three months ago. This timeline indicates a relatively new account, and avoids the period of spam.
Transaction Volume
Since its creation, the wallet has processed less than ten transactions.
Wallet Applications
The wallet is imported into several different wallet applications, namely Nighthawk, YWallet, and Zingo. They all run on the same Android phone.
Start/Stop
The duration of the Synchronization is measured from the beginning of the import until the wallet shows the balance.
Issues with Nighthawk Synchronization
Nighthawk experienced several synchronization errors which disrupted the wallet’s operation. These errors could indicate technical glitches within the Nighthawk application or compatibility issues with the wallet.
To address these errors, the wallet had to be restarted.
After restarting, the wallet was able to continue its operations.
Unified Server Connection Across Wallets
All the wallet applications (Nighthawk, YWallet, and Zingo) connect to the same server.
The performance of the Spend before Sync feature is, regrettably, not up to the expected standard.
Comparative analysis reveals that it operates at a speed approximately 20 times slower than that of Ywallet. Additionally, it is noteworthy to mention that SbS does not support Orchard transactions and therefore does not scan them, while both Ywallet and Zingo have to.
The default server is usually the same, but there are more to choose from. NightHawk limits to use of their own servers, but Ywallet and Zingo are fully customizable.
Here is an additional piece of information for consideration: Nighthawk and Edge require 5 minutes to initialize a new wallet, in contrast to Zingo and Ywallet, which accomplish this task instantaneously.
This is a shocking first impression that will certainly be a deterrent to new users.
agree wif u on most tings. but how did it take u 5 min to create wallet is weird.
see me on iOS creatin wallet up to sync in under 17 seconds - is der a bug on Android?: https://twitter.com/zerodartz/status/1716183434794594518
Yeah but thats from 2,267,500 which was like last week
Sorry, that was last month and I just rescanne from that height on Ywallet it took about 22 seconds. I recorded it, it’s just not letting me post the video format.
ok sumting has changed i guess for worse it seems wif update.
i tested wif my ancient android over month ago and it took 15min to sync last time for fresh wallet.
iOS only took 20 seconds.
but trying now on Android wif newer update its takin much longer 35 min.
also its using 24 days old birthday for new wallets, weird, and dat might cause slowness.
but still 5 min is too much for (a fast phone i guess?).
the birthheight should be made to change every day wen creatin fresh wallet i guess.
The amount of fragmented grantees on wallet performance is rather concerning. Hopefully there can be a more refined guarantee from current wallets and Brave, or no one is going to want to use these at scale. With the limited amount of use cases, it seems really odd that these sync and spend cases aren’t more stable/fast. That was the whole point of the last year’s exit emergency mode research.
Last year, I submitted a grant to integrate warp sync into librustzcash. It was rejected on the grounds that the ECC was working on its own sync algo (spend before sync).
I do recall this @hanh . I explicitly asked a question and never got a response… “if the user sees no noticeable difference in the sync time, what is the point on optimizing this for a year?” Meanwhile, there was plenty of other use cases and PoC PoS to be working on. . IMO, seems like the net output is off a bit. As a new user with a more near term birthdate, I’m not sold spend before sync matters. Sure when the chain is bloating with new users, it might be a solid insurance policy, but looking at the txn metrics for the last 3 months, this is not at all the case. It might make more sense with Brave users that sits at like 54 million or something. I do hope someone notes the issues so that Brave does not end up in the same UX. That would be a real disappointment given how much data has existed on these cases for years now.
(Full disclosure, I own no ZEC so expressing this for the project sake not as boost my bag please statement)
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.
Sadly until there is a market to fully support it, the “spend” is the issue. If you can’t spend it on anything then this feature literally makes no sense. For example, if all you can spend it on is bagels and you don’t like bagels…do you care? Just like some random delta on sync times. Idk, in general, strange looks across the board. There should be some standards in place to keep wallets up to some level of guarantees because it just looks odd for as much time has passed with the same UX issues.
The bigger question is how much dev fund money was burned to build a different sync algorithm that could have used to support other things like proof of stake? The lack of transparency is concerning given the continued push for a continuation of the dev fund.
While taking part in Plato’s cave of sock puppets, just consider the air drop case(“spend”) and Brave’s amount of users. It’s not that secret.
. IMO, seems like the net output is off a bit. As a new user with a more near term birthdate, I’m not sold spend before sync matters. Sure when the chain is bloating with new users, it might be a solid insurance policy, but looking at the txn metrics for the last 3 months, this is not at all the case. It might make more sense with Brave users that sits at like 54 million or something. I do hope someone notes the issues so that Brave does not end up in the same UX. That would be a real disappointment given how much data has existed on these cases for years now.
