You can do amazing things in 8 bytes [1].

[1] https://tromp.github.io/blog/2026/01/28/largest-number-revis...

You can (on real MSDOS!) go as low as 6 bytes

https://www.pouet.net/prod.php?which=63538

But most people wouldn't find that visually satisfying

The technical details why this works are very interesting though :)

I guess anything that is less than 7 bytes can be brute forced.

Good article with some questionable remarks like

> Q: Stealing is illegal, so why would anyone use a CRQC to steal Bitcoin?

> A: If you truly believe this, you really should value Bitcoin at 0 – it has many unnecessary components with a lot of overhead, like proof-of-work and digital signatures.

Proof of work is still necessary for two reasons:

1) to fairly distribute all coins (it's not sufficient though, e.g. Bitcoin's halvings still concentrate wealth on early miners/adopters)

2) to provide objective proof for the true transaction history, anchored in energy expenditure.

A related article on Bitcoin Core resistance to upgrading: https://murmurationstwo.substack.com/p/bitcoin-developers-ar...

I guess the argument goes more like: If nobody were to attempt to steal anything, you don’t need security for your ledger anyway.

> 2) to provide objective proof for the true transaction history, anchored in energy expenditure.

Why do you need this if you are willing to trust other people not to steal coins or lie?

> 1) to fairly distribute all coins

Same question as above. If you don't care about perfidy, simply use the honor system for coin distribution.

If you do care about perfidy, then you should probably care about people breaking the law to steal your coins.

The linked-to page mentions:

> Infinite length Mazes: It's possible to create an infinitely long Maze (a finite number of columns by as many rows as you like) by only keeping part of the Maze in memory at a time and "scrolling" from one end to the other, discarding earlier rows while creating later rows.

> An easier way to make an infinite Maze is with Eller's or the Sidewinder algorithms, as they already make Mazes one row at time, so simply keep letting them add rows to the Maze forever.

My tiny obfuscated maze program at https://tromp.github.io/pearls.html#maze will print an infinitely long maze if you enter a negative height.

Great idea. However it is infinite in one direction. Could be made infinite in two directions (I guess) by extending along a diagonal line that get long with each step. Probably could also make it infinite in all directions with a square that gets extended with each step. However, that would mean that if one walks away from the origin, the maze has to be generated in all directions. For practical applications it would be nice to only generate the part of the maze that is 'visible' from a certain point of view (either from the top or while walking inside the maze up to a certain distance).

The notation used seems rather confusing, not even showing the list of arguments. For example, the argument swapping combinator C which is normally defined as

    C f x y = f y x

is shown on this page as as y F x, which I can only make sense of by assuming that F is an infix function. In Haskell you could use infix notation to define

    C f x y = y `f` x

but you can't use capitalize function arguments.

I think that "having no known quantum attack" is a reasonable interpretation of "quantum resistant". If there were no possible "quantum attack" (under appropriate complexity assumptions, such as EC-DLP not being in P), then we could call it "quantum proof" instead of quantum resistant.

I understand what you mean, but I think such a concept or definition would be highly misleading: "having no known quantum attack" means every novel encryption method would be automatically "quantum resistant" for having had 0 adversarial attempts to find quantum or even classical weaknesses!

There should be some measure of competence-level-adjusted man-hours of cryptographers and mathematicians trying to swing their favorite hammers at the problem; in order to estimate this "quantum resilience".

In minutes, on a single computer, for example, is the lowest bar.

* https://mathematical-research-institute.sydney.edu.au/quantu...

* https://magma.maths.usyd.edu.au/magma/

Props to John Cannon, George Havas, Charles Leedham-Green, et al.

> let webWorkerURL = `${options.basePrefix}/.within.website/x/cmd/anubis/static/js/worker/sha256-${workerMethod}.mjs?cacheBuster=${options.version}`;

It looks like it's computing sha256 hashes. Such an ASIC friendly PoW has the downside that someone with ASICs would be able to either overwhelm the site or drive up the difficulty so high that CPUs can never get through.

Make that almost nobody.

I wrote a non-trivial lambda program [1] which enumerates proofs in the Calculus of Constructions to demonstrate [2] that BBλ(1850) > Loader's Number.

[1] https://github.com/tromp/AIT/blob/master/fast_growing_and_co...

[2] https://codegolf.stackexchange.com/questions/176966/golf-a-n...

Thanks, great read. Fills in quite a few holes in my own understanding of events.

Doesn't exactly leave one optimistic for a favorable final outcome, given how much U235 they supposedly already enriched to 60%. As I understand it, they could build twice as many bombs if they took the time to enrich to 90%, but they could build at least some now if they felt they had a reason to hurry.

I wouldn't be surprised if they felt they had a reason to hurry.