• 0 Posts
  • 45 Comments
Joined 3 years ago
cake
Cake day: September 11th, 2023

help-circle

  • Technus@lemmy.ziptoTechnology@lemmy.world•Claude reveals ECDSA curve origins
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    3
    ·
    28 days ago

    If I’m interpreting it correctly, that’s the probability that this particular PRNG with those particular seeds produces those particular outputs. That’s a strawman argument; a PRNG with uniform output should eventually produce any value.

    It’s perfectly believable that a known broken PRNG from 40+ years ago could be backsolved. The part I doubt is the sensationalized part, that the LLM found the exact method with which it was calculated. It’s just a plausible choice for a random oracle. It’s a local minimum the LLM settled into.

    That’s the thing with random oracles, there’s likely so many plausible combinations of candidate algorithms and inputs/seed values that the actual truth is almost certainly lost to history.


  • Technus@lemmy.ziptoTechnology@lemmy.world•Claude reveals ECDSA curve origins
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    2
    ·
    28 days ago

    Correction: Claude found a plausible way these curve points were generated. And “plausible” is carrying a metric fuckton of weight here.

    It found PRNG settings that could theoretically generate the same values, but the fact that it requires thousands of iterations makes me think this is more of a coincidence than anything. Especially given that the NSA employee remembered something completely different.




  • All the messaging about fast charging speed is focused on the wrong thing. EV drivers should be able to do the vast majority of their charging at home or at their destination. The messaging should be about getting chargers in more homes, apartment complexes and workplaces. Speed doesn’t matter as much if you’re going to be parked for half the day or overnight. That’s something that gas simply can’t do.

    Fast charging stations should only be necessary for road trips, where you should be taking a break every so often anyways.




  • In the scheme I’m proposing, the password never gets sent to the server.

    The issue of password reuse is the password getting sent to the site, because the prevailing approach is to hash the password server-side. Passwords leak because they get stored in plaintext, or hashed using outdated algorithms, or get logged with request metadata–bottom line, they end up stored somewhere that an attacker can get their grubby little paws on them, or in a way they can reasonably recover them.

    Using a master password to derive a passkey client-side isn’t any different than using a master password to unlock a password manager. It just cuts out the middle step.


  • I feel like there’s some potential in password-derived passkeys, which would get around the storage and hardware lock-in issues. It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.

    Most of the sources of compromise for regular users would be eliminated because the password never leaves the client.




  • Seems like a positive feedback loop:

    1. Netflix creates show that’s pretty good
    2. People watch it
    3. Netflix takes too long to release season 2
    4. People forget show exists, stop watching
    5. Netflix drops a season years later
    6. No one watches it because they forgot what happened in season 1 and Netflix shows are so serial that you have to know what happened
    7. Netflix cancels show due to low viewership
    8. Fans of the show feel jilted and slam Netflix on social media
    9. Rinse and repeat


  • Not sure what this internal state you are referring to is. Are you talking about all the values that come out of each step of the computations?

    It would need to be able to form memories like real brains do, by creating new connections between neurons and adjusting their weights in real time in response to stimuli, and having those connections persist. I think that’s a prerequisite to models that are capable of higher-level reasoning and understanding. But then you would need to store those changes to the model for each user, which would be tens or hundreds of gigabytes.

    These current once-through LLMs don’t have time to properly digest what they’re looking at, because they essentially forget everything once they output a token. I don’t think you can make up for that by spitting some tokens out to a file and reading them back in, because it still has to be human-readable and coherent. That transformation is inherently lossy.

    This is basically what I’m talking about: https://www.comicagile.net/comic/context-switching/

    But for every single token the LLM outputs. The fact that it’s allowed to take notes is a mitigation for this context loss, not a silver bullet.




  • The size of the context window is fixed in the structure of the model. LLMs are still at their core artificial neural networks, so an analogy to biology might be helpful.

    Think of the input layer of the model like the retinas in your eyes. Each token in the context window, after embedding (i.e. conversion to a series of numbers, because ofc it’s just all math under the hood), is fed to a certain set of input neurons, just like the rods and cones in your retina capture light and convert it to electrical signals, which are passed to neurons in your optic nerve, which connect to neurons in your visual cortex, each layer along the way processing and analyzing the signal.

    The number of tokens in the context window is directly proportional to the number of neurons in the input layer of the model. To make the context window bigger, you have to add more neurons to the input layer, but that quickly results in diminishing returns without adding more neurons to the inner layers to be able to process the extra information. Ultimately, you have to make the whole model larger, which means more parameters, which means more data to store and more processing power per prompt.



  • If you prompted an LLM to review all of it’s database entries, generate a new response based on that data, then save that output to the database and repeat at regular intervals, I could see calling that a kind of thinking.

    That’s kind of what the current agentic AI products like Claude Code do. The problem is context rot. When the context window fills up, the model loses the ability to distinguish between what information is important and what’s not, and it inevitably starts to hallucinate.

    The current fixes are to prune irrelevant information from the context window, use sub-agents with their own context windows, or just occasionally start over from scratch. They’ve also developed conventional AGENTS.md and CLAUDE.md files where you can store long-term context and basically “advice” for the model, which is automatically read into the context window.

    However, I think an AGI inherently would need to be able to store that state internally, to have memory circuits, and “consciousness” circuits that are connected in a loop so it can work on its own internally encoded context. And ideally it would be able to modify its own weights and connections to “learn” in real time.

    The problem is that would not scale to current usage because you’d need to store all that internal state, including potentially a unique copy of the model, for every user. And the companies wouldn’t want that because they’d be giving up control over the model’s outputs since they’d have no feasible way to supervise the learning process.