Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining
ZCASH Wekly Update - Upcoming events, Zcon0 & the Foundation & More
May the 4th be with you, Zcash community!
Since last week saw the end of our first engineering sprint, we’re now in the middle of the second sprint so I figure it makes sense to try and talk more about community related updates on the off week. So going forward, I’ll alternate these weekly reports between engineering and community/communications. Next week will be the end of our second engineering sprint and I’ll therefore have a recap of the various engineering teams sprint work. Note that each release cycle contains 3 sprints and that we are still in heavy dev mode for both implementing Sapling consensus code for the next release so we can activate it on test net in the following weeks and also external preparations for Overwinter activation at block height 347500 .
From the blog…
If you haven’t yet seen it, we’re experimenting with a new program to streamline community feedback of services in the Zcash ecosystem. We’re calling this the Community Spotlight and our first project comes from Zcash Foundation grant program backed Guarda wallet . So check out that blog and if you’re interested in testing the user experience in Guarda, use the form linked from the blog to let us and Guarda know your thoughts! If you have suggestions for future Community Spotlights, let us know!
In more recent news, we’re delighted to hear about support for Zcash in Circle Invest announced this week .
We have a lot of events coming up that we’re thrilled to participate in and engage with the community at!
This Sunday, we’re speaking at the Colorado Springs Blockchain & Crypto entrepreneurs meetup and next week will be attending the Blockchain Summit Latam so come say hello if you’ll be at either of those! Next week we’re also giving a remote presentation to the Blockchain Online Forum hosted by the Seoul Crypto Club.
The following week is a big week for us! As part of our sponsorship of 100 student passes for Consensus , we’re kicking off the week in New York with a session to greet the students and pass out some swag. Once Consensus commences the next day, several of us will be on the ground to meet potential and existing third parties in the ecosystem, engage with Zcash users and developers and generally promote and educate folks on the upcoming network upgrades. Zooko will also be doing a fireside chat with Dr. Whitfield Diffie to round out the first day.
In addition, we’ll be participating in the the New York Women in Blockchain meetup that week to talk about Zcash in Venezuela and then popping down to DC to present at the DC Blockchain Users Group. Come say hi if you’re around!
On the other side of the US, we’re participating in Boulder Startup Week where we’ll talk about opportunities in the blockchain industry.
Next week we’re hosting a special presentation from Zcash advisor, Joseph Bonneau about Hostile blockchain takeovers which is particularly relevant to the ongoing community discussions about ASIC resistance in Zcash.
Zcon0 & the Foundation
We’re starting to send out letters to applicants of Zcon0. If you haven’t fill out the form yet and are interested in joining us in Montreal this Summer, definitely consider applying to attend . This application process is mostly so we can consider financial aid needs and filter out people who are only engaging to promote unrelated projects, ICOs, etc.
Also, don’t forget to check out the governance proposal for the Zcash Foundation including their plan for a community governance panel which will vote on issues like board elections and ballot measures (i.e. should Zcash actively resist ASICs?).
That’s all for this week! I’ll be back next week with summaries of each engineering team’s sprint work!
Zcash (ZEC) Release Wallet Version 1.1.1
This release is an Overwinter-compatible version of the Zcash node software, with initial support for Sapling consensus rules and a Sapling testnet activation height set to block 252500.
Overwinter network upgrade
The first block of Overwinter will be block 347500, which is expected to be mined on the 25th of June 2018. Please upgrade to this release, or any release from v1.1.0 onwards, in order to follow the Overwinter network upgrade. See our previous blog post and the Overwinter Network Upgrade page for more information.
Developers preparing for Sapling
Sapling network upgrade
The consensus code preparations for the Sapling network upgrade, as described in ZIP 243 and the Sapling spec are finished and included in this release. Sapling support in the wallet and RPC is ongoing, and is expected to land in master over the next few weeks.
The Sapling MPC is currently working on producing the final Sapling parameters. In the meantime, Sapling will activate on testnet with dummy Sapling parameters at height 252500. This activation will be temporary, and the testnet will be rolled back by version 2.0.0 so that both mainnet and testnet will be using the same parameters. Users who want to continue testing Overwinter should continue to run version 1.1.0 on testnet, and then upgrade to 2.0.0 (which will be released after Overwinter activates).
Sapling can also be activated at a specific height in regtest mode by setting the config options
-nuparams=5ba81b19:HEIGHT -nuparams=76b809bb:HEIGHT. These config options will change when the testnet is rolled back for 2.0.0 (because the branch ID for Sapling will change, due to us following the safe upgrade conventions we introduced in Overwinter).
Users running testnet or regtest nodes will need to run
./zcutil/fetch-params.sh --testnet(for users building from source) or
zcash-fetch-params --testnet(for binary / Debian users).
As a reminder, because the Sapling activation height is not yet specified for mainnet, version 1.1.1 will behave similarly as other pre-Sapling releases even after a future activation of Sapling on the network. Upgrading from 1.1.1 will be required in order to follow the Sapling network upgrade on mainnet.
Sapling transaction format
Once Sapling has activated, transactions must use the new v4 format (including coinbase transactions). All RPC methods that create new transactions (such as
getblocktemplate) will create v4 transactions once the Sapling activation height has been reached.
Other notable changes
zcash-cli: arguments privacy
The RPC command line client gained a new argument,
-stdinto read extra arguments from standard input, one per line until EOF/Ctrl-D. For example:
$ src/zcash-cli -stdin z_importkey mysecretzkey yes 200000 ^D (Ctrl-D)
It is recommended to use this for sensitive information such as private keys, as command-line arguments can usually be read from the process table by any user on the system.
Asm representations of scriptSig signatures now contain SIGHASH type decodes
asmproperty of each scriptSig now contains the decoded signature hash type for each signature that provides a valid defined hash type.
The following items contain assembly representations of scriptSig signatures and are affected by this change:
/rest/block/(JSON format when including extended tx details)
For example, the
scriptSig.asmproperty of a transaction input that previously showed an assembly representation of:
now shows as:
Note that the output of the RPC
decodescriptdid not change because it is configured specifically to process scriptPubKey and not scriptSig scripts.
Summary of the changes included in this release
- We set the Sapling testnet activation height to block 252500. (#3305#3212)
- We implemented Sapling consensus rules. (#3207#3220, #3232#3255, #3275#3170, #3191#3197, #3169#3185)
- We implemented ZIP 243 for Sapling signature hashing. (#3233#3251)
- We backported transparent address refactors, and are in the process of adding support for Sapling keys, addresses and notes. (#3206#3234, #3123#3228, #3202#3242)
- We extended a mempool eviction RPC test to cover Sapling activation. (#3074#3179)
- We updated the Payment API documentation. (#3264#3160, #3181#3183)
- We updated the build process to use Rust 1.26 stable. (#3271#2784, #3153#3227)
- We extended Sprout tests to other epochs. (#3157#3086, #3180#3193, #28131.1.1 milestone.
Zcash Release Wallet v1.1.2-rc1
Zcash v1.1.2-rc1 release
Zcash (ZEC) Release Wallet v1.1.2
Hot on the heels of Zcon0 comes a new release of the Zcash node software (Overwinter-compatible). This release focused on implementing internal changes necessary for Sapling, with development progressing in tandem with the librustzcashsapling-crypto libraries.
Developer tips for Overwinter network upgrade
Overwinter activated successfully at block 347500 with most of the ecosystem upgrading smoothly. Some common issues we helped third parties with both before and after activation, were:
When using an offline node to sign raw transactions, the offline node needs to be synced past the Overwinter activation block height, so that the correct consensus branch id is used.
With the new Overwinter signature hashing scheme, when passing in the
amountfield must be specified. Previously this was not mandatory.
When developing custom code to perform the Overwinter signature hashing scheme, a common issue has been mixing up the endianness of fields.
Other notable changes
Removal of option
In release 1.0.9 we implemented end-of-support (EOS) halt for
zcashdsoftware versions made by the Zcash Company. The configuration option
-disabledeprecationwas added as a way for users to specifically choose to stay on a particular software version. However, it incorrectly implied that deprecated releases would still be supported.
This release removes the
-disabledeprecationoption, so that
zcashdsoftware versions made by the Zcash Company will always shut down in accordance with the defined EOS policy (currently 16 weeks after release). Users who wish to use a different policy must now specifically choose to either:
- edit and compile the source code themselves, or
- obtain a software version from someone else who has done so (and obtain support from them).
Either way, it is much clearer that the software they are running is not supported by the Zcash Company.
Summary of the changes included in this release
- Removed configuration option for turning off EOS halt, previously known as auto-senescence. (#3137#3299)
- Data field
finalsaplingroothas been added to RPC calls
- We added a class for Sapling notes. (#3272#3258)
- Test vectors were created for components of Sapling keys. (#3332#3259)
- Some tests were updated with fixes. (#3303#3320).
- We performed some refactoring for code clean up. (#3237#3321, #3322)
For a more complete list of changes, see our 1.1.2 milestone.
This week will have a more casual format for the update as most of the teams have opted into a one-time 3 week sprint which started last week. This is in order to reorient ourselves after a couple of distracting weeks with Zcon0 and folks taking time off around the 4th of July. So we’re kind of mid-sprint for this engineering update and there are no formal summaries of work accomplished.
A meta update to the teams structure:
- We’ve combined the protocol and zcashd teams. Since most of the consensus level engineering is complete for Sapling (barring any required fixes coming from audit results), the most urgent work for Sapling is now wallet-level support.
- We’ve added a new team focused on the reference mobile wallet project, an idea introduced in the recent roadmap proposal .
- We’ve also added an enterprise team which will focus on work supporting projects like last year’s Quorum collaboration. There’s not likely to be many updates from this team as collaborative work with other companies is typically done under NDA until a product is announced.
Here are some in progress or review items for some of these teams. You can follow with progress in their respective projects
Zcashd Team This team focus on development of the zcashd client.
- ZIP32 (ZIP PR 157) support aka Shielded Hierarchical Deterministic Wallets
- Sapling proof generation API
- Extending RPC support for Sapling keys
- Sapling note support
- New version of the Sapling spec is ready which now includes the completed proofs needed to support the Pedersen hash optimizations
Development Infrastructure Team This team works on making sure developers have the tools and infrastructure they need to efficiently collaborate, design, implement, review, test, and ship high quality projects.
- Investigating MacOS builder to resolve continued breakage
- creating a Windows CI worker
- Investigate current CI infrastructure to propose potential upgrades
- fix CentOS 7 builder
Ecosystem Team This team is the interface to everything not directly related to zcashd or the protocol and include support for third-party tools and services. Ecosystem projects developed by Zcash Co. also get handled in this team. Tracking for this team is kept private to prevent information leakage about third-parties.
- Researching ways to stay in touch with third parties and give appropriate support
- Ramping up for Sapling education and outreach to third-parties
Documentation Team This team works on improving the accessibility of zcashd and Zcash overall.
- investigate and formalize ReadTheDocs translation process
- test GitLab as repository host (test repo: https://gitlab.com/mdr0id/test-rtd-docs 2)
- migration of documentation on the website to RTD (for example the UX checklist & network upgrade guide for developers)
- brainstorming around a feature-based wallet selection guide
Community & Communication You can check out last week’s community and communication update on July 13th for the latest info.
This week marks the 1st of a 3-week sprint. Check out last week’s update for a recap of the last sprint.
During this sprint, zcashd engineers are focused on testnet testing of existing Sapling RPC functionality and implementing remaining RPC functionality for the 2.0.1 release.
Some exciting benchmarks are coming out of the testnet transactions:
Much of the RPC implementation work is going through review at this point. The curious can check out the wallet related pull requests pending review here: https://github.com/zcash/zcash/pulls?q=is%3Apr+is%3Aopen+label%3Awallet 2
We recommend the community follow along with the testing and wallet development in the #zcashd-team channel linked above.
Additionally, the protocol team that was merged with the Zcashd-team to focus on the 2.0.0 release is now spinning up into it’s own team again starting next sprint. The focus of the team over the next couple months will be protocol code cleanup/refactoring and eventually doing some research groups to study potential improvements in the next network upgrades.
Development Infrastructure Team The Development Infrastructure team ensures application developers have the tools and infrastructure they need to efficiently collaborate, design, implement, review, test, and ship high quality projects. These responsibilities include: CI/CD, release automation & execution, coverage reporting, simulations and testnets and “spin-up-a-box-for-arbitrary-work-tasks” service for engineers.
During the middle of a release cycle is when we target updates to dev infrastructure. We’re also making a lot of progress on build support for other platforms including Windows and MacOS.
A new channel was created in the community chat to follow along with development infrastructure progress: #dev-infrastructure.
Ecosystem Team For the time being this team handles business development in the phases after initial contact by providing technical insight and support.
We completed a second round of outreach to third-parties this week after an initial draft of the Sapling network upgrade integration guide was published.
Documentation Team This team works on improving the accessibility of zcashd and Zcash overall by creating and moderating documentation. Follow along with team discussions in the Community Chat #documentation channel. Check out the official Zcash documentation
This team has been working with ecosystem team to get developer documentation out regarding Sapling (as mentioned in the ecosystem team section). We’re also doing a lot of work cleaning up and organizing the documentation. And we’ve got some preliminary support for translations working.
Reference Wallet Team This teams current charter is to build a Zcash reference wallet. Deliverables will be a series of MVPs where Android is the first target platform.
So far, the wallet team has been focused on design and UX but with 2.0.0 out the door, we have some engineering resources available for the backend light client protocol design which is ramping up this sprint. We’re also making progress on an Android developer hire and hope to have that finalized so we can start implementation work in a timely fashion.
Community & Communication
We published another two videos from the Perspectives video series this week.
We also outlined some user expectations and developer guidelines for the Sapling activation which is just under 2 months away!
In the coming weeks leading up to Sapling activation, we plan on releasing some educational blog posts about new features and user experiences that the upgrade brings so stay tuned!
Finally, shout out to Lamassu for being the first third-party to announce their Sapling-readiness ! Feel free to ask wallets, exchanges and other services you use that support Zcash to make a similar public statement!
Zcash (ZEC) Release Wallet v2.0.1
Zcash (ZEC) Release Wallet Version 2.0.2
This release adds further support for Sapling in the zcashd wallet RPC and mitigates an issue identified by an external auditor. Information on the Sapling network upgrade (which activated on Oct 28th 2018) can be found below:
Notable Changes in this Release
z_getnewaddressnow returns a Sapling address by default
Previously when calling
z_getnewaddressa Sprout shielded address would be returned by default. With this release, a Sapling shielded address will be returned by default.
Transactions expiring soon will not be propagated
To address auditor issue ZEC-013 which identified a potential denial-of-service vector related to expiry height, nodes will no longer propagate transactions which are expiring soon, defined as within the next 3 blocks. For example, if the current block height is 99, and the next block to be mined is 100, a transaction with an expiry height of 100, 101, 102 will be considered "expiring soon" and will be rejected by the mempool. A transaction with an expiry height of 103 will be accepted. This does not impact transactions which have disabled expiry height (by setting to 0).
Summary of the Changes Included in this Release
- Add Sapling support to RPC
- Mitigate ZEC-013 transaction expiry height related DoS vector (#3689)
- Return Sapling addresses by default when calling RPC
- Add Sapling spend and output description benchmarks to RPC
- Fix bug with Sapling chain value tracking (#3684)
- Fix language encoding bug with parameter paths on Windows (#3633)
- Backport from upstream the relaying of blocks when pruning (#2815)
- Don't ban peers when loading pre-Sapling blocks during syncing (#3670)
- Fix bug with contents of default memo in Sapling (#3605)
- Update tests for Sapling (#3585, #3588)
For a more complete list of changes, please see the 2.0.2Network Upgrade Developer guide.
- Add Sapling support to RPC