Salvatore Ingala

> Right, it's the way I actually follow, the key is needed to check that we have 'control' on at least one xpub prior to building the PoR. About the...

> * Similar implementation complexity, because the wallet software already includes signing logic. HMACs (and therefore [SLIP-21](https://github.com/satoshilabs/slips/blob/master/slip-0021.md)) are quite easy to implement, much easier than signatures and BIP32 derivations. The...

> i think the PoR do not have to be standardized, but the PoR should be an optional field that the software wallet/coordinator can use. Some people (e.g. at Unchained...

Hardware signing devices need knowledge of the full descriptor/wallet policy in order to: - recognize change addresses - recognize from which of your different _accounts_ (sometimes called _wallets_) the inputs...

Rust support will be easier after https://github.com/rust-bitcoin/rust-miniscript/issues/182 and https://github.com/rust-bitcoin/rust-bitcoin/issues/4207 are addressed upstream.

> My understanding is that Ledger (cc @bigspider) creates a nonce, stores it, and then deletes it from storage as soon as it's loaded (before signing). We could similarly store...

Hi all, an early alpha of the Ledger Bitcoin Testnet app with MuSig2 support is available for testing. (NB: the app is called `Bitcoin Test Musig` and not `Bitcoin Test`)....

EDIT: this is now resolved. The current implementation seems to be using the aggregate pubkey (before the tweaks) inside the key of the `PSBT_IN_MUSIG2_PUB_NONCE` (and I'd assume `PSBT_IN_MUSIG2_PARTIAL_SIGNATURE`, but I...

> I've interpreted (and implemented) it as also allowing the taproot internal key, not just the output key. I think that is actually what I meant when writing the BIP,...

Looking good! I can confirm that I was able to complete two e2e tests on regtest (commit 09a6091711eef299de7cfbfd340a112706422c81), using Ledger's MuSig2 implementation for a cosigner and bitcoin-core for the other...