After a [successful release of 1.0.5] (New Release: 1.0.5 - Electric Coin Company) earlier this week (be sure to update your nodes if you haven’t, yet!), engineering set it’s sights on the longer-term future of Zcash.
We dove more into the topic of [selective disclosure] (Implement selective disclosure · Issue #406 · zcash/zcash · GitHub) and the tasks needed to get basic functionality working and improve on that over time. The first step is what we’re calling [“payment disclosure”] (payment disclosure · Issue #2036 · zcash/zcash · GitHub), a simplified implementation of [“proof of payment”] (proof of payment - high quality protocol upgrade version · Issue #737 · zcash/zcash · GitHub). This basically means that each transfer to shielded addresses can create additional data, the payment disclosure, which reveals the data encrypted in the blockchain if given to a third-party. There are some privacy considerations for this initial implementation which affect the change address used in the same shielding transfer. To clarify, while all shielded addresses (including those used for change) are private, a bad actor with access to a transfer’s payment disclosure and additional knowledge of/ability to guess the associated change address (for example, if the change address is a publicly known shielded address) would be able to decrypt the change portion as well. This would be resolved by implementing [“secret change addresses”] (Add secret change addresses. · Issue #2037 · zcash/zcash · GitHub) which are essentially shielded addresses only known by owner of the wallet. Our payment disclosure discussion also brought up the concept of conflicts between [forward secrecy] (Forward secrecy - Wikipedia) and recoverability and how we can best offer the most options for users regarding the trade-offs ([issue 2038] (Recovery Secret Seed · Issue #2038 · zcash/zcash · GitHub)). We’ll be continuing discussion on all things selective disclosure in a topical meeting next week.
During the same engineering meeting, while going over a user request to optionally store the wallet file outside of the default directory ([issue 1873] (Allow wallet file outside datadir? · Issue #1873 · zcash/zcash · GitHub)), the topic of experimental features came up. We want to be able to release some features in experimental mode first to allow the users who are inclined to test them a chance to play around and give feedback. We’ll be working on integrating a process for future releases ([issue 2035] (Add experimental feature framework to config system. · Issue #2035 · zcash/zcash · GitHub)).
We had a topical meeting regarding formalizing the [ZIP process] (GitHub - zcash/zips: Zcash Improvement Proposals), discussed the current draft: [ZIP 0] (https://github.com/zcash/zips/tree/master/drafts/daira-zip-process), and decided the next step would be to start working on a few ZIPs internally. We’re thinking of initially managing ZIPs acceptance with Zcash employee editors to make sure the process is running smooth then migrating towards community-centric editing and acceptance. This extends our continued work towards more open development on Zcash and considering medium and long term improvements.
Additionally, some individual pull requests from 1.0.5 which got pushed back for the 1.0.6 milestone ([PR 1706] (https://github.com/zcash/zcash/pull/1706) & [PR 1990] (Convert entire source tree from json_spirit to UniValue by str4d · Pull Request #1990 · zcash/zcash · GitHub)) were worked on this week in addition to some other tickets regarding [“opportunistic note merging”] (Develop a better (wrt efficiency and information leakage) note selection heuristic when sending private funds · Issue #1360 · zcash/zcash · GitHub). Next week, engineering will be doing initial ticket triaging and further development for [1.0.6] (1.0.6 Milestone · GitHub), slated for release on the 13th of February.
This week we also did a ton of work getting the new website ready and it’s looking great. We’re thinking it’ll be ready to go live late next week!
Also, some of the Zcash team will be heading to the [Construct conference] (http://www.coindesk.com/events/construct-2017/) in SF Monday and Tuesday next week and will be hosting a developer workshop as part of the event.
And in case some of you didn’t notice, we pushed back our first Show & Tell to next week (Friday, Feb. 3rd at 3p PT/6p ET/11p UTC). The event will be streamed at [this link] (Zcash Show & Tell: David Mercer (Mac & Windows client port developer) - YouTube) and feature David Mercer (@anon47418038) who has some exciting demos to show. 
That’s all for this week!