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

Implement the Founders' Reward. #125

Closed
nathan-at-least opened this issue Feb 25, 2015 · 12 comments

Comments

@nathan-at-least
Copy link
Contributor

commented Feb 25, 2015

For the Founders' Reward we desire these properties:

  • the public can verify the total amount of the reward.
  • the public can verify the rate at which the reward is disbursed / thaws. (see #96)
  • the founders & investors are satisfied that the reward meets the agreed upon terms and distribution.

I also propose this engineering goal:

  • the exception to consensus rules is minimal and contained in only the genesis block. eg: There is a single exceptional txOut containing all of the reward amount, and all subsequent distribution is through non-exceptional transactions. Edit 2016-04-13: We've decided instead to have a constraint imposed on coinbase transactions up to the end of the first halving interval.

A further goal might be:

  • While the public can verify the reward total, the public cannot see the internal distribution. (Note that the founders/investors of course must be able to individually verify their reward amount.)
@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Feb 25, 2015

With CHECKLOCKTIMEVERIFY (see BIP-0065) implemented, a "clear-text" premine is possible which achieves all of the goals except the last goal of founder/investor confidentiality.

This implementation sketch does not use any Zerocash operations, and lacks confidentiality.

  1. Have a single exceptional TxOut with an nValue equal to the premine total, and an anyone-can-spend scriptPubKey (see below). Call this the primordial premine TxOut.

In the genesis block, include these transactions:
2. The stakeholder split is a transaction from the primordial TxOut to N TxOuts, one for each stakeholder. The distribution of nValue along these TxOuts matches the premine's contractual agreement. The scriptPubKey is anyone-can-spend.
3. For each TxOut of the stakeholder split there is a monthly payout transaction which splits the relevant TxIn into K TxOuts representing K months. These have scriptPubKey with CHECKLOCKTIMEVERIFY set to i * M for i ∈ [0,K) where M is the expected number of blocks per month. The scriptPubKeys are also constrained to the stakeholders' public keys.

Because these all are baked into the genesis block, there are no race condition or authorization problems with the anyone-can-spend TxOuts. The only unspent TxOuts (UTXOs) left in this structure are to specific stakeholder addresses and have appropriate time locks.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Mar 2, 2015

@imichaelmiers pointed out we can use pseudonymous base-protocol addresses to provide confidentiality of the premine distribution.

Also, he points out that we should examine how other alt-coins implement their premines and learn from them.

@nathan-at-least nathan-at-least changed the title Implement the premine. Implement the Founder's Reward. Aug 17, 2015

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2015

Terminology Note: I just edited the title and ticket description (but not subsequent comments) to rename "premine" to "founder's reward". The term "premine" confuses our explicit goal of a time-released reward, so it's not "pre-" launch in that regard. Also, it's not "mined" like the mining reward. So, let's avoid using that term henceforth.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Oct 16, 2015

Related: #299 is about the feasibility of using CLTV on Pours, and this might be an important mechanism for this ticket's implementation.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2015

Note: A quirky edge case @ebfull just called my attention to is that upstream excludes the transaction(s) in the genesis block from the set of valid and available transactions! This means their outputs are not valid references and therefore can never be spent. In Bitcoin, this is the single coinbase transaction, but if we wanted to place other time-locked transactions in the genesis block as a reward implementation, we'd need to undo this upstream exception.

References:

@daira

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2016

This ticket needs review to make it reflect the plan for the Founders' reward to be a proportion of mining rewards for a set period.

@zookozcash

This comment has been minimized.

Copy link

commented Mar 9, 2016

Yeah, I don't think it will work to use the technique suggested above, of time-locked transactions baked into the genesis block. That would be cool, but there would be way too many transactions, since the Founders Reward is supposed to be distributed frequently, ideally with every block.

So I propose instead the simpler thing of having a single special payment address for the founders baked into the consensus rules.

@daira

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2016

I think that using a single payment address as the destination of the Founders' Reward is incredibly risky. It concentrates spend authority over (eventually) 10% of the money supply into a single secret. Granted, it would be possible –and highly advisable– to regularly spend from that address to other addresses that are less concentrated targets. However, if the spending key were compromised then it would still put the Zcash company in the position of having to race with the thief to spend the Founders' proportion of each and every block reward. The only way to resolve this situation would be a –possibly controversial– emergency hardfork to change the Founders' reward payment address.

@daira

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2016

Note that it's possible to monitor the blockchain for unauthorized spends of Founders' rewards. However, without support for viewing keys (#406), this requires the spend authority key to be permanently online somewhere in order to compute the serial numbers to compare with the ones spent in each transaction. Also, you still have to regularly empty the Founders' reward address(es) to limit how much the thief can steal before they are first detected.

[Edit: this comment was made when I was thinking that the Founders' Reward payments would be using JoinSplit transfers. Now they're transparent transfers, so the first part about viewing keys doesn't apply.]

@daira daira changed the title Implement the Founder's Reward. Implement the Founders' Reward. Mar 10, 2016

@ebfull

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2016

The founders reward should be sent to a P2SH address, a 2-of-3 multisig.

@zmanian

This comment has been minimized.

Copy link

commented Mar 15, 2016

What if Zcash a specified a different P2SH address every 1250 blocks for the Founders reward, you could store the 2 of 3 keys(or whatever) in an isolated manner so that a compromise of those keys would only do limited amount of damage to the Founders Reward rather than potentially loosing the entire future founders reward without a hard fork. This would only require storing 42 PSH outputs in the consensus which seems like a small price to pay for some defense in depth.

This concentration of the Founder's Reward in only a few keys seems like one downside of the ZCash approach vs the Ethereum approach.

@ebfull ebfull added this to the 1.0 milestone Mar 15, 2016

@ebfull ebfull added this to the 1.0 milestone Mar 15, 2016

@nathan-at-least nathan-at-least added RM misc and removed RM misc labels Mar 22, 2016

@nathan-at-least nathan-at-least modified the milestones: 1.0, Consensus Feature Implementation Deadline Mar 28, 2016

@nathan-at-least nathan-at-least modified the milestones: Consensus Feature Implementation Deadline, PoW Release Mar 29, 2016

@ebfull ebfull self-assigned this Apr 5, 2016

zkbot pushed a commit that referenced this issue Apr 11, 2016

zkbot
Auto merge of #831 - ebfull:foundersreward, r=nathan-at-least
Implement Founders' Reward

More info:  https://z.cash/blog/funding.html

The consensus rule is as follows:

```
All blocks before the first subsidy halving block, with the exception of
the genesis block, must contain an output which sends 20% of the block
subsidy value to a scriptPubKey `FOUNDERS_REWARD_SCRIPT`.
```

Right now, `FOUNDERS_REWARD_SCRIPT` is a 2-of-3 multisig P2SH.

Closes #125
@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2016

#831 has merged, so this is complete. Nice work @ebfull et al.

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.