Posted by salvatoshi
May 31, 2025/22:24 UTC
The proposed solution to a potential issue in the specifications for hardware signers involves adding a /T
step to the derivation path of each involved key rather than altering the descriptor template. This approach would allow the current descriptor, such as tr(musig(@0,@1)/**,{and_v(v:pk(@0/**),older(12960))}
, to remain unchanged, avoiding breaking changes. The addition of the /T
step would occur within the key origins, ensuring compatibility and flexibility.
The suggestion recognizes that requiring the T
value to be identical across all keys in a multiparty setting is impractical. Given that participants are likely to provide extended public keys (xpubs) at different times, enforcing uniformity would necessitate additional communication, complicating the process. Moreover, while it might be expected for wallets to store the key origins of other parties, this isn't always feasible. Thus, wallets should ideally not depend on having this information. This approach maintains the integrity of the existing system while introducing a method to accommodate the necessary functionality without imposing undue constraints on participants.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback