Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

last_received_timestamp is not a good enough indicator #778

Open
bertllll opened this issue Mar 19, 2024 · 0 comments
Open

last_received_timestamp is not a good enough indicator #778

bertllll opened this issue Mar 19, 2024 · 0 comments

Comments

@bertllll
Copy link

bertllll commented Mar 19, 2024

I'm speculating, no data or feedback backs this up.

I realized that the current logic to evaluate receivables for the possibility of an delinquent attitude of the debtor is particularly benevolent towards Nodes that act actively but with not so much focus on how much they pay in a single transaction. I'll explain better:

If a Node owes money in some kind of excessive manner and we've had to impose a ban, it can take a transaction of any size that will have an effect on this ban to be lifted, at least for some small amount of time. Why? Because when our Node detects the transaction and process it through the database it also adjusts the last_received_timestamp column to the time when the scan is being processed.
However, it is one of the parameter to check delinquency and the adjusted timestamp translates newly as "considerably young debt" which in turn means our Node will ignore this account despite the size of the debt still may remain critical and much above the requested limits. Its age makes an excuse. This is wrong and may attract hustlers to think how they could exploit this to their benefit.

An extreme situation, that might not ever be reliably applicable in the field, involves a malefactor that would try to send almost valueless payments to the creditors in such a frequency that the debt on his account could keep on constantly growing while the refreshing payments would make it always look like a very young debt that would stay away from the radar. Here I'm referring to the period of time made up by joining the maturity_threshold_sec (time until a payable is ignored from the perspective of the payer) and payment_grace_period_sec (how much extra time to the previous limit we give the debtor before we use a ban on them). This in total may be quite a long time.
This strategy would work well but is rather of luck in reality because it depends heavily on the setup of the scan cycles on the creditor's side. The idea of frequent payments is canceled out if the intervals of the receivable scans are comparably long. Stepping into the world of sci-fi, the debtor could figure out what the intervals are from observing how long it took until his ban was taken off to use this information for making a decision if the strategy can pay off.

Possible solution:
We probably shouldn't mark the last payment completely regardless but we should also check how effective the payment was. The parameter would become more of "the last timestamp when a payment left an insignificant amount of still owed money". Practically it can be implemented as anytime when the debt comes below one of the payment thresholds parameters, called permanent_debt_allowed.

@kauri-hero kauri-hero moved this to Ready for Development in MASQ Node v2 May 19, 2024
@github-project-automation github-project-automation bot moved this to Ready for Development in MASQNode Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔖 Ready
Status: Ready for Development
Development

No branches or pull requests

1 participant