CTV+CSFS: Can we reach consensus on a first step towards covenants?

The discussion revolves around the challenges and limitations present in implementing PTLCs (Point Time-Locked Contracts) more efficiently within the Bitcoin ecosystem, especially when considering the integration with musig2 for 2-of-2 multisignature transactions and general transaction signatures. The efficient implementation of PTLCs would ideally leverage a partially pre-signed musig2 signature for the redeem transaction. This approach would facilitate revealing the PTLC secret to the counterparty upon completing the signature. However, this method encounters a significant hurdle as adaptor signature support for musig2 is not included in the current specification and was notably removed from the secp256k1 library's implementation, as highlighted by a GitHub pull request. Although less efficient alternatives exist, such as using separate adaptor signatures, these too face limitations since plain adaptor signatures for Schnorr signatures are also unavailable in secp256k1.

Furthermore, even the more experimental secp256k1-zkp project does not include support for Schnorr-based adaptor signatures, as indicated by another pull request. While secp256k1-zkp supports ECDSA-based adaptor signatures and those in the older musig scheme preceding musig2, as detailed in secp256k1-zkp documentation and related to BIP-327, it still falls short of providing a complete solution for PTLCs in the context of musig2.

The lack of prioritization for standardizing and refining the cryptographic underpinnings necessary for PTLC support suggests that its adoption might be delayed until there's a wider recognition of its importance. The potential for making the "unhappy path" more efficient exists but would likely only be pursued on a per-peer basis to circumvent the immediate tooling issues without significantly impacting on-chain efficiency. The alternative mechanisms like CAT+CSFS could mitigate some tooling challenges at the expense of increased on-chain space consumption during unhappy paths, utilizing 102 witness bytes for a PTLC reveal compared to 56/67 witness bytes for an HTLC reveal. These script operations facilitate straightforward ECC mathematics for calculating preimages without necessitating secret keys. However, relying solely on CSFS poses additional challenges as it necessitates the use of adaptor signatures to prevent counterparties from selecting alternate R values for signatures, underscoring the broader issue of tooling inadequacies independent of protocol complexities and updates described by other contributors in the field.