This is another idea in a series that may be useful for salvaging POW's lack of security in small coins.
King Solomon could identify stakeholders in 51% attacks. Are there other ideas like this? For example, can we create an environment to encourage a parasite to make the host strong enough to defend itself against wolves? Is there a way to identify "self" (dedicated miners) from non-self in order to build a better immune system?
Your dedicated miners may be identified as being the ones who are still mining when the difficulty is high. Ostensibly, they will not attack the coin and you want them to win chain races where there is a 51% attacker trying to get all the blocks. You could credit their output address with 1/2 of the excess hashes they had to pay to solve difficulties that are more than 1 standard deviation above the days average (16% of the blocks). ( There should be a linear increase in credit from 0 to 1/2 as difficulty goes from avg up to the 16% in order to prevent a target point. ) The protocol automatically "spends" those hashes for them in the future if and only if there is a chain race between tips that is above some minimum like 6 blocks. The hash-credit they have stored would reduce the difficulty they have to solve verses the "on-chain" difficulty. The block gets chain work credit equal to the on-chain difficulty. The solvetime is faster due to the hash-credit being redeemed but the difficulty sent to the difficulty algorithm is still high, so subsequent blocks will have an over-estimate of difficulty, causing slower blocks, so the correct average emission rate is maintained. The hash-credit would not be exchangeable for coin, spendable to another address, and would expire slowly over the course of maybe a year. Each miner would need to use only 1 output address so that all their credit is available to all his equipment in a race. Miners pooling their credit and hashpower into a single address does not provide an extra benefit as I originally thought.
If 10% of your miners are always on, and they are the only ones mining in the upper 16% of difficulty, and if your average difficulty swings into the middle of that 16% are 20% above average, then that 10% of miners are getting 16%* 20% / 2 = 1.6% of the day's chain work back as credit. In 100 days they will have 160% of a day's chain work to fight 51% attacks.
I have said "hash-credit" for clarity. Given that price and/or reward/block may change, it appears to need to be a percent of current difficulty. For example if the difficulty is 20% too high, then the future credit is 10% of the block difficulty now and 10% of any difficulties in the future, minus the loss in value due the expiration rate. This is an interesting requirement because "percent of difficulty" is neither chain work or reward. "Interesting" could mean there's something rotten in Denmark but this seems to be the correct method.
How much credit to released during a race seems to be a difficult problem. It might be useful if a close battle between credit owners did not deplete either side. I'll edit this section later if I can think of something that can work.
Not fully reimbursing the miner for the excess difficulty is important because we do not want to fully reimburse an undedicated miner to use it to do the attacks we are trying to prevent. I have chosen to reimburse only the highest 16% of difficulties because non-dedicated miners often mine above the average before leaving. We do not want a really fast difficulty algorithm, but we want it to vary up and down some. We want to encourage a certain amount of on-off mining. The basic premise could be wrong: someone who likes accumulating a coin for a long time may have no qualms about attacking every now and then with simple 51% attacks or double spending, despite it hurting the value of the coin he has been mining a long time.
This has two POS features: the value is on the chain and tied to an identity before the blocks are mined. But I don't see any of the numerous problems and complexity that POS systems have. This is probably because the POW is still generating the randomness and the POS stake is being spent in the vote prevents grinding. The unfinished rules on how to release the credit need to be careful to not accidentally enable grinding.
A few coins have played around with the idea of not letting block winners immediately have their coin back. Those plans do not make any sense, but I'm wondering if that locked-up stake could be used to extend this. I have been unable to think of anything without getting into a full-blown POS.
I want to show this is a deep philosophical and/or a smart political approach. Non-dedicated miners are not being discouraged by an excellent DA. They are being enticed a little with a slightly weak DA to get a little excess profit and cause a little problem in difficulty swings. We are paying non-friends to help us identify friends. It's a honey-pot (credit: deadalnix) but it's not used to trick and identify non-friends but one that pays non-friends to identify friends. It's a very passive response to non-friends: they are not directly addressed in either the on-off mining or in the 51% attacks. The protocol's responsive interaction is with "friends". We actively prevent friends from making as much profit as non-friends and in exchange we pay back some of their loses to address real attacks.
This is another idea in a series that may be useful for salvaging POW's lack of security in small coins.
King Solomon could identify stakeholders in 51% attacks. Are there other ideas like this? For example, can we create an environment to encourage a parasite to make the host strong enough to defend itself against wolves? Is there a way to identify "self" (dedicated miners) from non-self in order to build a better immune system?
Your dedicated miners may be identified as being the ones who are still mining when the difficulty is high. Ostensibly, they will not attack the coin and you want them to win chain races where there is a 51% attacker trying to get all the blocks. You could credit their output address with 1/2 of the excess hashes they had to pay to solve difficulties that are more than 1 standard deviation above the days average (16% of the blocks). ( There should be a linear increase in credit from 0 to 1/2 as difficulty goes from avg up to the 16% in order to prevent a target point. ) The protocol automatically "spends" those hashes for them in the future if and only if there is a chain race between tips that is above some minimum like 6 blocks. The hash-credit they have stored would reduce the difficulty they have to solve verses the "on-chain" difficulty. The block gets chain work credit equal to the on-chain difficulty. The solvetime is faster due to the hash-credit being redeemed but the difficulty sent to the difficulty algorithm is still high, so subsequent blocks will have an over-estimate of difficulty, causing slower blocks, so the correct average emission rate is maintained. The hash-credit would not be exchangeable for coin, spendable to another address, and would expire slowly over the course of maybe a year. Each miner would need to use only 1 output address so that all their credit is available to all his equipment in a race. Miners pooling their credit and hashpower into a single address does not provide an extra benefit as I originally thought.
If 10% of your miners are always on, and they are the only ones mining in the upper 16% of difficulty, and if your average difficulty swings into the middle of that 16% are 20% above average, then that 10% of miners are getting 16%* 20% / 2 = 1.6% of the day's chain work back as credit. In 100 days they will have 160% of a day's chain work to fight 51% attacks.
I have said "hash-credit" for clarity. Given that price and/or reward/block may change, it appears to need to be a percent of current difficulty. For example if the difficulty is 20% too high, then the future credit is 10% of the block difficulty now and 10% of any difficulties in the future, minus the loss in value due the expiration rate. This is an interesting requirement because "percent of difficulty" is neither chain work or reward. "Interesting" could mean there's something rotten in Denmark but this seems to be the correct method.
How much credit to released during a race seems to be a difficult problem. It might be useful if a close battle between credit owners did not deplete either side. I'll edit this section later if I can think of something that can work.
Not fully reimbursing the miner for the excess difficulty is important because we do not want to fully reimburse an undedicated miner to use it to do the attacks we are trying to prevent. I have chosen to reimburse only the highest 16% of difficulties because non-dedicated miners often mine above the average before leaving. We do not want a really fast difficulty algorithm, but we want it to vary up and down some. We want to encourage a certain amount of on-off mining. The basic premise could be wrong: someone who likes accumulating a coin for a long time may have no qualms about attacking every now and then with simple 51% attacks or double spending, despite it hurting the value of the coin he has been mining a long time.
This has two POS features: the value is on the chain and tied to an identity before the blocks are mined. But I don't see any of the numerous problems and complexity that POS systems have. This is probably because the POW is still generating the randomness and the POS stake is being spent in the vote prevents grinding. The unfinished rules on how to release the credit need to be careful to not accidentally enable grinding.
A few coins have played around with the idea of not letting block winners immediately have their coin back. Those plans do not make any sense, but I'm wondering if that locked-up stake could be used to extend this. I have been unable to think of anything without getting into a full-blown POS.
I want to show this is a deep philosophical and/or a smart political approach. Non-dedicated miners are not being discouraged by an excellent DA. They are being enticed a little with a slightly weak DA to get a little excess profit and cause a little problem in difficulty swings. We are paying non-friends to help us identify friends. It's a honey-pot (credit: deadalnix) but it's not used to trick and identify non-friends but one that pays non-friends to identify friends. It's a very passive response to non-friends: they are not directly addressed in either the on-off mining or in the 51% attacks. The protocol's responsive interaction is with "friends". We actively prevent friends from making as much profit as non-friends and in exchange we pay back some of their loses to address real attacks.