The rawtr() descriptor has been in Bitcoin Core since 24.0, but it was never specified in a BIP. Pieter noted this on the bips repo back in March [0] and nobody picked it up, so I wrote a draft:
https://github.com/jeanpablojp/bips/blob/rawtr-descriptor/bip-rawtr.mediawiki BIP 390 only allows musig() inside tr(), rawtr() or sp(), and two of its test vectors are rawtr() descriptors, so there's a published BIP depending on an expression no BIP defines. Outside the repo people fill the blank by guessing: bdk-ffi's test suite cites rawtr as BIP-386, which doesn't mention it. The draft follows the shape of BIPs 384 and 385. Test vectors were generated against Bitcoin Core master with getdescriptorinfo and deriveaddresses. The first vector reuses the key from the first tr() vector of BIP 386: same key, different script, because rawtr() applies no tweak. The musig() vectors come from BIP 390 verbatim. Scope is rawtr(KEY) only. The partial-descriptor ideas (rawnode(), rawleaf()) have their own design discussion in bips PR 1721 and I'm not touching them here. On structure: Appendix B of BIP 380 has been one BIP per expression group so far, and musig() and sp() both got their own numbers this year, so I drafted it as a separate BIP rather than a new section in 386. Feedback welcome. [0] https://github.com/bitcoin/bips/pull/2050#issuecomment-3986205616 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/DD9687EA-368C-482F-91B6-C5E2E230830C%40hotmail.com.
