Edit: a more precise version of these specs was posted on Delving Bitcoin.

BIP-0327 discusses the necessity to keep some state during a signing session. However, a "signing session" in BIP-0327 only refers to the production of a single signature.

In the typical signing flow of a wallet, it's more logical to consider a session at the level of an entire transaction. All of the inputs of the transactions are likely to be obtained from the same descriptor, and the signer would produce the pubnonce/signature for all of them at the same time.

Therefore, in the flow of BIP-0327, you would expect one MuSig2 signing session per input to be active at the same time. That's problematic as it would require to persist state for an unbounded number of signing sessions.

Instead, we want a psbt-level session with a small state persisted on the device, that allows to complete a full signing flow for the entire PSBT; the necessary state for the each actual session for each internal input (possibly, one session per-input and per-placeholder of the wallet policy) can be synthetically generated.

Signing flow

For now, we assume that the app can handle a single psbt-level session; this could be generalized to multiple parallel psbt-level sessions in the future.

In the following, a session always refers to the psbt-level signing session.

Phase 1: pubnonce generation: A PSBT is sent to the bitcoin app, and it does not contain any pubnonce.

• If a session already exists, it is deleted from the persistent memory.
• A new session is created in volatile memory.
• The app produces a fresh random number $rand\_root$, and saves it in the current session.
• The app generates the randomness for the $i$-th placeholder and for the $j$-th input as: $rand_{i,j} = SHA256(rand\_root || i || j)$ (with a fixed-length encoding of $i$ and $j$). That is used as the rand' value in NonceGen for that input/placeholder pair.
• At completion (after all the pubnonces are returned), the session is copied into the persistent memory.

Phase 2: partial signature generation: A PSBT is sent to the bitcoin app, and contains the pubnonces. **

• A copy of the session is stored in the volatile memory, and the session is deleted from the persistent memory.
• For each input/placeholder pair $(i, j)$:
  • Recompute the synthetic pubnonce/secnonce pair with the syntetic randomness $rand_{i,j}$
  • Verify that the pubnonce the PSBT matches the recomputed one
  • Continue the signing flow as per BIP-0327, generating the partial signature.

Security considerations

State reuse avoidance

Storing the session in persistent memory only at the end of Phase 1, and deleting it before beginning Phase 2 simplifies auditing and making sure that there is no reuse of state across signing sessions.

Security of synthetic randomness

Generating $rand_{i, j}$ syntetically is not a problem, as the $rand\_root$ value is kept secret, making all the values produced for different $i$ and $j$ not predictable for an attacker.

Malleability of the PSBT

If the optional parameters are passed to the NonceGen function, they will depend on the transaction data present in the PSBT. Therefore, there is no guarantee that they will be unchanged the next time the PSBT is provided.

However, that does not constitute a security risk, as those parameters are only used as additional sources of entropy in NonceGen. A malicious client can't affect the secnonce/pubnonce pairs in any predictable way, since the $rand\_root$ never leaves the device.