# Covenant tools softfork

**URL:** <https://delvingbitcoin.org/t/covenant-tools-softfork/98>\
**Category:** Protocol Design\
**Tags:** softfork\
**Created:** [September 28, 2023, 6:33pm UTC](https://delvingbitcoin.org/t/covenant-tools-softfork/98 "2023-09-28T18:33:29Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![jamesob](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/jamesob/32/271_2.png) [@jamesob](https://delvingbitcoin.org/u/jamesob)\
**Post date:** [September 29, 2023, 1:41pm UTC](https://delvingbitcoin.org/t/covenant-tools-softfork/98/4 "2023-09-29T13:41:37Z")

</div>

@ariard writes on GitHub:

> If we can have an end-to-end proof-of-concept implementation of each use-case brought as a justification to the proposed soft-forked opcodes. Otherwise it’s quite impossible to provide a sound technical review of the primitives robustness and trade-offs and state what they enable exactly. And it sounds we’re good to repeat the loop of the last 3 or 4 years of covenants discussions.
> 
> As a reminder, just to take the last example of channel factories, most of the folks who have done _real_ research on the subject still disagree on the security model and fundamental trade-off of the proposed design of channel factories.
> 
> As one of my technical peer challenged on the [mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html) few months ago:
> 
> "So I think that means that part of the “evaluation phase” should involve implementing real systems on top of the proposed change, so that you can demonstrate real value from the change. It’s easy to say that “CTV can enable vaults” or “CTV can make opening a lightning channel non-interactive” – but it’s harder to go from saying something is possible to actually making it happen, so, at least to me, it seems reasonable to be skeptical of people claiming benefits without demonstrating they’re achievable in practice.”
> 
> I’m fully sharing this opinion.

It’s worth noting that two of the major use-cases I mention in the original post have test implementations:

- Vaults
  - `opvault-demo`: [GitHub - jamesob/opvault-demo: An example wallet using OP\_VAULT](https://github.com/jamesob/opvault-demo/)
  - `simple-ctv-vault`: [GitHub - jamesob/simple-ctv-vault: A simple vault structure using OP\_CTV](https://github.com/jamesob/simple-ctv-vault)

- LN-symmetry
  - @instagibbs’ CLN implementation: [GitHub - instagibbs/lightning at eltoo\_support](https://github.com/instagibbs/lightning/tree/eltoo_support)
  - Richard Meyers’ test implementation: [eltoo with Anyprevout and Taproot | Yakshaver.org](https://yakshaver.org/2021/07/26/first.html)

In my opinion, if all this fork did was enable these two use-cases (especially vaults), it would probably be worthwhile. But we know that indeed isn’t the case, and some of the applications e.g. DLC efficiency improvements ([spec](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)), are so straightforward that a demo implementation doesn’t seem prerequisite to seeing the value of CTV as a primitive.

Another more speculative use that has a demo implementation is spacechains ([GitHub - nbd-wtf/simple-ctv-spacechain: a demo of spacechain blind merged mined chains with CTV](https://github.com/nbd-wtf/simple-ctv-spacechain)).

---

_[View the full topic](https://delvingbitcoin.org/t/covenant-tools-softfork/98)._