delvingbitcoin
Tr(): rawnode() and rawleaf() support
Posted on: May 22, 2024 15:25 UTC
The ongoing discussions and proposals surrounding Bitcoin's Taproot (tr) descriptors, specifically on GitHub issue Issue 24114 and the Partial Descriptors Gist, introduce two new descriptor types aimed at enhancing flexibility and functionality.
The proposed descriptors are rawnode(HEXHASH)
and rawleaf(HEXSCRIPT,[HEXLEAFVER])
, each serving distinct purposes within the context of specifying Taproot trees.
The rawnode()
descriptor allows for the specification of a branch within a Taproot tree using its merkle hash. This addition caters to various user needs, including the support for Need-to-Know-Branches (N2KB), which is underscored by Jeremy's commentary in another pull request. It enables users to construct Taproot trees with omitted information or simplified TR trees, enhancing privacy and efficiency in certain scenarios.
The rawleaf()
descriptor, while seemingly redundant due to the existence of rawnode()
, holds its merit as argued by @sipa. It allows for the inclusion of raw scripts with different leaf versions, facilitating precise script and leaf version communication through PSBTs (Partially Signed Bitcoin Transactions). This capability underscores the ongoing discussion about potentially streamlining the descriptor under tr()
to avoid overloading the raw()
descriptor, indicating a preference for the specificity rawleaf
offers.
A proof of concept has been developed and is available in the wip-tr-raw-nodes branch of Eunovo's Bitcoin repository, as detailed in the provided diff comparison. This implementation introduces two new DescriptorImpl
subclasses, namely RawNodeDescriptor
and RawLeafDescriptor
, both of which are only valid within the P2TR context and can be inferred by the InferDescriptor
.
The inference logic for these descriptors suggests that if no taptree is inferred and the Merkle root is not null, a tr(internal_key,rawnode(merkle_root))
descriptor will be returned instead of the previously used rawtr(tr_public_key)
. This change raises questions regarding the advantages of this approach over the former, hinting at the potential benefits in terms of specificity and flexibility in constructing and inferring Taproot descriptors.