What does 8Bitcoder say to the solution from iamphoenix? He's the developer of this coin....
Actually this is idea of SlientBit and me.
IDEA:
Would it be possible to implement a time constrained reward system, where the amount of coin generated by the block depends on how much time it took from the the 1st confirmation of the previous block and it's own 1st check?
This way, no matter how many blocks were mined, the reward would be the same on a time basis. Multipools woudn't be a problem, because if they find 10 blocks in one minute they will get the same reward from those 10 blocks as the small pool that only found 1 block in the same amount of time.
In fact, this would probably remove the multipools altogether (coin not profitable when compared to others, never gets selected) or keep them on the coin forever (coin is very stable because price/availability is a function of time spent finding blocks and not hashrates used)
Is this feasible?
I have recently came up with the same idea, but before implementing it worth to think about some moments:
1)In normal mining (without multipools) it is convinient, and statistically legitimately when two or even three blocks are found faster than 2:30, and then difficulty adjusts and block finding requires more time, than 2:30. So, such reward-limit system must start only after 3-4 simultaneously found blocks, in order not to affect regular mining process. And it will make some problems for current alghoritms which calculate profitability (but it is a headache of multi-pool developers
).
2)Ok, let such reward-limit system is ready and limits the reward for fast-generating blocks. So, multipool comes into net, grabs 5-6 blocks and then leaves. The difficulty is high, and regular miners have to wait a lot of time for next few blocks. What's next? We have two options:
a) In case the reward for this blocks is depending on time of their generation and can be higher than 1000 MYR, at some point it may be profitable for multipool to come again and take this blocks. It's is bad, because miners will not receive anything at all. However, in this case, the number of daily generated coins is strictly as in coin specification and inflation is under control.
b) The reward for long-generating blocks doesn't depend on time of their generation and it is strictly 1000 MYR. In this case situation for regular miners will be the same as now (they receive the same small amount of MYR), but multi-pools will receive almost nothing. In this case, the number of daily generated coins will be less then in coin specification.
3)How to calculate the time between blocks correctly (I don't know technical details)? Which time is used, when block is solved? UTC from server or local machine time? Is it possible to make some fraud changing time on local machine or even server if block reward depends on it? We have to think about it
4)As I know, when hash for block is being solved, it includes the hashes of all transactions of this block, but in case of time-dependent reward during solving this transaction will change permanently in time. How it would affect the statistics of coin generation (now we have two variables: nonce and reward-transaction hash)?
5)Multi-pools are the part of cryptocoin world, so if we are "a coin for everyone" we have to find the ways in which multipools will have the same rights as asic-users and regular miners. Or in some time we will see the birth of another coin "for everyone" which solved this problem and our coin will not be the leader.
So, in conclusion I see this idea for reward-limiting system for fast-found blocks is very prospective, but we have a lot to discuss.
UPD. I have a workaround proposal. What if we don't change the total reward for fast-generating blocks (leave it 1000), but part of it will be put on public account to pay bounties? For example if 10 blocks instead of 1 block were generated simultaneously by multi-pool in 2:30 , multi-pool receives totally only 1000 MYR and other 9000 MYR (proportions might be changed) goes to bounty-account ? It will solve a set of our problems.
But anyway we are interested in answer for this question. Now we have only a small answer of foodies123 and we are waiting for answer from
.