Published on: 2020-02-18T23:29:21+00:00
Pieter Wuille emphasized the significance of Taproot in incentivizing protocols and implementations that utilize the key path, maximizing privacy and appealing to a broader range of users. He argued against having a separate MAST-no-Taproot spending type, as it would reduce incentives for those who don't prioritize spending policy privacy in building key-path-spendable protocols. Wuille also mentioned alternative options for cheap verification constructions but noted that they disregard incentives for privacy, which could negatively impact fungibility and overall system effectiveness.In a Bitcoin-dev thread, Jeremy questioned whether using Schnorr + Merkle Branch without Taproot optimization is equivalent. Dave responded that it is only true if all parties construct their merkle tree with a single `OP_CHECKSIG` as one of the top leaves. However, Taproot standardizes the position of the all-parties-agree condition, leading to a larger anonymity set and easier participation by pure single-sig users. Despite taproot scriptPubKeys being larger than P2WPKH scriptPubKeys, the witness data is considerably smaller, incentivizing receivers to demand P2TR payments even if spenders are reluctant to pay the extra 12 vbytes per output. Dave provided rough estimates for various PubKeys and witness data types. He concluded by stating that this branch of the discussion reiterates points covered two years ago.A group of anonymous developers expressed concerns about the development and deployment of Taproot, proposing an alternate path and suggesting modifications to its specification. They argue that Taproot is essentially the same as using Schnorr signatures separately, but combining them assumes specific use cases and probability distributions. The developers propose separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. They believe this conservative approach allows for real-world protocol engineering experience to validate the Taproot frequency assumption. The group suggests modifying Taproot's specification by adding a rule for the Taproot Public NUMS Optimization, which includes attempting to hash the witness stack and using a NUMS point only when a single-use nonce can be sent. They advocate for careful consideration of Taproot's benefits compared to simpler alternatives and incremental improvements.Another group of anonymous developers raised concerns about the deployment of Taproot in Bitcoin and questioned its benefits over simpler alternatives. They discussed Taproot's efficiency, privacy implications, and the wisdom of including multiple features into Bitcoin simultaneously. They proposed an alternate deployment path involving separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. The group also suggested modifications to Taproot's specification, such as allowing the witness type to be either a MAST hash or a Schnorr key, and evaluating delegated scripts using a P2SH-like semantic. They emphasized the importance of considering the actual use cases and probability distributions for Taproot's assumptions.In a recent bitcoin-dev discussion, it was confirmed that Taproot is more private than bare MAST and Schnorr when used separately. When combined with schnorr, Taproot enables various transaction types that represent a majority of spends seen on the blockchain throughout Bitcoin's history, optimizing them for anonymity set inclusion. While there is an overhead to the size of inputs, optimizations can allow for the creation of large anonymity sets. Encouraging script-path spenders to find mutually-agreed contract resolutions can further minimize blockchain use and increase the anonymity set. The discussion also highlighted the prevalence of single-sig, n-of-n, and k-of-n (for small n) transactions, supporting the assumption that Taproot with a key will be more common than script cases.A group of anonymous developers expressed concerns regarding the deployment of Taproot in Bitcoin, advocating for a careful evaluation of its benefits compared to simpler primitives. They proposed an alternative deployment path and modifications to Taproot's specification. Their concerns encompassed efficiency, privacy, and the need for incremental improvements that can work together. The group emphasized the importance of considering their suggestions and engaging in community dialogue.
Updated on: 2023-08-02T01:51:20.884258+00:00