Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining

The Encrypted Memo Field

As of October 28, 2016, Zcash is a reality! Anybody with Internet access can download the software, connect to the global decentralized network, and send and receive payments, without exposing their confidential transaction metadata to the world.Note: we have not yet created a user-friendly wallet. The software
we're distributing is only for command-line-wielding Linux users.
Fortunately many other individuals and companies have already stepped
forward to provide graphical user interfaces.This blog post is about a little-known but potentially valuable feature of this new protocol.

The Encrypted Memo Field

When you receive a Zcash payment from someone else's shielded address
to a shielded address of your own, you see the amount of Zcash
received, and you see the transaction ID, which allows you to identify
this transaction (in its encrypted form) in the blockchain.

You don't learn anything about the sender or about the history of the
money you're receiving, and you don't see the sender's address. This is
by design — the sender should be able to send you money without
necessarily revealing other information about themselves.

However, we realized that senders would sometimes need to communicate
information about a specific payment. For example an invoice number or
account number that the payment is for, an address to which any refunds
should be sent, a note to the recipient, etc.

So we implemented an additional field that is visible to the
recipient of a payment, called the “encrypted memo field”. It is always
present in every encrypted payment, and is always exactly 512 bytes
long. If a sender doesn't specify a memo, then the memo that is sent is
all zeroes (before encryption), and if the sender includes a memo
shorter than 512 bytes, then the remaining space is padded with zeroes
(before encryption).

This padding is necessary for privacy, so that an observer watching
the blockchain can't detect differences between different usage patterns
of the encrypted memos. It also means that you don't pay a higher
transaction fee for including a memo — the cost is already baked in.

The encrypted memo is visible only the to recipient, unless the
transaction view key for the transaction gets shared (by the sender or
the recipient) with a third party. In that case, the third party who
received the transaction view key would be able to see the memo, along
with the amount and the recipient address of the transaction in the
blockchain. Transaction view keys are already present in the protocol,
but are not yet supported in the API.

What Will People Do With This

We conceived of the encrypted memo field as being basically like the
memo space at the bottom of old-fashioned paper checks, but lately we've
been wondering: what else will people use this for?Zcash is the first system which combines the append-only property of blockchains with the selective disclosure
property of encryption. Using the memo field you can enter arbitrary
data (as long as it fits into 512 bytes) into the global, decentralized
Zcash blockchain, and your data will become part of the immutable and append-only ledger, but it will not be visible to anyone else — yet. If you later disclose the transaction view key to someone, then the data will become visible to them
in the blockchain. If you were to post the transaction view key
publicly, then the data would become visible to the public, still
embedded in its original place in the blockchain.Could this feature be useful for private messaging? Time-stamping?
Public records such as land title registries? Securely storing and
sharing confidential data such as health records or business records?I really don't know if the encrypted memo field would be appropriate
and effective for those purposes, but as of now, the feature is live and
nothing can stop you from experimenting with it. If you do, please let
me know what you learn!

Return Addresses

One of the more obvious uses for an encrypted memo field sent within a
ZEC payment between shielded addresses is a return or refund address.
Merchants may prompt their customers to include a refund address along
with a payment in the chance that the product must be returned or a
service canceled early. Since the memo isn't required to hold the
address from which the payment was sent, this feature could even be used
as a cryptographically secured gift receipt. If someone buys their
sister a birthday gift from a merchant, the gift giver can include their
sister's shielded payment address in the memo field and share the
transaction ID with her which holds the encrypted transaction details.
She won't know the value of the bracelet but if she finds it doesn't fit
right, she can return the product to the merchant with the transaction
ID, which the merchant can associate with the product and initiate a
refund to the address provided in the memo field.

The Travel Rule

Another specific use that we had in mind was satisfying The Travel Rule. The Travel Rule is a regulation of FinCEN
which states that when one financial institution is sending a
transaction to another, the sending institution is required to include
the identifying information of the customer on whose behalf they are
making the payment. It's called the Travel Rule because the identifying
information is required to travel with the payment, rather than
just being delivered out of band or kept in a database. Financial
institutions using Bitcoin (e.g. exchanges like Kraken and Poloniex)
face difficulty satisfying this regulation, because you can't really
include your customer's personal information in a globally-transparent
blockchain!With Zcash, a financial institution can satisfy that rule,
by putting the customer's personal information into the encrypted memo.
This makes it visible to the receiving financial institution, but not to
unauthorized third parties.

Love Notes In The Blockchain

Recently a young woman told me that she had received an encrypted
Zcash transaction, and in the memo field, she found a merkletree hash
which pointed to a file in the IPFS
distributed file system. Following that link, she found that the file
was a ticket to a special event, overseas, that she and her distant
lover had been talking about attending together.The memo was a love note. A love note which is permanently embedded
somewhere in the first few blocks of the Zcash blockchain, but which is
visible only to two people. I think that is beautiful.

zmsg

Here's a simple program to put memos into the encrypted memo field
and to read them out again (if you are the recipient of the enclosing
transaction): zmsg

Endless possibilities

While the examples listed in this post highlight some of the exciting
ways users, developers and merchants can use the encrypted memo field
in Zcash payments, it is only the beginning. We encourage everyone to
experiment with this feature and the tools being built around it. You
can share your findings and ideas for cool hacks in our online community.

Update ZCash Article for Indonesian Community

New — ZCash — POOL-SSL/TLS — 0% fee in 2016
https://www.coinotron.com
We've added ZEC pool. Just point your ZEC miners to port 3346.
Mining ZEC is FREE until the end of 2016 !!!
More info in Help section:
[https://www.coinotron.com/app?action=help2](https://www.coinotron.com/app?action=help)
Our pool supports SSL/TLS on port 3347. If you are using Claymore's miner you will pay less fee
Right now we have only PPLNS in ZEC pool. RBPPS and maybe PPS will be added in following weeks. We must solve at least 300 blocks before.

# Mac OS X Zcash Miner
By, Cocomos
## Hello Everyone,
### I have created a CPU miner for mac OS X that mines ZEC (Zcash). You can find it on my [GitHub21](http://github.com/Cocomos/MacZcashMiner). I am looking for people to test out the code. It has so far worked on the machines I have tested it on, but I need a wider sample base. It is simple to use and includes an interactive input program (that is bypassable). There is a "developer fee", but it is optional and can be run without it. All info is in the README on GitHub. As the program develops (with enough donations), this thread will become more permanent. Only CPU support at this time. More to come. To help the development please post issues and successful mining experiences here. All information helps!

Ubuntu mining, optiminer 1.2.0 and Claymore 9.3 results

Mining performance:Both at -i level 8 on all GPU'sif I subtract the 2.5% Dev fee from Claymore's 1693 Sol/s I end up with ~1651 S/s.Optiminer
comes in at 1510 S/s so Claymore is slightly better by 141 S/s or
~9.3%. Optiminer also stated that he has more room for optimization on
the RX 480 GPU's.

Stability:Claymore is still a beta but Optiminer seems to be
fairly stable. Main issue I have with Claymore is the fan speed control
has too much Hysteresis, especially for XFX cards I have on another rig
(Temps can start oscillating). I found that manually setting the fax
speed for each GPU at start in a script works best for both miners. I am
looking at using the mining intensity -ttli switch in Claymore to
provide more robust temp control (with static fan speed @ 80%).

Both miners can drop a GPU as temps start to rise (or for no apparent
reason). Once this happens, on my rigs, even after killing the miner I
hang when attempting a soft reboot and it requires a hard reset.
Unfortunately, this prevents remote ssh monitoring of the system until I
can find a reliable way to soft reboot. I have found staying below ~65C
is critical for stability. Claymore does seem to drop GPU's more
frequently, and I have disabled the watchdog as the Miner always hangs
when restarting. With the watchdog disabled at least it will keep mining
on the remaining GPU's.

Also: I have not been able to get Ubuntu Server to run reliably with 7
GPU's for some reason. I am still looking into this as I see no reason
to have a desktop running on a headless system. If I find a solution to
this I will post.

Update:I have Claymore running more stable on two rigs. Set
static fan speeds in startup script depending on how GPU temps have
looked (most @ 80% and few problematic GPU's @ 88%). I have two XFX card
that just get hot so I also have them set for -i 0 and -i 6
respectively. Set the -ttli option to kick in on all 14 cards at 63C.
This seems to keep things very stable and no card ever gets above 64C.
Have been mining this way most of the day and not a single dropped GPU.

The Nitro's are running at -i 8 most of the time and only drop down
when the room gets a little warm. I need to tweek the XFX cards a bit so
they run at a higher -i at night when things are cold.

Important point: Claymore will drop a card lower than -i 0 via the
-ttli option. I have seen it drop an additional 20% when a hot card hits
64C. I just need to test how low it will go and if I can set the
initial -i higher to cover a larger ambient temperature range (70F to
55F in my house).

So now the next question: IS it better to restart the miner
periodically via -r option or to just leave it running long term? I head
out of town tomorrow so Ill set one to restart periodically and the
other to run continuously to test.

Update:Death by restart on Claymore.

Seems continuous run would be a better option as the other rig is
running fine. Restarting the miner has some level of risk apparently.

A Future Friendly Fork

“Forks” (or “hard-forks”) are a highly contentious topic in cryptocurrencies. You can analyze a fork with two questions:

Does it result in two (persistent) separate branches of the original blockchain?

Does it result in community schism?

In principle, any of the four combinations of these two consequences could happen.

Interestingly, three out of four of these combinations have already occurred in practice!

In the future, as the Zcash community grows, there may come a time
when we need multiple, distinct technologies, each one building on a
different branch of the original blockchain. This is likely to happen,
because different technologies offer different trade-offs to their
users, and some uses of Zcash might benefit more from one technology,
while other uses may benefit more from a different, incompatible design.

I hope that, when that time comes, the Zcash community fills in the
unoccupied space in the matrix above, deploying different technologies,
well-fitted to different needs, but continuing to be tolerant and
cooperative with one another, to the benefit of all.

Coming soon: Zcash (“MagicBean”) 1.0.5

Folks, you can see our development process in action here:

For example, if you click on the "1.0.5" Milestone, you'll see this:

From this page you can tell when 1.0.5 is due to be released (January
23!) and what bugfixes and improvements are going to be included in it.
You can also see which patches are already written (in case you want to
beta-test specific fixes), if users have been making requests or
reporting bugs, etc.

One thing you can't see from that is what's the "summary" or
"the general idea" of the release. For 1.0.5, I'm not sure what the
"general idea" is. Maybe it is just "various bugfixes and usability
improvements suggested by the feedback we're getting from users".

Zcash Release V 1.0.5

This release contains a number of bug fixes and minor usability improvements, including:
1. The chain is now fully rescanned when keys are imported that are older than the wallet. (#1978)
2. The number of commitments in the note commitment tree is now displayed by `getblockchaininfo`. (#1946)
3. `zcash.conf` now must exist in order to start zcashd. (#2013)
4. Fixed a bug where `z_sendmany` logged incorrect txid fragments when sending from transparent addresses. (#1980)
5. We integrated upstream's cookie-based RPC authentication. (#1999)
6. We added a restriction to wallet export paths to protect user security. (#2006)
7. `z_getoperationstatus` is now sorted chronologically. (#2015)
8. Messages containing newlines are now rendered properly by the metrics UI. (#1972)
9. We added more tools for benchmarking JoinSplit creation. (#1953)
10. We now show serialized transaction size in `listtransactions`, more operation details in `z_getoperationstatus`, and the age of the note being spent in `z_sendmany` logging. (#2001, #1976, #1977)
11. We now instruct users to run `fetch-params` if the parameters could not be found locally. (#1979)
12. We handle exceptions better in some situations for more user-friendly error messages. (#1976)
For a more complete list of changes, see our [1.0.5 milestone](https://github.com/zcash/zcash/milestone/49?closed=1).

Discussion

Bitcoin is one of the more complex projects in recent engineering
history. Not only using sophisticated cryptographic design, but complex
data structures built with nested templated types. All of these factors
make implementing Bitcoin in other languages difficult.

However, more diversity and common packages have been written in Rust
that will make implementing Bitcoin and other cryptocurrencies much
easier.

I'm reaching out to the community for advice and engineering help to
successfully build a production-ready Rust implementation of Bitcoin.
There are significant hurdles to overcome, but the payoff is fairly
large for both developer communities and currency user economies.

Developer Benefits:

Rust devs will be able to join forces with the other Bitcoin devs

Bitcoin developers will be able to use memory safe backends for their applications

Many of the classes of memory corruption vulnerabilities in C++ are entirely avoided using Rust

Many of the cryptographic and networking primitives in Bitcoin are low-level, and have very disparate use-cases

Communities entirely outside Bitcoin could benefit from a well-executed implementation

User Benefits:

Safer client implementations mean wallet compromise is less likely

May gain performance boost

Less money lost / spent on security due to less exploitation

More money/time saved on developers

Redesigned code may be easier to maintain / extend

Project Cons:

Enormous amount of developer time required

There are truly hard problems that require innovative problem solving

Reading thousands of lines of C++ may actually make your eyes bleed

This is a community project, so likely no money for contributors

Banks will have a harder time affording attacks on Bitcoin software... wait...

Building rusty bitcoins isn't a project that will survive on the fingertips of one person.
This endeavor requires group effort to succeed.

I believe a full re-implementation of Bitcoin in Rust is preferable
to trying to use Rust's FFI for calling into C++ code. There may be
better ways for integrating Rust components gradually (middleware using
protobufs API?).

Because of the complexities of templated types in the C++ codebase,
there are virtually no way to directly implement those classes in Rust
without rebuilding a C++ compiler inside the Rust compiler. May be wrong
about this, but seems to be the case from discussions I've read online.

Please let me know in the replies or private messages if you are interested.

Transaction Linkability

Having the two types of addresses within Zcash (transparent and
shielded) is an advantage which allows users to have more flexibility
with how they store and transact ZEC. The dynamic between transparent
and shielded addresses, however, presents a level of increased
complexity for transactions containing both types (i.e. shielding ZEC by
sending from a transparent to a shielded address or deshielding ZEC by
sending from a shielded to a transparent address).

If all Zcash transactions used shielded addresses (which we hope will
someday become the norm), then the complexities introduced with the two
types of addresses disappear and privacy would strengthen for everyone
in the ecosystem. Until then, understanding privacy implications such as
transaction linking will be helpful for users interested in maintaining
maximum control over the visibility of their transaction details.

This post will outline some privacy considerations while using Zcash
with its current support for both transparent and shielded addresses and
some solutions users can employ in such situations.

Where does Zcash introduce linkability?

Transparent Addresses

Knowing that transparent addresses publicly disclose transaction
details on the Zcash blockchain, we can assume a degree of linkability
between a string of transactions using this type of address, similar to
the linkability seen in bitcoin transactions.

But what happens when shielded addresses are sprinkled into the mix?
Thankfully, shielded addresses in Zcash indeed break linkability when
used properly.

So even if you or your friends must use transparent addresses for one
reason or another, others using shielded addresses (whether they mean
to or not) break down the direct linkability that would otherwise exist
with exclusively transparent addresses.

Linking Values

The above method where Bob de-links Alice and Carol simply by using a
shielded address isn’t 100% reliable for every situation, however.

To explain why, let’s first highlight a property of transactions
which include both address types: when transparent addresses shield ZEC
(t → z) or when shielded addresses deshield ZEC (z → t), the values sent
to or received from transparent addresses are public even though those
values are masked in the shielded address part of the transaction. We
can observe this property in the transaction series above where Bob uses
a shielded address but the transparent addresses used by Alice and
Carol still reveal the value sent and received.

Further, this association increases the closer in blocktime Alice’s
public output and Carol’s public input are recorded. For example, in
the above transactions, Alice sends ZEC to Bob in block number 50374 and
Bob sends ZEC to Carol in block number 50378. This makes it easier to
link the values than if Bob instead transacted with Carol in block
number 111583.

To mitigate this, Bob should be aware when deshielding a value equal
to one recently received from a transparent address. Zcash wallets might
even consider implementing a feature to allow automatic detection of
potential of linking past and future transactions when deshielding ZEC. [2]

Unique Transaction Fees

Another linking possibility regards the use of transaction fees. Most
wallets use a standard fee to pay miners (.0001 ZEC). In a previous
post covering basic Zcash transaction anatomy,
we showed how fee outputs are always transparent even with shielded
addresses. While this doesn’t reveal much to the public if a standard
fee value is used, addresses which consistently pay unique fees could be
linked.

The solution here is to simply use standard transaction fees!

Reducing Linkability By Reducing Complexity

While the advantages of supplying both transparent and shielded addresses to users allows for more options [3],
there is no doubt that sending ZEC between them introduces complexities
which affect individual’s financial privacy. The most concrete solution
to avoiding transaction linkability is simply using and requesting
others use shielded addresses, which in turn strengthens the community’s
overall privacy. The Zcash core development team has priorities to
support growth in shielded address use and call on third party services
to consider ways which make shielded addresses easier to use as well.
We’re just at the beginning of this exciting new ecosystem and are
looking forward to seeing privacy for all strengthen over time.

[1]

/em>,
we use a question mark to indicate the value received by Bob's shielded
address even though it seems exactly 14.9999 ZEC would have been
received. This is because it's possible that an additional shielded
input and/or output was included in the transfer but we would not be
able to see this on the blockchain.

This value linkability is much more likely in situations where users are sending between their own addresses rather than between different users. In the example used, Alice and Bob might actually be the same person sending between their own transparent and shielded addresses.

[2]

[3]shielded addresses offer the privacy features which distinguish Zcash from purely public blockchain networks, the transparent addresses provide (at least for now) a relief in resource requirements along with familiar functionality to previously launched cryptocurrencies.

Author

Paige Peterson | Jan 25, 2017

TREZOR Wallet Supports Zcash

TREZOR Wallet has integrated Zcash in previous
releases, but the Wallet has been supporting Zcash only on the beta
chain of the wallet. Starting today, the beta graduated into a full
version. Zcash is supported directly on the main wallet chain at
wallet.trezor.io. You will need the latest firmware update (1.4.2) on
your TREZOR to use it with the Wallet.

And create a zcash.conf file in:
###code# which is normally at
C:\Users\YOUR-USERNAME\AppData\Roaming\Zcash\

For what to put in your zcash.conf, its the same as for linux in the
User Guide. If you want to see the fun splash screen output, you need to
launch zcashd.exe usering Powershell with showmetrics activated in your
zcash.conf or on the command line, like so:
.\zcashd.exe -showmetrics=1 -daemon=0

HOWEVER, use cmd.exe, not Powershell, for sending transactions with
zcash-cli.exe, or the quoting is even more esoteric than normal! If you
use cmd.exe it is the same as for linux as shown in the User Guide.

Its been a long slog working on this since October of last year with
input and help from lots of people in the Zcash and Zclassic communities
along the way, but we're finally running on Windows. All-in-one
installer with GUI wallet coming soon!

Zcash-New Release: V 1.0.6

With the upcoming 1.0.6 release
slated for Monday (Feb. 13th), a lot of the engineering effort this
week was focused on final editing and reviewing of pull requests. Our
Monday engineering meeting took a look at all remaining issues in the
1.0.6 milestone and confirmed whether addressing them was feasible for
this release or should be pushed back to 1.0.72.
To reiterate the 3 week release cycle process: last week’s triaging for
the issues we would like to address in the upcoming release was done
with a rather optimistic mindset while this week focused on realistic
gauging of the current and next milestones. Next week we’ll look at big
picture planning and then start the process over with optimistic issue
triaging for 1.0.7.

In addition to all the new concepts we want to develop into Zcash,
we’re also looking at the changes from Bitcoin v0.11.2 (the version from
which Zcash forked) and Bitcoin v0.12.0 to see which parts we want to
eventually merge into Zcash. Some of this work has already been done but
engineering focused time this week on creating an overview of code
changes between the two versions to give us a concrete list from which
to work.

Our topical engineering meeting this week focused on delegated proving3,
a feature which will enable light client support for sending to
shielded addresses. While one of our priorities is to reduce resource
requirements for this operation, we think it is additionally important
to prioritize alternative methods for shielded address support for
hardware with significantly reduced resources, such as mobile devices
and hardware wallets. One perspective of delegated proving is as a
third-party service where the user's trust should be minimal. Another
option would be that the user sets up their own personal proving service
allowing for much high trust. For example, a Zcash user may set up a
delegated proving service on a home computer to offload some processes
for transactions sent from their smartphone. Specification and
development on this feature will be ongoing so keep an eye out for
updates.

The network experienced a security hiccup1could not sync with the main network past block 58969. It was determined this was most likely caused by a bug
which was fixed in later releases. An alert message was sent to nodes
running v1.0.2 and below putting them into safe mode and disabling
critical RPC functionality requiring an upgrade to a more recent version
to re-enable. A lesser alert message was sent to v1.0.3 nodes
requesting an upgrade to a more recent release without a safe mode
trigger. This event prompted focus on improving chain fork detection2
and discussion on improving communication on critical security events.
The pool which reported this incident has since upgraded and are
successfully mining on the main chain. We would like to take this time
to encourage node operators to keep up-to-date with the newest versions
and always review the release notesthis forum post2.

Additionally, improvements to the revamped https://z.cash2
were integrated and next week, we hope to include more documentation on
zk-SNARK so the site can be a primary resource for those interested in
learning more about this technology regardless of technical background.

On the community side of things, we’re hosting another technical AMA in 2 weekssuccessful first event which took place last Friday featuring @radix42
discussing his work on MacOS and Windows client ports. Let us know what
you thought and any ideas for future presentation topics or projects.

Stay tuned for the 1.0.6 release announcement on Monday and next week’s engineering update!

Zcash - Dev update February 17, 2017

This week began with the successful and timely release of 1.0.6 which features low level interface improvements along with upgrades to security components. If you haven’t updated your nodes yet, go ahead and do that now then come back to read the rest of this update.

For the big picture planning theme of the week, we started fleshing out al ist of priorities15 which is helping to shape a development roadmap. You’ll see the details of this roadmap explained further in an upcoming blog post. From a priorities standpoint, security incidents will always come first and foremost with 100% engineering time dedicated to any related tasks. We will also keep continuous improvement high on priorities but with a fraction of engineering time dedicated so other tasks can happen simultaneously. New features on this priorities list include payment disclosure delegated proving and XCAT4 - which might not be a surprise if you've been keeping up with dev updates so far. We consider these features low/medium hanging fruit which will enhance the Zcash ecosystem to a significant extent. Research and development on core circuit improvements in addition to user-defined

are further down the list of priorities at this point but still in the scope of our roadmap.

We also discussed a security incident response process which we will
make public via a blog post in the near future in addition to our
continued open development process. While our engineering meetings are
currently kept to an internal scope, we plan on extending invitations to
outside developers with related work and interest. We are additionally
exploring other methods for more open video meetings. Our AMA’s are also
set to occur on a bi-monthly basis with the next one
set for a week from today on Friday, February 24th. We’re also keen on
keeping up public text-based engineering discussions which are hosted on
the community chat1, mostly in the #zcash-dev channel. Engineers, advisors and scientists working with ZECC are marked with Zcash Team Member.

To keep the ball rolling with Payment disclosure, we had another
topical meeting which focused on nailing down a solution to the privacy
leaks with change addresses which resulted in a new approach (issue 2102PR 2103) and specification into a ZIP which will be pushed as a draft for review in the near future.

In addition to the above changes from upstream for 1.0.71z_decryptsinceblock which mimics listsinceblock functionality but includes transactions sent to shielded addresses in the wallet. We also continued work on a test for prioritising transactions.