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

I know firsthand that a large custodian would make use of CTV to replace presigned transactions specifically for custodial operations.

Beyond that, as you should recall from your VAULT days, CTV (or an equivalent) is a necessary prerequisite to doing any kind of “better” vault. It’s tablestakes. Rob Hamilton recently substantiated the industry demand for good vaults, using VAULT or similar, and once again I can corroborate firsthand there.

So to downplay the demand for vaults is very strange to me. It’s an obvious use that people keep asking for in various forms, and CTV is a required primitive.

The best argument you can make against CTV on this count is that TXHASH’s CTV mode would serve the same purpose, but scrutinizing the TXHASH implementation for validity is probably an order of magnitude harder than for CTV’s given its complexity.

I’m not understanding you here - CTV vaults, and my implementation in particular, allows you to either do a time-delayed spend, or sweep immediately to cold. That much is shown in the first state diagram on the page.

I’m not sure what your basis for saying this is. Aside from the “thundering herd use” potential, congestion control can be used by miners to compress payouts in the coinbase transaction during times of elevated feerates. I spoke to LukeJr about this last night, who runs Ocean Mining, and he said that miners would make use of this - although possibly on the basis of firmware limitations rather than fee smoothing.

The point stands that there are many uses for what’s referred to as “congestion control,” and to dismiss them all casually seems presumptuous.

The “bare legacy” mode for CTV is especially important in these cases because it’s the most succinct first-stage commitment (<32byte-hash> OP_CTV) that can serve to lock in a series of n payments on bitcoin.

1 Like