The cashu crate's V4 (cashuB) encoder always writes a NUT-02 v2 keyset
id in its short 8-byte form (serialize_v4_keyset_id narrows to
ShortKeysetId unconditionally), which is spec-compliant: the receiver
must expand it against the mint's keyset list before spending. The
payment-receive loop in ecash.rs called MintClient::swap() directly
with the short id still attached, so mint.minibits.cash (whose active
keyset is v2) rejected every cashuB payment with
`422 inputs[0].id: NUT02: ID length invalid` — hence "seller doesn't
accept your Cashu mint" on any peer purchase.
MintClient::receive_token() already resolves this via
resolve_truncated_keyset_ids(); expose it pub(crate) and call it from
the ecash.rs loop too. The only other swap() call sites either run
after resolution or operate on our own full-id proofs.
Adds a test documenting that the short form is what crosses the wire,
so serialize_v4 is not "fixed" to defeat it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ssmithxandClaude Sonnet 5
2773532769