"Recursive covenant" with CTV and CSFS

The discussion revolves around the notion that on-chain payment for censorship does not pose a greater threat than its off-chain counterpart. This perspective challenges the argument presented in a Bitmex blog post, which emphasizes the need for a trusted oracle to facilitate the release of Discreet Log Contracts (DLC) payments contingent upon the non-mining of a targeted transaction. The counterargument suggests an alternative approach involving funds placed in escrow. Here, miners would submit bolt12 invoices to the oracle, which, in turn, would execute payments once it verifies that blocks are confirmed to a satisfactory degree. This method is considered to have a risk profile comparable to the one described by Bitmex, owing to the inherent trust placed in the oracle.

Moreover, the discussion extends to technical specifics, highlighting that the process entails the use of <signature> <message> <pubkey>, with the public key positioned at the top of the stack, as detailed in Bitcoin Improvement Proposal 348. This technique is not unique to Bitcoin; it finds parallels in Elements' Confidential Signatures for Federated Systems (CSFS) and Bitcoin Cash's CHECKDATASIG feature, suggesting a broader applicability across different blockchain technologies. This exchange underscores the ongoing dialogue among developers regarding the mechanisms of transaction censorship and the role of trust in decentralized systems, reflecting a complex interplay between technical solutions and the governance models they necessitate.