Why CTV, why now? Was RE: Stumbling into a contentious soft fork activation attempt

Hi Devs,

There's a lot of noise in the other thread and it's hard to parse out what merits a response or not without getting into a messy quagmire, so I figured a separate email with high level points was the best way to respond.

Covenants are an important part of Bitcoin's future, not for "adding use cases" but for making the fundamental pillars underlying Bitcoin more robust. For example, covenants play a central role in privacy, scalability, self custody, and decentralization (as I attempted to show in https://rubin.io/advent21).

Bitcoin researchers have known about covenants conceptually for a long time, but the implications and problems with them led to them being viewed with heavy skepticism and concern for many years.

CTV was an output of my personal "research program" on how to make simple covenant types without undue validation burdens. It is designed to be the simplest and least risky covenant specification you can do that still delivers sufficient flexibility and power to build many useful applications.

CTV has been under development for multiple years and the spec has been essentially unmodified for 2 years (since the BIP was assigned a number).

CTV's specification is highly design specific to being a pre-committed transaction. It'd be difficult to engineer an alternative for what it does in a substantially different way.

CTV composes with potential future upgrades, such as OP_AMOUNT, CAT, CSFS, TLUV. (See https://rubin.io/blog/2021/07/02/covenants/ and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019423.html )

CTV is non-rival (that means "both can happen") with any other upgrade (e.g. APO, TLUV).

During the last 2 years, CTV has been reviewed by a wide range of folks and there have not been (any?) conceptual or concrete NACKs for CTV to have or introduce any risk or vulnerability to Bitcoin.

The main complaints about CTV are that we might come up with something better eventually, a better system of things, or that CTV is not flexible or general enough to make interesting applications, and it would be unfortunate to go through with using up the 32 byte argument version of an OP_NOP and the pains of any soft fork for something that we may eventually know how to do better, replacing CTV.

More general approaches (e.g., based on CAT+CSFS) while more capability powerful, have limitations given large script sizes and difficulty in manipulating transactions and their outputs (e.g., Taproot outs requires some OP_TWEAK as well), and are harder to reason about given higher degrees of malleability.

During the last 2 years, while some other interesting concepts have arisen (such as IIDs or TLUV), nothing in particular has fully overlapped CTV's functionality, the closest being APO and they would both be valuable tools to have independently.

During the last 2 years, no other proposal has reached the level of "technical maturity" as CTV in terms of spec, implementation, testing, tooling (rust miniscript integration, Sapio, python-vaults), and the variety of applications demonstrated possible. As the saying goes, one in the hand is worth two in the bush.

Many current users (not just end users, but businesses and protocol developers as well) see CTV as delivering useful functionality for existing applications despite its limitations (and some of those limitations emerge as strengths). In particular, CTV is helpful for Lightning Network companies to deliver non-custodial channels to more users and generally improving wallet vault custody software.

Applications that are improved/enabled by CTV and not used today, like Payment Pools, deliver strong privacy benefits. Privacy is something that the longer we exist in a worse state, the harder it becomes to improve. This is unlike e.g. scalability or self custody where improvements can be made independent of previous activity. On the other hand, information leaks from records of transactions are forever. There is more benefit from reducing privacy leaks sooner than later. In other words, privacy is a path dependent property not immediately upgradable to whatever current technology provides.

Software Development is also path dependent. Many have remarked that there is not great alternative research on other covenant proposals, but not many application builders or protocol researchers are investing deep time and expertise on producing alternative paths to covenants either. Accepting an upgrade for limited covenants, like CTV, will give rise to many application builders including covenants in their stack (e.g. for batching or vaults or other applications) and will encourage more developers to contribute to generic tooling (Sapio can be improved!) and also to -- via market processes -- determine what other types of covenant would be safe and high value for those already using CTV.

In my advocacy, I published the essay "Roadmap or Load o' Crap" ( https://rubin.io/bitcoin/2021/12/24/advent-27/), which presents a hypothetical path for 'completing' BIP-119 this year and analyzes some possible future work as well as the timeline viability of some alternatives based on my best understandings. In this essay, I say very plainly:

*More “regular contributors” would need to spend time reviewing the code

> and BIP to assure themselves of correctness and safety. Nothing can move
> forward without, no matter the count of casual contributors. Many regular
> contributors don’t want to ‘get political’ and look at forks. Fortunately,
> while all consensus changes are complex, CTV is a very tiny and easy to
> review change in comparison with SegWit or Taproot (more similar to
> CheckLockTimeVerify – a couple hundred lines of consensus code, a couple
> hundred lines of non consensus code, and a couple thousand lines of tests,
> no cryptographic primitives). NOTE: This is a big if! Every contributor has
> the right to review, and ACK or provide a reasoned NACK. Even if everyone
> else is excited about something doesn’t mean there isn’t space for new
> thought-through dissent. At the end of the article, I discuss some concrete
> next steps to ensure more developer review occurs.*

Nowhere have I called for an imminent contentious soft fork attempt. All I am doing is agitating for other developers to perform reviews. I recognize that developers have limited time and individual priorities that may lead them to prefer to spend time on improving Bitcoin in other ways, and I would not call the soft fork process to bear for an upgrade that I did not believe would yield large cross cutting benefits across a multitude of interest areas. I've also plainly described that while "*there could be a UASF for it, since there is strong user demand for CTV, ... I wouldn’t personally lead the charge on that**...*". In no way am I endeavoring to cause the community to take sides.

Lastly, and finally, I would like to close this email with a quote from my Twitter from April '21 https://twitter.com/JeremyRubin/status/1384689155465089025

worth clarifying: I don't give a single fuck if BIP-119 CTV specifically is

> activated or not.

I want the functionality, in whatever form (eg noinput), to fix critical

> gaps in #Bitcoin's armor:

Decentralization.

> Scaling.
> Self Custody.
> Privacy.

let's. fucking. go.

This isn't an ego driven journey about getting in a feature I worked hard on.

I couldn't care less.

This is about finding a pragmatic and low risk path to reinforcing Bitcoin's fundamentals for the coming year.

This is about not resting on our laurels while we see properties critical to Bitcoin erode.

Agree or disagree with CTV as the right next step, but we are all united in wanting Bitcoin to be the best that it can be.

Best,

Jeremy

On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:

> CTV was an output of my personal "research program" on how to make simple
> covenant types without undue validation burdens. It is designed to be the
> simplest and least risky covenant specification you can do that still
> delivers sufficient flexibility and power to build many useful applications.

I believe the new elements opcodes [0] allow simulating CTV on the liquid blockchain (or liquid-testnet [1] if you'd rather use fake money but not use Jeremy's CTV signet). It's very much not as efficient as having a dedicated opcode, of course, but I think the following script template would work:

INSPECTVERSION SHA256INITIALIZE INSPECTLOCKTIME SHA256UPDATEE INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE

PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE

{ for <x> in 0..<numoutputs-1> <x> INSPECTOUTPUTASSET CAT SHA256UPDATE <x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE <x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE <x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT SHA256UPDATE }

SHA256FINALIZE <expectedhash> EQUAL

Provided NUMINPUTS is one, this also means the txid of the spending tx is fixed, I believe (since these are tapoot only opcodes, scriptSig malleability isn't possible); if NUMINPUTS is greater than one, you'd need to limit what other inputs could be used somehow which would be application specific, I think.

I think that might be compatible with confidential assets/values, but I'm not really sure.

I think it should be possible to use a similar approach with CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style signatures on elements/liquid. Though you'd probably want to have the output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256 DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're not signing something that might be misused in a different context later)

Anyway, since liquid isn't congested, and mostly doesn't have lightning channels built on top of it, probably the vaulting application is the only interesting one to build on top on liquid today? There's apparently about $120M worth of BTC and $36M worth of USDT on liquid, which seems like it could justify some vault-related work. And real experience with CTV-like constructs seems like it would be very informative.

Cheers, aj

[0] https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
[1] https://liquidtestnet.com/

I agree this emulation seems sound but also tap out at how the CT stuff works with this type of covenant as well.

Happy hacking!

On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> > CTV was an output of my personal "research program" on how to make simple
> > covenant types without undue validation burdens. It is designed to be the
> > simplest and least risky covenant specification you can do that still
> > delivers sufficient flexibility and power to build many useful
> applications.
>
> I believe the new elements opcodes [0] allow simulating CTV on the liquid
> blockchain (or liquid-testnet [1] if you'd rather use fake money but not
> use Jeremy's CTV signet). It's very much not as efficient as having a
> dedicated opcode, of course, but I think the following script template
> would work:
>
> INSPECTVERSION SHA256INITIALIZE
> INSPECTLOCKTIME SHA256UPDATEE
> INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE
> INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE
>
> PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE
> PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE
>
> { for <x> in 0..<numoutputs-1>
> <x> INSPECTOUTPUTASSET CAT SHA256UPDATE
> <x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT
> SHA256UPDATE
> }
>
> SHA256FINALIZE <expectedhash> EQUAL
>
> Provided NUMINPUTS is one, this also means the txid of the spending tx is
> fixed, I believe (since these are tapoot only opcodes, scriptSig
> malleability isn't possible); if NUMINPUTS is greater than one, you'd
> need to limit what other inputs could be used somehow which would be
> application specific, I think.
>
> I think that might be compatible with confidential assets/values, but
> I'm not really sure.
>
> I think it should be possible to use a similar approach with
> CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style
> signatures on elements/liquid. Though you'd probably want to have the
> output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN
> IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256
> DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're
> not signing something that might be misused in a different context later)
>
>
> Anyway, since liquid isn't congested, and mostly doesn't have lightning
> channels built on top of it, probably the vaulting application is the
> only interesting one to build on top on liquid today? There's apparently
> about $120M worth of BTC and $36M worth of USDT on liquid, which seems
> like it could justify some vault-related work. And real experience with
> CTV-like constructs seems like it would be very informative.
>
> Cheers,
> aj
>
> [0]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> [1] https://liquidtestnet.com/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>