Published on: 2022-01-28T16:53:40+00:00
In an email thread on the Bitcoin-dev mailing list, Thibaut Le Guilly responds to Lloyd Fournier regarding the use of CTV in the Discreet Log Contract (DLC) protocol. Thibaut agrees that CTV could simplify the protocol but raises the possibility of using the CHECKSIGFROMSTACK opcode instead. He suggests that this opcode would allow for requiring an oracle signature over the outcome without any special tricks or the need for the oracle to release a nonce in advance. However, he admits that he hasn't thoroughly studied covenant opcodes yet.Jeremy, another participant in the discussion, replies to Thibaut's message. He acknowledges that CSFS might have independent benefits in general but points out that in this specific case, CTV is only being used in the user-generated mapping of Oracle result to Transaction Outcome. Jeremy adds that if Thibaut comes up with something CSFS-based for the Oracles, it would be complimentary to the current usage of CTV.Jonas Nick chimes in by thanking Thibaut for proposing the interesting application of OP_CTV. However, Jonas mentions that this particular use case doesn't necessarily require OP_CTV and can also be achieved through other covenant constructions such as ANYPREVOUT-based covenants. These alternative constructions offer similar benefits. Specifically, the script of the Taproot leaves can be set to CHECKSIGVERIFY CHECKSIGVERIFY, where the creation of signatures has minimal computational cost. The downside of this approach is the additional overhead of 64 witness bytes compared to CTV.Overall, the email thread discusses the potential use of OP_CTV and alternative covenant constructions for DLCs. It explores the advantages and considerations of each approach, highlighting the potential benefits and trade-offs associated with different opcode choices.
Updated on: 2023-08-02T05:26:20.231936+00:00