A Taproot-native (re-)bindable transaction bundle proposal

In the recent discussion within the Bitcoin Development Mailing List, Antoine Poinsot highlighted the reluctance of existing production systems to adopt new technological changes, such as taproot, unless there's a substantial reason. This is evident from the continued use of P2PKH addresses despite the potential for significant fee savings through upgrading. The crux of the conversation revolves around the fact that the creation of non-P2TR outputs by these existing systems remains unchanged because they function adequately without the need for immediate upgrades.

The dialogue then shifts focus towards the introduction of new scripting features which are inherently more appealing for fresh code rather than updating existing ones. There's an acknowledgment (ACK) of the proposal for new opcodes to be exclusive to taproot, indicating a forward-looking approach to development within the Bitcoin ecosystem. This perspective underscores a broader willingness within the community to innovate and implement new features in areas where they can be most beneficial—namely, in newly developed code rather than retrofitting old systems.

For further information and insights into this discussion, Peter Todd's insights can be explored through his website.