RFC 8032 describes Edwards Curve Digital Signature Algorithms. The most well known version of which is ed25519 - which uses the PureEdDSA strategy with SHA512 and Curve25519.

I'm working on a project where it is desirable to depart from that for two reasons. The first is implementation size, an embedded/FPGA implementation is in the long term plan and the the primary hash algorithm other places in the project is Blake3. The second is that the PureEdDSA strategy requires two passes over the data being signed/verified, which is undesireable for similar runtime memory reasons.

This market resolves YES if:

1. I cannot get a signature scheme based EdDSA and Blake3 that signs and verifies in one pass working in a timely manner. (ruled out, I got it working just fine, and then transitioned to Schnorr signatures)

2. The implementation proves to be unreliable over the first year of use in some way.

3. There's any security flaw that comes up in the first year of use due to using ~HashEdDSA~ Schnorr signatures with Blake3 instead of PureEdDSA with SHA512.

4. Any sufficiently compelling unforseen reason that I should have stuck with ed25519 or blake3 and then ed25519 on top of it.

5. I have the code audited and the auditer finds major problems.

Explicitly excluded from those other reasons:

1. I am annoyed that I need to implement ~HashEdDSA~ Schnorr(Blake3,Curve25519) multiple times to port the library to multiple languages.

2. Curve25519 is broken (by quantum computers or otherwise).

3. Blake3 is broken in a way that also affects the other uses in the project (e.g. collisions can be generated).

The market resolves no if a year after both public release and production use, the market hasn't resolved yes.

I am not a cryptography researcher. I have implemented multiple hash functions and signature schemes (including more complicated group signature schemes), but pretty closely following existing work/papers. This initial version of the project is written in Rust, and will be using existing libraries to the extent possible.