Descriptors using H as a hardened indicator

This update came to light following the identification of a test that incorrectly classified H as an invalid hardened indicator. A subsequent pull request corrected this by reassigning the test to the valid category, ensuring consistency with BIP 380's specifications. Despite this amendment, debates have emerged about whether the adjustment aligns with the broader expectations and implementations within the Bitcoin ecosystem.

Bitcoin Core, a pivotal component of the Bitcoin network, currently does not support H as a hardened indicator, mirroring the absence of such implementation in rust-miniscript. This gap has sparked discussions on whether it would be more appropriate to amend BIP 380 to reflect the current state of implementations rather than adjusting core projects to accommodate this specification. A link to an open pull request on Bitcoin Core (here) highlights ongoing deliberations around integrating support for H as a hardened indicator or revisiting the BIP itself to possibly revise its contents based on practical implementation challenges and existing capabilities.

The discourse further extends to the compatibility of descriptor implementations with the H indicator. Specifically, the community seeks to understand whether any existing descriptor implementations are capable of emitting or accepting descriptors that utilize H for indicating hardened paths. The primary concern revolves around ensuring interoperability among different implementations, where the ability to parse descriptors across various platforms becomes crucial. Although some libraries extend BIP 32 utilities to include H, the prevalence and acceptance of this practice among descriptor implementations remain uncertain. This inquiry emphasizes the need for a cohesive approach to hardened indicators, ensuring that enhancements to Bitcoin's technical standards foster greater compatibility and user confidence.