Add aboveMinDepth() check in WalkValidatorImpl.java to disincentivise blowballs around most recent milestones
Motivation
Currently nodes (for example the one spamming 'TYPPI') have an incentive to use lowest depth when selecting tips. It improves their own confirmation rate but, particularly while they are still using IRI 1.4.2.4, hurts the overall network rate. In order to reward spammers for using higher depth, i am proposing the inclusion of an aboveMinDepth() function that checks to make sure at least one of the two tips a tx confirms indirectly references a milestone older than milestone.latestSolidSubtangleMilestoneIndex - minDepth. If both tips confirm only recent milestones it should be ignored and the random walk should continue on a different path
Requirements
Addition of function aboveMinDepth() in WalkValidatorImpl.java.
Open Questions
Is there any incentive to not choose a minimum depth in the current implementation?
Description
Add
aboveMinDepth()
check inWalkValidatorImpl.java
to disincentivise blowballs around most recent milestonesMotivation
Currently nodes (for example the one spamming 'TYPPI') have an incentive to use lowest depth when selecting tips. It improves their own confirmation rate but, particularly while they are still using IRI 1.4.2.4, hurts the overall network rate. In order to reward spammers for using higher depth, i am proposing the inclusion of an
aboveMinDepth()
function that checks to make sure at least one of the two tips a tx confirms indirectly references a milestone older thanmilestone.latestSolidSubtangleMilestoneIndex - minDepth
. If both tips confirm only recent milestones it should be ignored and the random walk should continue on a different pathRequirements
Addition of function
aboveMinDepth()
inWalkValidatorImpl.java
.Open Questions
Is there any incentive to not choose a minimum depth in the current implementation?
Am I planning to do it myself with a PR?
No, not sure best way to implement if ok change