Phase 6 of docs/frost-batch-signing.md. 361 jvmTest and 227 testDebugUnitTest
pass.
## Inbound path (SignedGroupKeyStateTest)
Both drive the manager with a hand-built inner event rather than one the other
device queued, which is the only way to be a faulty or dishonest member in this
harness.
- A one-value nonce offered for a three-item batch does not count towards the
threshold: the coordinator never reaches a signer set. The length check is all
that stands between a batch and a signer whose contribution lines up against
the wrong messages, so truncating or padding would produce partial signatures
aggregated against events nobody agreed to. The test then pumps the real nonce
and the batch completes -- it is a stall, not damage, which is
FrostSignerMessage's composite key doing its job.
- A second proposal under the session's own id changes neither its event ids nor
its seeds. Every seed is already committed to its item's message; a different
batch under the same id would have those seeds produce a second partial
signature over a second message, which is how a share is extracted.
## Real FROST, no database (FrostSigningRoundTest)
- A k=3 batch from one signer set, all three verifying against the room's key --
the manager's shape with the database taken out of the way.
- Item 0's signature does not verify against item 1. Signing three events in
lockstep must not make any of them interchangeable.
- Both halves of the no-shared-nonce property, because either alone is enough to
be relied on by accident: SecretNonce.generate mixes the message in, so one
seed under two messages already gives two nonces -- and the manager mints
distinct seeds regardless.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2309879153