Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

Zcash and Jaxx Announce ZEC approved and live on iOS Appstore

Toronto, ON – April 12, 2017 – Today marks
another historic day for Zcash as the privacy-oriented cryptocurrency
announces its approval on the App Store via Jaxx’s iOS platform.

The team behind Zcash includes some of the leading scientists behind
the advanced zero-knowledge technology used in the protocol. Together
with expert engineers, they are continuously researching and developing
improvements to the infrastructure and usability for users and
third-party services like Jaxx.

Zooko Wilcox, CEO of the company behind Zcash development, Zerocoin
Electric Coin Company, said, “Jaxx is a very simple, easy-to-use wallet
and the team behind it has been a pleasure to work with. I’m delighted
that thanks to them, hundreds of millions of iPhone users can, for the
first time send and receive Zcash from their phones.”

Jaxx was the first wallet to integrate Zcash following its mainnet
launch on October 28, 2016, and is thrilled to now have Zcash available
on its iOS platform. Apple has a rigorous approval process, especially
for allowing cryptocurrencies onto the App Store, and their approval is a
clear indication that Zcash is a fast growing and well respected
technology.

Anthony Diiorio, CEO of Jaxx, said, “The privacy aspect of their
technology meshes really well with Jaxx’s philosophies. We’ve been
working on a Zcash-integrated iOS version for a long time and we’re over
the moon that Zcash has been approved on the App Store.”

Jaxx also confirmed today that they are in talks with Zcash on the
possibility of supporting ZEC shielded addresses. Currently, Jaxx
supports transparent addresses which behave similarly to Bitcoin,
publishing transaction data publicly to the blockchain. While the mere
use of shielded addresses by others provide greater privacy for
transparent addresses compared to Bitcoin, official support for shielded
addresses in Jaxx will significantly enhance capabilities for users.

“Zcash is a very well run project and it’s been an absolute pleasure
to work with Zooko and team. We look forward to continuous collaboration
between our two projects, especially for when we implement Zcash’s
shielded addresses,” said Diiorio.

In addition to being integrated on all of Jaxx’s platforms, Zcash
also announced its integration on a second wallet, SmartWallet, a
Brazilian money application.

Jaxx’s iOS version with Zcash is now available for download via jaxx.io or on the Apple App Store.

Zcash CEO Zooko Wilcox and Jaxx CEO Anthony Diiorio are available for interview.

About Zcash:

The Zcash Company is a science-driven team; a combination of academic
expertise in computer science and cryptography with security software
engineering talent. We are developing the next generation of secure
digital currency and blockchain technology through the use of
zero-knowledge proofs, to guarantee privacy and confidentiality. We aim
to set a new standard for privacy. The Zcash protocol is a decentralized
and open-source cryptocurrency offering total payment confidentiality.
Unlike Bitcoin, Zcash transactions automatically hide the sender,
recipient, and value of all transactions on the blockchain. It is based
on peer-reviewed cryptographic research, and built by a world-class,
security-focused engineering team. However, as with any new technology,
there is risk involved. Currently the team is focused on building and
maintaining an open, permissionless system that is viable, robust, and
justifiably reliable and secure for users.

About Jaxx:

Jaxx is a multi-token blockchain wallet that provides a unified
experience across 9 platforms and devices, including Windows, Apple and
Linux desktops, Apple and Android mobile devices and tablets, as well as
Google Chrome and Firefox extensions. The Jaxx wallet enables
crypto-to-crypto exchange with frictionless in-wallet conversion via
Shapeshift. Users are always in control of their keys and Jaxx neither
holds nor has access to customer funds. Design and user experience
driven, and built with simplicity in mind, Jaxx’s mission is to become
the interface to the blockchain world.

Zcash (ZEC) Pre Release v1.0.8-1

Security Announcement 2017-04-13

Synopsis: A bug related to transaction priority
handling may allow an attacker to crash Zcash nodes (DoS) via a
specially crafted transaction. A fix is implemented in zcashd release 1.0.8-1.

There is a separate release post documenting the included changes.

ZcashCo, and several exchanges, wallet vendors, and miners have
already deployed a mitigation as well as detectors for this attack
vector. No attacks have been detected.

Who is at Risk: Users are at risk who rely on zcashd releases starting with 1.0.4 up to and including 1.0.8.

We have collaborated with major exchanges, wallet providers, and
miners and they have already mitigated this issue for their services.

Who is not at Risk: Users who have upgraded to zcashd 1.0.8-1, or rely on a service which has done so are not at risk.

How can at-risk users protect themselves?

Upgrading to zcashd release 1.0.8-1 is the most certain protection.

For users of third party services (such as exchanges, wallets,
or mining pools), check if the service has announced upgrading to
zcashd 1.0.8-1.

How can I tell if an attack is occurring? ZcashCo and several large
exchanges, wallet providers, and miners have deployed sensors which detect
attacks against this vector. In the event that an attack is detected,
the ZcashCo will take the following actions:

The Zcash developers will issue an in-band alert, causing all
zcashd nodes to announce the potential attack.

ZcashCo will coordinate in private channels with major exchanges,
wallet vendors, and mining outfits to alert them of the attack and
to post their own announcements.

Note: The major exchanges, wallet vendors, and miners we are in
communication with are already protected against such an attack.

Impact:If an attack transaction is successfully executed then only
the users running vulnerable clients which have accepted the
transaction in their mempool will be vulnerable. Accepting an attacker's
transaction with an old client may cause the Zcash client to crash.

Technical Background: Zcash, like Bitcoin, assigns a
priority to transactions in order to decide whether they should be
accepted into a node's mempool. In practice the current transaction
volume for Zcash is sufficiently low that this rarely has an effect, but
the mechanism is still enabled. In Zcash 1.0.4, a change was made to
this calculation to boost the priority of shielded transactions.
However, an error in this code can –in circumstances that are normally
rare, but can be forced by an attacker– result in an out-of-bounds
memory access, which causes a segmentation fault.

Followup Announcements:

See the security notifications page for further updates on this
issue, and any future security issue.

Zcash Announces Apple App Store Approval on Jaxx’s iOS Platform

An exciting update for the Zcash ecosystem comes from the Jaxx
team. Jaxx were one of the very first wallets to support Zcash,
implementing it into their Android and desktop wallets only days after
the Zcash launch on October 28th.

In their initial statement announcing integration with Zcash, they
indicated upcoming support in their iOS wallet and today, Zcash on Jaxx for iOS is live!

Anthony Di Iorio, CEO of Jaxx, says, "The privacy aspect of their
technology meshes really well with Jaxx’s philosophies. We’ve been
working on a Zcash integrated iOS version for a long time and we’re over
the moon that Zcash has been approved on the App Store."

Jaxx for iOS has 32,000 users and growing. With the inclusion of
Zcash, now hundreds of millions of users have the ability to send and
receive Zcash from their iPhones.

Jaxx has additionally confirmed their interest in supporting shielded addresses
in the future. As more wallets with easy-to-use interfaces introduce
shielded addresses into their software, not only will the users of those
applications gain enhanced privacy for transactions they send and
receive but also, the ecosystem as a whole will become more private.

We are excited about the expansion of Zcash into additional operating
systems and hope to see this trigger more support for Zcash in iOS
moving forward.

Zcash [ZEC] 1.0.9 Postponed

We have decided to postpone the Zcash Sprout 1.0.9 release from today's
planned release date to mid-May.

We have been planning a transition in May of our release process and
policies to improve our collaborations with community and industry
partners, to improve safety, and to prepare for our Sapling protocol
upgrade. Due to the v1.0.8-1 hotfix release last week, it makes
the most sense to postpone 1.0.9 until the new process is in place.

We'll post an announcement of the new release process and policies ahead
of the 1.0.9 release. We have exciting features and collaborations
underway. Stay tuned!

ZCASH [ ZEC] Payment Contexts & Reusing Shielded Addresses

The privacy provided in Zcash allows users to disclose a shielded payment address publicly or to multiple individuals without the worry of transactions sent to that address becoming linked in the blockchain. When sending to or from a shielded address, the data involved in that side of the transaction is encrypted (regardless if receiving from or sending to a transparent address).

Distinct Payment Contexts

While shielded addresses are encrypted, the scope of the payment address is something to consider.

If Alice has a small business she runs out of her home, any business
mail sent to her home address provides a clear link between her personal
life and business even if the details of the correspondences are
secured in envelopes. In a similar fashion, if Alice has a business
which accepts Zcash for services or products and personal blog which she
posts the same Zcash address for accepting donations to, it is possible
for a third-party to correlate the business and blog.

It is therefore recommended for Alice to use separate payment
addresses for her business and blog, similar to having a separate
business address (such as a private mailbox) for receiving business
correspondence.

Reusing Shielded Addresses

Note that it is advisable to reuse shielded addresses for
receiving payments within the same context. While it has become standard
practice for generating a new address for each receiving transaction in
most cryptocurrencies, that is not a problem when using shielded
addresses. In fact, it saves the extra hassle of tracking many different
addresses and reduces the number of outputs consumed when
creating a new transaction. This reduction makes overall transaction
size smaller and requires less resources for generating a zero-knowledge
proof.

A great example of this distinction can be seen on the donations page for the non-profit Riseup.net. When a supporter goes to make a bitcoin
donation, they're provided with a newly generated address but when a
supporter makes a Zcash donation, the same shielded address is provided
for everyone!

One Shielded Address Per Purpose

We encourage folks to follow suit and reuse shielded addresses for
accepting Zcash payments within the same context. For contexts which
should remain unassociated, however, make sure to keep the shielded
addresses unassociated as well.

ZCASH [ZEC] - Dev update April 21, 2017

At the beginning of the week, we had the first of our regularly scheduled (once a month) meetings about the pre-Sapling hard fork (HF0) in which we narrowed down tickets into a select group using the tag HF0 wishlist. These tickets address the meta goal of making HF0 and future hard forks safer and simpler.

We also had a topical meeting around revamping the release lifecycle and policy An overview of which will be released as a blog post in the very near future. We also touched on the concept of development environments but did not come to a final resolution on their implementation across the areas in which they aim to be used.

Work on other process-related concepts like roadmapping and security incident procedure were also discussed more this week with the goal ofreleasing public documents outlining them coming in the near future.

And with last week’s securityincident engineering timesync behind us, regular work on pull-request review and pre-Sapling features (payment disclosure, payment offloading and XCAT) were back in full swing this week.

We also continued work on the block observatory and testnet faucet mentioned in last week’s update.

A handful of new FAQs
were added to the website this week and next week, keep an eye out for
the initial version of our zk-SNARK section in addition to the newest in
the explaining zk-SNARK blog series.

We’ve also planned a Google hangout and livestream with Zcash
engineers to discuss and explain zk-SNARKs in two weeks on May 6th at
16:00 UTC. Those interested can request an invite to join the hangout or
post questions as comments in the video beforehand and/or questions in the chat box when the session is live.

As a reminder, check out the working groups
wiki page if you’re interested in becoming more involved in Zcash core
development and ecosystem maintenance and growth. Also, don’t forget to
ping us if you’d like to be invited to one of our future topical meetings, we’d love to include those from the greater community who are interested!

Zcash- Explaining SNARKs Part V: From Computations to Polynomials

In the three previous parts, we developed a certain machinery for dealing with polynomials.
In this part, we show how to translate statements we would like to prove and verify to the language of polynomials.
The idea of using polynomials in this way goes back to the groundbreaking work of Lund, Fortnow, Karloff and Nisan.

In 2013, another breakthrough work of Gennaro, Gentry, Parno and Raykova defined an extremely useful translation of computations
into polynomials called a Quadratic Arithmetic Program (QAP).
QAPs have become the basis for modern zk-SNARK constructions, in particular those used by Zcash.

In this post we explain the translation into QAPs by example. Even
when focusing on a small example rather than the general definition, it
is unavoidable that it is a lot to digest at first, so be prepared for a
certain mental effort :).

such that(c1⋅c2)⋅(c1+c3)=7" role="presentation">(c1⋅c2)⋅(c1+c3)=7.The first step is to present the expression computed from c1,c2,c3" role="presentation">c1,c2,c3 as an arithmetic circuit.

Arithmetic circuits

An arithmetic circuit consists of gates computing arithmetic
operations like addition and multiplication, with wires connecting the
gates.
In our case, the circuit looks like this:

The bottom wires are the input wires, and the top wire is the output
wire giving the result of the circuit computation on the inputs.

As can be seen in the picture, we label the wires and gates of the
circuit in a very particular way, that is needed for the next step of
translating the circuit into a QAP:

When the same outgoing wire goes into more than one gate, we still think of it as one wire - like w1" role="presentation">w1

in the example.

We assume multiplication gates have exactly two input wires, which we call the left wire and right wire.

We don't label the wires going from an addition to multiplication gate, nor the addition gate; we think of the inputs of the addition gate as going directly into the multiplication gate. So in the example we think of w1" role="presentation">w1

and w3" role="presentation">w3 as both being right inputs of g2" role="presentation">g2

.

A legal assignment for the circuit, is an assignment of
values to the labeled wires where the output value of each
multiplication gate is indeed the product of the corresponding inputs.

So for our circuit, a legal assignment is of the form:
(c1,…,c5)" role="presentation">(c1,…,c5)

where c4=c1⋅c2" role="presentation">c4=c1⋅c2 and c5=c4⋅(c1+c3)" role="presentation">c5=c4⋅(c1+c3)

.

In this terminology, what Alice wants to prove is that she knows a legal assignment (c1,…,c5)" role="presentation">(c1,…,c5)

such that c5=7" role="presentation">c5=7

.
The next step is to translate this statement into one about polynomials using QAPs.

Reduction to a QAP

We associate each multiplication gate with a field element:
g1" role="presentation">g1

The idea for the definition is that the polynomials will usually be zero on the target points,
except the ones involved in the target point's corresponding multiplication gate.

Concretely, as w1,w2,w4" role="presentation">w1,w2,w4

are, respectively, the left, right and output wire of g1" role="presentation">g1;we define L1=R2=O4=2−X" role="presentation">L1=R2=O4=2−X, as the polynomial 2−X" role="presentation">2−X is one on the point 1" role="presentation">1 corresponding to g1" role="presentation">g1 and zero on the point 2" role="presentation">2 corresponding to g2" role="presentation">g2

.

Note that w1" role="presentation">w1

and w3" role="presentation">w3 are both right inputs of g2" role="presentation">g2.Therefore, we define similarly L4=R1=R3=O5=X−1" role="presentation">L4=R1=R3=O5=X−1 - as X−1" role="presentation">X−1 is one on the target point 2" role="presentation">2 corresponding to g2" role="presentation">g2

and
zero on the other target point.

We set the rest of the polynomials to be the zero polynomial.

Given fixed values (c1,…,c5)" role="presentation">(c1,…,c5)

we use them as coefficients to
define a left, right, and output "sum" polynomials.
That is, we define

as above given some c1,…,c5" role="presentation">c1,…,c5.Let's evaluate all these polynomials at the target point 1" role="presentation">1

:

Out of all the Li" role="presentation">Li

's only L1" role="presentation">L1 is non-zero on 1" role="presentation">1.So we have L(1)=c1⋅L1(1)=c1" role="presentation">L(1)=c1⋅L1(1)=c1.Similarly, we get R(1)=c2" role="presentation">R(1)=c2 and O(1)=c4" role="presentation">O(1)=c4

We found 1st block after few hours of runing this pool We are currently mining only ZCash

Payment from 0.01

Zcash-Explaining SNARKs Part V: From Computations to Polynomials

In the three previous parts, we developed a certain machinery for dealing with polynomials.
In this part, we show how to translate statements we would like to prove and verify to the language of polynomials.
The idea of using polynomials in this way goes back to thegroundbreaking work of Lund, Fortnow, Karloff and Nisan.

In 2013, another breakthrough work of Gennaro, Gentry, Parno and Raykova defined an extremely useful translation of computations
into polynomials called a Quadratic Arithmetic Program (QAP).
QAPs have become the basis for modern zk-SNARK constructions, in particular those used by Zcash.

In this post we explain the translation into QAPs by example. Even
when focusing on a small example rather than the general definition, it
is unavoidable that it is a lot to digest at first, so be prepared for a
certain mental effort

Zcash [ZEC] Internet Money

Six months ago today we launched an ambitious attempt to create the future of Internet Money.
We dream of giving every human on earth free and equal access to a
global, programmable financial system. Internet money is to government
money as email is to national postal services.

Today, exactly six months after launch, is the first day that the Zcash market cap reached $100M.

Jaxx told us that they saw the rate of Zcash transactions by their users quadruple from February to March (the most recent month that they have statistics).

We have big projects in the works, and so do many of our partners in the large and growing Zcash ecosystem. Stay tuned!

And remember: even though we created Zcash, we do not own or control
it. Humanity is too vast and diverse to accept our economy falling under
anyone’s control. Zcash is a decentralized, open-source network that
anyone on Earth can use, extend, or modify without needing the
permission of anyone else. We started the Zcash project, but its future
lies in your hands.

Our new process has slightly more time between releases. We'll usethis extra time to add more thorough pre-release and package testing,have a retrospective meeting for each release, and begin per-releasecoordination for each of our longer term roadmap priorities.

Clearer Coordination

An essential change with this new policy is an explicit release
lifecycle, the most important parts of which are the release date and
the deprecation date, about four months later on the 4th third-Tuesday
after the release.

For active releases which have not yet reached their deprecation date,
we make our best effort to provide security fixes, follow up to bug
reports, avoid disruption on the production network, and help users to
upgrade to the latest release. For deprecated releases the only help
we promise is in upgrading to the latest release.

In order to codify this cycle, we even intend to introduce a feature
called auto-senescence starting in 1.0.9 which will cause nodes to
automatically exit when they detect they've reached their deprecation
phase. This feature will always have an opt-out, since (as discussed
below) our goal is to give users their own choice, not to coerce or
control them.

An important side-note: this policy is defined entirely in the context
of a single release, so a user does not need to know anything about
our future releases or our new policies for those releases in order to
understand this policy for their own installation.

User autonomy: deprecation vs auto-upgrade

We consider user choice to be a paramount value to protect. Although
this may sound abstract or overly dramatic it directly affects our
technical design choices and plays out as our choice of a deprecation approach, rather than an auto-upgrade approach.

Auto-upgrade of apps has become widespread, because of numerous
advantages. One of the most important advantages is in ensuring old
software is rare so that vulnerabilities and technical debt are removed
from the network thus making the whole safer.

Meanwhile, most users rely on default behavior, and a default
auto-upgrade puts them de facto under the influence of a sole group of
application developers. Most people believe this is fine, and while it
often has been, we believe we're seeing a deep shift in de-facto
governance due to these kinds of technological developments.

We prefer deprecation rather than auto-upgrade, where users must themselves choose either to upgrade to our new releases or other people's
alternatives. We believe this still gives the systemic advantage of
removing old software, yet users must explicitly opt-in to each upgrade,
and each time is an opportunity to educate themselves and decide on a
different fate.

How is deprecation better for Zcash?

Because users and our development community have this agreement, we can
begin relying on this schedule for protocol upgrades, security fixes,
usability improvements, and removing technical debt.

Once this policy is put in to place starting with our 1.0.9 release
in May, we are on track to begin the protocol upgrade to the Sapling feature set.

We'll also be able to roll out usability improvements, such as payment
disclosure and in several months' time we'll know that support for
those improvements should be widespread, and therefore all wallets
and vendors will benefit from ecosystem-wide consistency.

I emphasized "should be" because users may always choose to reject our
deprecation policy by editing their local configuration or installing
alternative implementations. In that case, we'll have a clear signal
from the user community about their reservations with our direction,
so this is one of the key mechanisms of our improving governance.

We'd Love to Hear From You

Please reach out to us with any feedback on this new release policy. You can find us on the community chatemail.

[1]We're still determining when and how to deprecate releases before 1.0.9.

Zcash [ZEC] New public block explorer

I've been debating tossing up a public Insight
instance for zcash, both because its a block explorer and because there
is increasing demand for one that people can use for its API calls for
various reasons (broadcasting transactions without having your own full
node, various wallet applications, etc).

The recent performance issues on the network tipped me over into
doing so, as zcha.in was having issues because of it and more than one
view into the network is a Good Thing!

zcha.in has great features Insight doesn't, and Insight has some that
it lacks, so I think this is a win for everyone. Its going to cost a
bit to run it, especially once traffic on it goes up, so please donate
to support it via any of the methods at https://zcash.mercerweiss.com/...

Thanks again for everyone's support, and let me know if you find any issues with it!

ZCASH [ZEC] NEW Pool | PPLNS | 0.5% Fee |

I just added a pool for Zcash https://zec.coin-miners.info HOW TO CONNECT stratum+tcp://stratum2.coin-miners.info:3032 ( Auto VarDiff - for GPU ) stratum+tls://stratum2.coin-miners.info:3033 (SSL Support, Automatic VarDiff - Encrypted stratum is currently only supported by the Claymore and Optiminer miner) Nicehash1 : stratum+tcp://stratum2.coin-miners.info:3034

Happy mining zcash

The Zerocoin Electric Coin Company (ZECC), developers of the Zcash™
digital currency, today announced a partnership with J.P. Morgan, one of
the world’s largest banks, to add technology from Zcash to J.P.
Morgan's enterprise blockchain platform, Quorum.

Zooko Wilcox, CEO of the Zerocoin Electric Coin Company said, “We’re
delighted to be working with J.P. Morgan on this project. Quorum’s
innovative, open source design demonstrates that J.P. Morgan is leading
the way for applications of distributed ledger technology in global
finance. Zcash is the leading technology for cryptographic protection of
assets on a distributed ledger. Combining these will unlock
transformative possibilities.”

The team behind Zcash includes many of the scientists and engineers
behind the advanced cryptography that enables Zcash’s unique privacy and
confidentiality. They recently announced plans to explore potential
enterprise applications for this technology. Quorum is the first
distributed ledger platform that will feature this zero-knowledge
security layer (ZSL). J.P. Morgan's Quorum is an enterprise-ready
distributed ledger and smart contract platform, based on the Ethereum
protocol. It is open source and can be freely used and extended.

Quorum has been featured in presentations by the Enterprise Ethereum
Alliance. J.P. Morgan is a founding member of the Enterprise Ethereum
Alliance, and ZECC has just announced that it has also joined the
Enterprise Ethereum Alliance.

“By adding the Zero-knowledge Security Layer into Quorum, we are able
to explore how state of the art cryptographic privacy technology will
enhance the next generation of financial services applications.”
– Suresh Shetty, J.P. Morgan Executive Director and Blockchain Center of
Excellence Lead Architect

About Zerocoin Electric Coin Company:
The Zerocoin Electric Coin Company is a science-driven team; a
combination of academic expertise in computer science and cryptography
with security software engineering talent. We are developing the next
generation of secure digital currency and blockchain technology through
the use of zero-knowledge proofs, to guarantee privacy and
confidentiality. More information on Zerocoin Electric Coin Company and
the Zcash protocol is available at https://z.cash.

About J.P. Morgan’s Corporate & Investment Bank:
J.P. Morgan’s Corporate & Investment Bank is a global leader across
banking, markets and investor services. The world’s most important
corporations, governments and institutions entrust us with their
business in more than 100 countries. With $21.4 trillion of assets under
custody and $391 billion in deposits, the Corporate & Investment
Bank provides strategic advice, raises capital, manages risk and extends
liquidity in markets around the world. Further information about J.P.
Morgan is available atwww.jpmorgan.com.

Jay Graber (2): Change help text examples to use Zcash addresses Poll on getblocktemplate result rather than use bare sleep to avoid race condition.

Nathan Wilcox (39): [Direct master commit] Fix a release snafu in debian version string. Show toolchain versions in build.sh. Start on a make-release.py script; currently just arg parsing and unittests [unittests fail]. Update version spec by altering test; also update regex to pass single 0 digits in major/minor/patch. Add another case from debian-style versions. Add all of the zcash release tags in my current repo as positive test vector. Add support for beta/rc release versions. Add version sorting, assert that RELEASE_PREV is the most recent release. Make SystemExit errors less redundant in output; verify clean git status on master. Always run unittests prior to actual runs. Make --help output clean by not running self-test. Add an option to run against a different repo directory. Make sure to pull the latest master. Exit instead of raising an unexpected exception, since it's already logged. Implement PathPatcher abstraction, clientversion.h rewrite, and build numbering w/ unittests. Implement the IS_RELEASE rule for betas. Generalize buildnum patching for both clientversion.h and configure.ac. Modify the APPROX_RELEASE_HEIGHT. Remove portions of ./doc/release-process.md now implemented in make-release.py. Switch from sh_out_logged to sh_log. Shorten the arg log line. Commit the version changes and build. Generate manpages; commit that; improve error output in sh_log. Polish logging a bit more. Tidy up / systematize logging output a bit more. First full-release-branch version of script; rewrite large swatch of release-process.md. [Manually tested.] Enable set -u mode. Fix a variable name typo. Reuse zcash_rpc. Do not use -rpcwait on all zcash_rpc invocations, only block when starting zcashd. Fix release-process.md doc usage for make-release.py to have correct arguments and order. Include release version in commit comments. Examine all future versions which are assumed to follow the same Version parser schema. Consider both beta and rc versions to be IS_RELEASE == false. Add a few more version strings to positive parser test. Define the deprecation policy for 1.0.9. Clarify that the feature is automated shutdown. make-release.py: Versioning changes for 1.0.9. make-release.py: Updated manpages for 1.0.9.

ZCASH [ZEC] Dev update

Meta:
As a reminder, the goal of the working
groups is to eventually have regular, specialized meetings so that each
area of development can move forward more efficiently and provide
meeting notes or reports of their recent progress to include in these
updates.

If you have interest in participating in the existing working groups
or jumpstarting one of the proposed working groups, let us know!

Protocol:
While discussion about HFO and Sapling
were minimal this week due to focusing on the 1.0.9 release, we did
manage to merge support for automatic shutdown of deprecated client
versions (PR 2297)
which is relevant to future hard forks for protocol upgrades. Note that
this automatic shutdown is default but can be bypassed via flags in
your configuration file.

A couple of devs spent time this week looking at proving optimizations for generating zk-proofs.

Release:

We released version 1.0.9 on Wednesday this week. Tickets included in 1.0.9 can be seen in the milestone

Our next release date is for the pre-1.0.10 CI deploy3
on June 6th. As a reminder, these CI releases are scheduled in between
client releases so upgrades to development infrastructure and the Zcash
client have distict due dates.

The 1.0.10 release is set for June 20th and you can keep track of what will be included in the milestone

Development infrastructure:
A few minor changes
to the dev infrastructure were included in 1.0.9, however, as mentioned
above, future changes to the dev infrastructure and continuous
integration will happen via separate milestone dates from now on.

Network infrastructure:
In the 1.0.9 release, many benchmarks were included and enhanced to better test network behavior. AMQP1 was also finally merged which extends messaging capabilities for third-party devs.

Berkeley DB replacement:
No further discussions this week. See the Wallet DB to SQLite project for current status.

It’s worth noting that the current proof of concept for Payment
disclosure uses Berkeley DB and we’re considering swapping out with
SQLite before the feature is released.

Miscellaneous:
This week was quite busy for a few
of us in the company, attending Consensus 2017 and Token Summit in NYC.
Both were great opportunities to do some business development and
outreach!

We had an internal demo of XCAT and progress is certainly moving
forward! With the XCAT, Payment offloading and Payment disclosure proof
of concepts coming along nicely, it shouldn’t be too long now until we
start seeing some of these as experimental features in the Zcash client.

We’re a little late on the final installment of the SNARK explainers but expect to see that next week!

Zcash [ZEC] wallets list

ZCash GUI Wallets

To make the user experience with ZCash
more convenient, GUI (Graphical User Interface) wallets have already
been created by the community and by companies. Here are the wallet
options available to ZCash users as of March 2017:

This wallet is suitable for users and miners who work on desktop
systems and wish to have full control of the ZCash private keys. It has
all the typical features that might be expected from a desktop
crypto-currency wallet:

Balance/monetary amounts

List of transactions

Status of blockchain synchronization

Management of ZCash addresses (including Z addresses)

Sending ZCash

It communicates with the ZCash server (zcashd) running locally via the zcash-cli program. When installed, it is packaged as one executable JAR file (ZCashSwingWalletUI.jar) and requires Java (JDK7 or later). The details of how to obtain, and install the ZCash Desktop GUI wallet may be found on GitHub. Users who are less experienced with working on a command line, may instead use this quite-user-friendly installation guide and usage guide.

From a TREZOR representative, “This is a hardware Bitcoin wallet; a
single purpose device which allows you to make secure Bitcoin
transactions. With TREZOR, transactions are completely safe even when
initiated on a compromised or vulnerable computer. Because the use of
TREZOR is very easy and intuitive we believe it will help Bitcoin
adoption among people not familiar with the security issues.”
TREZOR Web SiteThis is a hardware wallet with strong security, Usage: Desktop, Private key control: Owned by the user

From the Bitsquare web site: “Bitsquare is an open-source desktop
application that allows you to buy and sell bitcoins in exchange
for national currencies, or alternative crypto currencies.” Bitsquare
functions as a decentralized privacy-focused exchange and wallet with a
strong community behind it. It also supports ZCash: Bitsquare Web Site.
License: Open source – AGPL, Usage: Desktop, Private key control: Owned by the user

waterhole.io is a trading platform and a wallet provider for multiple crypto-currencies. It already supports ZCash. Quote from the official announcement: Waterhole development team is pleased to announce the GUI mobile wallet for Zcash…. Along with the first Zcash GUI wallet, the built-in escrow trading mechanism allows users to trade and chat in-app directly. The OTC feature will be available to existing BTC users and all future Zcash users from day 1 when the new coins get launched. Waterhole already have a lot of users and making BTC and ZEC faucet regularly for new registered users.

ZCASH [ZEC] - Dev update June 9, 2017

Meta:
Progress has been made for a few of the
working groups this past week but we’re still hoping to encourage others
to take on coordination of existing and proposed groups. If you’re
interested in becoming a coordinator, note taker or member of one of the
working groups (listed above), certainly get in touch. The minimum goal
is to have one meeting per month per group with a status report about
the recent progress made.

Protocol:
We made progress on discussing the
Sapling crypto upgrade this week, the coordinator lead an informational
meeting to highlight the plans and desired features for the upgrade to
Zcash employees and external interested parties who reached out to us
about attending. You can check out the agenda and notes for the meeting for details about what was discussed.

Miscellaneous:We created a new Github project called Beswick which will be the codename for improving the z_sendmany RPC and new RPCs such as z_decryptsinceblock.

We made futher progress on the UX ecosystem research project which includes studying two Zcash supporting wallets and documenting certain actions such as sending/receiving ZEC and making a purchase. At the conclusion of this project, we’ll have public reports to share which will not only benefit Zcash developers but also the greater cryptocurrency ecosystem. We’re learning a lot with this project and are excited to share our findings.

We also just published Pay-to-sudoku Revisited. PTS is a project which allows a verifier to pay a prover for knowing the solution to a given sudoku puzzle without the solution itself being revealed using zero-knowledge contingent payment (ZKCP), an invention by Greg Maxwell.

We’re also making progress on a central documentation source which will merge the various Github wiki’s, /doc files in zcashd and some information on https://z.cash. More details next week!

ZCASH [ZEC] Dev update - June 16, 2017

This week I’m opting for a shorter and simpler format for the dev update compared to recent updates which were categorized by working groups. This is due to some internal shifting + adjusting roles within the company, employees taking much needed time off and focus on the upcoming release.

Most of this week has seen a lot of engineering stabilization and maintenance work. Our focus has been on ticket triaging and review for next week’s 1.0.10 release We’ve addressed a number of issues so far including an information leak in chained joinsplits (PR 2440), a non-critical mis-application of consensus code from upstream resulting in a local bug(PR 2386) and a couple of documentation updates (PR 2429) & #2421).

We’ve finished up the proof of concept for the first iteration of payment offloading. After testing and review for the implementation and further security + stabilization work for the network, we’ll release this as an experimental feature.

We progressed more on design discussions and development for the XCAT implementation with Zcash and Bitcoin (ZBXCAT)

Some final touches are being done on a Japanese translation for https://z.cash which will most likely go live next week.

We progressed in our initial UX research of the Zcash ecosystem.
We’ll be concluding this project next week and publishing reports soon
thereafter.

More work on organizing the Sapling upgrade took place this week and
you can expect an update on the goals for Sapling via a blog post next
week.