Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

Zcash is the first open, permissionless financial system
employing zero-knowledge security.

The Zcash genesis block will launch in 10 days. Zcash is
currently in testnet (testnet coins have no value and will never hold monetary
value); our engineering roadmap is publicly available
here. If anyone
says that they will pay you Zcash before October 28, 2016, then there must be
some mistake, because Zcash will not exist until then.

Please note, Zcash is still an experimental technology, and this
is only the beginning of its (hopefully) long life. It is based on
peer-reviewed cryptographic research, and built by a world-class,
security-focused
engineering team, but there is risk involved. We are
consistently focused on building and maintaining an open, permissionless system
that is viable, robust, and justifiably reliable and secure for users.

Visit the technologypage
to learn more about the Zcash protocol, and how to join the
Zcash community.

What is Zcash?

Zcash offers total payment confidentiality, while still maintaining a
decentralized network using a public blockchain. Unlike Bitcoin, Zcash
transactions automatically hide the sender, recipient, and value of all
transactions on the blockchain. Only those with the correct view key can see
the contents. Users have complete control and can opt-in to provide others with
their view key at their discretion.

Zcash transactions do not depend on the cooperation of other parties.

How does it work?

Since the contents of Zcash transactions are encrypted and private, the
system uses a novel cryptographic method to verify payments.

Zcash uses a zero-knowledge proof construction called a zk-SNARK,
developed by our team of
experienced cryptographers. These constructions allow the network to maintain a
secure ledger of balances without disclosing the parties or amounts involved.
Instead of publicly demonstrating spend-authority and transaction values, the
transaction metadata is encrypted and zk-SNARKs are used to prove that nobody
is cheating or stealing.

Who is behind Zcash?

About

Technology

Zcash is a decentralized and open-source cryptocurrency that offers privacy
and selective transparency of transactions. Zcash payments are published on a
public blockchain, but the sender, recipient, and amount of a transaction
remain private.

Zcash is based on peer-reviewed cryptographic research, and built by a
security-specialized engineering team on an open source platform based on
Bitcoin Core's battle-tested codebase. Our improvement over Bitcoin is the
addition of privacy. Zcash uses advanced cryptographic techniques, namely
zero-knowledge proofs, to guarantee the validity of transactions without
revealing additional information about them.

Our zero-knowledge proving scheme makes it possible to conceal values and
other identifying information from the public blockchain. Users simply prove
that the values balance out and that they are not double-spending the amount
they want to send.

See our FAQ for
technical, business, governance, economic or general questions.

Company Values

The Zcash company aims to set a new standard for privacy through the use of
groundbreaking cryptography.

In an open and programmable financial system, privacy is the only way to
ensure fungibility and guarantee that cryptocurrency can be interchangeable as
a fluid medium of exchange for users. Companies need the protection of privacy
along their supply chain in order to conduct their business, especially in the
context of public blockchains. In addition, we believe that personal privacy is
necessary for core human values like dignity, intimacy, and morality.

We are a science-driven team. Our scientists and engineers are the
discoverers of the underlying scientific principles and the designers of the
protocol; we are not the controllers or the power-holders, and do not control
the mining or distribution of Zcash. Every user of Zcash contributes to its
decentralization, helping to protect it against failure and corruption. Our team
is one among many participants in the network. We created Zcash, but its
ultimate destiny lies not in our hands, but in yours.

Join us!

Need help? Want more details? Have ideas? We are an inclusive and growing
community. Come on in!

I don't think there's a windows version yet, but it runs fine on linux.

Be aware that this is a a very slow "test-only" cpu miner, so once a
public GPU miner will be available, hashing will be much faster.

There is no ICO.

The coin has not launched yet, it will or should launch around 28.th of
October, there's testnet currently where miners, pools, transactions etc. are
tested.

Mining is done with a new algo called "Equihash" - it's not
compatible with any ASIC, it's currently mineable by CPU and GPU - there are no
public miners yet.
However there is a big open source miner contest here:http://zcashminers.org/ - you can earn up to
$30k if you publish your miner.
The Algo is very slow, about 0.7-1 soltutions (hashes) per second. (Yes, you
read that right). I'll be mining it for sure

The technology looks interesting and promising, there seems to be a big dev
team behind it, it's good to see things are finally getting real.

Twitter is full with messages about zcash, so it seems to catch attention
pretty well, astonished me even more that there's no ANN here.

I've played around with it a lot and hope to have a full functioning pool up at
launch, chances that everything works out and I'll be ready are looking pretty
good right now, stay tuned and get yourself informed about the coin.

I'll update this post once I get more information about miners, pools the exact
launch dates, issues and so on...

This program is intended to make it easy to work with the ZCash client tools
by providing a Graphical User Interface (GUI) that acts as a wrapper and
presents the information in a user-friendly manner.

Zcash limited pre-order started! on Genesis mining

New Release Candidate: Less than One Week to Launch

The Zcash team has been hard at work preparing for the launch, which
is on track for the 28th October. Despite some hiccups due to the
widespread DNS disruptions on Friday, today we deployed the fourth
beta release of the Zcash reference implementation, 1.0.0-rc2, to
the testnet.

We have included mitigations for security issues found by the
NCC Group and Coinspect audits. (#1459, #1464, #1504)

We have merged some changes from Bitcoin to help address potential
denial-of-service vulnerabilities. (#1588, #1589, #1591)

A bug that could cause assertion failures when restarting after a crash
has been fixed. (#1378)

A more efficient CPU Equihash solver written by John Tromp has been
integrated into the built-in miner. This is not used by default, but
can be enabled by adding equihashsolver=tromp to zcash.conf.
Thanks go to John Tromp, and to @sarath-hotspot for providing the impetus
for this improvement. (#1570, #1578)

{NiceHash} Zcash CPU/GPU miner for Linux and Windows

As you might already know, NiceHash will support Zcash from day one (28th of
the October).
We are pushing boundaries and working around the clock so that we can offer you
something user friendly in the front but beast in the back.

Current tests are showing between 5 and 10 H/s for CPU miner. GPU
development isn't far behind.
If all that won't be enough for you, you'll still be able to rent hashing power
to mine Zcash - on demand and with no contracts.

New Release Candidate: Final zk-SNARK parameters

Daira Hopwood | Oct 27, 2016

The Zcash team has been working to finalize the software for the launch of
the Zcash block chain. We are planning to make the launch release available
on the morning (PDT) of 28th October, subject to any last-minute
technical hitches.

We encourage everyone to test this latest 1.0.0-rc4 release by following the
Beta Guide. That will also make sure that you are able to run the
software on your system, and have the zk-SNARK parameters (a ~910 MB download)
ready for launch.

Two Releases

As part of a strategy to reduce technical risk and to ensure auditability,
we have made two releases within a day of each other. Most users should
skip from 1.0.0-rc2 directly to 1.0.0-rc4.

1.0.0-rc3 - bug fixes and dependency upgrades

The intermediate 1.0.0-rc3 release included only bug fixes, and updates of
libraries that Zcash depends on:

The node metrics screen added in the rc2 release caused a bug when the
output was not directed to a terminal, which has been corrected. (#1612)

The tinyformat library was updated in order to mitigate a potential
buffer overflow vulnerability. (#1640, #1349)

A fix for a minor potential race condition was backported from Bitcoin.
(#1634)

A couple of portability problems with the fetch-params.sh script
and the Debian packages have been fixed. (#1053, #1537, #1613)

We have eliminated an error-prone case and a confusing error message
when spending part of a coinbase output (e.g. mining reward).
As a consequence it is now necessary to spend coinbase outputs exactly
so that there is no change; the node will not implicitly select a change
address. (#1616)

For a more complete list of changes, see our 1.0.0-rc3 and 1.0.0-rc4
release github milestones.

Imminent Launch

In the remaining time before launch, we will only make further changes
if they are necessary to correct critical problems that would be an
obstacle to Zcash launching successfully. If all goes to plan, the only
thing remaining is the mainnet genesis block — the code is done!

It takes some time to generate the genesis block, and build the binaries.
We're going to mint the genesis block and prepare binaries etc. the night
before (i.e. this evening, Thursday, Oct 27), and then go to sleep. Then
we will get up and release it the next morning, San Francisco time. Keep
an eye on our Twitter feed!

Zcash Listed on Poloniex:

Third Party Support at Launch

The Zcash core team is thrilled to have many supporters at launch. It
is a sign of a robust and diverse ecosystem already beginning to grow.

Zcash is an experimental new technology and external support is
highly valuable at this nascent stage. As a science-based team, we are
focusing our energies on building and engineering the protocol, and we
do not have current plans to build a GUI wallet. There are multiple
developers in our community who have stepped up to do so.

What follows is a list of some of the wallets and exchange that we currently know about.

A word of caution: there have already been multiple scams and
fraudulent projects, so we suggest researching any third-party
application well before using.

This post is intended for Zcash users who want to involve themselves
in the early phase of the ecosystem but do not know how to install and
run the Zcash software (Linux-only, command-line tool). This post is not
an endorsement of any wallet or exchange. Rather it’s a listing of
current providers – that we know about – who already support Zcash.

We have not yet written down our thoughts about the privacy
consequences of using Zcash via third-party service providers. For the
time being, you could probably just simplify by assuming that when you
use a third-party service provider, the metadata about your transactions
will be visible to others — at least to that provider and probably also
to others who can see the transactions associated with your address, in
the blockchain.

However, if the people you are transacting with use Zcash’s shielded
addresses, then that may give you a degree of privacy even if you are
not yet using shielded addresses yourself. We will write more to explain
the way this works in the future.

WALLETS

From the Cockpit site, “This wallet allows users to
access their ZCash wallet remotely via a Web UI. This makes it ideal for
managing multiple systems mining ZCash. The complete information on how
to install the ZCash Cockpit UI Wallet may be found on GitHub.”

From an official representative, “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 Jaxx representative, “This 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 buying and selling
with frictionless in-wallet conversion. Users are always in control of
their keys and Jaxx neither holds nor has access to customer funds.”

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.”

From a ShapeShift representative, “This is a crucial
piece of infrastructure in the world of Bitcoin. From start to finish,
users can exchange blockchain tokens in seconds, with no account
required. No emails or passwords. No lengthy sign up process. No
accounts. No bid and ask orders. No friction. ShapeShift's goal is the
fastest, safest, and most convenient way to swap digital assets.

From the YUNBI website, “Formerly Peatio Exchange, YUNBI is an open source cryptocurrency exchange cofunded by BitFundPE.”

There are many more discussions open on the Forum. Join the community to contribute and participate!

If you are interested in providing external support by creating a wallet or supporting Zcash on your exchange, please view theZcash Integration Guide, and contact [email protected]
to reach a real-live human for further discussion. If you want favorite
exchange or wallet to support Zcash, we encourage you to reach out to
them and ask!

Zcash New Release: 1.0.2

Today we're announcing the release of Zcash 1.0.2 which fixes a bug
that prevented creating transactions to multiple shielded recipient
addresses. This is an implementation bug in the zcashd wallet which does not impact the consensus protocol.

The list of changes included in this release:

We fixed a bug to ensure that JoinSplit transactions to multiple z-addresses will succeed. (#1790)

We changed z_sendmany to check if the size of a transaction for a given number of outputs will be valid. (#1808)

We fixed a bug that could crash the miner when it was interrupted. (#1778)

Background

JoinSplits encapsulate zero-knowledge value transfer and have two
private inputs and two private outputs. Multiple JoinSplits may be chained
into a single transaction in order to spend more than two private
inputs and/or send to more than two private outputs. The order of inputs
and outputs can be a subtle information leak to private recipients (see
#778). A patch to fix this information leak (#1561) in our 1.0.0-rc2
release randomizes the input and output orderings, but in doing so
failed to permute the necessary commitment witnesses in the same manner
as the private inputs. In this release we’ve temporarily disabled
input/output order randomization (#1790).

Nathan Wilcox and Jay Graber

Zcash Founders' Reward Transfers

With the Zcash launch of October 28th, 2016, a couple weeks behind
us, and a couple of bugfix releases out, we're beginning to turn our
focus to the coming year. The last lingering task to complete our MVP
goal is to begin the Founders' Reward transfers.

We will begin initiating transfers of the Founders' Reward funds
sometime on or after November 28th, 2016, a month after our launch.
Recipients of the Founders' Reward may independently use these funds as
they see fit. Additionally the end of the mining slow start
is predicted to be roughly around the same time after which the rate of
ⓩ production over time will become constant for approximately the
following four years.

Background

The rest of this post presents a technical background on the Founders'
Reward and the Miners' Reward, and how the mining slow start
interacts with them. Finally, some of the links provided allow you to
observe up-to-date details for these kinds of funds.

Monetary Base and Founders' Reward

The Founders' Reward is the cornerstone of our funding and developer incentives model, and allocates 10% of all tokens created to a Founders' Reward fund, with the remaining 90% allocated to miners eventually.

The 10% of the total supply that makes up the Founders' Reward is
distributed between launch and the first halving (at block 850,000).
During this period (which will last approximately four years), half of
the total monetary base will be generated. After the first halving,
there will be no more Founders' Reward, and all newly-created ⓩ will be
received by miners. The following figure shows the monetary base and
Founder's Reward plotted over time:

Block Subsidies

When a new valid block is discovered, the special coinbase transaction is permitted to create new ⓩ tokens according to the monetary base growth schedule. The total number of ⓩ created per block in this beginning stage of the network follow the slow start
rule: for the first 20,000 blocks, the number of ⓩ grows linearly from 0
ⓩ towards 12.5 ⓩ (which is approximately ~34 days). Thus the 20,000th
block is the first block with a 12.5 ⓩ subsidy. As of this writing we
are around block 11034, or about 55% through the slow-start period. This
figure shows the rate per block as a function of block height:

This block subsidy is split between the Miners' Reward (80%) and the
Founders' Reward (20%) during the halving interval. After that the
entire block subsidy will go to the Miners' Reward. You can see an
example by viewing any coinbase transaction, such asthis example from block 8086:

Founders' Reward Addresses

The miner's address is chosen by the miner at the time they created the block, whereas the founders' Reward address,t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojdseen above, is specified in the consensus rules (specifically inthis source code).
Throughout the approximately four years of Founders' Reward
distribution, the specific addresses used will change, a measure to
improve our operational security.

You can see that as of this writing (around block 8775), no funds have moved from the Founders' Reward address t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd(link to zcha.in explorer). Once we begin transfering funds out of that address, the URL should reflect those transfers out.

Conclusion

Once Founder's Reward transfers begin, on or around November 28th, and the slow start
completes the Zcash network will be in the basic post-launch steady
state. We designed the Founders' Reward as the best practical structure
to make Zcash a reality, both in its launch and it's continued
evolution. We're avidly preparing for that evolution!

Resources

To learn about the current public state of Founders' Reward funds or Miners' reward funds, you can use the following resources:

Security Announcement 2016-11-22

Nathan Wilcox | Nov 22, 2016

Synopsis: A cache invalidation bug may allow an attacker to trigger
a chain fork causing pre-1.0.3 nodes to follow an invalid chain. A
fix is implemented in zcashd release 1.0.3.

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 only when two conditions are met
simultaneously:

They rely on zcashd releases older than 1.0.3, including 1.0.0,
1.0.1, and 1.0.2, AND

A network-wide attack is executed to trigger a chain fork. This
requires a majority of miners to run vulnerable software.

Users who rely on third party services should inquire if those services
have mitigated this issue. 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 meet either of the following two
conditions are not at risk:

they have upgraded to zcashd 1.0.3, or rely on a service which has done so, OR

no network-wide attack has succeeded (for example, because a sufficient
portion of miners have mitigated the vulnerability).

In other words: individuals and services are protected as soon as they
upgrade, and the entire network is protected as soon as a sufficient
portion of miners upgrade.

For users of third party services (such as exchanges, wallets,
or mining pools), check if the service has announced upgrading to
zcashd 1.0.3. If it hasn't, consider pausing use of that service
until they announce an upgrade.

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 a network attack is successfully executed (which requires
a majority of mining capacity to be vulnerable) then only users running
vulnerable clients will follow a chain fork that is invalid. Transactions
on that fork will be rolled back as more miners upgrade to the valid fork.

Technical Background: Due to a cache invalidation bug, some nodes on
the Zcash network will accept particular invalid transactions as valid
[1]. If a majority of the network hashrate accepts an invalid transaction
as valid, there could be a chain fork.

Anatomy of A Zcash Transaction

Since the successful launch of the Zcash network on October 28th,
we've had an outpouring of interest from miners and users who want to
take advantage of the confidentiality and privacy properties enabled in
the protocol. When sending or receiving ZEC, the added choice of using
shielded or transparent addresses is an important factor for those
users. Understanding how these two types are used in a transaction is a
suitable place to start to make the most informed choices.

The Building Blocks of A Transaction

The user-facing building blocks of a Zcash transaction can be broken
down into sending and receiving addresses, account balances and
transaction fees. More complex transaction components are explored in
our protocol specification
so we'll avoid those concepts for now. For sending to shielded
addresses, an additional “memo field” component is available but that
will be a topic for a future post.

The diagram above shows the process of sending and receiving ZEC as
part of a transaction. The use of shielded addresses - whether sending
or receiving - requires the generation of a zero-knowledge proof which
allows others to verify a transaction's encrypted data without it being
revealed. (More detail on how this works will be discussed in an
upcoming post on the inner workings of transactions between shielded
addresses.) These addresses always start with a “z” and are sometimes
referred to as “z-addrs”. Similarly, the use of transparent addresses
require interaction with what is known as a “Transparent Value Pool” (or
TVP) and publicly reveals transaction data. These addresses always
start with a “t” and are sometimes referred to as “t-addrs”. The
transaction fee also passes through the TVP and is therefore always
visible on the blockchain. Even though fees are always revealed in a
transaction, shielded addresses and value are not affected as shown in
the following real Zcash transaction.

Change Addresses

Like other blockchain protocols, spending from a balance in an
address requires sending all of the balance. Therefore, unless you want
to send the exact balance to another party, you must split the balance
by including a second receiving address you control to accept any
balance change. It is possible to simply use the sending address as the
change address to prevent the added management of multiple addresses.
This, however, is not normally recommended since it would be trivial for
someone to build an identity profile based off of transactions sent to
and from that single public address. Creating a new address for each
transaction has become recommended standard practice in order to
obfuscate a user's transactions. Since public transactions link sending
and receiving addresses, however, this level of obfuscation is still
quite trivial to navigate around and does not provide a meaningful level
of privacy.Thankfully, when sending ZEC from a shielded address, that data is

kept private so sending change back to the sending address is
permissible. In Zcash, all transactions between shielded addresses look
identical so the reuse of shielded addresses is not vulnerable in the
same way that transparent addresses are.

Sending Between Shielded and Transparent Addresses

In Zcash, ZEC is the balance unit for how much value an address
contains. It differs from purely public blockchain currencies in that a
ZEC balance has a different set of properties depending on what address
type it is currently held in and the previous address(es) it was sent
from. If ZEC is held in a transparent address, its unspent balance is
publicly viewable. Regardless of that balance being sent to one or more
transparent addresses, shielded addresses or a combination of these
types, the output ZEC from a transparent address will be visible. A
benefit of sending transparent ZEC to a shielded address is breaking the
linkability between future transparent addresses if that's where it
ends up again. The action of shielding ZEC is particularly important at
these early stages where many wallets (such as mobile wallets) may not
yet support shielded addresses due to the resource requirements as
explained in a previous blog post on user expectations for hardware and software limitations.

In the transaction above where a transparent address sends to a shielded
address, you can see that this process of shielding ZEC reveals the
balance sent and that it is held by shielded addresses. The shielded
addresses involved and whether it was sent to one or two shielded
addresses remains confidential.

To
contrast, a ZEC balance in a shielded address keeps the balance and
account address private. If spending to one or more shielded addresses,
the value stays private but any transparent addresses on the receiving
end will deshield the ZEC and reveal the value received on the
blockchain. When deshielding ZEC, the input shielded addresses and
whether the value was sent from one or two of these remains
confidential.

Further Notes on More Complex Transactions and Privacy Implications

It should be noted that these examples do not detail the properties
of more complex transactions where both transparent and shielded
addresses are sending or receiving. With this overview on the basic
properties of addresses and spending ZEC balances, however, users can
hopefully gain a better perspective on how the transactions work when
transacting between any two addresses. Expect future posts on the inner
workings of shielded addresses, further considerations on linkability
and privacy implications, and details on the more complex transactions.
We are eager to promote shielded addresses to improve stats
on their use. While transactions involving shielded addresses require
more resources than those with strictly transparent addresses, the
improved privacy provided when using them is a clear benefit for
financial freedom and is the core improvement Zcash brings as a
cryptocurrency.

How Transactions Between Shielded Addresses Work

In'Anatomy of A Zcash Transaction'we gave a general overview of Zcash Transactions. The purpose of this post is to provide a simplified explanation of how privacy-preserving transactions work in Zcash, and where exactly Zero-Knowledge proofs come into the picture. In the terminology of that post, we are focusing exculsively here on transactions between shielded addresses (commonly referred to as z-addrs).

To focus on understanding the privacy-preserving apsect, let's put aside everything having to do with reaching consensus using Proof of Work and the blockchain, and focus on a particular node that has obtained the correct list of unspent transaction outputs.

Let's recall first how this list looks on the bitcoin blockchain. Each unspent transaction output (UTXO) can be thought of as an unspent 'note' that is described by the address/public key of its owner and the amount of BTC it contains. For simplicity of presentation, let's assume each such note contains exactly 1 BTC, and there is at most one note per address. Thus, at a given time, a node's database consists of a list of unspent notes, where each note can be described simply by the address of the owner. For example, the database may look like this.

Note1=

(PK1), Note2= (PK2), Note3= (PK3)

Suppose PK1

is Alice's address and she wishes to send her 1 BTC note to Bob's address PK4. She sends a message which essentially says "Move 1 BTC from PK1 to PK4" to all nodes. She signs this messsage with the secret key sk1 corresponding to PK1, and this convinces the node she has the right to move money from PK1. After the node checks the signature, and checks that there is indeed a 1 BTC note with address PK1,

We will soon see this is helpful for obtaining privacy. Thus, the database may look like this.

Note1=

( PK1 , r1), Note2= ( PK2 , r2), Note3= ( PK3 , r3)

A natural first step towards privacy would be to have the node store only "encryptions", or simply hashes, of the notes, rather than the notes themselves.

H1=

HASH(Note1), H2= HASH(Note2), H3= HASH(Note3)

As a second step to preserve privacy, the node will continue to store the hash of a note even after it has been spent. Thus, it is no longer a database of unspent notes, but rather a database of all notes that ever existed.

The main question now is how to distinguish, without destroying privacy, between notes that have been spent and notes that haven't. This is where the nullifier set comes in. This is a list of hashes of all serial numbers of notes that have been spent. Each node stores the nullifier set, in addition to the set of hashed notes. For example, after Note2

has been spent, the node's database might look like this.

Hashed notes Nullifier set

H1=

HASH(Note1)

nf1=

HASH(r2)

H2=

HASH(Note2)

H3=

HASH(Note3)

How a transaction is made

Now suppose Alice owns Note1

and wishes to send it to Bob, whose public key is PK4.

We will assume for simplicity that Alice and Bob have a private channel between them although this is not actually necessary in Zcash. Basically, Alice will invalidate her note by publishing its nullifier, and at the same time create a new note that is controlled by Bob.

More precisely, she does the following.

She randomly chooses a new serial number r4

and defines the new note Note4= ( PK4 , r4).

She sends Note4

to Bob privately.

She sends the nullifier of Note1,

nf2= HASH(r1)

to all nodes.

She sends the hash of the new note H4=

HASH(Note4)

to all nodes.

Now, when a node receives nf2

and H4, it will check whether the note corresponding to nf2 has already been spent, simply by checking if nf2 already exists in the nullifier set. If it doesn't, the node adds nf2 to the nullifier set and adds H4

to the set of hashed notes; thereby validating the transaction between Alice and Bob.

Hashed notes Nullifier set

H1=

HASH(Note1)

nf1=

HASH(r2)

H2=

HASH(Note2)

nf2=

HASH(r1)

H3=

HASH(Note3)

H4=

HASH(Note4)

..but wait a second, we checked that Note1

wasn't spent before.. but we didn't check whether it belongs to Alice. Actually, we didn't check that it was a 'real' note at all, real in the sense that its hash was in the node's table of hashed notes. The simple way to fix this would be for Alice to simply publish Note1,

rather than its hash; but of course, this would undermine the privacy we are trying to achieve.

This is where Zero-Knowledge proofs come to the rescue:

In addition to the steps above, Alice will publish a proof-string π

convincing the nodes that whomever published this transaction knows values PK1, sk1, and r1

such that

The hash of the note Note1=

(PK1, r1)

exists in the set of hashed notes.

sk1

is the private key corresponding to PK1 (and thus, whomever knows it is the rightful owner of Note1)

.

The hash of r1

is nf2, (and thus, if nf2 - that we now know is the nullifer of Note1 - is not currently in the nullifier set, Note1

still hasn't been spent).

The properties of Zero-Knowledge proofs will ensure no information about PK1,

sk1, or r1 are revealed by π

.

The main places above where we cheated or omitted details

We emphasize that this has been an oversimplified description, and recommend the protocol spec for full details.Here are some of the main things that were overlooked: The hased notes need to be stored not just as a list, but in a Merkle tree. This plays an important role in making the Zero-Knowledge proofs efficient. Moreover, we need to store a computationally hiding and binding commitment of the note, rather than just its hash. The nullifier needs to be defined in a slightly more complex way to ensure future privacy of the receiver in relation to the sender. We did not go into details on how to eliminate the need for a private channel between sender and recipient.

Zcash 1.0 Mac binaries and User Guide

Welcome! This guide is intended to get you running on the official Zcash network on your Mac. Zcash currently has some limitations: it requires a 64-bit processor, and in some situations requires heavy memory and CPU consumption to create transactions (4GB RAM for shielded transactions).

Please let us know if you run into snags. This is a volunteer port from linux to Mac OS X, and I depend on your donations!

A quick note about terminology

Zcash supports two different kinds of addresses, a z-addr (which begins with a z) is an address that uses zero-knowledge proofs and other cryptography to protect user privacy. There are also t-addrs (which begin with a t) that are similar to Bitcoin's addresses.

Get started

Binary installation

Next, fetch and install the tarball of the pre-compiled binary release. You'll have to install it as root, and may get warnings about it not being able to change the ownership of some directories. This is normal and can be ignored:

<span class="pl-c1">cd</span> /

wget https://zcash.dl.mercerweiss.com/zcash-1.0.3-mac.tar.gz

tar xvf zcash-1.0.3-mac.tar.gz

Now you'll need to download and install the proving keys:

zcash-fetch-params

And then skip to the "Configuration" section below

Compile it yourself

First off you need Apple's Xcode (at least version 7, preferably 8.x) and the Xcode Command Line Tools:

Get all that installed, then download and compile zcash with the following commands:

git clone https://github.com/radix42/zcash.git

<span class="pl-c1">cd</span> zcash

git checkout v1.0.3-mac

./zcutil/build-mac.sh

Then download the proving keys:

./src/fetch-params.sh

This will fetch our Sprout proving and verifying keys (the final ones created in the Parameter Generation Ceremony), and place them into ~/.zcash-params/. These keys are just under 911MB in size, so it may take some time to download them.

Configuration

Create the ~/Library/Application\ Support/Zcash directory and place a configuration file at ~/Library/Application\ Support/Zcash/zcash.conf using the following commands:

Note that this will overwrite any zcash.conf settings you may have added from testnet. You can retain a zcash.conf from testnet, but make sure that the testnet=1 and addnode=betatestnet.z.cash settings are removed; use addnode=mainnet.z.cash instead. We strongly recommend that you use a random password to avoid potential security issues with access to the RPC interface.

Running Zcash:

Now, run zcashd (if you installed from source, you must run zcashd and zcash-cli from within the directory you built them in, and preface those commands with ./src/

zcashd

To run it in the background (without the node metrics screen that is normally displayed) use zcashd --daemon.

You should be able to use the RPC after it finishes loading. Here's a quick way to test:

zcash-cli getinfo

NOTE: If you are familiar with bitcoind's RPC interface, you can use many of those calls to send ZEC between t-addr addresses. We do not support the 'Accounts' feature (which has also been deprecated in bitcoind) — only the empty string "" can be used as an account name.

NOTE: The main network node at mainnet.z.cash is also accessible via Tor hidden service at zcmaintvsivr7pcn.onion.

To see the peers you are connected to:

zcash-cli getpeerinfo

Using Zcash

First, you want to obtain Zcash. You can purchase them from an exchange, from other users, or sell goods and services for them! Exactly how to obtain Zcash (safely) is not in scope for this document, but you should be careful. Avoid scams!

For the past 10 days, 1 day pool luck 50%, all 9 days exceeds 150%

Pool Link:

History of block mined:

Pool hash rate history for past 10 days:

We setup the pool and have a few of friends gradually adding hash power for
testing in the past 10 days. They are very happy with the payout. Daily UTC
04:00 AM PPLNS per pay round. Will switch to PPS or HBPPS once hash rate get
higher later.Technical features: Completely rewrite pool using Java for large scale
mining connections. Improved backend stability and concurrency. Optimizations
for better pool efficiency.Welcome to give us a try and introductory pool fee is 0% until
12/31/2016 and 1% after. Give a try for couple of days and see your returns boost!

The judges: Jack Grigg, Solar Designer, and Dmitry Khovratovich, selected these submissions as the Winners and Runners Up based on the criteria, which included many factors of quality, community contributions, and performance.The Zcash Company
sponsored this challenge to help strengthen and decentralize the Zcash
community, as well as contribute to the advancement of computer science.
Least Authority, as a supporter of the Zcash Company, operated this challenge.The Zcash Open Source Miner Challenge has made mining for ZEC accessible to more people and facilitated collaboration within the Zcash community. While the code available
is off to a good start, we encourage everyone to continue improving and
building upon each other's work. The challenge website will transition
to repository of these open source miners… And we may even do another
challenge in the future!