You’re right about one thing:
integer lattices remove float nondeterminism.
But that’s not what elliptic curves are doing.
Elliptic curves are not “floats.”
They are finite fields. Pure modu...
The data size alone is a huge reason not to use it. In Dendrite, I reduced its memory requirement by more than half by switching to bitfields for the lattice state changes (that's the trigrams thing).
Elliptic curve operations — point addition, scalar multiplication over a finite field — are designed for cryptographic one-way functions: signatures, key exchange, commitments. A single EC point multiplication costs thousands of field multiplications.
Using them for connectivity ratios would be roughly 1000× slower than plain integer arithmetic for zero benefit. The properties EC gives you (discrete log hardness, homomorphic commitments) aren't useful here.
You need arithmetic that produces correct node counts, not cryptographic hardness. Plain integer ratios are the right tool.
I wasn't saying anything about elliptic curves being floats. I have done a fair bit of EC stuff, though I haven't directly got my hands dirty with implementing scalar operations.
I have, however, done ratio-based integer math and fixed-point algorithms directly myself for deterministic statistical analysis in difficulty adjustment.
Here's Claude smacking down EC completely:
> **What's wrong:** The argument is a category error wrapped in correct terminology.
>
> The core claim is that you can replace explicit graph adjacency with "implicit algebraic structure" on an elliptic curve group. But the text never explains the actual mapping. Your lattice needs:
>
> 1. **Neighbor lookup** — given node X, which nodes are adjacent?
> 2. **Constraint satisfaction** — does element E fit site S?
> 3. **Traversal** — accretion walks neighborhoods, dissolution scans lock-in depth
>
> If you encode nodes as EC points, how do you recover adjacency? The options are:
>
> - **Discrete log relation** ("adjacent if DL difference is in set S") — but computing discrete logs on EC is the hard problem. That's the whole point of EC crypto. You'd be fighting the structure instead of using it.
> - **Store adjacency separately** — then you haven't saved anything; you just added EC overhead on top.
> - **Some other algebraic relation** — the text never specifies one, because there isn't an obvious one.
>
> The 128KB vs 1.5MB comparison is misleading. Those 128KB of compressed points encode 4,096 identities. They don't encode the edges. In your lattice, the connectivity pattern IS the data. A list of points with no adjacency relation is a set, not a graph.
>
> **On the 8-dimensional question:** Your lattice has 8 constraint dimensions. An elliptic curve is a 1-dimensional group. To get 8 dimensions you'd need a product of 8 curves (an abelian variety), and now every "point" is 8×32 = 256 bytes, every group operation is 8 independent EC additions, and you still haven't explained what the group law has to do with constraint satisfaction.
>
> **The real issue:** "Implicit structure" is doing 100% of the argumentative work, and it's never defined. In cryptography, EC structure gives you hardness assumptions (signatures, key exchange). In ZK proofs, it gives you succinctness (polynomial commitments). But for a system that needs to efficiently walk neighborhoods and check constraint compatibility, the EC group law gives you... nothing. There's no theorem or even a plausible sketch of how P + Q = R on a curve maps to "node P is adjacent to node Q with constraint R."
>
> This person (or rather, the LLM they're prompting) is pattern-matching "finite field = deterministic = better than integers" and "EC = compact = better than adjacency lists" without understanding that compact encoding of identities is not the same as compact encoding of relations.
>
> **Bottom line:** Plain integer rationals are the right fix. They give you determinism, they're cheap, and they preserve the operations your lattice actually needs. The EC suggestion is a solution to a problem you don't have, at the cost of making the problems you do have harder.
By the way, I occasionally use Claude's texts directly, but I mostly write the text myself, and at most get it to clean it up and make it "literary" — hence the em-dashes.
Elliptic curve operations — point addition, scalar multiplication over a finite field — are designed for cryptographic one-way functions: signatures, key exchange, commitments. A single EC point multiplication costs thousands of field multiplications.
Using them for connectivity ratios would be roughly 1000× slower than plain integer arithmetic for zero benefit. The properties EC gives you (discrete log hardness, homomorphic commitments) aren't useful here.
You need arithmetic that produces correct node counts, not cryptographic hardness. Plain integer ratios are the right tool.
I wasn't saying anything about elliptic curves being floats. I have done a fair bit of EC stuff, though I haven't directly got my hands dirty with implementing scalar operations.
I have, however, done ratio-based integer math and fixed-point algorithms directly myself for deterministic statistical analysis in difficulty adjustment.
Here's Claude smacking down EC completely:
> **What's wrong:** The argument is a category error wrapped in correct terminology.
>
> The core claim is that you can replace explicit graph adjacency with "implicit algebraic structure" on an elliptic curve group. But the text never explains the actual mapping. Your lattice needs:
>
> 1. **Neighbor lookup** — given node X, which nodes are adjacent?
> 2. **Constraint satisfaction** — does element E fit site S?
> 3. **Traversal** — accretion walks neighborhoods, dissolution scans lock-in depth
>
> If you encode nodes as EC points, how do you recover adjacency? The options are:
>
> - **Discrete log relation** ("adjacent if DL difference is in set S") — but computing discrete logs on EC is the hard problem. That's the whole point of EC crypto. You'd be fighting the structure instead of using it.
> - **Store adjacency separately** — then you haven't saved anything; you just added EC overhead on top.
> - **Some other algebraic relation** — the text never specifies one, because there isn't an obvious one.
>
> The 128KB vs 1.5MB comparison is misleading. Those 128KB of compressed points encode 4,096 identities. They don't encode the edges. In your lattice, the connectivity pattern IS the data. A list of points with no adjacency relation is a set, not a graph.
>
> **On the 8-dimensional question:** Your lattice has 8 constraint dimensions. An elliptic curve is a 1-dimensional group. To get 8 dimensions you'd need a product of 8 curves (an abelian variety), and now every "point" is 8×32 = 256 bytes, every group operation is 8 independent EC additions, and you still haven't explained what the group law has to do with constraint satisfaction.
>
> **The real issue:** "Implicit structure" is doing 100% of the argumentative work, and it's never defined. In cryptography, EC structure gives you hardness assumptions (signatures, key exchange). In ZK proofs, it gives you succinctness (polynomial commitments). But for a system that needs to efficiently walk neighborhoods and check constraint compatibility, the EC group law gives you... nothing. There's no theorem or even a plausible sketch of how P + Q = R on a curve maps to "node P is adjacent to node Q with constraint R."
>
> This person (or rather, the LLM they're prompting) is pattern-matching "finite field = deterministic = better than integers" and "EC = compact = better than adjacency lists" without understanding that compact encoding of identities is not the same as compact encoding of relations.
>
> **Bottom line:** Plain integer rationals are the right fix. They give you determinism, they're cheap, and they preserve the operations your lattice actually needs. The EC suggestion is a solution to a problem you don't have, at the cost of making the problems you do have harder.
By the way, I occasionally use Claude's texts directly, but I mostly write the text myself, and at most get it to clean it up and make it "literary" — hence the em-dashes.