fixed blocks coming in too fast on testnet #253
No reviewers
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#253
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix_testnet_too_fast"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When we get a delayed block, we thereafter knock the difficulty so low that it takes multiple (up to a 100) blocks to get back up to sufficient difficulty. It doesn't make sense for us to do this as we already adjust difficulty every block.
Move both fork heights to chainparams
I agree it hasn't worked properly, but I think returning the difficulty back to something sane is better than letting testnet potentially get stuck. The entire point of the testnet is to make testing easier/possible, so the extra headache if ever stuck is just an added barrier. Doing nothing arguably allows easy testing (and mining) to continue as well.
What's the point here? I'd actually think that all of this could probably be removed since we re-target every block and our full period is constant.
They only apply to testnet (because that's the only one with fPowAllowMinDifficultyBlocks enabled). Still think it's worth it?
It's allowed to move by an eighth (12.5%) every block. You can travel a long way in half an hour -- something most people could tolerate. Something sane might be the median of the past 50 blocks; it could get complicated.
Judging form the numbers I was seeing, though, there are miners going in and out of this often. I don't know why that is. I know that our testnet servers are on shared machines; maybe their resources fluctuate significantly. Or maybe the addition of a third person is sporadic but not uncommon.
Yes, it's only effective the very first time its hit (on the block right after genesis). We could special-case that block, but that would be making an assumption that DifficultyAdjustmentInterval returns 1. It does return 1 with our current settings, but if we're going to go down that road we might want to eliminate the parameters. And after working on this, I think that adjusting difficulty every block is unwise. It's too noisy, too prone to simple CPU fluctuations.
Yes, all forks should be documented/handled there. The params in the other networks could be anything (i.e. 0 or 1 or whatever) since it should never apply.
Unwise or not, that's how the network operates. I don't think it's any wiser to fork for a modification here, especially since mainnet has been running more or less sanely (i.e. nothing is broken at the moment). And it's even less sane to do different retarget periods for testnet than for mainnet.
Yes, the cap on the block height should make testnet and mainnet the same again. And I agree that a fork to make us not readjust difficulty every block is likely not worth it.
Fixed.
I left my
mincall in as I think it's much more clear than what was there before, but feel free to revisit this in the upstream merge.I'm OK with changes, let's @lbrynaut makes final review.