The future of Zcash in the year 2020

[str4d]

@mistfpga

And any adjustment to the rules that we are currently talking about would be opt-in - so users can select if they want some of their transaction(sender/receiver sets these), block reward or transaction fees (the miner sets this not the sender) to go to some development - or the (default) initial contract distribution is honoured.

The only way any of the above could be implemented as an adjustment to the consensus rules^[1], is for the consensus rules to specify that certain hard-coded addresses may optionally be present as outputs. But if it’s optional, then it’s basically useless as a consensus rule. Users and mining pools are already free to optionally add addresses as outputs to their transactions (a few wallets have done this in the past as “dev fees”, and IIRC some mining pools in the Grin network opt to donate a small percentage of their profits to developers). The only marginal benefit it provides would be having a globally-agreed-upon list of receiving addresses - but users can by definition ignore those and just create equivalent outputs to different addresses.

(As a side-note, miners wouldn’t get to set anything; it’s the mining pools that create the coinbase transactions and choose a policy. Miners could at most move their mining power to a different pool with a different policy, or solo-mine with significantly less efficiency (and thus incentive to do so) unless they are large enough that they are effectively their own mining pool.)

Tying this back to what @acityinohio stated about the Zcash Foundation’s position:

@acityinohio

The Foundation would only support proposals that:

a) don’t rely on the Foundation being a single gatekeeper of funds
b) don’t change the upper bound of ZEC supply
and c) have some kind of opt in mechanism for choosing to disburse funds (from miners and/or users)

Any opt-in proposal where the opt-in process is not “user chooses to upgrade to a version of the node software that will follow a Network Upgrade activating this proposal” should IMHO not be proposed as a consensus rule change, because it adds needless complexity for no useful benefit. I think it would be valuable for @acityinohio to clarify the above statement, because if it is referring to local on-demand opt-in (as @mistfpga is referring to), this implies (in my view) that the ZF would only support proposals that do not change the consensus rules.

_{[1] I am specifically ignoring consensus rule changes that would create some kind of dynamic in-network decision-making process (a la Tezos) to decide when to turn on or off some kind of funding, because that is an extension of consensus-making and is not a local opt-in decision like @mistfpga was referring to.}