Here is a different video

💁‍♂️ ₿ut also amazing 

nostr:note134nj963uspkpz884vvwh2r9exlcp320t0t9a2x8f5pvgqekps5jq6q4l9u 

 How does someone on the receiving end decode which keys were used to sign the event after the fact? 

 "MuSig allows multiple users each with their own private key to create a combined public key that’s indistinguishable from any other schnorr pubkey, including being the same size as a single-user pubkey" via https://bitcoinops.org/en/topics/musig/ 

 You can't "decode", but you can do `nak key combine` and pass in two pubkeys and it check if the result matches the pubkey in the cooperatively-signed event.

The problem is that the two pubkeys you pass in require the 02/03 prefix byte that we have stupidly removed from npubs. 

 😍 awesome that you baked-in multisig into nak now, that's badass, thank you! @fiatjaf I'd be curious what your take is on the state of FROST/threshold sigs (relatedly, is it safe to assume you've seen this post about ROASTr)? https://stacker.news/items/524728

Reliance on single-sig keys for using Nostr clients is scary to me. "Not your keys, not your Nostr identity/reputation"... it seems threshold keys in particular could be very powerful for using with bunkers for signing Nostr events 

 I haven't seen that, no. Will read now, thank you.

FROST and ROAST are very interesting, although I don't understand them very much. 

 👀 

 This is using btcd's (roasbeef) implementation of MuSig2, by the way. If it's broken complain to him. 

 I wish there were same go packages for bitcoin primitives.  

 s/same/sane