DEV Community: FF

Buying the dip without catching the knife: a 2-line crypto pullback rule, walk-forward validated across 40 coins

FF — Sun, 25 Oct 2026 14:38:27 +0000

"Buy the dip" is the most repeated advice in crypto — and following it blindly is one of the most reliable ways to lose money. A 6% pullback inside a bull market and a 6% bleed on the way to zero print the same red candle. One is an opportunity; the other is a knife.

We built Trend Dip, a pullback strategy that only buys reclaims inside an uptrend, validated it walk-forward across 40 coins on 4-hour bars, and shipped it as a free preset in our in-browser backtester — no signup, the whole engine is WASM running locally in your browser, so you can re-run every number in this post on any coin in about a second.

The rule (two lines)

ENTRY:CROSS(C,LOWER) && C>TRENDMA    // buy the reclaim of the lower Bollinger band, in an uptrend
EXIT:CROSS(C,MID)                    // sell at the mid band

…where LOWER = MA(C,20) − 2·STD(C,20), MID = MA(C,20), and TRENDMA = MA(C,100). Each piece earns its place:

C > MA100 — the trend filter. This is what separates a dip from a knife. Below the 100-bar average, the same band reclaim is ignored entirely.
CROSS(C, LOWER) — buy the reclaim, not the touch. The entry fires on the bar whose close comes back above the band. The market has already rejected the low once before you spend a cent. This single change moved the OOS win rate by roughly ten points versus buying the first touch.
Exit at the mid band. The thesis is snap-back to the 20-bar mean, so that's where the trade ends. We tried smarter exits — trailing lows, trend-break exits — every one performed worse out of sample.
No stop in the formula. Deliberate: 4h crypto charts routinely flush 5% below the band and revert by the next close, and a stop converts those wicks into realized losses. Adding a 10–20% protective stop changed the results almost imperceptibly (stops almost never fired). The backtester still gives you an optional stop field if you want a hard tail cap.

How we validated it

Four rules, all of which matter:

Not one chart — forty. BTC, ETH, SOL, BNB, XRP, DOGE, AVAX, DOT and 32 more majors with long histories. A rule that only works on a cherry-picked chart is a screenshot, not an edge.
Walk-forward, not full-history. Each coin's ~500 days of 4h bars split 70/30: the first 70% is where parameters would effectively have been chosen; the final 30% is scored blind as one continuous out-of-sample segment. All headline numbers below are OOS only.
Realistic fills. Signals confirm at bar close, fill at the next bar's open — no lookahead — with 0.10% taker fee + 0.05% slippage per side (~0.3% round trip). The same engine and simulator that power the public backtest page ran every test.
Benchmarks. The identical harness scored the nine other strategies on the site on the same data.

The numbers

Out-of-sample metric (40 coins, 4h, 70/30)	Result
Win rate, all held-out trades	73.6% (174 trades)
Win rate, in-sample (for contrast)	62.9% (267 trades)
Coins profitable OOS	26 / 40
Coins beating buy & hold OOS	24 / 40
Coins winning ≥50% of held-out trades	33 / 35 with ≥3 trades
Median per-coin max drawdown	−6.1%
Worst / median / best held-out trade	−16.7% / +1.2% / +34.8%
Average holding time	12 bars ≈ 2 days
Win rate at 2× fees	69.5%
BTC / ETH / SOL win rate	83% / 75% / 100%

Two details deserve a second look. First, the OOS win rate is higher than the in-sample one — overfit strategies show the opposite signature: brilliant in the tuning window, collapsing the moment data is unfamiliar. Second, the edge survives fees at two to three times what a normal spot account pays.

Trying hard to break it

Six consecutive time slices scored separately: win rates 71%, 56%, 62%, 55%, 69%, 75% — every window above 50%. A regime-dependent fluke does not do that.
Parameter plateau. Defaults (20 bars, 2σ, MA100) sit in the middle of a plateau: 1.8σ–2.5σ all won 70–77%, neighbouring trend filters (50–200) all stayed positive. If performance collapses when you nudge a parameter 10%, you found noise.
Split-date sensitivity. Moving the walk-forward cut across 50/30 → 90/10 changed the aggregate win rate only between 55% and 66%.
Exit shoot-outs. Adding a 10-bar-low emergency exit or a trend-break exit lowered the OOS win rate (61.5% and 51.0%). The boring mid-band exit won — stops were selling into the very wicks the strategy profits from reverting.
Benchmarks: the best of the nine existing strategies managed a 51% OOS win rate on the same data.

Where it loses — read this part

73.6% win rate is not a money printer. The median winner is small (+1.2%) because the target — the mid band — is close. The profile is many small wins, occasional runners, occasional give-backs. The worst held-out trade lost 16.7%.
No formula stop means tail exposure exists. Historically the MA100 filter and mid-band exit capped the damage, but a coin that breaks down mid-trade holds until it recovers to the mid band. If that worries you, set the optional stop in the backtester and accept slightly worse expected numbers for a hard floor.
The held-out window is one market regime (~5 months per coin, dips inside an uptrend). In a full bear market the MA100 filter will simply keep the strategy flat for long stretches — designed behavior, not a bonus.
Survivorship bias is real — today's top-40 list excludes the coins that died.

Run it across the whole market

One coin's backtest is an anecdote. The scanner page runs the identical formula across a whole universe in one pass — each coin split walk-forward, ranked by out-of-sample Sharpe:

Under the hood (the dev part)

The whole thing — formula parser, indicator engine, backtest simulator, walk-forward scanner — is a Rust→WASM module evaluated entirely in your browser on real exchange candles. The strategy DSL is a tiny TDX-style language (ENTRY:CROSS(C,LOWER) && C>TRENDMA;), so every rule on the site is user-editable text, and the simulator fills at the next bar's open with configurable fees and slippage. Nothing you type is uploaded anywhere.

Re-run this exact strategy on any pair: backtest page
Scan the whole universe: scanner page
Full write-up with more stress tests: original article (canonical URL of this post — it's the same article, cross-posted)

Disclaimer: everything above is a historical backtest, not a promise. Backtested win rates decay in live trading. Not financial advice — crypto is volatile and you can lose your entire investment.

Testing automata-theory exercises in the browser: a regex flavor for CS coursework

FF — Sun, 04 Oct 2026 12:19:22 +0000

If you've ever taught or taken a formal languages course, you know the workflow: the exercise says write a regular expression for all strings over {a,b} containing an even number of a's, you write (b|ab)* on paper... and then you have no way to check it.

Programming regex flavors can't validate it for you — they're full of conveniences the formal dialect doesn't have: character classes, quantifier shorthands, anchors. What you want is a checker that speaks the textbook dialect: union ∪ or |, concatenation, Kleene star *, plus +, parentheses. Nothing more.

RegexTester.dev now ships a Formal Automata Theory flavor exactly for this.

What it accepts

Symbols from your chosen alphabet (typically a, b, or 0, 1)
Union: ∪ or |
Concatenation: juxtaposition or .
Kleene star: *, and one-or-more: +
Grouping with parentheses

Everything else — \d, [a-z], lookahead, backreferences — is rejected with an explanation, because the point is to exercise exactly the constructs the course covers.

Instant feedback

Type the expression and test strings in, and you immediately see which strings match and which don't — so you can iterate on the exercise instead of waiting for a grader.

The flavor runs on the same engine infrastructure as the other eight dialects (PCRE2, RE2, .NET, Python, Java, Go, Rust, JavaScript), so the matching behavior is well-defined and consistent.

Why a browser tool for coursework?

Because the feedback loop is everything when learning. The gap between writing (b|ab)* on paper and knowing whether it's right is where most of the confusion in a formal languages course lives. Close that gap to seconds and students experiment their way to understanding: they can see that (b|ab)* matches babb but not abab, and fix their mental model immediately.

It also works the other direction: instructors can build exercise sets with permalinks — every regex and test string combination in the tester has a shareable URL, so "check your answer against this" becomes a link.

Try it: open regextester.dev, pick the Formal Automata flavor from the selector, and test that even-number-of-a's exercise.

Full write-up: regextester.dev/blog/Formal-automata-theory-flavor. Free, no signup — built for students and educators.

Benchmarking regex patterns properly: P95/P99, equivalence checks, real engines

FF — Sun, 04 Oct 2026 12:08:30 +0000

Every developer has been here: two regex patterns that both work. One is a dense one-liner, the other reads like prose. Which do you ship?

"Use the simpler one" is a fine heuristic until the pattern runs over a 50 MB log file or every request in a hot path. Then you want data. The problem is that regex benchmarks done casually lie to you three ways:

The engine problem — your JS benchmark measures JavaScript's RegExp, but the pattern ships to a PCRE2-based backend. Different engine, different behavior, different speed.
The clock problem — a fast regex finishes in microseconds, far below performance.now() resolution. You're measuring timer noise.
The equivalence problem — the faster pattern is faster because it matches less. You optimized a bug.

RegexTester.dev's built-in Benchmark Suite was designed against those three traps. Here's how it works.

Real engines, identical conditions

Up to 5 alternative patterns run sequentially under identical input, flags and engine — the same engines the tester itself uses: PCRE2 and RE2 as WebAssembly in a dedicated worker, .NET's System.Text.RegularExpressions as a real interpreter, and native JS RegExp (including the normalize-to-JS path used for Python, Java and other flavors).

Sub-clock-precision timing

Each sample times K consecutive executions and records time ÷ K, with K auto-calibrated so every sample spans between 0.35 ms and 12 ms. This batch amplification resolves sub-microsecond patterns with sub-nanosecond effective resolution — far below browser clock precision.

You get median, mean, P95, P99, ops/sec and the relative speedup of the fastest pattern, with a ±RSE column that tells you when a number is too noisy to trust.

Equivalence checking

Speed means nothing if the output changed. The suite records each pattern's match count on the benchmark input and raises an "Output differs" warning when counts diverge — a pattern that's faster because it matches less gets flagged before you ship it.

Reading the charts

Latency histograms and timelines make the distribution shape visible: a tight spike means stable performance; a long tail means some inputs hit pathological backtracking even when the median looks fine.

Export

Results export as Markdown (for PRs and docs) or JSON (for your own tooling), with the environment (UA, cores, timestamp) baked in so numbers stay comparable.

Try it: open regextester.dev/bench, paste two alternatives, press Run. Sixty seconds later you'll know which one to ship — and whether they really do the same thing.

Full write-up: regextester.dev/blog/regex-benchmark-suite. Free, no signup, everything runs locally.

I built a regex debugger that shows every backtrack (flame graph included)

FF — Sun, 04 Oct 2026 12:08:29 +0000

Testers tell you what a regex matches. A debugger tells you why — and where it burns time.

Every regex tester shows the same three things: matches, groups, and an explanation of the pattern. That covers the happy path. It stops helping the moment a regex is almost right — matching one tag too many, missing a case you can't reproduce, or taking 400 ms on an input that looks identical to the one that took 4.

The failure modes of a backtracking engine are invisible from the outside. A pattern doesn't slowly get slower — it tries a prefix, gives characters back, retries the inner quantifier at a different split, fails, and repeats that a few thousand times. The match result looks the same as the fast version's. Only the trace of what the engine actually did tells them apart.

So I built a full debugger into RegexTester.dev. Here's what it does.

One click from the tester

The entry point is the Debug button on the tester toolbar. Hit it, and the debugger opens with the trace already recorded. The demo pattern <([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+/>) against <div>Content</div> generates 7,530 execution steps for 18 characters of input. That gap between "looks simple" and "7,530 steps" is exactly what the debugger makes visible.

The execution graph

The graph is a flame-chart of the engine's work. Each bar is one node attempt — a TRY that ended in OK (green), FAIL (red), or was undone by backtracking (thin blue give-back marks). Rows are stack depth; vertical bands separate match attempts.

It behaves like a proper profiler view: scroll-wheel zoom, drag to pan, double-click to zoom to a block, click any block to jump there — the amber marker follows, and every other panel updates in lockstep. A healthy trace reads as a calm staircase. A sick one shows the signature immediately: one region of the graph orders of magnitude wider than everything else, striped with red and blue.

Hot spots: where the steps go

The Hot spots table is the profiler summary: every node of your pattern, ranked, with its operation count, give-backs, failures, and share of total steps.

This is the same workflow you'd use on slow code: profile, find the hot function, fix, re-profile. It just didn't exist for regular expressions in a browser before.

From diagnosis to fix in two clicks

Diagnosis without a fix is only half a tool. The Suggestions panel combines static analysis with trace statistics to propose concrete rewrites — dialect-aware, so a PCRE2 pattern gets atomic groups and possessive quantifiers while a JavaScript pattern gets the constructs ES2025 actually supports.

The classic case: (a+)+b on aaaaaaaaaaX — the textbook catastrophic backtracking example. The debugger names the disease and prescribes the cure:

Two things make this safe to trust:

Equivalence checking — both patterns run against the real engine for your dialect on your input; only identical match lists earn the "same matches on this input" badge. A faster regex that matches less is a bug, not an optimization.
Apply writes the rewrite into the tester and re-traces immediately: same input, Healthy verdict, 404 steps instead of 50,000+.

A tracer kept honest

The trace comes from an instrumented backtracking engine — a continuation-passing matcher written for this purpose, speaking the semantics of nine flavor dialects. Every trace is cross-checked against the real thing: the match outcome is compared with the actual engine for the selected flavor (native RegExp, or PCRE2/.NET compiled to WebAssembly), and a "trace verified" badge only appears when they agree.

Try it: regextester.dev/debug — or read the full write-up at regextester.dev/blog/regex-debugger. Free, no signup, everything runs locally.