EPoSe Movement #1 - EPoW : Proposing Changes in Block Reward Algorithm

[Xecute0101]

This is the first proposal to change our reward system for Qwertycoin Network.

Purpose: Qwertycoin aims to incentivize/disincentivize the network through a systematic approach by adjusting equations related to block reward calculations.

Current Status:

1. Basic Block Reward Emission Equation (Abbreviated):
   ((Total Supply - Previously Emitted Supply) / Emission Factor) - Penalty for Block Size

Proposed Change:

1. Basic Block Reward Emission Equation (Abbreviated):
   (((Total Supply - Previously Emitted Supply) / Emission Factor) - Penalty for Block Size) * ((Timestamp of New Block - Timestamp of Previous Block) / Block Target)

Premises:

1. The block reward is designed to decrease per each block based on the previous emission.
2. Since Basic Block Reward Emission is controlled and reduced to a fraction of normal block reward from such attacks, the overall block reward reduction will not be affected by this change.

Implications of This Change:

1. By reinforcing the consistency of block reward emission over time (instead of block rewards by its sequence in the blockchain), the network hash rate is expected to be supported continuously and find an equilibrium automatically.
2. Even if an attacker creates a high difficulty for the next block and exit, existing miners are incentivized to receive a huge block reward when they find the next block.
3. Prevention of attacks with intermittent hash rate jumps must be dealt in a separate issue.

[Xecute0101]

There shall be lower and upper bounds for this timestamp factor. Considering 2 for upper bound and 0 for lower bound.

[Xecute0101]

The difficulty algorithm will be modified that it will help to keep the block time as consistent as possible.

[aivve]

You may find something usable here concerning punishing miners for deviation from T seredat/karbowanec@231db52#commitcomment-23983192

[Xecute0101]

I am leaning towards fixing difficulty algo for the efficiency of blockchain instead of controlling the number of blocks:

1. If there are many pending txs, for an example, under a massive tx attack or we have txs from a lot of users that goes over the maximum size of a transaction set in the config file, diff algo should lowered difficulty to allow those to be included in the blocks and help reduce network backlog and mempool loads. Together with the reward penalty, malicious miners will be penalized for the size of the block, short duration of timestamp between blocks for zero gain.

[aivve]

Joining and synchronizing node can't verify that at the time some block was mined mempool was overcrowded. You can only estimate by taking into account transactions from previous blocks. If transaction count is above median you can lower the difficulty, this way it will be verifiable by the algorithm.

[Xecute0101]

Joining and synchronizing node can't verify that at the time some block was mined mempool was overcrowded. You can only estimate by taking into account transactions from previous blocks. If transaction count is above median you can lower the difficulty, this way it will be verifiable by the algorithm.

So for this, an index of mempool status at the time of the most recent block can be included in the block header blob like an index figure. Is this what you mean?

[aivve]

Yes, but this is an overhead impossible to agree upon and verify, whereas you already have required data that allow you to estimate the demand for transactions - their count in previous blocks. Create a median of transaction count and use it to adjust difficulty to speedup blocks so you can include transactions faster. But this duplicates the job done by variable block size - if there is demand for transactions block size will grow to accommodate. There's no need to speed up block time.

From the other hand thus you will have two mechanisms to cope with the upsurge of transactions in the case of rapid adoption or usage.

[Xecute0101]

This difficulty adjustment will only activate when total pending tx size is beyond max block size. Now when it is below 1mb(current limit).

Even in case when attackers are posting tons of txs to fill up the mempool and lower difficulty for more block rewards, the proposed changes in block rewards will prevent them from any gains. They will just spend a lot of coins.

Yet this difficulty adjustment will improve the efficiency in handling large amount of traffic. To protect nodes from excessive memory use, using database structure such as RocksDB or LMDB for txs in mempool will definitely improve the overall stability.

[nnian]

Is Basic Block Reward Emission Equation (Abbreviated): (((Total Supply - Previously Emitted Supply) / Emission Factor) - Penalty for Block Size) * ((Timestamp of New Block - Timestamp of Previous Block) / Block Target)
the desired new formula for calculating the next block reward? Or do we have to change the formula again?

[Xecute0101]

we just need to multiply ((timestamp of new block - timestamp of previous block)/blocktarget) to existing reward formula.

[Xecute0101]

I propose to create a variable, called Consistency = ((Timestamp of New Block - Timestamp of Previous Block) / Block Target) and set the minimum and maximum range for this variable between 0 and 2.

[Xecute0101]

@speqtr will work on the implementation.