BIP-390: allow musig() under rawtr() #2050

musig() was previously specified as only usable under tr(), but the BIP-390 test vectors already include valid rawtr(musig(...)) descriptors and Bitcoin Core’s descriptor implementation accepts musig() as a generic KEY under both tr() and rawtr(). This change updates the wording to explicitly allow musig() inside rawtr(), aligning the specification with the existing test vectors and Core semantics without changing any behavior.

concept ACK

ACK 7e8facb4793ea8baafc07a5f4e9b28283d7c86d7

Just FYI: rawtr itself is not specified in any BIP.

Nobody seems to have picked this up since your note, so I'm writing it.

It'll be its own BIP with a row in BIP 380's Appendix B: the appendix has been one BIP per expression group so far, and both musig() and sp() got their own numbers this year. You wrote rawtr in Core and co-authored 386, so if you think it belongs in 386 instead, I'd rather hear it now than at the PR.

What makes it awkward today is that BIP 390 already leans on it: musig() can only appear inside tr(), rawtr() or sp(), and two of its test vectors are rawtr() descriptors. A published BIP depends on an expression the BIPs never define. Outside the repo people fill the blank by guessing, and bdk-ffi's test coverage lists rawtr as BIP-386.

My plan is test vectors first, generated against master with getdescriptorinfo and deriveaddresses, then the text following 384 and 385, then a post to the list before opening anything here. I'd keep it to rawtr(KEY) and leave rawnode()/rawleaf() where they are in #1721.

This is not correct