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.


    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.

  • New Release: 1.0.4

    Today we're announcing the release of Zcash 1.0.4, which fixes several bugs, improves performance, and adjusts mining policies. With this release, private payments will get relayed and mined faster.

    Summary of the changes in this release:

    1. We fixed a cache invalidation bug that caused some orphaned blocks to trigger node crashes. (#1928)
    2. We fixed a race condition that inhibited creation of multi-JoinSplit transactions. (#1911)
    3. We adjusted mining policies to encourage inclusion of transactions containing JoinSplits. (#1895, #1902)
    4. We improved rescan and reindex performance. (#1892, #1904)
    5. We improved zk-SNARK verification performance by 7%. (#1919, stats)
    6. We added additional well-formedness checks for JoinSplit proofs. (#1938)
    7. We added a fee parameter to z_sendmany. (#1907)
    8. We added a getlocalsolps RPC method for obtaining the mining rate without the metrics screen. (#1642)
    9. The Bash completion files were updated to work with zcashd. (#1909)
    10. The build scripts were extended to make porting Zcash to other platforms easier. (#1905)
    11. A checkpoint was added at block height 15,000. (#1865)

    We're encouraging all users and miners to update to this new version. See our download page and the 1.0 User Guide for more information.For a more complete list of changes, see our 1.0.4 GitHub milestone. To follow our progress, watch the GitHub project and join the forum.

  • 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



    Here are my results from testing Optiminer 1.2.0 and Claymore 9.3 on a 7 GPU Ubuntu 16.04 Desktop rig. RX480 8GB Nitro Sapphire and MSI Z97 Gaming 5.



    Mining performance:
    Both at -i level 8 on all GPU's
    if 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.

    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.

    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.

    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.

  • Zcash Ceremony Video

    By paigeZcashCo Team Member

    Technical resources, documentation and participant accounts are listed in the video description.

  • ZCash Pool: 0% True PPS mining. Just change worker type to PPS and enjoy no fee PPS.

    ( until 2017-01-15 or pool's hashrate > 3 MH/s )


  • 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).


  • An Update on Integrating Zcash on Ethereum (ZoE)


  • Build Bitcoin (and ZCash) in Rust

    Consensus-Ready Bitcoin in Rust


    • Combine forces with Andrew Poelstra
    • Create a Rust library implementing all the core features and BIPs of the Bitcoin reference client
    • Create APIs for alt-coin implementations
    • Extend / create modules for ZCash


    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.

    Any critique, advice, information is very welcome.

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

    The mere use of shielded addresses by merchants accepting ZEC payments and by your friends provides an increased level of privacy for you, too! In the above example, the transaction series where Bob uses a shielded address (b) breaks the link between Alice and Carol. To help understand these properties, we created the following transactions which mimic the examples above: Alice sends 15 ZEC (minus fee) to transparent Bobtransparent Bob sends 10 ZEC to Carol compared with Alice sends 15 ZEC (minus fee) to shielded Bobshielded Bob sends 10 ZEC to Carol.

    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.

    Now, let’s consider the condition where Bob sends the full balance received from Alice to Carol and therefore has no change output. If Alice’s public output X and Carol’s public input Y are equal (or X equals Y minus two standard transaction fees) and that value is unique enough to other public values stored in the Zcash blockchain, there is a degree of association between Alice and Carol. You can see this example in the following transactions: Alice sends 15 ZEC (minus .0001 ZEC fee) to shielded Bobshielded Bob sends 14.9999 ZEC (minus .0001 ZEC fee) to Carol.

    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.

    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.


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


    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.

    More information can be found on our blog: blog.trezor.io

  • Zcash proxy V1.1.0 update :


  • Zcash for Windows Release Candidate

    Yes you read that subject line correctly! My release candidate for command line Windows Zcash (requires 64 bit Windows 7 or newer) is at:


    You need to manually download the proving keys into: ###code# which is normally C:\Users\YOUR-USERNAME\AppData\Roaming\ZcashParams\

    They are on my mirror of them on the fast Amazon CloudFront CDN at: https://zcash.dl.mercerweiss.c... and https://zcash.dl.mercerweiss.com/sprout-verifying.key

    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!

    And we're STILL short on rent, which is due today! I do NOT have a day job, and just 5 ZEC (or equivalent in btc or $$$) will cover what I'm short, donation addresses are at: https://zcash.mercerweiss.com/index.html#Donations


    David Mercer Tucson, AZ [email protected]

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

    Specification on formalizing the ZIP process1standardization of memo field formats and payment disclosureprotocol spec3 has reached a state where it's ready for publication. We plan to submit it to Cryptology ePrint Archive2 next week.

    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.

    Some research was also done on user defined assets1security level of the BN_128 curve in libsnark3.

    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.

    We continued work on pulling in changes from upstream1PR 20991, PR 2100PR 2101) and unifying the RPC documentation1.

    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.

    On the infrastructure side of things, more was done to finalize a chain fork detectornetwork dashboard4 which shows a visual of recent peers on the network and highly available nodes.

    Next week, we’ll redirect more focus onto 1.0.7 issues and continuing development and specification of payment disclosure.

  • Zcash [ZEC] New Pool :


Log in to reply

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.