Updated details [ZEC] ZCASH + Announcing Zcash Cloud Mining




  • Privacy technology for blockchains

    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 technology page 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?

    All of the authors of the Zerocash protocol are on our team, which includes most of the creators of the Zerocoin protocol and leading researchers of zk-SNARKs themselves .

    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.

    Download the Tech Preview release here, or get started with our Beta Guide . For more in-depth technical specification, see our developer wiki's specification page.

    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!

    Resources

    · REWARD STRUCTURE:

    ·
    2.5 minute block times, 12.5 ZEC per block

    (so the same 50 ZEC per 10 minutes as Bitcoin)

    - During the first four years, 80% goes to miners and 20% to Founders' Reward (so miners get 10 ZEC per block for first four years, then 6.25 ZEC, and then halving after)

    - During the first ~month, the block reward ramps up linearly from 0.005(ish?) ZEC to 12.5 ZEC
    (the mining slow start)


    Suprnova's Pool:

    https://zec.suprnova.cc


    Official, public standalone Miner:


    https://github.com/str4d/zcash/tree/standalone-min...

    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 Smiley

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


    Feel free to discuss and post your findings

    Team:

    https://z.cash/team.html


    Exchange:

    https://www.bitmex.com


    You can now mine ZCash Testnet on

    https://zec.suprnova.cc

    You can use the Standalone Miner provided here:

    https://github.com/str4d/zcash/tree/standalone-miner

    Zcash Cloud Mining

    Announcing Zcash Cloud Mining from Zeropond!

    We are building out a datacenter with mining software preloaded onto every machine.


    cloud.zeropond.com


    zeropond.tumblr.co











  • GUI Wallets


    https://github.com/vaklinov/zcash-swing-wallet-ui


    raphical user interface wrapper for the ZCash command line tools

    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






  • coupon genesis-mining ( zcash ) : o73C6H 💰💰💰💰💰✔✔✔



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

    The new release includes the following user-visible changes:

    1. Wallet encryption has been disabled. The reasons for disabling this feature for the time being are explained in our security warnings document. We recommend using full disk encryption for now instead. (#1552)
    2. We have included mitigations for security issues found by the NCC Group and Coinspect audits. (#1459, #1464, #1504)
    3. We have merged some changes from Bitcoin to help address potential denial-of-service vulnerabilities. (#1588, #1589, #1591)
    4. A bug that could cause assertion failures when restarting after a crash has been fixed. (#1378)
    5. 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)
    6. Running the node now displays a screen showing node metrics (and some pretty ASCII art ☺). (#1375)
    7. The consensus rules have been tightened to reject block and transaction versions that were previously used by Bitcoin but are not valid for Zcash. (#1556, #1600)
    8. The testnet now enforces the same rules on standard transactions as will be enforced on mainnet. (#1582, #1557)
    9. We have made changes to the getblocktemplate RPC call to support mining pools. (#1424, #1602)
    10. Improved support for deterministic builds. (#1549)
    11. Build fixes for the musl C library used by Alpine Linux. (#1558)
    12. Documentation improvements. (#1500, #1575)

    For a more complete list of changes, see our 1.0.0-rc2 release github milestone.

    This release resets the beta testnet. It continues to use the beta 2 proving and verify keys.

    To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.









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

    Download windows binaries here.

    Linux build instructions are here.

    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.

    Stay tuned as our testers say it's worth it.



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

    Over last weekend the final zk-SNARK parameters were created in the Parameter Generation Ceremony. The transcripts and software used for the ceremony have been published, and we'll be making another post with more information on that very soon.

    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:

    1. 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)
    2. The version of Berkeley DB has been updated to 6.2.23. (#1637)
    3. The tinyformat library was updated in order to mitigate a potential buffer overflow vulnerability. (#1640, #1349)
    4. A fix for a minor potential race condition was backported from Bitcoin. (#1634)
    5. A couple of portability problems with the fetch-params.sh script and the Debian packages have been fixed. (#1053, #1537, #1613)
    6. 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)
    7. Updates to documentation and examples. (#826, #965, #1152, #1154, #1643)
    8. Network bootstrapping for mainnet. (#1369)

    1.0.0-rc4 - zkSNARK Params and Founders' Reward Addresses

    The 1.0.0-rc4 release, which is the one now deployed on the testnet, made some final updates in preparation for the Zcash launch:

    1. The zk-SNARK parameters have been updated to the ones created by the ceremony performed last weekend.
    2. The Founders' Reward addresses for mainnet have also been updated.

    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!

    To follow our progress, watch the GitHub project and join the forum. To get an email announcement when Zcash Sprout is ready, put your email address in here.



  • Zcash Listed on Poloniex:


    https://poloniex.com/exchange#btc_zec





  • 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 hope that as this community grows, other individuals will take on the responsibility of maintaining a repository or lists of Zcash providers. For example, Zcash contributor @vaklinov has begun hosting a list of wallets here: https://zcashblog.wordpress.com/zcash-gui-wallets/.

    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

    Cockpit UI Wallet - https://github.com/hellcatz/zcash-cli-cockpit

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

    Desktop GUI Wallet - https://github.com/vaklinov/zcash-swing-wallet-ui

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

    Jaxx - https://jaxx.io/

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

    TREZOR - http://bitcointrezor.com/

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

    Waterhole GUI mobile wallet - https://waterhole.io/

    From the waterhole.io site, “This is a trading platform and a wallet provider for multiple crypto-currencies. It already supports ZCash.”

    EXCHANGES

    Bitfinex - https://www.bitfinex.com/

    From the Bitfinex website: “This is one of the leading cryptocurrency exchanges, and the world’s largest exchange by volume for trading bitcoin against the US Dollar.”

    Bittrex - https://bittrex.com/

    From the Bittrex website, “Based and fully regulated in the USA, Bittrex is the go-to spot for traders who demand lightning fast trade execution, stable wallets, and industry-best security practices.”

    Bitnow - https://bitnow.co.nz/

    New Zealand

    Bitsquare - https://bitsquare.io/bitsquare.pdf

    From the Bitsquare whitepaper, “This is an open source peer-to-peer application that allows anyone to buy and sell Bitcoin in exchange to national currencies or alternative crypto currencies.”

    Changelly - https://changelly.com/

    From a Changelly representative, “Changelly is an instant cryptocurrency exchange.”

    HitBTC - https://hitbtc.com/

    From an HitBTC representative, “This is a global platform dealing with virtual currencies, providing advanced exchange and clearing technologies. HitBTC is operated by Beta Business Solutions Inc.”

    Kraken - https://www.kraken.com/

    From the Kraken website, “Mainly a Euro and US Dollar exchange for Bitcoin and Litecoin, but also offers markets for several other cryptocurrencies and fiat currencies.”

    Poloniex - https://poloniex.com/

    From the Poloniex website, “A US-based cryptocurrency exchange offering maximum security and advanced trading features, trading in numerous virtual currencies, including Bitcoin, Ethereum, Litecoin and Dogecoin.”

    ShapeShift - https://shapeshift.io

    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.

    YUNBI - https://yunbi.com

    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 the Zcash 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.1


    Today we're announcing the release of Zcash 1.0.1, which fixes a few bugs and improves diagnostics:

    1. Fixed a bug where transactions that contain shielded payments were not being mined in some circumstances. (#1718)
    2. Invalid arguments passed when building JoinSplits now produce more descriptive errors. (#1752)
    3. Added new RPC call, z_validateaddress (#1748)
    4. The friendly metrics screen has improved accuracy and additional information. (#1735)
    5. A consensus rule improperly applied to the genesis block was adjusted. (#1754)
    6. fetch-params.sh has been improved and is included in the gitian build. (#1758, #1759)
    7. A checkpoint was added for block 2500. (#1750)

    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.1 github milestone. To follow our progress, watch the GitHub project and join the forum.



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

    1. We fixed a bug to ensure that JoinSplit transactions to multiple z-addresses will succeed. (#1790)
    2. We changed z_sendmany to check if the size of a transaction for a given number of outputs will be valid. (#1808)
    3. We fixed a bug that could crash the miner when it was interrupted. (#1778)
    4. Community contributors helped improve our documentation. (#1765, #1763)

    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.2 github milestone. To follow our progress, watch the GitHub project and join the forum.

    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.

    For further background, please see our prior blog posts:

    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.



    Source: Continued Funding and Transparency

    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:





    ZEC distribution rate for first 30,000 blocks. Source: User Expectations at Sprout Pt. 1: Slow-Start Mining & Mining Ecosystem

    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 as this example from block 8086:

    • Address t1XepX38RxS3o5hLioLbaNb6Fa2Y2Be55xw, the miner's address, receives 4.0431 ⓩ, and
    • Address t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd, which collects the Founders' Reward, receives 1.01075 ⓩ.

    Founders' Reward Addresses

    The miner's address is chosen by the miner at the time they created the block, whereas the founders' Reward address, t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd seen above, is specified in the consensus rules (specifically in this 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:

    Note: The last two links are to the zcha.in explorer which is not operated by the Zcash Company. Any blockchain explorer will provide the same information.














  • Zcash-New Release: 1.0.3

    Today we're announcing the release of Zcash 1.0.3 which fixes several

    crashes and security bugs, improves performance, and adjusts relay

    policies.

    We strongly recommend users and miners update to this version, as it fixes a cache invalidation bug that could be used by an attacker to disrupt the network. (See #1874.)

    Other changes in this release include:

    1. We fixed a bug that caused the wallet to crash during startup in some situations, such as when the wallet is not synchronized properly with the blockchain. (#1858)
    2. We re-enabled note randomization that was temporarily disabled in 1.0.2. (#1814)
    3. We adjusted fee policies to reflect changes made in Bitcoin Core and encourage relaying of transactions containing JoinSplits. (#1855)
    4. We improved diagnostics and strengthened testing for the merkle tree's interaction with the constraint system. (#1797)
    5. We disabled RPC keepalive features temporarily to avoid deadlocks. (#1847)
    6. We adjusted our use of the libsnark verification API to improve zk-SNARK verification performance by 10%. (#1760, stats)
    7. We changed the error message format for z_sendmany so that amounts are displayed in units of ZEC. (#1838)

    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.3 github milestone. To follow our progress, watch the GitHub project and join the forum.



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

    1. They rely on zcashd releases older than 1.0.3, including 1.0.0, 1.0.1, and 1.0.2, AND
    2. 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:

    1. they have upgraded to zcashd 1.0.3, or rely on a service which has done so, OR
    2. 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.

    How can at-risk users protect themselves?

    1. Upgrading to zcashd release 1.0.3 is the most certain protection.
    2. 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 always announce known ongoing attacks in these places:
    • 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.












  • ZCash and ZClassic solo mining stratum with Web interface.



    • Your personal solo ZCash & ZClassic stratum
    • Rigs availability monitoring
    • Keep track of accepts, rejects, blocks stats
    • Easy detection of sick rigs
    • Daemon failover list

    Public binary release with devfeehttps://github.com/sammy007/zcash-proxy/releases


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

    it will update its database accordingly:

    Note4=

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

    Now suppose each note also contains a random 'serial number' (aka unique identifier) r.

    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!

    Donations in BTC to: 1L33E8M1LdXmAtgWaSgAVr4TEyDrLWk69B

    Email me at [email protected] for any Mac specific questions.

    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.

    Requirements

    Currently, you will need:

    • A Mac running Yosemite, El Capitan or Sierra
    • 4GB of free memory
    • Homebrew from http://brew.sh

    The interfaces are a commandline client (zcash-cli) and a Remote Procedure Call (RPC) interface, which is documented here:

    https://github.com/zcash/zcash/blob/v1.0.3/doc/payment-api.md

    Security

    Before installing, upgrading, or running zcash, ensure you have checked for any security issues. Please See our Security page:

    https://z.cash/support/security.html

    Get started

    Binary installation

    After you've installed Homebrew from http://brew.sh install the following dependencies:

    brew tap discoteq/discoteq<span class="pl-k">;</span> brew install flock
    brew install wget

    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:

    https://itunes.apple.com/us/app/xcode/id497799835?mt=12

    And Homebrew:

    http://brew.sh/

    And this is the list of brew packages you'll need installed:

    brew tap discoteq/discoteq<span class="pl-k">;</span> brew install flock
    brew install autoconf autogen automake
    brew tap homebrew/versions<span class="pl-k">;</span> brew install homebrew/versions/gcc5
    brew install binutils
    brew install protobuf
    brew install coreutils
    brew install wget

    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:

    mkdir -p <span class="pl-k">~</span>/Library/Application<span class="pl-cce">\ </span>Support/Zcash
    <span class="pl-c1">echo</span> <span class="pl-pds">"</span><span class="pl-s">addnode=mainnet.z.cash</span><span class="pl-pds">"</span> <span class="pl-k">></span>~/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf
    <span class="pl-c1">echo</span> <span class="pl-pds">"</span><span class="pl-s">rpcuser=username</span><span class="pl-pds">"</span> <span class="pl-k">>></span>~/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf
    <span class="pl-c1">echo</span> <span class="pl-pds">"</span><span class="pl-s">rpcpassword=</span><span class="pl-pds">`</span><span class="pl-s">head -c 32 /dev/urandom </span><span class="pl-k">|</span> base64<span class="pl-pds">`"</span> <span class="pl-k">>></span>~/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf

    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.

    Enabling CPU mining:

    If you want to enable CPU mining, run these commands:

    $ <span class="pl-c1">echo</span> <span class="pl-pds">'</span><span class="pl-s">gen=1</span><span class="pl-pds">'</span> <span class="pl-k">>></span> <span class="pl-k">~</span>/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf
    $ <span class="pl-c1">echo</span> <span class="pl-pds">"</span><span class="pl-s">genproclimit=</span><span class="pl-pds">$(</span><span class="pl-s">nproc</span><span class="pl-pds">)"</span> <span class="pl-k">>></span> <span class="pl-k">~</span>/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf

    The default miner is not efficient, but has been well reviewed. To use a much more efficient but unreviewed solver, you can run this command:

    $ <span class="pl-c1">echo</span> <span class="pl-pds">'</span><span class="pl-s">equihashsolver=tromp</span><span class="pl-pds">'</span> <span class="pl-k">>></span> <span class="pl-k">~</span>/Library/Application<span class="pl-cce">\ </span>Support/Zcash/zcash.conf

    There are 3rd party CPU and GPU miners for Mac now, see the Zcash Forum at: https://forum.z.cash

    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!

    Generating a t-addr

    Let's generate a t-addr first.

    zcash-cli getnewaddress
    tb4oHp2v54vfmdgQ3v3SNuQga8JKHTNi2a1

    Receiving Zcash with a z-addr

    Now let's generate a z-addr.

    zcash-cli z_getnewaddress
    ztbqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG

    This creates a private address and stores its key in your local wallet file. Give this address to the sender!

    A z-addr is pretty large, so it's easy to make mistakes with them. Let's put it in an environment variable to avoid mistakes:

    $ ZADDR=<span class="pl-pds">'</span><span class="pl-s">ztbqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG</span><span class="pl-pds">'</span>

    To get a list of all addresses in your wallet for which you have a spending key, run this command:

    zcash-cli z_listaddresses

    You should see something like:

    [
        <span class="pl-pds">"</span><span class="pl-s">zta6qngiR3U7HxYopyTWkaDLwYBd83D5MT7Jb9gpgTzPLMZytzRbtdPP1Syv4RvRgHeoZrJWSask3DyfwXG9DGPMWMvX7aC</span><span class="pl-pds">"</span>,
        <span class="pl-pds">"</span><span class="pl-s">ztbqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG</span><span class="pl-pds">"</span>
    ]

    Great! Now, send your z-addr to the sender. You should eventually see their transaction when checking:

    zcash-cli z_listreceivedbyaddress <span class="pl-pds">"</span><span class="pl-smi">$ZADDR</span><span class="pl-pds">"</span>
    [
        {
            <span class="pl-pds">"</span><span class="pl-s">txid</span><span class="pl-pds">"</span> : <span class="pl-pds">"</span><span class="pl-s">af1665b317abe538148114a45322f28151925501c081949cc7a5207ef21cb750</span><span class="pl-pds">"</span>,
            <span class="pl-pds">"</span><span class="pl-s">amount</span><span class="pl-pds">"</span> : <span class="pl-c1">1.23</span>,
            "memo" : "48656c6c6f20ceb2210000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
        }
    ]

    Sending coins with your z-addr

    If someone gives you their z-addr...

    $ FRIEND=<span class="pl-pds">'</span><span class="pl-s">ztcDe8krwEt1ozWmGZhBDWrcUfmK3Ue5D5z1f6u2EZLLCjQq7mBRkaAPb45FUH4Tca91rF4R1vf983ukR71kHyXeED4quGV</span><span class="pl-pds">'</span>

    You can send 0.8 ZEC by doing...

    zcash-cli z_sendmany <span class="pl-pds">"</span><span class="pl-smi">$ZADDR</span><span class="pl-pds">"</span> <span class="pl-pds">"</span><span class="pl-s">[{</span><span class="pl-cce">\"</span><span class="pl-s">amount</span><span class="pl-cce">\"</span><span class="pl-s">: 0.8, </span><span class="pl-cce">\"</span><span class="pl-s">address</span><span class="pl-cce">\"</span><span class="pl-s">: </span><span class="pl-cce">\"</span><span class="pl-smi">$FRIEND</span><span class="pl-cce">\"</span><span class="pl-s">}]</span><span class="pl-pds">"</span>

    After waiting about a minute, you can check to see if the operation has finished and produced a result:

    zcash-cli z_getoperationresult
    [
        {
            <span class="pl-pds">"</span><span class="pl-s">id</span><span class="pl-pds">"</span> : <span class="pl-pds">"</span><span class="pl-s">opid-4eafcaf3-b028-40e0-9c29-137da5612f63</span><span class="pl-pds">"</span>,
            <span class="pl-pds">"</span><span class="pl-s">status</span><span class="pl-pds">"</span> : <span class="pl-pds">"</span><span class="pl-s">success</span><span class="pl-pds">"</span>,
            <span class="pl-pds">"</span><span class="pl-s">creation_time</span><span class="pl-pds">"</span> : <span class="pl-c1">1473439760</span>,
            <span class="pl-pds">"</span><span class="pl-s">result</span><span class="pl-pds">"</span> : {
                <span class="pl-pds">"</span><span class="pl-s">txid</span><span class="pl-pds">"</span> : <span class="pl-pds">"</span><span class="pl-s">3b85cab48629713cc0caae99a49557d7b906c52a4ade97b944f57b81d9b0852d</span><span class="pl-pds">"</span>
            },
            <span class="pl-pds">"</span><span class="pl-s">execution_secs</span><span class="pl-pds">"</span> : <span class="pl-c1">51.64785629</span>
        }
    ]

    Known Security Issues

    Each release contains a ./doc/security-warnings.md document describing security issues known to affect that release. You can find the most recent version of this document here:

    https://github.com/radix42/zcash/blob/master/doc/security-warnings.md

    Please also see our security page for recent notifications and other resources:

    https://z.cash/support/security.html


    By

    radix42/zcash







  • Waterhole Zcash pool 0% fee / high lucky rate. More payout!


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

    Pool Link:

    https://waterhole.io/pool/ze

    History of block mined:

    https://waterhole.io/pool/zec/blocks


    Pool hash rate history for past 10 days:

    https://waterhole.io/pool/zec/stats
    (bottom figure choose all)



    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!










  • Announcing the Winners of the Open Source Miner Challenge!


    A few months ago, we launched the Zcash Open Source Miner Challenge and today we are announcing the winners:

    -CPU Winner, $10,000 prize: xenoncat with https://github.com/xenoncat/equihash+xenon

    -GPU Winner, $10,000 prize: mbevand with https://github.com/mbevand/silentarmy

    -Runner Up, $5,000 prize: tromp with https://github.com/tromp/equihash

    -Runner Up, $3,000 prize: morpav with https://github.com/morpav/zceq_solver

    -Runner Up, $2,000 prize: davidjaenson with https://github.com/davidjaenson/equihash

    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!



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






Log in to reply