為什麼不能在帶有描述符的主根腳本路徑中添加 OP_RETURN（或一些任意腳本）？
我正在閱讀比特幣核心的描述符文件，我注意到該
raw()SCRIPT表達式只能在描述符頂層使用。實際上，當使用此描述符呼叫時，會getdescriptorinfo返回-5錯誤消息Can only have raw() at top level：
tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,raw(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556))我認為這
raw()是在主根腳本路徑中添加類型承諾的唯一方法OP_RETURN，或者至少我想不出其他方法。例如，我可以考慮使用pk()帶有雜湊的表達式，但我想這樣做很糟糕。為什麼不允許
OP_RETURN在主根地址內送出類型承諾，更不用說其他任意腳本了？它是描述符限制還是更基本的限制？我讀了這篇文章，但我認為它並不能真正回答我的觀點。如果描述符僅在頂層支持任意腳本，那為什麼呢？
答案是雙重的。
首先，比特幣核心描述符正在使用Miniscript進行擴展。在即將發布的版本 (24.0) 中，Miniscript 將僅在 Segwit 版本 0 輸出 (P2WSH) 中得到支持。
一旦添加了對 Tapscript 的 Miniscript 支持，您將能夠在 Taproot 描述符的腳本路徑中使用更多腳本功能。
關於任意腳本，包括那些使用 Miniscript 無法表示（因此無法解決）的腳本。關於支持“部分描述符”的討論正在進行中，這是一個可解決的描述符，其中包含我們沒有可解決性資訊的支出路徑。
部分 Taproot 描述符將允許您
rawnode(HEX)在樹中擁有 a。如果您想通過關鍵路徑保持可解性，這就是您所需要的，否則您可以只使用rawtr().主根腳本路徑中的 OP_RETURN 類型承諾，或者至少我想不出其他方法。例如，我可以考慮將 pk() 表達式與雜湊一起使用，但我想這樣做很糟糕。
與您的主要問題無關，但我認為使用另一種形式的承諾不一定是壞事。如果您因為 UTxO 集中的 OP_RETURN 輸出修剪而考慮這個，請注意這在這種情況下是沒有意義的。
您可以使用成本較低的方法來送出數據。例如調整公鑰。這將消除對部分描述符的需要。