So as most PoW algorithms go block rewards start out at a fixed number with some form of halving or reduction and assigned intervals. This method creates a large volume of coins generated in a small volume of the coins life (usually in the beginning). This centralizes the amount of distributed greatly to the ones who mine in the early days. What this algo is good at doing is creating deflation by lowering the amount of coins released as time goes on until no more are released. Solution? PoWR A PoW Random reward algorithm that randomizes the number of coins awarded per block, and instead of halving at set intervals, the maximum random number is reduced. Ex. Year 1: Every block has a chance of awarding 0 to 50 decred. Year 2: Every block has a chance of awarding 0 to 49 decreed. Year 3: Every block has a chance of awarding 0 to 48 decreed. Year 50: Every block has a chance of awarding 0 to 0 decree. This would still induce deflation with the laws of averages stating that distribution would go from 25 down to 0 decree from blocks from beginning to end. It would help combat the guarantee of large rewards in the beginning and small rewards in the end but would still allow for the possibility of larger block rewards later in the lifecycle of PoW. Also it wouldn't have to follow a yearly reduction, it could be on constant a downward curve per block. Just my rambling 2c, if you think this idea does or does not have merit discuss below =)
I think deflation is generally a good thing in terms of crypto currencies. The problem I see with bitcoin is that the people who mined in the first few years hold a vast majority of all the bitcoins that will ever be produced, thus centralizing the economic power of bitcoin. In the above example someone mining in year 25 of the 50 year PoWR cycle would still have a chance of receiving 0 to 25 coins (25 coins being the theoretical average of rewarded coins in year 1).
I don't think there is any secure way of doing this. For the lottery system PRNG, block header bytes are used to seed it as these are difficult to game. If you make the subsidy based on this, you will just get miners generating and not publishing blocks until there is some large reward for them. This also allows much easier gaming of the stake lottery. For the lottery system to work, you need consistent, known reward amounts. If you used older blocks to seed the PRNG, you hit another issue. Miners will know in advance which blocks have subsidy and which don't and will only expend power on blocks that do. This will cause wild variation in block time, which will destabilize the entire system.
I totally agree with you. also I have to complete that not all the first miners hold a majority of bitcoins. I thing everything started with popularity of bitcoin when real money holders could buy a large amount of bitcoin. The economic power of bitcoin is centralized since it's boom in november- december 2014. Also these days I am surprised to see DDOS attack on btc exchanges when the price starts to go up exactly when large amounts of money (fiat) are deposited into their balance ... you can't trade... but the exchanger can
Alot of that was way over my head so sorry if I sound ignorant. Can you force miners to publish all generated blocks to prevent them from not publishing until there is a large reward. As for the 2nd part. They could still know in advance if it was random?
There isn't a way to force miners to display all the blocks they've generated. You could incentivize them to publish blocks by giving them more reward, but that would break the entire scheme. There are two real ways you could seed the pseudorandom number generator. You could do so with some random constants concatenated with the block height and hash iteratively. This would give you a random number for the block reward, but the block reward would be known prior to each block being created. You could also hash the header of the previous block, but this becomes gameable if you have a higher hash rate. One thing you could to is make the coinbase reward for ThisBlock be something like Code: 0x7FFFFFFFFFFFFFF & int64(H(ThisBlockHeader || Constant)[0:8]) In this way, the user will never know how many coins they generated until after they find their golden nonce. That mask always gives a positive number, and you could reduce the magnitude over time to give you less subsidy. For example, when height % 100000 == 0 { subsidy >>= 2 }. I'm not sure this will actually give you a more even distribution of funds. It is still true that the higher hash rate you have, the higher likelihood you'll have of getting the most coins amortized over time.
I'm going to read that about 8 more times =) In the mean time I appreciate the discussion! I agree with you that the higher hash rate you have the higher likelihood you'll have at getting most of the coins amortized over time. Would using the mask allow for the possibility of Ex. in the original post? If so the higest hash rate miner would still be getting the most coins at year 25 but it would allow for the possibility of any miner to attain a block reward that is as high as the average block reward in year 1. It makes the first years of of mining not as rewarding (but still very rewarding).
The mask just ensures the number generated is positive, because Bitcoin and derivatives store amounts as int64s. The bit shifts (>>) halve the subsidy also like Bitcoin. I thought about it more over the weekend and I don't think it can work in any fashion. Even if the amounts are only known after you mine the block, if the miner gets a low value block they are incentivized not publish it. The reason is because the less blocks they publish, the lower the network hash rate goes down and the easier it is for them to generate more blocks in secret. The reason they would do this is to try to find a block with a higher reward and publish that. I think it would default to a less secure form of PoW.
Fair enough. I'm glad we got some technical discussion on it and maybe provoked more thought into improving the ecosystem.
Considering that probability will result in generation of the mean on average, all this would do is create some unfairness in the system based on luck. Seems more reasonable to simply slow down at a more gradual rate.
Be very careful with randomly generated block rewards. I think DOGE used to use it long ago. More recently, CLAM used it and there were smart people on that but there was vulnerabilities with that. Also random block rewards doesn't really decentralize mining.
Also I don't think you guys discussed the third way of doing random rewards. You could make the reward based on a future block hash. But unfortunately this method still has the same problem. A miner can control the hash of that future block instead to get a bigger block reward.