Hi all,
Thanks everyone for taking part in this discussion! It's very important that we discuss and work together towards a solution!
Lower price
I agree with ny2cafuse: when the price drops there will still be profitable blocks (the low diff ones) that are going to be mined by the multipools. I also agree with strataghyst: price manipulation is a bad idea in general. Furthermore, the price must go up at one point.. So even if a lower price would fix, it won't be a permanent solution.
I agree it should be left to the market but the theory of lowering diff and higher profit does not make sense here. Normally it would but Clever already mines 80+% of the blocks so whatever diff is in place his gain in NLG would be the same. His profit however would drop with the price.
Different diff readjusment
I agree with thsminer: changing the diff readjustment is not a complete solution. I should've been more verbose in my earlier post. I think we can change the diff readjustment more so it fits better with Guldencoin's specs and performs better. But it won't be a complete solution. The scale and speed of the multipools is simply too large relative to our dedicated miners.
Longer coin maturity
If I was going to set up a multi-pool, I would start by mining 20 blocks; 20.000 NLG. Lets call it a "buffer". I would put those buffer coins in the exchange wallet. Then I would write software that watches the exchange rate and coin difficulty to calculate the profitability. When the coin is profitable, the software directs the miners to start mining x blocks until the diff is so high that it isn't profitable anymore. Say 10 blocks are mined, the software would directly sell 10.000 NLG from the buffer on the exchange. Once the 10 mined blocks have matured, those coins are sent to the buffer (exchange wallet). Then the whole process starts over again.
I don't know for sure if clevermining works this way, but it's trivial to implement. Therefore, increasing the coin maturity duration only requires multi-pools to have a larger buffer so they can bridge the maturity time. At the same time, a long coin maturity is a huge downside for independent and smaller miners.. So I'm a bit divided on this one.. It might help, but only as long as multi-pools haven't worked around it yet.. And it has downsides for small independent miners, the ones that are dedicated to our network.
It's not a final solution and it may support more stable hashrate. Right now the small miners are nowhere so every change for the better is good for the small miners.
Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.
Right now a jumpool gets 80+% of the coins in a couple of minutes. Even if such pool mines in advance and drops the block after the timeout expires and we asume a timeout of 75 seconds he could not mine more than 1 block every 75 seconds and thus his gains lower dramaticaly. He would have to adjust his software to act as you described but always have 10 fold less profitaility as other coins. The premining of blocks can be further prevented by randomising the timeout. If he mines in advance he can drop the block till it's accepted but cannot mine the next because he does not know in advance if he's at the right time, if another miner was lucky to be the first, hashing in advance is useless because the next block would not match.So thats not a problem the real problem can be higher vulnerability to timewarp and a proper calculation has to be done for that
Adjustment between blocks
I've been thinking about changing the diff between blocks. The problem is that a diff based on time is prone to errors and would likely cause chain splits when different miners and nodes are not in sync (clock time). This can be solved by doing a diff change only once every -lets say- 10 minutes. The diff is halved when 10 minutes have past without a block. Because machine times are not always in sync, it needs a graceful period of -lets say- 1 minute before that time. This means nodes can be out of sync for max 1 minute. This actually still a short amount of time, I've seen lots of machines with a wrong time greater than 1 minute. But if you were to take a larger graceful margin, people might try to take advance of that in the form of exploits (halving diff after 9 minutes instead of 10, and hoping for all other nodes to accept it because it's in the grace margin).
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.
brought this up as one of many solutions but is not for the short run and agree not for the initial blocktime problem.
Time based block reward
When the block reward is based on the seconds that have past since the previous block, it will discourage multi pools to mine a lot of blocks at once, as it won't be profitable since the reward will be low.
For example: 150 seconds since last block would reward 1000 NLG and 15 seconds would reward 100 NLG.
As pointed out by ny2cafuse: the downside is that "lucky" blocks will have a smaller reward. On the other side, we could change the max block reward to 2000 NLG (rewarded at a block being 300 seconds after the previous block). This means that in the end exactly 1000 NLG per 150 seconds would be generated, regardless of "lucky" or "bad-luck" blocks or jumping pools. To me it's still unclear if there are exploits with this approach (for instance: invalid block times to receive more coins).
Like I said before NO limits. If there is a very tough block it is a huge incentive to gain thousands of NLG to mine it. Limiting does affect the coin supply. Here again the small miners benefit because they also can have the jackpot when their pool finds a tough block. Okay the luck factor changed from lucky to find a NLG 1000 block in three seconds to finding a NLG 10000 block in 15 minutes, but it's still there. There maybe a drawback however, right now clever stops at high diff but in this case he can wait till the blocktime is over 150+ seconds and wham mines that block fast, waits, leaves the easy low value for the small miners and hits again when the blocktime goes over 150some secs.
I'd love to hear everyones thoughts and feedback.
As mentioned before: Guldencoin is a long term project. It's important that we think about decisions that are being made and achieve good consensus.
Cheers!
Geert-Johan Riemer
Beside all these solutions I still think the problem is the way DGW3 is implemented. It just does not react the way it should and that has nothing to do with being designed for... Because its a counting algo based on the last 24 blocks. One thing that also keeps me busy is the fact that KGW did not work properly either so maybe the solution is at some totally other place in the code. You sometimes see the same strange behaviour when variables are used outside the memory space and overwritten by some other procedure