BIP draft: CISA for Taproot Key Path Spends

The discussion revolves around the complexities and potential challenges of implementing a new feature within Bitcoin transaction protocols proposed by Waxwing. The idea suggests incrementing the marker byte with a group ID to allow parties to remain somewhat independent, yet this method still requires complete agreement on all outputs before any party can sign, making the parties not fully independent in practice. This approach could be technically feasible but raises concerns regarding the necessity and practicability of up-front coordination among parties, which could be cumbersome due to the required communication and holding of state.

Further analysis delves into the limitations of using SINGLE with ANYONECANPAY sighash types, which only cater to transactions involving one input and one output per party. This setup limits scenarios where multiple inputs consolidate into fewer outputs without revealing which input funds which output. Moreover, there are additional costs associated with the explicit sighash bytes, which increase the weight unit per input, thus potentially outweighing the minor savings gained from such arrangements.

An alternative proposition involves utilizing a multi-full-aggregation-group concept, where each participant could manage their aggregation independently. This would lead to significant savings in transaction overhead and complexity. For example, a hypothetical scenario calculates potential savings of approximately 3.4% per participant/group compared to traditional methods. However, despite these technical possibilities, the actual utility and real-world application remain questionable due to inherent constraints and the lack of clear use-cases that justify such complexities.

The conversation also touches on potential risks like fingerprinting issues, which could arise from unique mixing of different aggregation types in a transaction. These concerns have been acknowledged in the Bitcoin Improvement Proposal (BIP), enhancing the documentation for better decision-making. Despite openness to exploring other interesting use-cases for the multi-group-full-agg feature, the preference leans towards maintaining simplicity unless there is a significant interest or demand for more flexibility without a definitive use-case. This dialogue underscores the ongoing efforts to refine and document the rationale behind transaction protocol choices in the Bitcoin developer community.