Quick update: We are still aiming for May 31 to release the full set of products that will resolve Zcash wallet performance issues, but two minor issues have caused a slight delay in one of the releases, zcashd 5.5.0. We’ll have it out by Friday.
3 Likes
I’m not caught up on the whole conversation here, but I wanted to come onto the forum to say:
@hanh is my hero!!!
Since 1 year ago I, like a lot of people, have had issues using Zcash wallets. After a year of intermittently trying to use Zecwallet and failing to sync each time, I gave up a month ago.
I moved to Nighthawk wallet. It seemed to manage to sync, but the UI was frozen; I could see my balance but i couldn’t do anything with my funds. It also took up 16 GB of mobile phone storage. I gave up yesterday.
I downloaded Zingo. 24 hours later, it has only synced 1 transaction.
1 hour ago, i downloaded Ywallet. It has fully synced, I can send funds, and it’s only using 99MB. Hurrah!
@hanh, your contributions are invaluable!
24 Likes
Couldn’t agree more. And it’s one person (vs. however many work on nighthawk, zingone with the wind, etc…). @hanh is the real MVP.
9 Likes
[This Movie Scene] Everytime I see @hanh single-handedly building and delivering products that become Flagships for the Zcash community.
6 Likes
I smell a retroactive grant…
Agreed. 
With multiple node implementations - and with QEDIT getting involved in protocol development - we need a different approach to network upgrades. I expect that @Souptacular will have some good insights on this topic.
The first step is to do a proper retrospective on the NU5 upgrade.
I’ll add this to the agenda for today’s Arborist Call.
10 Likes
Yes, it does.
The ZIP 317 block template construction algorithm allows for 50 “unpaid actions” per block. We anticipate that this will be sufficient for transactions from wallets that have not updated to pay ZIP 317 fees to be able to be mined temporarily. However, they should update.
7 Likes
Update on zcashd 5.5.0 from ECC engineering: All known issues have been fixed, and the release candidate was cut yesterday. Testing and packaging should be complete early next week.
10 Likes
I’m really happy about the simplifications that have been made to zcashd as part of the ZIP 317 work. (Most of them are in zcashd v5.5.0; the remainder will be in v5.6.0.)
The logic we inherited from Bitcoin for fee and priority estimation in the internal zcashd wallet, and for block construction in getblocktemplate, was grossly overcomplicated. It also made assumptions unsuited to Zcash — for example the concept of “coin age priority” depends on knowing which coins are being spent and their values, so it can only apply to transparent coins. We had a hack to work around that particular problem: transactions with any shielded component were treated as maximum priority. But there was still a divergence in fee behaviour between legacy and z_* APIs, which meant that the design simplifications to use a fixed fee (before ZIP 317) were never fully adopted.
I’ve been wanting to simplify this since before Zcash launched, but there was no practical opportunity to do that given all the other demands on engineering bandwidth.
Coin age priority is now completely gone in v5.5.0. (Upstream Bitcoin Core had removed it earlier, but their PRs were entangled with other changes we didn’t want.) Priority estimation and the estimatepriority RPC call is gone. The concept of “free transactions” is gone, replaced with the “block unpaid action limit” in the ZIP 317 block template algorithm. Fee selection is greatly simplified, and the old fee estimation code is almost gone. (It’s no longer used by the internal wallet; in v5.6.0 the remaining code and the estimatefee RPC call will be removed.) We’ve removed 6 zcashd config options (sendfreetransactions, blockprioritysize, limitfreerelay, relaypriority, txconfirmtarget, mintxfee), and added only one (blockunpaidactionlimit) in exchange! Verbose, near-duplicate code in implementations of several of the z_* RPC calls has been merged together and rationalised. This is all a huge simplification and removal of technical debt, replacing behaviour that never made sense in the context of Zcash with behaviour that has been specifically designed for it.
I don’t know whether adoption of ZIP 317 will in practice halt the sandblasting, but it’s a serious effort toward doing so. It will certainly make it more expensive for the adversary; whether that’s sufficient depends on their resources and motivations. In the meantime we’ve significantly improved zcashd’s robustness, performance (mainly in previous 5.x releases), and technical debt.
33 Likes
May we have an update for the week ahead?
There are a lot of Zcash client operators and wallet users tapping the F5 button in anticipation of a fix for the fee issue and spamming attack!
1 Like
We have tagged a second release candidate addressing some minor issues discovered during our comprehensive testing of the first release candidate. Once we’ve completed testing on this second RC, we will publish the final 5.5.0 release.
4 Likes
Hello, again.
Testing and cleanup is complete, and today ECC released 5.5.0 — a bit later than hoped, but we are still on track to exit wallet performance emergency mode by the end of May.
This latest release contains infrastructure improvements that lay the groundwork for 5.6.0 and the completed transaction-fee-structure change (ZIP 317). Check out the blog post for more details.
As mentioned previously, the 5.5.0 release will not have an immediate, noticeable impact on normal user experience, but it’s an important milestone and narrows ECC’s focus on the remaining pieces that will restore good user experience in the impacted apps and allow users to quickly access and spend their funds.
Zcashd 5.6.0, lightwalletd, and SDK updates will be released at the same time, at the end of May, which will signal the end of emergency mode. Here’s the updated release schedule:
22 Likes
Awesome! Great stuff from the ECC team.
7 Likes
A proposal related to this:
4 Likes
Hi, again. Time for another update. 
ECC’s engineering teams continue to prioritize the features and functionality necessary to exit “Emergency Mode.”
Criteria for exiting Emergency Mode are that the ECC CEO, Head of Engineering, and Head of Growth all agree that we have accomplished the following.
- Users of Edge, Unstoppable, and Nighthawk can spend their current funds (funds that are already synced when they open their wallet).
- Users of those wallets can receive and become able to spend new incoming funds at a rate of a month’s worth of transactions in 1 hour.
- Users have confidence that the sync is making progress and will eventually complete.
- None of those wallets are impacted by frequent crashes or inconsistent behavior (such as failing to display some already synced transactions).
With the release of zcashd 5.5.0 last month, our focus has turned to zcashd 5.6.0, along with updates to both lightwalletd and the mobile SDK. This combination of releases will enable improved lightwallet sync performance and a fund availability feature, allowing users to spend funds before a full sync has completed.
We have actively engaged with our wallet development partners to ensure they have access to integrate and test these new features as quickly as possible. This will help ensure end users can take advantage of the performance improvements as quickly as possible after release. We still expect to deliver the all updates below by the end of May, but it may take some time after this point for each of the wallet providers to update their code and enable the new functionality for their users.
Release schedule:
12 Likes
We are looking forward to the release of the updated dependencies: ECC Mobile SDK, librustzcash and Lightwalletd adapter software.
The Nighthawk Wallet team is on track to deliver items per our roadmap set for the 2023 year. The upgrades to our infrastructure are underway with migration to a completely automated deployment system. This work will support novel methods being introduced to sync light wallets at a greater efficiency and service the broader Zcash ecosystem using lightwalletd.com services.
We continue working together with ECC developers, offering potential solutions and suggestions to help fill gaps and to enable our team to merge skills and maximize efforts towards delivering an easy-to-use, Shielded-by-default ZEC experience.
7 Likes
The roadmap looks good! Great to see you prioritize chain sync issue. The Unstoppable wallet team is looking forward to the updates and will try to apply them as soon as they are out.
In case you need us for anything as development progresses we are available 24/7 over Telegram.
Love and peace!
3 Likes
Does the ECC have V&V test engineers and their efforts also factored into the wallet deliverables?
does ECC restructuring change end of may timeline i guess?
Slightly… we are still aiming to get a release candidate for zcashd out this week, with the lightwalletd and SDK changes shortly thereafter. The goal is to stay as close to the original plan as possible, but recognizing we lost a few days with the restructuring and shifting of work.
6 Likes