[socketcluster]

Why would experts care about my product? There's no big money behind it. The big money has to come in first, then the experts come later to tell the big money whatever they want to hear. Maybe they want to hear the truth maybe not... Either way the paymaster always hears what they want.

Besides, I am an expert. I studied cryptography at university as part of my degree. I have 15 years of experience as a software engineer including 2 years leading a major part of a $300 million dollar cryptocurrency project which never got hacked... I know why the experts were not interested in my project and after careful analysis, I believe it has nothing to do with flaws in my work.

If anything, it might be because my project doesn't have enough flaws...

At this stage, I hope you're right. I hope I will find the flaws in my projects that I've been looking for after 5 years.

[Nevermark]

You are leaving something out then. Which you allude to.

Bravo on five years! I recently solved a problem that took me over 30. I originally thought, 3-5 months maybe, then 3-5 years, ... I am happy it didn't take 50. I have killed a lot of my own darlings.

Well apparently you know what you are doing, I am sure you have something.

I have found the best language models are great at attacking things. You may have already done that, but if not its worth a try. Free brutality.

[socketcluster]

I built my quantum-resistant signature scheme from the simplest cryptographic primitives I could find precisely to mitigate risk.

This implementation simplicity came with tradeoffs; I chose a stateful signature scheme (Lamport OTS with Merkle Signature Tree) which I could fully understand and easily verify from first principles. It's actually one of the simpler aspects of my blockchain.

Originally, I wanted to use SPHINCS+ (stateless) but there were no good libraries for it at the time in the Node.js ecosystem and TBH, I didn't fully grasp some of the finer technical details at the time; it was clear it would have been a much more complex and error-prone solution.

That said, statefulness in the signature scheme creates complexity elsewhere and shifts the risk to the clients. There are risks that a poorly implemented client could lead to key-reuse. Also, there are concurrency scenarios which can't be supported securely (e.g. if the user tries to sign multiple transactions in parallel from two different clients from the same wallet/private key).

And yes, I did run several versions of Claude including Claude 4.6 sonnet against both:

https://www.npmjs.com/package/lite-merkle https://www.npmjs.com/package/lite-lamport

It said it found 2 non-critical issues with lite-lamport but neither was exploitable.

I had to add comments to the README so that anyone who tries to run an AI against the code knows that I'm aware of these concerns but they are not issues. I did fix a non-critical signature malleability issue but that was more to appease the AI since there was no exploit for it at the level of the blockchain; it basically ignored any extra trailing bits at the end of a valid signature which could in theory lead to replay scenarios with an extended signature with junk data at the end but not possible in practice since transaction IDs are unique and deterministic. There's no possibility of double-spend.

I look forward to running the new Claude Mythos on it when it comes out. In the meantime, if anyone can find an issue with it, please let me know.