Alternatives for Non-Direct Development Funding.

[nuttycom]

I am adding this proposal in the interest of ensuring that there is a 20% deferral, pure lockbox version of @skyl's proposal available for the community to vote on.

[str4d]

Reviewed for semantic stability in ZIP Sync with @conradoplg and @arya2, as well as @daira.

[nuttycom]

This may be modified to depend on #867 and specify the addition of a single funding stream:

  ================= =========== ============= ============== ============
        Stream       Numerator   Denominator   Start height   End height
  ================= =========== ============= ============== ============
  ``FS_DEFERRED``       20           100          2726400     u32::MAX
  ================= =========== ============= ============== ============

with the "Address" for the FS_DEFERRED stream being DEFERRED_POOL for all heights.

[str4d]

As a helpful visualization, this is what the flow of ZEC within a coinbase transaction for a single block looks like (as percentages overall; the halving effect is not shown here due to issues with getting cross-graph heights correct):

ZIP 1014

---
config:
  sankey:
    showValues: false
---
sankey-beta

Block Subsidy,Zcash Foundation,0.05
Block Subsidy,Bootstrap Project,0.07
Block Subsidy,Zcash Community Grants,0.08
Block Subsidy,Miners,0.8
Fees,Miners,0.01

Loading

This ZIP draft

---
config:
  sankey:
    showValues: false
---
sankey-beta

Block Subsidy,Lockbox,0.2
Block Subsidy,Miners,0.8
Fees,Miners,0.01

Loading

[str4d]

Reviewed on my own for semantic stability.

[str4d]

This last sentence is superfluous; draft-nuttycom-lockbox-streams defines how ZIP 207 is amended to support the lockbox, and ZIP 207 already defines an "active funding stream":

An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.

as well as the process for modifying funding streams:

Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process.

It would be equally valid, and equally superfluous, to say "A future network upgrade is required in order for the streams that do not terminate at u32::MAX_VALUE to extend beyond their current termination height."

What would be a clarifying improvement here is to encode the intention that u32::MAX_VALUE is being used to mean "no end height":

Suggested change

	is set to `u32::MAX_VALUE`. A future network upgrade is required in order for
	these streams to be terminated.
	is set to `u32::MAX_VALUE`. A future network upgrade that alters the
	maximum possible block height MUST also alter these termination heights.

[nuttycom]

My rationale for calling out that it could be modified by a future ZIP is to clarify it for voters who are not familiar with the ZIP process, and who might mistakenly think that such rules cannot be changed in the future (which is a common error I have observed.)

[str4d]

If that is the motivation for calling it out, then it should be stated neutrally: point out that end heights for any stream can be added, modified, or removed by future ZIPs.

[str4d]

This section is AFAICT largely unaltered from ZIP 1014, other than replacing ZF with FPF. There are parts of this section about FPF that are noticeably different and/or more specific in the ZF ZIP draft. I'm not going to make any changes in this editorial pass; instead I will open a subsequent PR that aligns this ZIP draft with the ZF one, in order to make the differences between them clear (and so the owners of this ZIP draft can consider those differences individually; there is no requirement for the two ZIP drafts to actually align here, other than as needed by FPF itself).

[aquietinvestor]

I discussed this comment with Alex from ZF/FPF today. I am going to review the precise language in the ZF draft over the next couple days, discuss it with Alex and then we'll come back to you. Thanks.

[str4d]

Once @nuttycom or @aquietinvestor responds to #866 (comment), I can get this re-rendered and merged.

[noamchom67]

This proposal is a direct copy of #860 with alternative parameters. #860 was merged into #866, and the latter now has another alternative parameter set matching this proposal. Closing this PR as superceded by #866.

Thanks for adding my proposal as Alternative #4. The only part of #866 that I can't find to match in my proposal is a specific "Revisitation" requirement.

I also believe that the "Direct Grant Option" is outdated/ to be removed. None of the current ecosystem sentiment is indicating an intention for Direct (Protocol Coded) Grants.

Revisitation: The terms of this ZIP should be revisited by the Zcash ecosystem
upon creation/ activation of a "non-direct funding model". At that completion of
an NDFM which accessess the lockbox funds, this ZIP should be reconsidered (potentially terminated)
by the Zcash ecosystem, to determine if its ongoing direct block subsidies
are preferred for continuation. Discussions/ solications/ sentiment gathering
from the Zcash ecosystem should be initiated ~6 months in advance of the presumed
activation of a "non-direct funding model", such that the Zcash
ecosystem preference can be expediently realized.

[daira]

Nit: REQUIRED isn't used. (There is a lowercase usage but it doesn't appear to be intended as a conformance term.)

[daira]

Although that would be sufficient,

• this way of expressing it assumes familiarity with Rust syntax;
• it is arguably clearer just to write "no end height".

Suggested change

	is set to `u32::MAX_VALUE`. A future network upgrade that alters the
	is given as "no end height". A future network upgrade that alters the

This requires a corresponding modification to draft-nuttycom-lockbox-streams. @nuttycom

[conradoplg]

I had comitted this fix but then I realized it would require updating the table and the next sentence, which I'm not sure how you all would prefer to do so I restored this. I don't think it matters that much though.

[conradoplg]

I also believe that the "Direct Grant Option" is outdated/ to be removed. None of the current ecosystem sentiment is indicating an intention for Direct (Protocol Coded) Grants.

@aquietinvestor do you also agree with removing this, so we can remove it for both Alternatives that were specifying it?

Revisitation: The terms of this ZIP should be revisited by the Zcash ecosystem upon creation/ activation of a "non-direct funding model". At that completion of an NDFM which accessess the lockbox funds, this ZIP should be reconsidered (potentially terminated) by the Zcash ecosystem, to determine if its ongoing direct block subsidies are preferred for continuation. Discussions/ solications/ sentiment gathering from the Zcash ecosystem should be initiated ~6 months in advance of the presumed activation of a "non-direct funding model", such that the Zcash ecosystem preference can be expediently realized.

I committed this in 8b1c43e

[daira]

Define Restricted Fund, if it is intended to continue using that term.

[aquietinvestor]

I also believe that the "Direct Grant Option" is outdated/ to be removed. None of the current ecosystem sentiment is indicating an intention for Direct (Protocol Coded) Grants.

@aquietinvestor do you also agree with removing this, so we can remove it for both Alternatives that were specifying it?

Revisitation: The terms of this ZIP should be revisited by the Zcash ecosystem upon creation/ activation of a "non-direct funding model". At that completion of an NDFM which accessess the lockbox funds, this ZIP should be reconsidered (potentially terminated) by the Zcash ecosystem, to determine if its ongoing direct block subsidies are preferred for continuation. Discussions/ solications/ sentiment gathering from the Zcash ecosystem should be initiated ~6 months in advance of the presumed activation of a "non-direct funding model", such that the Zcash ecosystem preference can be expediently realized.

I committed this in 8b1c43e

@conradoplg Yes, it is fine to remove the direct grant option. Thank you.

[str4d]

Non-editorial comments have been addressed. I have fixed rendering bugs and re-rendered.