Covenant tools softfork

@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 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:

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), 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).