The FAQ says the following under What are the general characteristics of a Zcash block? (https://z.cash/support/faq/#zcash-block):

What are the general characteristics of a Zcash block?

  * Average block time: 1.25 minutes (75 seconds)
  * Maximum block size: 2MB
  * Block Reward: currently 6.25, 3.125 after November 18, 2020
    - Each 4 year period, the ZEC creation amount will halve (from 12.5 to 6.25 to 3.125 to 1.5625 and so on).

Obviously, the reward is now 3.125 since the date is past November, 2020.

continuation of this work tokio-rs/website#425

Currently you get a 404.

Following from #101, this should explain the implementation of batch verification for RedJubJub signatures, covering:

• how batch verification works (in terms of the cryptography);
• how the batch verification is wrapped into a tower-batch wrapper, and in particular explaining a little bit about what actually happens when messages are sent through channels;
• how the batch verifier is wrapped up in a fallback wrapper and put in a once-cell to provide a global batch verification context.

This should follow up from #37, with an adaptation of the text in https://doc.zebra.zfnd.org/tower_batch/index.html . This will be easy to write since almost all of the text already exists.

It does device fingerprinting which sucks. Also we don't even use it, so.

This post should explain how we implement semantic and contextual verification, dividing responsibility across the zebra-consensus and zebra-state crates. This can make reference to the Tower concepts explained in #98 and the structural/semantic/contextual distinction introduced in #37.

In this section:

There ought to be a link to zfnd.org.

Can we build microservices in one process in the absence of a cloud environment?
– N. Bukharin, probably

This post should explain what Tower is, why it exists, and how it works. Then, it should explain how we make use of Tower within Zebra. It would be nice to show some particular examples of where we make use of Tower's capabilities.

Copied over from the old GitHub repo: ZcashFoundation/ZcashFoundation#71

Authored by @acityinohio.

There have been many issues presented regarding the Grant program (feedback, improvements, etc) and I wanted to collect them here as a general "how can we improve grants?" issue. Summarizing them here:

1. Increase frequency of grants/streamline opportunities for applications (#69)
2. Continuation/lower-barrier grants (#70)
3. Community funding + matching (#41, #55)

I think we'll need to update the Grant program significantly, if not in 2018Q4, for the following cycle (which may be continuous/not in the normal two quarter cadence!).

Job Opportunity: Protocol Developer and Open Source Maintainer

The Zcash Foundation is hiring a protocol developer and open source maintainer. Are you interested in furthering our mission of building Internet payment and privacy infrastructure for the public good, primarily through the Zcash? Do you have experience with Rust and C++ and familiarity with Bitcoin and Zcash at the protocol level? Do you want the freedom to work how you want, where you want, and on software that will always be open source? Are you sick of all these rhetorical questions? Then (virtually) step right up!

Requirements

• Proficiency with Rust and C++
• Familiarity with Bitcoin and Zcash protocols and codebases
• Experience maintaining open source projects and working with open source contributors
• Willingness to contribute to Zcash and to upstream projects
• Strong belief that financial privacy should be universally accessible

Benefits

• Competitive salary, payable in USD and/or ZEC
• The Zcash Foundation is completely remote; work where and how you want
• Medical/Dental/401k benefits for US-based applicants
• Opportunity to shape engineering culture as first technical hire
• Mission >> Profit. We are a well-funded non-profit, which means you never have to make technical compromises for the pursuit of short-term profit.

Interested? Send a resume/CV and any supporting links to contact [at] zfnd [dot] org . We will endeavor to respond to every applicant.

Copied over from the old GitHub repo: ZcashFoundation/ZcashFoundation#63

Authored by @nathan-at-least.

Currently ZcashCo operates various kinds of Zcash infrastructure. Probably the most essential are seed nodes.

Ideally from my perspective ZcashCo would no operate any Zcash infrastructure in order to make Zcash resilient against the scenario of ZcashCo turning evil / imploding / being coerced, etc… The Foundation would be in a good position to define a set of "essential infrastructure" and then potentially fund its operation through grants.

IMO, the essential infrastructure includes:

• Seeder nodes, which help new nodes bootstrap into the network.
• Sufficient nodes to ensure the blockchain history is available to new nodes. (Ideally the network naturally provides this.)
• Hosting of zkSNARK parameters, which are necessary for using shielded transactions.
• Arguably: Nodes operating Tor hidden services and/or I2P equivalent, to enable IP address privacy.

Tangentially: I'm not clear if operating infrastructure or organizing and funding others to operate public infrastructure is within the mandate of the Foundation. Can we clarify this publicly?

Previous comments can be seen at the original link.

Could not open link: https://www.zfnd.org/blog/community-sentiment-collection-poll/ (occurs in zip-1008.html) due to <HTTPError 404: 'Not Found'>
Could not open link: https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/ (occurs in zip-1002.html and zip-1003.html and zip-1006.html and zip-1010.html) due to <HTTPError 404: 'Not Found'>
Could not open link: https://www.zfnd.org/blog/foundation-in-2019/ (occurs in zip-1003.html and zip-1010.html) due to <HTTPError 404: 'Not Found'>
Could not open link: https://www.zfnd.org/blog/multisig-governance/ (occurs in zip-1009.html) due to <HTTPError 404: 'Not Found'>
Could not open link: https://www.zfnd.org/governance/community-advisory-panel/ (occurs in zip-1014.html) due to <HTTPError 404: 'Not Found'>

Copied over from the old GitHub repo: ZcashFoundation/ZcashFoundation#76

Authored by @acityinohio.

Keeping this open to keep the community aware, and to make sure we update our financials on the new website.

In January, the batch verification post

https://www.zfnd.org/blog/futures-batch-verification/

introduced the structural / semantic / contextual verification distinction and promised a follow-up post about transaction data modeling. That promise should be kept, with a post that explains how the transaction structure makes invalid transactions unrepresentable.

This blog post should follow #100, and explain how we checkpoint up to Sapling, skipping verification of sprout proofs.

It should talk about the design of the Checkpoint verifier, how it chains previous block hashes from checkpoint to checkpoint, and how we use the transaction merkle tree to bind transactions to the block header. (And therefore to the checkpoints.)

Hi. I'm super jazzed… yes, JAZZED! about the ZF Grants site!

I poked around a bit to see if the platform is open source. Is it? Can we transition it towards open source?

The first-order thing I want is just transparent issue tracking for it for bugs or feature requests. If it's proprietary, should we use this repo?

Second-order, I think open source could have nice longer term bigger picture pay-offs. Over on the Zcash forum I'm agitating for community-maintained integrations between the different Zcash community sites (forum, chat, ZF grants, etc…). It's a wacky fun light-hearted experimental idea, which is that the more tie-ins we have between these systems the more it might improve the communities interactions.

Even without that wacky idea, though, having ZF Grants be open source can allow a more explicit form of "process governance" for grants. Changes to the process could be explicitly coded up and discussion embodied in pull requests. Worthwhile to think about.

Edit: Yet a third thought is that open source would allow public scrutiny of security issues with the grant sites.

This website is still up. I think that it should be replaced with a page advertising a redirect to zfnd.org. What do you think?

This should explain how we implement state management, covering:

• finalized and non-finalized state;
• why we make that distinction, the cost we pay in potential divergence from zcashd, and why we think that's a worthwhile tradeoff;
• how we handle finalized state;
• how we handle non-finalized state.

There's potential overlap with #100. This post should definitely follow that one. I think it would make sense for #100 to describe the division of responsibility, but not delve too deep into the details of the state system.