How to solve the 'first block after' problem
-
'The first block after’ a large drop in hash rate occurs will take a long time to be mined, as the difficulty for this block is announced by the last block mined with high hash rate.
When it is mined it will announce a reduced hash rate and difficulty for the next block ,so that the block chain returns to one block per minute over time.
While we can influence the speed of the difficulty decrease by adjusting the rules for the difficulty calculation, we never can influence the waiting time for the first block with the mechanisms currently imlemented.We need to think about ways to reduce the waiting time for this ‘first block after’ and I’m asking for ideas how to archive that.
-
My Idea:
we could implement a rule triggered by a kind of watchdog timer:
If now() - timestamp(last block mined) > xxx minutes
then Difficulty = diffculty / 2This would be done on all active nodes, so a block mined with the reduced difficulty would be accepted.
The time difference for the halving of the difficulty must be greater than the window where we accept older blocks due to clock differences of nodes. -
@Wellenreiter thanks for starting this thread, it’s an important discussion.
the trigger rule sounds interesting.
Question: Say the xxx minutes = 3. Am I right in understanding that every 3 mins if a block is not found the difficulty will half.
Say the diff is 100. After 3 mins the diff would be 50, if no block is found…after another 3 mins the diff will be 25…if no block is found the diff will be 12.5…and so on ?
Is that correct ?
-
yes, that is the idea behind it.
I hope, that the trigger will click in once only, as hopefully a block will be found, which itself will set a lower diff
We also may add a counter, so the trigger can click in a given number of times only, e.g the max halving count is 2 or 3
we need to allow a high variance in time to block, as the ‘luck factor’ seems to be high with neoscrypt.
as soon as possible the normal diff calculation should be used again -
The interest in this topic seems to be low :(
Another idea, but more a medium to long term solution:
Change the POW algorithm to a POW/POS algorithm, with 60% POW/30% POS blocks as a start. That may change over time.
If the POS generated blocks also announce new POW difficulties, we can reduce the wait time for the ‘first block after’
Additional advantage:
We move away from the CPU/GPU/power intensive POW algorithm and reduce the carbon footprint of Feathercoin.
Does anybody know the khash/watt or watt/khash ratio for modern GPUs?
-
Moved topic to category ‘Feathercoin discussion’
This topic is accessible to all registered users now
-
I dont know how the network negotiates who gets the win if there are two submissions that clear the difficulty. I would expect the first submitted to win, but if we give people the entire minute no matter what then i would expect the best to win.
If it truly is a case of the best wins. you pick a difficulty that allows multiple submissions and again, the best wins. I’m not quite sure how you handle the flood of submissions, but really that’s a network distribution problem.
In a perfect world you accept anything and best wins.
Now if it really is a case of first wins. then the difficulty really should be a sliding mechanism. there should be no wait the full minute, its a case of the rate of difficulty declination. and it could change every block based on the time to solve the previous (though you probably want something more stable then that)
you still have to negotiate who had the best though as when it drops to a certain difficulty multiple solutions (that were being held as the miners best) would come across. Also due to lag, someone might submit a best solution 10 seconds before everyone sees it. that one should still win.
presumably there are already solutions for these problems and just implementing a sliding difficulty is really the way to go. probably something that decays linearly since the difficulty is already an exponential thing.
-
As long as blocks are mined sequential there is no problem.
Due to the fact, that the distribution of the fact that a new block is found takes some time (less than a second typically), there are situations, that two or more blocks are mined and valid successors of the last valid block.
In that case the one having the longest chain of successors wins.
If that is equal the chain containing the most work wins.But the problem we talk about is not related to that mechanism.
The problem is, that the difficulty for the next block is calculated by the node mining that block and distributed as part of the block header. This means, when the hash rate drops dramatically, it takes a long time, until a new (=lower) difficulty is distributed through the network and it takes a long time to mine the next block.
What we are discussing here is a way to reduce the difficulty before the next block is mined, if a block was not found for a given amount of time.
-
i was basically agreeing with you just debating the semantics (like continuous difficulty degrading vs starting it after so long and doing it by steps. its really 6 of one half dozen of the other in the end) . I’m all for it either way.
It is worth saying though, it would be really nice if everyone could just submit their best result and best result wins. then no matter what you have 1 minute blocks. but i suspect the extra network traffic/resolution of the best is a problem with that sort of solution . The traffic from people submitting crap solutions and the resolution of all that seems problematic.
-
@j_scheibel said in How to solve the 'first block after' problem:
… it would be really nice if everyone could just submit their best result and best result wins…
If everyone just submits the best result, without a limit (= difficulty) there would be no mechanism adjust the block rate to 1 per minute.
Also it would create a consensus problem.I would like to keep the discussion in the difficulty adjustment and not on the way how the blocks are created.
-
Another possible solution:
when no new blocks are seen for a given time frame, the daemons themself generate one special block at the configured lowest difficulty.
Characteristics of the block:
- no coins generated
- no transactions are contained
That way a new difficulty can be calculated /announced after the hash rate drops dramatically and the time to block can be limited without breaking the protocol.
For sure there are complications in this solution, that need to be addressed.
This is a high level idea only
