I am looking forward to the next ECC update from @januszgrze
Meanwhile, I can provide the updates shared in the @LightCli_WG meetings, the DAGSync is a series of developments in the works. The changes are expected in zcashd and lightwalletd adapter software and need subsequent testing and review on test-net. Then the librustzcash modifications to include the updated syncing mechanism to play with the lightwalletd adapter layer, and ultimately the changes in the SDK and client apps to integrate with the new workflows.
The SDK and client apps will see a series of updates to improve the overall performance of syncing, the rollout of which has already started.
Regarding DAGSync, mentioned by @aiyadt it is a series of updates to zcashd, lightwalletd and finally the mobile SDKs. The initial piece we are working on is making funds available as quickly as possible upon opening a wallet. The second piece is moving away from a linear-style sync where every block must be downloaded and processed to a selective non-linear sync (the DAG “graph” component). The combination of these approaches will result in faster sync times and faster availability of funds across any of the apps that leverage the SDK.
Thanks David! We appreciate the kind words! All the functional areas within ECC are focusing on this problem and working as hard as we can to continue to make improvements.
Hi, everyone. We’re making progress on Zcash wallet performance issues. Here’s the update.
TL;DR
ECC is still on track to deliver a set of product releases by May 31 that will resolve Zcash wallet performance issues.
Zcashd 5.5.0 will be released on or around April 17.
Code dependencies have pushed the fund availability improvement (originally slated for 5.5.0) to 5.6.0, but this does not affect the overall timeline for exiting “Emergency Mode.”
Two weeks ago, we updated the community on our progress with regard to fixing wallet syncing issues that are affecting users of third-party apps Edge, Nighthawk, and Unstoppable. We said our goal was to exit “Emergency Mode” by May 31, and — good news — we are still on track.
On or around April 17, ECC will release zcashd 5.5.0. This contains infrastructure improvements (that lay the groundwork for 5.6.0) and the completed transaction-fee-structure change (ZIP 317), which will be enabled when wallets are working normally again.
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.
As mentioned in previous communications, the solution comprises changes to every component in the shielded mobile wallet stack: zcashd, lightwalletd, the ECC wallet SDKs, and the ECC prototype wallet.
Dont know about that link of yours but some mobile wallets already attempt to instruct or enforce good hygiene to some degree. When unshielding you’ll typically be notified prior to the send of the tx’s sub-optimal privacy policy
It is always important for the community to have orientations for future updates. It’s like a vacation - knowing that it’s coming gives us the joy of waiting.
Thanks for this link and for raising the good point about how the NUP resources seem to be abandoned (or at minimum, out-of-date). I’m intrigued by the bottom of the NUP 2.0 ECC page because it identifies that a Network Upgrade #6 would be coming in 2022. Can we hear an update about that projection from the ECC team? What are the NU6 target features?
Thanks for highlighting these resources and confusion about the Network Upgrade Pipeline. At ECC, because we are focused on improving shielded wallet performance as an urgent top priority, we postponed non-related protocol upgrade processes and work.
We could have communicated more clearly about this, and we intend to rectify that moving forward.
We removed the associated timeline chart from https://z.cash because it is not up-to-date and wanted to reduce misleading information. The Time.Graphics Embed Timeline link is stale and not updated. We will see if we can remove it.
Generally, however, we believe this episode shows that the NUP 2.0 is too reliant on ECC as a single point of failure. We’d like to see more collaboration and ownership of the network upgrade process across development orgs working on protocol improvements or implementations. To that end, we intend to engage multiple orgs to iterate on, improve, or replace the NUP 2.0 with a community-lead process.
We will determine what next step we can take on this effort after the release of Zcashd 5.5.0 (April 17), and we’ll keep our eyes/ears open if any other dev orgs are coordinating on network upgrade improvements.
Related, but distinct from the upgrade process, we’ll also be resuming our protocol research and posts around Proof-of-Stake and cross-chain interoperability after we’ve delivered SDK improvements to shielded wallet performance as described in the mini-roadmap above.
Does zcash 5.5.0 include the part of zip317 that brings the minimum fee from 1000 up to 10000? If so, mobile wallets sending regular single recipient transactions will be affected by that change.
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.
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!
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.
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.
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.
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.
