lbcd rejects other lbcd peers's getdata
network message. #36
Labels
No labels
ci
claimtrie
consider soon
Epic
good first issue
hacktoberfest
help wanted
mempool
mining
peer
priority: blocker
priority: high
priority: low
priority: medium
rpc
runtime
test
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
ux
wallet
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbcd#36
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
This can be reproduced by having a lbcd connected to only another lbcd instance.
lbcd --datadir=~/tmp/lbcd-test/datadir --logdir=~/tmp/lbcd-test/logdir --nolisten --norpc --connect 127.0.0.1:9246
The catching up (sync from scratch) node soon lost the peer and stuck since we indicate it to connect only one lbcd node.
The other lbcd instance complains and ban the catching up node.
Currently, the
OnGetData()
handler penalizes peers requesting large number of blocks.https://github.com/lbryio/lbcd/blob/master/server.go#L652:L652
For peers, especially those sync from scratch, trying to catch up to checkpoints, they would request as many as the
wire.MaxInvPerMsg
allows, and get themselves banned quickly.The options here are either relaxing the checking heuristics/logics on the handler side, or reduce the block on the requesting side.