Open bigspider opened 9 months ago
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.
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.
rand'
value in NonceGen
for that input/placeholder pair.Phase 2: partial signature generation: A PSBT is sent to the bitcoin app, and contains the pubnonces. **
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.
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.
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.
Extend wallet policies with
musig
support, as tentatively specified here.For wallet policies, expressions of the form:
will suffice;
KEY
can be restricted to xpubs (although it's possible to generalize to other key expressions if there are use cases). It is unclear if there is any benefit in supporting things likemusig(KEY/**, ..., KEY/**)
, which seems inherently inefficient.References
Tasks:
musig
descriptorsmusig
descriptormusig
descriptor.musig()
(per this)musig
musig()
(per this)