Phase 3 of docs/frost-batch-signing.md. A session can now be proposed over
several events, and the whole batch is signed in one round of four group
events with one approval. 356 jvmTest and 224 testDebugUnitTest pass.
## The wire, and the compatibility rule that shapes it
FrostSigningEvents.encodeProposal serialises a batch of one as the bare event
object it always was, and only a genuine batch as a JSON array. That is not
tidiness. A build predating this reads an array with Event.fromJsonOrNull, gets
null, and drops the proposal -- so an old device refuses a batch outright
rather than signing part of one, while single signing keeps working right
through a mixed-version rollout. Emitting an array unconditionally would break
every one-event session for those devices and buy nothing.
decodeProposal accepts both forms permanently: proposals in the old shape do
not stop arriving because this build stopped writing them. It is
all-or-nothing -- an array with one unreadable element is refused rather than
silently shortened, because the batch's length is what every later payload is
checked against, and a proposal that quietly lost an event would have every
signer's contribution rejected for being the wrong size: a stall with nothing
to blame.
## MAX_BATCH_SIZE, checked twice
64, enforced in proposeSigningBatch and again, independently, in
acceptProposal. The second check is the one that matters. A proposal is the
only place in this protocol where a remote party decides how much work everyone
else does -- k native key generations, k signatures, and a group event carrying
k payloads, from a single message -- and until batching that was bounded only
by never being more than one.
## acceptProposal over a list
Each element is rebuilt from its own fields under this device's own reading of
the room's path and checked against the id it claims, exactly as before but per
item, and the whole proposal is dropped if any one fails. The write-once rule
widens from "the event this session signs" to "the ordered list of events this
session signs": a second proposal under the same id whose list differs anywhere
is logged and ignored.
## The API
FrostSigningManager.proposeSigningBatch(events: List<EventTemplate<*>>) is
public here rather than in Phase 4, because without it there is no way to
produce a k>1 session and everything above would ship untested. proposeSigning
keeps its signature as the one-event form, so no caller moves. Each template
carries its own createdAt.
## Tests
- FrostProposalCodecTest (new, commonTest): a batch of one is byte-for-byte the
old JSON object -- the assertion that stands in for the old build nobody can
run here -- plus order preservation, old-form decoding, and refusal of empty,
malformed and partly-unreadable arrays.
- SignedGroupKeyStateTest: a k=3 batch between two devices over two databases.
Three signatures verifying against the room, three dialects applied on both
devices in order, five messages from the coordinator and two from the other
signer, and one approval line rather than three.
- The negative test that matters: no two items of a batch share an aggregated
nonce or a seed, and the two devices' seeds do not intersect. Every positive
test still passes if two items share a nonce -- the signatures verify fine;
what sharing costs is the secret share.
- The cap is refused when proposed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
59c34263b3