Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ZIP 207] [Blossom NU] Split Founders' Reward #3673

Open
nathan-at-least opened this Issue Nov 14, 2018 · 14 comments

Comments

@nathan-at-least
Copy link
Contributor

nathan-at-least commented Nov 14, 2018

From Announcing Zcash Blossom and proposed feature goals:

Split Founders' Reward

  • What is it? Alter the consensus rules so that there are distinct FR addresses for the Zcash Foundation, Zcash Company Strategic Reserve, and the remainder.
  • Who does this affect? FR Recipients and Governance/Transparency focused public
  • Why is this a goal? This decouples these three funding streams organizationally, legally, and operationally. It further reinforces transparency as to the structure of the Founders' Reward.

Close Criteria: Close this ticket when there are well-specified precise requirements for this feature goal.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

nathan-at-least commented Dec 10, 2018

The feature requirements for this are fairly simple:

At the activation height, transition from the Sprout/Overwinter/Sapling FR consensus rules to new similar rules.

The current, initial rules require a portion of block reward be sent to an FR Address which rotates on a regular block interval, which I'll call a period in this ticket. The new rules should require portions of the block rewards are assigned to multiple specific FR Addresses per period, one for each of:

  • the Zcash Foundation Fund,
  • the Zcash Company Dev Fund, and
  • the Reward Fund.

TODO: Define the proportions required to be sent to each address category.

@daira

This comment has been minimized.

Copy link
Contributor

daira commented Dec 11, 2018

If we're changing the FR addresses, then I would like to take the opportunity to make them Sapling addresses, and to allow directing mining rewards to Sapling addresses. (This may depend on adding shielded multisig.)

@mms710

This comment has been minimized.

Copy link

mms710 commented Dec 12, 2018

We did a first pass of RICE scoring without the full engineering team (eg we will need to do another pass) and the score for this item was 21.0.

@mms710

This comment has been minimized.

Copy link

mms710 commented Dec 14, 2018

Sorry, it took me a while to get back to this. Some context on the RICE scoring method: the RICE score is supposed to help provide a guideline for rough prioritization of various ideas (in this case, various possible Blossom goals). While it will be used as a guideline, it is not a hard and fast rule that something with a higher RICE score will always be worked on first or have a higher priority. The most useful way RICE scores can impact the Zcash selection process is by providing an indication of which items are "low-hanging fruit". You'll notice that some of the higher scored items have low effort associated with them.

In addition, it's important to know that this is an initial RICE score. After the goal is fully detailed and specified, we will perform the RICE scoring again because we will have gained more information that will make the RICE scores more accurate.

We calculate our RICE scores using the following formula:
(Reach * Impact * Confidence)/Effort.
Reach: How many users will this change/feature impact, or how many new users will this gain? Alternately, you can think of this as roughly what % of our user base this change will reach. Give this a 1-10 score, 1 being the least amount of reach and 10 being the most. Generally, items with a 9 or 10 score will gain new users.
Impact: How large of an impact will this change/feature have on users? Will it increase their usage of Zcash, or of shielded transactions? Give this a 1-10 score, 1 being the least impact and 10 being the most.
Confidence: How confident are you that this change will reach the amount of users you said and impact users as much as you said? Please express this in a % form between 1-100% (typically in increments of 10), 10% meaning not at all confident and 100% being very confident.
Effort: How many person months will this work take to complete? This should be an estimate and you can use portions of person months in the calculation. For example, 2 weeks = .5 months.

RICE Score for this Item:
Reach: 9 - this will impact all of our users and may help us gain new users
Impact: 10 - we expect this to have a high impact on the users this will affect
Confidence: 70% - we're somewhat confident about our reach and impact numbers
Effort: 3 - we think this will take 3 person months to complete

Calculation: (9* 10 *.7)/3 = 21.0 RICE Score

@daira

This comment has been minimized.

Copy link
Contributor

daira commented Dec 15, 2018

I'm confused about the estimates of 9 for Reach and 10 for Impact. This change only directly affects the Zcash Foundation: roughly speaking, it allows the Foundation to rely on receiving their portion of FR directly rather than relying on ZcashCo passing it on to them. (More precisely it replaces, for that portion of the FR for the year after Blossom activation, the FR keyholders at ZcashCo with the FR keyholders at the Foundation.) It's unclear to me who is proposed to hold the keys to the Reward portion, but if it's either the Company or the Foundation then that part amounts to a no-op in terms of trust and security requirements.

It's true that, to the extent to which users perceive this change as being part of an increase in transparency and decentralization, that might have political advantages that could indirectly increase adoption. But if I understand correctly, it is not intended to actually change the distribution of FR funds at all, or if it is then that is independent of the consensus change being proposed here. So it's unclear to me how confident we can be in this effect. I am really quite skeptical that any users or potential users of Zcash actually distrust ZcashCo to pass on the Foundation portion of FR to them (and wouldn't the Foundation cry foul immediately if it failed to do so?)

@mms710

This comment has been minimized.

Copy link

mms710 commented Dec 18, 2018

Clarification on this ticket: This is going to be implemented using t-addresses for now.

To respond to Daira's question about risk above: The way in which this reduces risk is that it reduces the blast radius if either Zcash Company or the Zcash Foundation are compromised.

@mms710

This comment has been minimized.

Copy link

mms710 commented Dec 20, 2018

We very much want to do this but we don't believe Zcash Company will have time to do this in Blossom. Instead we will put it on deck for NU3.

@mms710

This comment has been minimized.

Copy link

mms710 commented Dec 26, 2018

Due to the removal of the counterfeit detection turnstyle from the Blossom upgrade list and due to the fact that some other Blossom goals (Sprout address retirement, rollback protection and shielded support custodian reinforcement) could probably be partially or fully done without a network upgrade, we can slot this back into the Blossom upgrade.

@str4d

This comment has been minimized.

Copy link
Contributor

str4d commented Jan 2, 2019

Using t-addrs for this, we need to write up a specification that covers the following points:

  • The Founders' Reward consensus rule in ContextualCheckBlock() will be gated on Blossom activation.
  • Prior to activation, the current logic applies (there must be a single output with value GetBlockSubsidy(nHeight) / 5 payed to address GetFoundersRewardScriptAtHeight(nHeight)).
  • From activation:
    • There will be three sets of FR addresses, each containing 12 addresses (creating a roughly-monthly sequence of FR periods between Blossom activation in October 2019 and the block reward halving around October 2020).
      • Constraint: we should pick the height transitions to be nice block height multiples, to simplify the implementation logic for miners and mining pools. Ideally we would also pick the Blossom activation height to be near that multiple, but this isn't a requirement.
        • To-do: pick the height transitions, taking #3672 and #3690 (both reducing block times) into account.
      • To-do: will the existing FR addresses be used for either the Zcash Company strategic reserve or the remainder, or will fresh addresses be used for all three?
      • To-do: specify the sets of FR addresses (this does not need to happen until the specification freeze at the end of February).
    • Each set of FR addresses will have an associated value (specified as exact constants in zatoshis, rather than relying on the division operation, as we don't have to deal with the slow-start).
      • To-do: specify the values (placeholder constants are necessary for the specification pre-audit freeze, while final values can wait until the specification freeze, as their sum can be trivially audited to add up to the intended FR total).
    • The coinbase in each block MUST contain three outputs corresponding to the three sets, that each pay the correct value to the FR address for that height.

@str4d str4d pinned this issue Jan 2, 2019

@str4d str4d changed the title Split Founders' Reward feature requirements [Blossom NU] Split Founders' Reward feature requirements Jan 2, 2019

@mms710 mms710 added this to Current Sprint in Zcashd Team Jan 3, 2019

@mms710 mms710 changed the title [Blossom NU] Split Founders' Reward feature requirements [Blossom NU] Write spec for Split Founders' Reward Jan 3, 2019

@mms710 mms710 assigned str4d and unassigned nathan-at-least Jan 3, 2019

@mms710

This comment has been minimized.

Copy link

mms710 commented Jan 8, 2019

Zcash Company has decided to move forward with pursuing splitting the founder's reward for Blossom. As a note, there are three more points along the network upgrade timeline below where we may need to abort this goal if we find significant issues with our approach as a result of issues that come up in specification auditing (end of Feb) inability to finish the code in time (end of March) or issues that come up as a result of code auditing or testing (end of May).

image

In addition to this goal, Zcash Company will be pursuing Harmony Mining (#3672) and Shorter Blocktimes (#3690) while maintaining transaction version 4 (#3739).

@mms710 mms710 moved this from Current Sprint to In Progress in Zcashd Team Jan 10, 2019

@daira daira changed the title [Blossom NU] Write spec for Split Founders' Reward [ZIP 207] [Blossom NU] Split Founders' Reward Jan 10, 2019

@mms710 mms710 moved this from In Progress to In Review in Zcashd Team Jan 17, 2019

@mms710

This comment has been minimized.

Copy link

mms710 commented Jan 22, 2019

@str4d would we need to make changes to the specification if we wanted to have more than three funding streams? For example, if we wanted to make more granular levels of funding to multiple different addresses for the Company, Foundation and various other projects.

@str4d

This comment has been minimized.

Copy link
Contributor

str4d commented Jan 22, 2019

@mms710 the only necessary change to the ZIP would be modifying the list of funding streams. The ZIP is specified in such a way that the implemented logic would be agnostic of the funding streams themselves; the only restriction is that the total value of all active funding streams at a given height MUST NOT exceed the block reward (because mathematics). Any restrictions or splits beyond that are social decisions, not technical ones.

@mms710

This comment has been minimized.

Copy link

mms710 commented Jan 23, 2019

Got it. @nathan-at-least Do you and Zooko have an idea yet of what the list of funding streams will be if you wanted to split them more granularly within Foundation, Company and remainder?

@acityinohio

This comment has been minimized.

Copy link

acityinohio commented Jan 25, 2019

From the Foundation perspective all the pledged ZEC can all be sent to a single address (ideally t-addr within our current set-up but could do Sapling in the future)

@mms710 mms710 moved this from In Review to Current Sprint in Zcashd Team Jan 31, 2019

@mms710 mms710 moved this from Current Sprint to Sapling Priorites in Zcashd Team Jan 31, 2019

@mms710 mms710 moved this from Sapling Priorites to Sprint Backlog in Zcashd Team Jan 31, 2019

@mms710 mms710 moved this from Bugs/Security Issues/TechDebt Backlog to Protocol Backlog in Zcashd Team Apr 4, 2019

@mms710 mms710 moved this from Protocol Backlog to Blocked in Zcashd Team Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.