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.
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.
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.
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:
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.
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.
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.
We at Edge have full intent to support the updated SDKs that improve performance and stability. As maintainers of the react-native-zcash repo/library with RN bindings, we will keep the repo updated for Edge and other react native focused projects incorporating Zcash. We look forward to the updates bringing zcash usability to the masses.
To follow up Nick’s post from yesterday, ECC’s restructuring operations created a small impact on the overall delivery schedule for the remaining “Emergency Mode” functionality. The release timeline below includes those updates.
In addition to what is listed, we also completed a quiet SDK update release, which included block download and scanning parallelization features. This is part of our continuing Emergency Mode efforts to address functionality and feature challenges within the software. The end result of releasing this functionality is a much improved linear scan capability ahead of the zcashd 5.6.0 release, which will enable the DAGSync algorithm and fund availability.
We are also actively engaged with our third-party wallet development partners as we reach critical milestones. This ensures a two-way communication channel while minimizing the wait for end users to see new features realized in their favorite wallet product.
With the updated timeline below, we are expecting a release candidate for zcashd 5.6.0 in the week of June 5, with the stable release a week later. The updated lightwalletd and SDK versions will follow the same timeframe, coming during the week of June 12.
The release candidate for zcashd 5.6.0 was cut yesterday and final QA is underway, with the intent to deliver the updated version next week. Full node operators can access the code for testing at Release v5.6.0-rc1 · zcash/zcash · GitHub.
… As outlined in a recent blog post, ECC is in the process of transitioning to a narrowed focus on proof-of-stake ZEC, a mobile SDK and accompanying wallet, and US-based policy work.
ECC released zcashd 5.6.0 today, a key piece to solving wallet performance issues and one of the last remaining hurdles to exiting emergency mode. Because of some necessary changes to back-end structures, we’ve included a migration tool, which makes things much simpler for node operators performing the upgrade.
The SDK and lightwalletd will be released next week.
Hi, everyone. Lightwalletd 0.4.14* was released July 4, which means the mobile wallet SDK is the only outstanding piece in ECC’s plan to resolve wallet performance issues and exit Emergency Mode. Please see table of releases below.
The lightwalletd update introduces additional gRPC methods in support of fast fund spendability and the DAGSync algorithm implementation provided with zcashd 5.6.0. This version also includes bug fixes and a change to the compact block serialization format.
All lightwalletd operators should upgrade to this latest version ahead of the mobile wallet SDK release. While the new SDK will provide backwards compatibility to non-upgraded lightwalletd environments, the new speed and performance functionality will not work unless the wallet connects to an upgraded lightwalletd server.
NOTE: This release requires a rebuild of the compact block disk cache. The process can take a few hours, depending on hardware and network speed. Please plan appropriately prior to beginning the upgrade.