SIMD-0376: Relaxing Transaction Signature Verification

[Rexicon226]

No description provided.

[0x0ece]

I'm strongly in favor.

Saving 30-40% on sigverify is massive, especially when we project into the future and think about 1m TPS. When we did FD demos at 1m TPS we had 33 cores dedicated to just sigverify... this change will reduce by 1/3!

This is not an urgent change, but it's a very important one -- imo as important as LtHash. And practically speaking in Rust we can just replace dalek with ed25519-zebra, that's been used in prod by zcash for a long time.

[t-nelson]

fwiw we only moved to verify_strict 'cause status cache used to be keyed directly off signature, so the malleability was unacceptable for tx replay protection. it's now keyed off message hash, so we're free to relax

[Rexicon226]

Interesting, thanks for the insight.

We should think hard now if there are any usecases in the future which could require non malleable signatures. This proposal can easily be amended to achieve strongly binding signatures, while retaining all of the benefits mentioned. All that's needed is to reject small-order A points, which is extremely cheap to do in this context.

As mentioned in the written proposal, the main reason I chose this equation, one which does not achieve SBS, is because there is an existing, well proven, rust library for Agave to use. Both Sig and Firedancer use from-scratch ed25519 implementations, so there is no difference in which version to use for us. Agave could trivially implement the proposed algorithm with ed25519-dalek primatives, but I don't know if that's something they are interested in doing.

If we will never need SBS, might as well use the well-proven library and more relaxed algorithm. If we might, and would like to not break backwards compatibility with malleated signatures, then we could opt for the slightly stricter algorithm and perhaps losen it later.

[t-nelson]

too be clear, status cache using the signature as a key was a bug and vulnerability. no similar use cases dependent upon unique signatures should be permitted so long as we're using ed25519 dsa.

---

one thing we do need to consider is that the first signature on a transaction has become the canonical identifier. there are likely some social games that could be played with malleable signatures. i'm not sure that's something that we need to care too much about though

[Rexicon226]

too be clear, status cache using the signature as a key was a bug and vulnerability. no similar use cases dependent upon unique signatures should be permitted so long as we're using ed25519 dsa.

Agreed.

one thing we do need to consider is that the first signature on a transaction has become the canonical identifier. there are likely some social games that could be played with malleable signatures. i'm not sure that's something that we need to care too much about though

That's an interesting one! I assume you're talking about things like wallets showing the transaction signature in their view. I feel like this would be more impactful if it were related to the addresses of the accounts themselves, rather than the transaction signatures, as that's where I've seen most "social" attacks target (a talk I attended a couple months ago). I don't want to ramble about speculations though, and I am no expert on the subject, so I would love to hear other people's opinions and some examples. It's always seemed like an interesting attack vector to me.

[samkim-crypto]

I am in favor of this as well. I think relaxing the SBS requirement while maintaining SUF is the right way forward.

[samkim-crypto]

@Rexicon226 I think we should refine how we frame the security trade-offs. Currently, the proposal implies that we might care less about SBS, but technically zip-215 preserves both SUF and SBS for all properly generated keys.

The nuance is that for weak keys (torsion points), zip-215 actually breaks both properties (whereas dalek-strict maintains them by banning those keys entirely).

I think we should explicitly mention that we are okay with this trade-off because:

1. No private keys: Weak keys are just torsion points and lack a proper private scalar. More importantly, because the verification equation loosens for these keys, they cannot secure funds (signature can be forged by anyone). Therefore, no honest user would ever use then, and they effectively serve only as spam/attacker addresses.
2. Quarantined malleability: It is true that signatures become malleable on weak keys (allowing non-unique tx ids), but this behavior is isolated entirely to these specific attacker-controlled accounts. Since honest wallets always generate prime-order keys, a regular user's TXID is always unique.
   While dumb apps might get confused by the duplicate TXIDs, this is acceptable because the confusion is self-inflicted and contained. The attacker is effectively paying network fees to corrupt the indexing of their own spam history. Since the collision never involves an honest user's TXID, no user's data is ever at risk.

(This blog post has a great breakdown of the sig verification variants for reference: https://hdevalence.ca/blog/2020-10-04-its-25519am/)"