This message needs faxed to the desk of all the engineers and project managers at ECC, Brave, Filecoin, and ZF. There is a risk of a catastrophe, if the Brave + Zcash integration gets performance blocked based on Zcash network/ blockchain bloat and sync issues (that have been known for +1 year now)
I’ve raised this concern for more than a full year also. Why has the ecosystem spread resources too thin across a handful of competing wallet products that up until recently couldn’t get the job done?
One or two bullet proof wallets with great UX is far superior to +5 average wallets.
What counter points have I encountered? This community has strangely convinced itself that the expansive choice among +5 average-frozen-slow wallets is somehow better than being “forced” into using the 1 or 2 excellent wallets. I can’t say that the logic makes any sense. It is counter-productive from a business sense, it fragments user experiences, it adds a few multiples of complexity when finding, tracking, and resolving software bugs. It creates a lot of duplicated-redundant work.
Yes Exactly. Suppose a $1 ZEC airdrop to all new Brave + Zcash wallet users. It would be a crucial test of Zcash usability at scale!
Can you please add more details for your test environment. For example, was this in WIFI / 4G / 5G and can you please post a speed test of your network speeds. (UP and Down). Which phone and OS version too. Details matter when bench-marking
You can see the connection is not that great but should be consider globally. It has peaks of 53 Kb in the top navbar, but is this consistent across devices? Is the ISP capping the device per pull on each of those?
This is another magnet near the compass, leading you to miss the forest for the trees when cardinally should be heading towards the ocean.
If the bar is low then other products seem better. If all these wallets struggle to implement features, it gives a clear optic on the variables involved per SDK update. Ideally, they all should match and perform optimally, but this does not seem to be the case. Additionally, several sub par wallets do provide data that likely disappoints, but doesn’t lie. Another grant idea, which I was going to apply for but due to other things I stand for, DID NOT, would be some QA across these wallets. It seems like a full sale to show how fast your wallet syncs the whole chain…How easy it is to spend before sync etc… Unfortunately the narratives seem to be very geared on privacy which honestly most people don’t care about. In this vacuum, yes everyone gets it, but globally I’m not sold. Additionally, many of these other narratives around regulation etc are great for people informed but your average person needs all this abstracted away and just easy to use. Privacy by default doesn’t mean dissertate the crypto on my device per curve implementation. It just means natural, blend it in, make it seamless, and let users be free to transact in the digital world.
Zooming out the goal here is to distill these practices in the community for the $1 ZEC case. ECC/ZF/ZCG cannot do everything nor should they if the mission is reach billions of users. At some point actually decentralizing practices to be mastered, is what will make this project last.
The one dollar == one zec is radically different. I’m not trying to troll but it is louring. It be the closest to a stable coin and usable by most. Issue now is you can barely market order across major exchanges (maybe all the miners are switching to zebra, idk). If you look at the usage since ZIP 317, it’s not used much so not sure why any exchange would allocate sources to it. Just looking at orchard fully txns they go down each month. Think last month was likely atl, but who knows with all the noise. Cold storage should be done before the sun dies out and otherwise the toggling of decentralize full nodes is strange, plus in the distance future you will only have a PoC of PoS. Not a full implementation. Even with some magic there is a lot to fix, but who knows maybe another strategy since it all seems off anyway.
But anyway, alt coins are wicking during altcoin season and not much spice here so ever onward since it’s the same old story time and time and time again. Enjoy the stay.
Considering our focus on evaluating the relative performance of these algorithms, the relevance of bandwidth speed appears to be of limited significance. However, the connection is established using Wi-Fi on a 5G broadband network. The ISP download speed is greater than 10 Mbps.
I think it matters a lot especially latency. Also what about phone specs and OS? I think its fair to argue improvements can be made, but its equally important we are fair with how we test. The goal should be for all wallets to improve, and in what areas. Digging out these details helps with that.
The observed outcome stems from an actual user experience, specifically mine.
May I inquire if you have not observed similar behavior?
It is my belief that the onus should not be on the user to modify their network or mobile device; rather, it is incumbent upon us to deliver the optimal experience within the constraints of the user’s existing setup. In this context, I have noted a markedly superior performance, approximately twentyfold, of one wallet compared to another.
I recommend that you conduct a test using your own device and share the findings accordingly.
It’s worth pointing out that sync speed and Spend Before Sync are/solve different issues. The one-line summary is that SBS gives users the ability to spend their existing funds without requiring the wallet to fully sync the entire blockchain.
AND in any wallet that is using our SDK, the ZEC you received very recently is likely to become quickly spendable because it will scan the chain tip first in order to make existing older notes quickly spendable.
Zingo doesn’t use the ECC SDK, and I’m not sure exactly what is going on with Nighthawk in your test, but it’s worth reporting it to that team directly.
In the meantime, it would be cool to see how Zashi works for you in the context of real-world UX. @refinance if you’re interested in joining the beta-testers club, DM me.
Honestly, just sign up for the beta and do another experiment. Run this beta against the best performer in your environment. Then you could sanity check this spend before sync against wallets that aren’t synced. For example, perhaps the wallet sync time is not optimal, but surely the spend before sync will work. It doesn’t seem likely to test some of this on mainnet though since zip 317, but perhaps you could ask the grant folks to simulate this on testnet with all the tooling they have created over the years.
Literally not running these tests for free. These should already being done.
Would be really excited to see your environment run the beta against the best performer. Ideally it should be better or orders of magnitude better and providing new features, no? Or what are we waiting on?
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?
