MuSig2 support

[bigspider]

Add full support for musig() in wallet policies.

Unlike typical signatures, where the client sends a transaction to the device and receives a signed transaction back, MuSig2 is a 2-party protocol among a group of cosigners, where:

• during the first round, all the cosigners generate a secret nonce, and share with each other a pubnonce
• Once all the pubnonces are available, the cosigners can proceed to aggregate the pubnonces, producing the aggregate aggnonce, and produce a musig partial signature

Any (untrusted) coordinator, once all the partial signatures are collected, can produce the final signature.

Security considerations

Special care needs to be taken in the handling of nonces, and the way nonces are persisted in storage.
See more in the musig.md document added as part of the PR.

UX consideration

As it is a two round protocol, there were some choices to be made on how to handle it: software wallets will in fact send the same PSBT to the device twice in order to complete the protocol.

In order to minimize the UX impact for the device - but also for wallets implementing it, the following choice was made:

• the first round is executed silently - that is without requiring any user confirmation

This is not a security problem, because the first round of MuSig2 just produces and stores a random number; private keys are not even accessed.

In cases when the other cosigners are online at the same time, this allows software wallets to use MuSig2 while essentially providing identical UX to a non-MuSig2 wallet (connect the device, , inspect and confirm the transaction).

If the first and second round happen in two separate sessions, only the second one will require user confirmation, while of course the first one still needs the device to be unlocked and connected with the bitcoin app open.

BIPs related to this PR

The details of the signing protocol are detailed in BIP-327, but there are other related BIPs: BIP-328, BIP-390, BIP-373.
BIP-388 is in process of being updated.

Structure of the implementation

The PR required some refactoring that have a fairly big impact on the codebase, particularly in order to generalize the 'key expressions' in wallet policies to support the musig() expression, whereas in the past it was always limited to a single xpub; the code to handle the PSBT fields in the transaction and identify the correct derivation path for each input also needed to be generalized.
However, most of the musig-related code is relatively self-contained and modularized in the following files:

• doc/musig.md - Technical details, and security details, about the MuSig2 feature.
• src/handler/sign_psbt/musig_signing.{c,j} - portions of the sign_psbt handler that are handling the logic of Round 1 and Round 2 of MuSig2,
• src/musig/musig.{c,h} - implementation of the relevant algorithms defined in BIP-327, closely matching the Python reference implementation
• src/musig/musig_sessions.{c,h} - encapsulates the logic to handle the persistence in NVRAM after the end of MuSig's round 1, until the beginning of Round 2.

Status of test coverage

There are some e2e tests with the corresponding bitcoin-core implementation which is still a WIP and does not support complex policies. Testing will be needed with musig nested inside miniscript as soon as possible - to be done in a separate PR ahead of release. Created issue #302 for tracking.

Incidental changes

Also improves the signing flow to only sign for spending paths that are filled in in the PSBT (that is, the corresponding PSBT_IN_BIP32_DERIVATION or PSBT_IN_TAP_BIP32_DERIVATION fields are present), optimizing certain use cases for wallet policies with multiple alternative spending paths.

Closes: #208
Closes: #177

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 85.33333% with 11 lines in your changes missing coverage. Please review.

Project coverage is 84.70%. Comparing base (bc81ed0) to head (2d22ebe).

Files with missing lines	Patch %	Lines
src/common/wallet.c	84.72%	11 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #294      +/-   ##
===========================================
- Coverage    84.76%   84.70%   -0.06%     
===========================================
  Files           17       17              
  Lines         2186     2230      +44     
===========================================
+ Hits          1853     1889      +36     
- Misses         333      341       +8     

Flag	Coverage Δ
unittests	84.70% <85.33%> (-0.06%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate failed

Failed conditions
6.0% Coverage on New Code (required ≥ 80%)
11.1% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[lpascal-ledger]

Reviewed the C part mostly, need to dive more into the Python bits.

[lpascal-ledger]

Nothing interesting to say, that all sounds fair 👍