Peacetime traffic: inject failed payment attempts - #131
Open
GeorgeTsagk wants to merge 2 commits into
Open
Conversation
Generated peacetime traffic was all-settle, which is unrealistic — real nodes see many failed attempts per success. Add `--payment-attempts` (mean attempts per success, default 4.0) so the builder injects failed retries alongside each successful forward. Each real, routed forward is still recorded as settled; on top of it a geometric number of failed copies is synthesised on the same channel pair (retry-until-success with per-attempt success probability 1/payment_attempts), giving a mean of payment_attempts with natural retry spread. The failed attempts are staggered backward in time so they read as a time-ordered retry sequence ending in the success, rather than simultaneous duplicates. At the default this yields ~75% failed forwards (3 failed tries per success) while leaving settle volume completely untouched — failures are added, never substituted, so this is independent of the activity multiplier (which otherwise saturates and cannot preserve settles). Failed forwards carry `settled=false` on BootstrapForward (serde default true, so older traffic files still parse) and replay as failed during bootstrapping, contributing no fee to reputation.
…ll reputation Synthesising failed retries inflates the traffic file ~payment_attempts x. To avoid materialising a full-length (eg 6 month) file on disk, allow generating a short dense window and looping it at import. - forward-builder `--duration` now parses `Xd` as days and `Xm` as months (via parse_window), falling back to humantime for long forms like `6months`, so a short window is easy to express (eg `--duration 7d`). - reputation-builder gains `--allow-boost`: when set it reads the full short file and tiles it (boost_history) to cover the reputation window, shifting each repetition forward by the source span so timestamps stay strictly monotonic across seams (the decaying average rejects out-of-order updates). Off by default; a full-length file is used as-is. The loop happens in memory at import, so no duplicated data is written.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds the option to include logged failure attempts alongside the existing peacetime settle traffic. In reality, no attempt succeeds immediately, it is expected to see payment retries even when all the actors in the system are honest senders.
By injecting failed events in the peacetime traffic we're directly increasing the size of the traffic file. To mitigate that when running local experiments, we added two things:
--allow-boostflag to thereputation-builder: when used, it will tile the smaller traffic window to fill the full 6-month oneWhen experimenting with payment retries it is faster to generate a window of 7 days and tile it to fill 6 months, instead of generating the full 6 month window. Tiling matches full 6-month generation on aggregate reputation but, by repeating rather than resampling a short window, gives lower-fidelity history for low-activity channels.
Rationale
Any fast jamming mitigation will have to absorb honest fast failures too. By including them in our peacetime data we're creating a more realistic baseline before running our attack scenarios.