Topic: [In Development] Random Reward Coin with UNPREDICTABLE Rewards (Read 551 times)
I believe it is a good idea and think it should be implemented in a 'random reward' coin. That said, I don't think this will be enough to make a coin 'stand out' on its own.
February 24, 2014, 04:39:39 PM
Looking for a bit of feedback on this idea - I am interested to see how the community thinks this will work.
Right now, all the "random" block reward coins (Doge, Lotto, Moon, Leaf, Lucky, etc etc) use a pseudo-random generator with a known seed in the GetBlockValue function (see main.cpp in any altcoin) to determine the block reward. This means that the block reward, by design, is predictable before the block is discovered. This has, of course, led to many multi-pools such as WafflePool and MiddleCoin mining only the valuable blocks (which leaves the dedicated miners with on average less then the average block reward in profits).
The protocol change I propose:
- The first tx in each block remains for the miner of that block, but rewards a tiny amount, say 1 coin
- A second standard tx is added to each block (after the genesis block) that pays a pseudo-random reward (say, similar to Doge's payout scheme) to the first txout of the previous block.
By delaying the miner reward by 1 block, this allows the reward to be unpredictable until the block is actually discovered - so you don't know how much you will get paid for a block until you have already mined it.
What do you think the ramifications of this would be? Did multi-pools contribute to Doge's success, or do they detract from it? Are unpredictable block rewards actually desirable?
--
I am also experimenting with varied difficulty based on nTime gap - aka, the difficulty decreases the longer it has been since the last block. I consider this an interesting proposition, and a way to actually make use of multi-pools and coin hoppers in a much more beneficial way (they hop on when a block hasn't been discovered until after the block target time), therefore significantly decreasing time variance between block discoveries (and therefore transaction confirmations). This is more complicated however, as significant variance is currently acceptable for nTime, and so time syncing would need to be built into the network propagation, and nTime variance significantly decreased.
Right now, all the "random" block reward coins (Doge, Lotto, Moon, Leaf, Lucky, etc etc) use a pseudo-random generator with a known seed in the GetBlockValue function (see main.cpp in any altcoin) to determine the block reward. This means that the block reward, by design, is predictable before the block is discovered. This has, of course, led to many multi-pools such as WafflePool and MiddleCoin mining only the valuable blocks (which leaves the dedicated miners with on average less then the average block reward in profits).
The protocol change I propose:
- The first tx in each block remains for the miner of that block, but rewards a tiny amount, say 1 coin
- A second standard tx is added to each block (after the genesis block) that pays a pseudo-random reward (say, similar to Doge's payout scheme) to the first txout of the previous block.
By delaying the miner reward by 1 block, this allows the reward to be unpredictable until the block is actually discovered - so you don't know how much you will get paid for a block until you have already mined it.
What do you think the ramifications of this would be? Did multi-pools contribute to Doge's success, or do they detract from it? Are unpredictable block rewards actually desirable?
--
I am also experimenting with varied difficulty based on nTime gap - aka, the difficulty decreases the longer it has been since the last block. I consider this an interesting proposition, and a way to actually make use of multi-pools and coin hoppers in a much more beneficial way (they hop on when a block hasn't been discovered until after the block target time), therefore significantly decreasing time variance between block discoveries (and therefore transaction confirmations). This is more complicated however, as significant variance is currently acceptable for nTime, and so time syncing would need to be built into the network propagation, and nTime variance significantly decreased.
Welll.......... derpppp
at least you got one reply! Still asking around though. February 24, 2014, 01:53:26 PM
Looking for a bit of feedback on this idea - I am interested to see how the community thinks this will work.
Right now, all the "random" block reward coins (Doge, Lotto, Moon, Leaf, Lucky, etc etc) use a pseudo-random generator with a known seed in the GetBlockValue function (see main.cpp in any altcoin) to determine the block reward. This means that the block reward, by design, is predictable before the block is discovered. This has, of course, led to many multi-pools such as WafflePool and MiddleCoin mining only the valuable blocks (which leaves the dedicated miners with on average less then the average block reward in profits).
The protocol change I propose:
- The first tx in each block remains for the miner of that block, but rewards a tiny amount, say 1 coin
- A second standard tx is added to each block (after the genesis block) that pays a pseudo-random reward (say, similar to Doge's payout scheme) to the first txout of the previous block.
By delaying the miner reward by 1 block, this allows the reward to be unpredictable until the block is actually discovered - so you don't know how much you will get paid for a block until you have already mined it.
What do you think the ramifications of this would be? Did multi-pools contribute to Doge's success, or do they detract from it? Are unpredictable block rewards actually desirable?
--
I am also experimenting with varied difficulty based on nTime gap - aka, the difficulty decreases the longer it has been since the last block. I consider this an interesting proposition, and a way to actually make use of multi-pools and coin hoppers in a much more beneficial way (they hop on when a block hasn't been discovered until after the block target time), therefore significantly decreasing time variance between block discoveries (and therefore transaction confirmations). This is more complicated however, as significant variance is currently acceptable for nTime, and so time syncing would need to be built into the network propagation, and nTime variance significantly decreased.
Right now, all the "random" block reward coins (Doge, Lotto, Moon, Leaf, Lucky, etc etc) use a pseudo-random generator with a known seed in the GetBlockValue function (see main.cpp in any altcoin) to determine the block reward. This means that the block reward, by design, is predictable before the block is discovered. This has, of course, led to many multi-pools such as WafflePool and MiddleCoin mining only the valuable blocks (which leaves the dedicated miners with on average less then the average block reward in profits).
The protocol change I propose:
- The first tx in each block remains for the miner of that block, but rewards a tiny amount, say 1 coin
- A second standard tx is added to each block (after the genesis block) that pays a pseudo-random reward (say, similar to Doge's payout scheme) to the first txout of the previous block.
By delaying the miner reward by 1 block, this allows the reward to be unpredictable until the block is actually discovered - so you don't know how much you will get paid for a block until you have already mined it.
What do you think the ramifications of this would be? Did multi-pools contribute to Doge's success, or do they detract from it? Are unpredictable block rewards actually desirable?
--
I am also experimenting with varied difficulty based on nTime gap - aka, the difficulty decreases the longer it has been since the last block. I consider this an interesting proposition, and a way to actually make use of multi-pools and coin hoppers in a much more beneficial way (they hop on when a block hasn't been discovered until after the block target time), therefore significantly decreasing time variance between block discoveries (and therefore transaction confirmations). This is more complicated however, as significant variance is currently acceptable for nTime, and so time syncing would need to be built into the network propagation, and nTime variance significantly decreased.
Jump to: