Published on: 2020-09-20T03:23:28+00:00
In an email exchange within the bitcoin-dev community, LL and Jay Berg discussed the security and privacy implications of reusing keys in Taproot. LL stated that there is not much difference in security or privacy, and the advice to avoid key reuse remains the same. Jay Berg, new to bitcoin-dev, asked if reusing keys acts differently in Taproot compared to Pay-to-PubKey-Hash. The conversation referred to a thread about Taproot complexity started by Anthony Towns on February 10, 2020.The creation of UTXOs in Taproot allows for indistinguishable spends as long as keys are not reused. Reusing keys may have security and privacy implications, but it is unclear whether it has different implications in Taproot compared to Pay-to-PubKey-Hash. The use of the same public key to create the same address remains the same in both cases. The question raised is whether there are worse security and privacy implications when reusing public keys with Taproot.ZmnSCPxj presented an argument related to Taproot in a message to the group. He explained how most scripts in use have a pre-determined set of participants represented by pubkeys, and Taproot allows for the union of these participants as the keypath branch. This provides privacy and reduced onchain fees when all participants sign a transaction using the keypath spend. Taproot can be beneficial for complex contracts and protocols, offering privacy and transaction size benefits.The discussion on the bitcoin-dev mailing list focused on the development and benefits of Taproot. It allows wallets to change recovery options if a key is lost and offers advantages such as reduced onchain fees. Graftroot was also mentioned but not proposed due to incomplete documentation. The benefits of Taproot include preserving anonymity sets even after spending. However, concerns were raised about the merit of Taproot compared to alternatives and the development process.Privacy concerns regarding Taproot design were also discussed. It was suggested that users may care more about privacy when contesting a close of a channel, and timelocks were identified as a privacy leak. The optimization for the common case of N of N opt-out in the protocol was highlighted as beneficial for user privacy and advanced functionality.Bryan Bishop questioned the Taproot upgrade, specifically the assumption about the frequency and likelihood of the signature case over the script case. Matt Corallo clarified that optimization for the common N of N case encourages developers to make this possibility a reality, enhancing user privacy for advanced scripting systems.A group of anonymous developers expressed concerns about the Taproot upgrade and its development. They questioned the probability assumption of the N of N case and its comparison to script paths. Privacy concerns were raised, suggesting alternative designs with MAST that offer more privacy. The developers proposed solutions such as allowing the witness type to be either a MAST hash or a schnorr key and separate soft-forks for Merkle Branch Witnesses and Schnorr Signatures.The developers emphasized their duty to raise these concerns and suggestions for the benefit of the community. Despite concerns, Taproot is viewed as a good midway point to release the feature and move forward.
Updated on: 2023-08-02T01:50:21.179250+00:00