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

[stevenroose]

Eh, I seem to somehow have missed the second half of AJ’s first response. My bad.

@ajtowns

So much for “I won’t be … pointing fingers”, I guess? In any event, I would personally argue this was a serious flaw in how we deployed taproot, and one that we shouldn’t repeat.

I wasn’t trying to point fingers at whomever was involved in the taproot deployment. More rather trying to indicate that the bar for the taproot soft fork was met on perceived technical merit only, while today it seems that practical usage is the only bar upheld. Is this because people actually don’t see technical merit in CTV and CSFS and hence want convincing by usage, or because we believe purely technical merit is no longer enough for a consensus upgrade?

@ajtowns

If you can’t find even one person willing to spend time on a moonshot project, it’s probably not actually much of a moonshot. Second, is that, reportedly these things only take a few hours, not months.

Arguably CTV so closely resembles presigned transactions yes, one can swap presigned txs to CTV in a few hours, but that is only possible because we have spent the presigned txs project for several months while keeping the potential of swapping to CTV in mind while designing API. This strategy wouldn’t apply for any project that really needs a new primitive to be built.

@ajtowns

Personally, I think the biggest blocker to progress here continues to be CTV’s misguided description of “covenants”, and its misguided and unjustified concern about “recursive covenants”. Particularly given those concerns are incompatible with co-activation of CSFS, I would have thought a simple first step would be updating BIP 119 to remove/correct them

I’m confused. Are you talking about a technical amendment to CTV? Or are you (again, like in your recent mailing list post) whining about the Motivation section of the BIP? Excuse my French, but if your “biggest blocker” in what is trying to be a pragmatic evaluation of a technical change is some wording in a BIP’s motivation section, I can’t help but question whether you are actually trying to constructively participate in this conversation.

@ajtowns

Otherwise, discarding BIP 119 entirely and starting from scratch with an equally expressive and more efficient simplified TXHASH BIP could be a good option.

FWIW, I wouldn’t mind this outcome of course, I implemented TXHASH exactly because it’s a more powerful version of CTV that offers a lot more flexibility. Though when I published the BIP and implementation, I barely received any feedback, so I figured there was not much interest. Given your own remarks on the topic, I suspect you also haven’t read the BIP text yourself.

@AntoineP

Since the receiver crafts the address to request funds on, this means the Liquid watchmen would need to both 1) know the amount before giving away the address and 2) trust that the user will for sure use the exact same amount they said they would in the previous round of communication, or the funds may be locked forever or have the excess burned to fees

It’s true that CTV isn’t suitable for a scheme where you want to present the user with an address that they can deposit any sort of funds into. However, when these transactions are managed by software, I think it’s ok. Liquid could just abandon the “pegin address” concept and have wallets implement pegins internally.

We do the same with Ark: when onboarding you craft an exit tx and send it to the server for cosigning. With CTV you could do away with this round of interaction and since the amount is visible in the tx, you could also re-generate the template hash and recover funds using a mnemonic, which in the current system is impossible because loss of the cosign signature means you can’t recover the exit tx.

(For completion, TXHASH is able to assert that input amount equals output amount, so that would solve this particular problem if you only use a single input. Can’t do input sum amount equals output sum amount unfortunately.)