[ZIP 235] Deposit 60% of Transaction Fees to the ZSF

[aphelionz]

This PR creates a ZIP that proposes depositing 60% of transaction fees into the ZSF, as described in #703

[teor2345]

Just a quick draft review of this ZIP, but as you can see by my suggestions I need to check some details with the rest of the ZIP Editors next week.

[aphelionz]

@teor2345 @daira I've added a small section regarding the "future implications" that we discussed on the Oct 5 Arborist call. Is that sufficient? Thank you 🙏

[teor2345]

There needs to be an explanation of the security goal, why reducing miner fees is secure now, and when it might not be secure in future.

Here is a draft security argument, but I'd like @daira to review it before it gets put into the ZIP:

Rationale

Mining Security

For Zcash to be secure, miners need financial incentives to:

• mine blocks,
• include transactions in those blocks, and
• choose to mine those blocks on the chain with the most work.

If miners don't have those incentives, then they might stop mining transactions, or deliberately create chain forks to re-mine transactions for themselves. These forks can roll back previously mined blocks and transactions, making Zcash transactions less secure and reliable.

Since the block reward is currently large in comparison to transaction fees, and the work required to create a block is significant, there is little incentive for miners to roll back blocks to take those transaction fees for themselves.

However, the incentive to mine a single transaction with a small fee is also small. So miners won't lose much by skipping mining a single transaction. This is a potential security issue, which can be mitigated by having multiple mining pools using diverse transaction selection policies.

Currently, miners only gain significant fees from mining large numbers of transactions (or logical actions) on the chain with the most work. This incentivises them to mine more transactions, because the amount of work required to mine a block is almost the same, regardless of the number of transactions.

Since miner fees are small, putting 60% of them into the ZSF does not significantly change the number of blocks a miner needs to mine to make the same profit. And the increase in issuance due to these ZSF deposits is also small.

Future Security Considerations

If the block reward becomes small in comparison to miner fees, then Zcash security rests on:

• the minimum ZSF deposit fraction,
• the relative size of the block reward compared to median transaction fees,
• the relative size of the block reward compared to the largest transaction fees, and
• the amount of work required to create a block.

However, smaller block rewards also make single transactions more valuable, so miners have less incentive to skip single transactions.

Here is an analysis of each of these factors:

If the minimum ZSF deposit fraction is small, then miners have a larger incentive to rollback and take transaction fees, rather than continuously mining to gain the deposit fees through later ZSF issuance.

For example, if the deposit fraction is 50%, then miners with less than 100% mining pool share have an incentive to rollback and take 50% of the transaction fee now, rather than waiting for later issuance of the ZSF deposit 50% over the long term. The break-even point depends on the timeframe. Every 4 years 50% of the ZSF is issued, so the break-even point over 4 years is around 33% miner fees, 33% ZSF fees re-issued, and 33% ZSF fees used for future issuance.

If median transaction fees are small, then miners have a smaller incentive to continuously mine many transactions. So a smaller ZSF deposit fraction would be more secure.

If the largest transactions fees are high enough, then miners have a larger incentive to rollback and take transaction fees. So a larger ZSF deposit fraction would be more secure, to incentivise waiting for future issuance. This incentive also depends on the number of transactions with large fees.

If the amount of work required to create a block is small, then miners have a larger incentive to rollback blocks and try mining the same transactions themselves.

[aphelionz]

Ty @daira and @teor2345 🙏

[nathan-at-least]

@teor2345 's text here makes sense to me.

Ok, I wrote a huge comment here that had a bunch of algebra, but was basically tautological, so I edited it to summarize the tautology:

Before the issuance reaches 0, these kinds of 0-issuance security issues are less severe. (Tautology)

The reason I got confused / distracted is pondering the possible case where the "average fees" being deposited will equal the issuance rate (if we ignore integer rounding errors and assume a fairly consistent rate of fees). If Zcash were likely to enter this era / regime, then we would never reach a true 0 issuance rate.

So I do think it's somewhat interesting to have a model that answers this question: "If average fees over some time window (say a month) remain ≥X ZEC, then how long will it be until those fee deposits match the issuance (ZSF withdrawal) rate?"

Relatedly if we believe it requires "Y ZEC per block to pay for network security / development / maintenance" then it is tautological that ZSF deposits need to be ≥Y (on average) for sustainability.

[aphelionz]

Thanks @nathan-at-least and thanks for the edit :)

I have added the tautology to the ZIP

[daira]

It might also be useful to survey whether other cryptocurrencies have made any roughly similar changes in issuance or fees, and what the effects on them have been.

[daira]

If median transaction fees are small, then miners have a smaller incentive to continuously mine many transactions. So a smaller ZSF deposit fraction would be more secure.

I see what you mean, but the second sentence is ambiguous. I think it is intended to mean: "This dilutes the negative impact on security of a smaller ZSF deposit fraction." (I.e. a smaller ZSF deposit fraction is still less secure than a larger one wrt rollback incentives, just not by as much.)

[daira]

Is "dApp" sufficiently well known to not require a definition or expansion?

[tomekpiotrowski]

I've expanded it to 'decentralized applications'.

[str4d]

Assigned ZIP 235.