🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️

recreational LLM yapper

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

лучше впасть в нищету, голодать или красть
чем в число блюдолизов презренных попасть
лучше кости глодать, чем прельститься сластями
за столом у мерзавцев, имеющих власть

[Taelin @VictorTaelin]

Just saving this here to document a story and as a self reflection on whether AI is really making me more productive

Yesterday morning I found a way to complete the new HVM approach, that is much faster than before. I spent a few hours writing a spec, and then used Opus to implement. About 3k lines of C code later, everything worked and performance was incredible: 5x faster than HVM4 (stable at ~10x now). So, in one day I had outclassed HVM4. Incredible. I'd never have implemented that so fast manually.

Now, enter today. I want to turn this into a real thing, but I haven't fully read the 3k lines yet. So, how do I trust it? I spent the whole day auditing the code. With AI. Several bugs found, most minor like forgetting to collect() some argument. But then I stumble upon this:

λ{ inl: 1 ; inr: 1 }

This was a test. But wait. This is matching on inl/inr. So the branches should receive the value of the Either. But they were numbers instead. Numbers aren't functions. This makes no sense. So why this is a test?

It then stuck me. The AI completely misunderstood how function arities work. It literally assumed for no good reason that HVM5 was supposed to handle under/over-applied functions. For no good reason. I never wrote that. It never asked either. It just kinda thought "HVM is weird in some aspects, this might be one of them..." - and then it went on to implement a massive system to handle cases that should never happen to begin with. And all of that code is obviously wrong because it should not even exist. It is wrong. It is damage. And it is there.

But it isn't too bad either. I just told Opus that it was wrong. Perhaps not so politely. And it solved it just fine.

But then this begs the question. I spent ~20 hours in this file, and it is STILL not done. I went from 0 to 95% in the first 5 hours. Yet, 15 hours later, it is still not 100%. I suppose that is the real effect of using AI. If I had just written the C file manually in the last two days, would I not be further than where I am *right now*?

Surely, the first version would have taken much longer to drop. But when I'd finish writing all that code, there would be zero, literally zero retarded shit. And, just today, I caught 5 or 6 retarded shit. And the worst part is: I don't know what the number of retarded shit left is, but I'm afraid it is >0.

So if I have to read it all, review it all to ensure there is no retarded shit... what did I achieve by using AI, other than that dopamine anticipation?

[Daniel J. Bernstein @hashbreaker]

Posted new paper "Exploiting ML-DSA bugs" and demo scripts: https://t.co/zoazTjsFcM The current panic to roll out new ML-DSA code in place of ECC signatures will give away tons of keys to attackers through the predictable flood of efficiently exploitable software vulnerabilities.

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@konoplintus это всё интернет-популярность Эа-Насира, чую))

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@angeris like, I do believe 2^100 exists, I am less sure about some... larger numbers :)

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@angeris I am ofc off by many orders of magnitude, but it doesn't seem impossible in principle; in fact it is very likely that natural numbers are "low-scale limit" of some phenomenon

does it make me ultrafinitist philosophically? idk...

[guille @angeris]

there is a pretty (in?)famous story here from harvey friedman on ultrafinitism

friedman goes up to esenin-volpin, a hardline ultrafinitist, after one of his lectures and then posits to him that if the number 2^100 doesn't exist, then surely he believes that somewhere on the line from 2^1, 2^2, ..., 2^100 the numbers stop being real

esenin-volpin asks him to be more specific and so friedman begins:

does 2 exist?

"yes"

does 4 exist?

(waits a second) "yes"

does 8 exist

(waits even longer) "... yes"

friedman doesn't get to 32 by the time that he runs out of patience, but the point was made

[Tom Gur @TomGur]

Oded Goldreich posted a very insightful digest of the interactive proofs of proximity paper by Rothblum, Vadhan, and Wigderson. This is one of my favourite TCS papers, and Oded's new exposition makes it even easier to appreciate its beauty and elegance.

https://t.co/2d5GNNKc3f

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@ameensol ithoughtthatwasobvious.jpg

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@PrazRama decel is the one who fuds accels, clearly

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@Osint613 we are all confused, but I sleep with my pants on

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

(stolen from meme chat)

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@tek_kac I would also love a full writeup on a break, lmao (because I figured out in the morning before we got the submission that commutator kernel spaces reveal *some* coordinates of the hidden basis, but exact mechanic of what they do seems circuit specific)

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

1./ Yup. Apparently AADP (as well as ADP (!)) is not secure for sparse circuits at all. A huge upset.

For unrelated reasons (a neighboring scheme that we investigated), we have a generic transformation that fixes it, but only in char 2. Currently speculating on char p fix.

[Alloc Init @alloc_init_]

Open challenges for AADP WE are happening!

A commutator-based attack breaking both AADP and the original ADP for sparse circuits was submitted. We are aware of the mitigation that fixes this class of attacks in characteristic 2 and are working on extending it to characteristic p.

Congratulations to the submitter, we will be in touch!

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@0xdasha @VitalikButerin @captainntan BTW I never ever claimed that HFHE does not work - I just said that you do not have available code to check whether it works or not!

And I stand that the linked repo is just a demo - useful scheme involves actually reducing the ciphertext size!

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@0xdasha @VitalikButerin @captainntan arithmetic is not plaintext, it is bunch of numbers twisted by masks derived from the key

they are indexed by stuff related to the hypergraph, but because no meaningful reduction is happening you pretty much have addition = concat, multiplication = pairwise multiply

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

@tek_kac yooo thats strong motivation! :)

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

done

[🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ @levs57]

I think I should change my profile description to "recreational LLM user", it actually fits my current role surprisingly well!

This whole thread is gold, tbh.

[dasha @0xdasha]

“i assumed” so you haven’t checked the code, nor the math, haven't verified the paths, and are a recreational what, assumer + llm user + public yapper? which puts us on roughly the same level of technical ability. you only need the paper and the node to put it in the same slop machine chat, not to actually read it. so i will also respond with my slop machine to you for the last time, and if @lambda0xE wants to correct anything, he will, otherwise check back later

He is not right that the PoC “doesn’t use hypergraphs.”
The code literally constructs H as a sparse incidence/parity structure: m_bits as vertices, n_bits as hyperedges/columns, each column choosing h_col_wt rows. See gen_H in include/pvac/crypto/matrix.hpp:190-216, and tests/test_hg.cpp:97-106, which prints m (vertices), n (hyperedges), and k (col weight).

“Reduction to hypergraphs” is the wrong phrase. The ciphertext structure is hypergraph-based; the reduction/security direction is toward LPN / syndrome / check-residual hardness, not “reduction to hypergraphs.” In code, sigma_from_H builds each edge syndrome as XOR of selected H columns plus noise: include/pvac/crypto/matrix.hpp:266-302.

The critic’s “addition is concat” is technically true but rhetorically misleading.
ct_add appends layers/edges and offsets layer IDs, yes: include/pvac/ops/arithmetic.hpp:165-187. But in an additive masked-carrier / abelian-group representation, concatenating signed carriers is a normal way to represent a sum. “Concat” does not imply fake encryption or plaintext math.

The “multiplication is plaintext multiplication” claim is wrong in the important sense.
ct_mul does multiply field elements, but they are public masked layer aggregates, not plaintext messages. It takes PubKey, Cipher A, Cipher B; no SecKey. The unmasking happens only in dec_values, where secret-derived Rinv is used: include/pvac/ops/decrypt.hpp:46-74. So the accurate description is: public masked aggregate multiplication + repacking into new product-layer edges, not plaintext multiplication.

The growth criticism is fair for this PoC.
ct_mul creates LA * LB product layers, and test_compactness.cpp:62-68 explicitly asserts that. So yes, the PoC is naive for multiplicative depth and does not expose production relinearization/bootstrapping/reduction.

So the correct answer is not “he is right.” It is:

He found that the public PoC is intentionally naive and does not include the production optimizer. He did not prove there are no hypergraphs, no HFHE structure, or plaintext multiplication. Those claims are wrong based on the code.

The arithmetic accumulator can be read separately from the syndrome layer, but the ciphertext object and security/check-residual structure are built around the hypergraph incidence matrix.