I don’t know if I am doing this right, but @paige and others said they would help flesh it out if needs be.
I propose that no adjustment is made to the current status quo of block rewards, I would like to add that their should be no protocol adjustment of redistribution of mining fees without explicit user consent.
I am not sure how this is an Improvement but - I just want it on record.
How do I champion this zip?
Thank you. and sorry if I got this wrong and this isn’t what I am supposed to do. Just delete it.
Yeah, the whole community can help flesh it out. The goal, IMO, is to make each proposal as clear and specific as possible so that the community can be clear about which decision they’re making.
This sounds more like a “community resolution” rather than a protocol change. Resolutions are definitely improvements for Zcash even though they aren’t literal changes to the protocol, because they help everyone know what the community intends for the future of Zcash.
I would argue that the ZIP process already has a space for resolutions like this, but if it doesn’t, I advocate extending the ZIP process to include them.
Would this preclude any introduction of proof-of-stake, including hybrid PoW-PoS?
Those kinds of changes alter block rewards such that some go to stakers instead of miners, and I’ve seen different people interpreting that differently.
Does this include transaction fees?
Would this resolution prohibit introducing consensus rules that redirect some or all of transaction fees to anyone other than miners?
Example rule: half of transaction fees go to the block miner and half go to a development fund.
What does “explicit user consent” mean?
Does that mean users can introduce a rule to redistribute mining rewards or fees, as long as they consent? Maybe an example of how “consent” is measured is stake-based voting, where if 60% of all ZEC votes for a change to a mining reward redistribution, then that’s acceptable.
Or does it mean that rules that let users redirect funds “dynamically” are acceptable? For example: users can vote either for or against allocating issued tokens to a dev organization in each block?
Does the “current status quo” of block rewards include only the amounts of block rewards, or does it also include transaction details such as the ability to use t-addresses? For example, would the resolution prohibit disabling t-addresses for mining rewards in the future?
Cool. Thank you for the speedy response, there is little time. I will try to champion some other zips too. Can I please use RFC language? I think it will be easier most people are familiar with those.
No, mining is the processing of transactions. Stakers are miners too. They should get block distribution if PoS comes in.
This I don’t know. I cannot find any stance from the ECC in the early docs that state what happens to the transaction fees, only block rewards. I would really appreciate it if you can point me to any more info on this.
but in principle no, it doesn’t. (until I find information to the contrary)
Not in principle. but it is kinda an assumption that they will go there. - but I see this as the potential funding source.
This means that like the current FR rewards are baked into the coinbase, so would the addresses for donations for the foundation.
A user would signal by enabling a switch on their mining software or transaction client that would let them give an additional percentage of either the transaction or block distribution e.g.
I sent you 1 zec.
I pay 0.001 zec in mining fees that at in this zip go to the miner
I opt to pay 0.001zec on top as a donation. (by ticking a box in the software)
In this case the sender sends 1.002 zec. 0.001 goes to the foundation.
The miner if the pool or software he is using donates a percentage of his fee’s say 10% the miner donates 10% of the blocks total fees. I am leaving out block distribution because that will run out. I am open to the idea of putting it into the zip though.
This is unacceptable in this zip under any circumstance except emergency security issues. The block distribution is not up for change from the miners(transaction processors) in this zip. The intent of this zip is to honour the 90% block distribution as set out when we all opted in to zec. No voting. This zip is to stop that exact above scenario.
You could add these opt-in’s to the block distribution but that stops one day. Fees are forever, I am trying to think 60 years time when most of us will be long gone. There will be massive advances in tech over that time which this will have to keep up with.
The spirit of the zip is also longevity.
Not at all the intent of the zip is to preserve the 90% block distribution. to the miners (transaction processors) not to disrupt the usecases for zcash, especially its most important ones.
This zip kinda needs z only mining addressing to work properly, there might be too many correlation attacks from fees otherwise.
Speaking as a ZIP Editor, @mistfpga’s proposal is entirely in scope for a potential ZIP, under the current process. ZIPs do not have to describe protocol changes (especially in a case like this where they are acting as an alternative to one or more other proposed ZIPs).
Such a ZIP would of course have a very simple Specification section; the meat would be in the Rationale.