Change max block decrement amount to 50 #56
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#56
Loading…
Reference in a new issue
No description provided.
Delete branch "change_block_decrements"
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?
Increase the maximum amount that a rpc call is allowed to decrement blocks from 20 to 50. This affects how far RPC command getprooforname, used by lbryum, can go back in blocks.
Calling getproofforname and going back 50 blocks takes about 0.009 seconds (going back 20 blocks takes about 0.007) which should not be too much of a load increase.
This should decrease cases where we get the error "Block too deep to generate proof" from lbryum when calling its getvalueforname command.
dumb question - what have a limit at all?
Going back too many blocks will take too long. You don't want lbryum instances requesting the value for block index 1, causing lbrycrd to roll back thousands of blocks and holding up all other requests.
Ideally, we should store proofs for past blocks on lbryum server , instead of getting it from lbrycrd.