January 13, 2017 - Dev update

Happy New Year, Zcash community!

While the core team continues development on Zcash, one of our goals this year is to open up the development process to be more community-centric and encourage others working on Zcash-related projects to do so as well. This will be the first of weekly engineering updates from Zcash Co – every Friday, we’ll post a recap of the engineering work we’ve done in the past week and an outlook for next week’s tasks.

So without further ado, here’s this week’s Zcash development update:

Lots of us are getting back into the swing of things post-holiday travel and family time. So while most of the team has been working at a slower pace for a few weeks, we hit the ground running with the start of 2017 with fresh excitement for what this year has in store for Zcash.

As mentioned in the intro, we’re starting to think about opening up Zcash development to improve the post-launch development processes which were mostly internal and focused on immediate engineering needs (read: bugs). We will be extending development to a more long-term outlook as part of this transition as well.

With the upcoming milestone for a 1.0.5 release, there has been a lot of focus on pull-request (PR) reviews - a good amount of attention on the z_sendmany RPC call (PR #1976, PR #1977, PR #1980) and generally improving the RPC interface functionality and outputs (PR #1991, PR #1999, PR #2001, PR #2015). Enhancing performance during creation of JoinSplits (PR #1932, PR #1942), improving security for exporting wallets (PR #2006) and removing dependency on OpenSSL (PR #1706) are some other issues that have been worked on for this release. Next week will be focused on final review and merging of PRs and releasing 1.0.5.

In addition, we had a focused engineering meeting this week on how the protocol handles blocks with a timestamp before that of the previous block (issue #1889), and next week we’ll be having one focused on selective disclosure – a feature which will give users greater usability with their shielded addresses to selectively share an address or transaction’s viewing keys (issue #406).

Beyond the Zcash core software, we’ve been working on tying up loose ends in the protocol specification, brainstorming and implementing a revamp of the https://z.cash website, and enhancing our user support processes (PR #1935, PR #2016).

Over the holidays, many Zcashers attended 33C3 and had the opportunity to mingle with hackers from all around the world. There was even a non-Zcash Co employee presentation about Zcash at the event and Zooko hopped on a short podcast to tell the sweet story of a secret, embedded love note in the Zcash block chain. Further, @str4d has been working on a presentation about zk-SNARKs that he will be giving at the Milan Bitcoin meetup this week. We hear there will be a video recording of the presentation so look out for that!

That should do it for this week’s update. We highly encourage engineering updates from other projects (such as the super helpful and useful client porting work from @anon47418038) in the comments so we can all stay updated with each other’s work and help each other grow the Zcash ecosystem. And of course any feedback or questions you have are also welcome!


Oh yes, a status update! I’ve been sick but have managed to still make some good progress on various things over the holidays and the first part of this month.

I’ll start with everyone’s biggest ask, “when is Windows coming??” @veikkoeeva lent a hand with resolving some of the build issues I’ve been having on Windows over the Christmas season, and I now have it able to build zcashd.exe and zcash-cli.exe! Unfortunately there are still some cross-platform issues with libsnark, more on that below. He’s also started a branch that uses Cmake rather than autotools, so that builds on Windows can use Visual Studio rather than gcc in the mingw64 toolchain.

On the libsnark front, and with the encouragement of team members from ZcashCo and the libsnark project, I’m working on an update to it that replaces all of its instances of old school C-style data types that are processor/platform dependent with modern C++11 ones. Banishing things like “long”, “unsigned long” and similar that have variable bit-widths depending on your processor. So far that runs and tests well on linux, but there are still some platform dependent things holding it back from running on Windows that I’m digging into. Once the libsnark issues are squared away, a full 100% release for Windows will be possible in short order (@vaklinov is going to start on Windows integration of my Windows build and the SwingUI wallet now, even before zcashd is fully functional).

Over on the Mac, some time in the next week or two I’ll be able to send patches upstream to ZcashCo that use #ifdef’s and similar things to allow my Mac fork to be integrated into the main Zcash code repository. Lots of this is actually being done by the Zclassic crew, who paid a bounty for adapting my Mac port to it, and they want it to all live in the master branch of their repo.

So for the moment I’m focused on getting libsnark to be more cross-platform out of the box to allow it to work on Windows, regardless of compiler. This will also help the wider universe of libsnark users beyond Zcash.

Again, I’m a volunteer working purely on donations and some random contracting, so donations of any size really help out: MercerWeiss Consulting — Independent Cryptocurrency Developer


David Mercer
Tucson, AZ


Thanks for the updates guys!