Builder: Stu

Language(s): Rust

Contributes To: CTV Prototypes, Char Network

Work(s/ed) At: ZBD

Before Bitcoin, Stu spent his days working as a Windows System Administrator and in IT Support. His routine consisted of long boring days of sitting in a chair engaging in monotonous maintenance work, reconfiguring systems, and resetting passwords for users who’d forgotten them.

It was the kind of job where a problem occurring that actually requires you to engage your attention in a meaningful way is so rare an occurrence that you wind up sitting around hoping for something like that to happen most of the time. 

Stu spent most days just browsing through Reddit threads during his copious amounts of downtime. But this turned out to not be such a bad scenario in the end, as this was how Stu found himself pulled into the Bitcoin space around 2017. 

Like many Bitcoiners, or rather soon-to-be Bitcoiners, back in that period, Stu got sucked into the Initial Coin Offering (ICO) and altcoin frenzy of the time. Also, like many Bitcoiners around that time, he wound up getting burned financially by some bad investments in random unknown projects in which he probably shouldn’t have invested in the first place.

Inevitably the gravity of Bitcoin pulled him down the proverbial rabbit hole. 

After a few years of learning more deeply about Bitcoin, Stu hit a period of frenzy and quit his job at the peak of the 2021 bull market to look for opportunities to work in the Bitcoin space. By that time the programming language Rust had become widely used in different Bitcoin projects and libraries, so Stu began learning it so that he could contribute to Bitcoin. 

Towards the end of 2022, his search for a job in the space ended when he was hired by Michael Tildwell to work at ZBD, a company that integrates bitcoin payments into videogames using the Lightning Network. 

Working At ZBD 

Stu worked DevOps at ZBD, but in his free time he kept working at prototype Rust projects.

“Most of my side projects are related to what I was interested in at the time, as I was working at ZBD I started making games that could use bitcoin,” Stu told Bitcoin Magazine. 

To start, he built a multiplayer web game, rain.run, based around players collecting lightning bolts for rewards in satoshis, to get more familiar with building applications that have to talk to each other over a network. Afterwards he built a simple connect4 game played over the Nostr protocol. 

“[This] was a great way to learn how Nostr worked,” said Stu.

“I attended btc++ in Austin in 2024, which was the Script edition.” The four day conference was the most dense forum for discussion around Bitcoin script improvements and covenants in the last year or so. 

“There seemed to be, at the time, some kind of consensus developing for covenants on Bitcoin,” recalled Stu.

“This got me really interested in how Bitcoin script worked and [led] me to experimenting with Taproot and Bitcoin scripts…” he added.

“I didn’t really end up with much but it was a great way to learn how scripts worked.” 

TABConf, Payment Pools, and CTV

In 2024, Stu attended TABConf, another developer-focused conference, which is held yearly in Atlanta, Georgia. The conversations in Atlanta also revolved heavily around covenants. 

Like all developer-focused conferences, TABConf put on a hackathon. Stu chose to build a project using Discreet Log Contracts (DLCs), which enabled users to bet on the outcome of  chess matches. It became very obvious to Stu that building software around pre-signing large numbers of transactions introduced a lot of complexity for developers. 

Discussing this issue, he said: “The answer to this problem seemed to be CHECKTEMPLATEVERIFY (CTV). As I wanted to learn more about covenants, CTV seemed like a good place to start, so I started integrating CTV into my DLC chess project. I couldn’t believe how simple it made everything…” 

Stu went on to build a proof-of-concept prototype of a Payment Pool using CTV. Payment pools are a very basic layer 2 system where groups of larger than two share control over a single unspent bitcoin output. 

“One way we can scale bitcoin to be used by everyone, without using centralized third parties, is for users to share UTXO’s,” he said when asked why he chose to work on a proof-of-concept for a payment pool. “Payment pools are a great way to do this, especially alongside other layer 2 solutions such as Lightning or Ark.” 

Covenants

Covenants have become a contentious issue in the discussion about where to take Bitcoin going forward. Every developer has their personal opinion on them, and Stu is no exception. 

“I think using covenants to replace pre-signed transactions alone is an amazing improvement for developers to build faster and safer,” he said. “It removes a lot of interactivity and friction for users, so there is less need for them to be online or coordinate with other parties, which can improve the user experience by a great deal.” 

I asked him if this is what drew him to building proof-of-concepts and prototypes using CTV as opposed to other covenant proposals.

“I was drawn to CTV because it was so simple to implement in the applications I wanted to build. Once I built the payment pool with CTV, I was planning on doing the same for all covenant proposals. I figured out how to get the exact same functionality with CAT, but it just took a very long time to get working, and added way more code. The Bitcoin script was like 50 lines of code, compared to CTV with like 3 lines.”

“I’m pretty sure there is consensus between protocol developers that there is no risk to Bitcoin if we enabled CTV…” he said. “…so the argument now seems to be that the users don’t want it. But the users are already using applications and protocols such as Lightning and multisig vaults that would be improved by CTV. So…I think it should be the priority for the next soft fork…”

When asked about the current contentious nature of the discussion around covenants and the next soft fork, and how the atmosphere could be improved, he had this to say:

“Someone needs to get Saylor to tweet a sandwich emoji and everything will be good.”

“But seriously, I don’t really know. Maybe more in person events where people can discuss face to face would help. It doesn’t seem like much of a technical reason that we aren’t making progress, more of a political one,” he went on to say in a more serious tone. 

“I think some of the hesitance is more around making any change at all to Bitcoin. The reason it is so hard to change is an amazing property of Bitcoin, but it doesn’t have to extend to soft forks quite so much. It causes a lot of stress for certain Bitcoin developers, especially Bitcoin Core maintainers. Everyone is waiting on their opinion on the next fork, which seems to make them hesitant on joining in the conversation at all, which makes it hard to get consensus on any new change,” he said. 

The Future

Stu recently participated in the Bitcoin Open Source Software (BOSS) program by Chaincode Labs, a program designed as a way for developers new to the Bitcoin ecosystem to cut their teeth and quickly develop a deeper understanding of and experience with building on Bitcoin. 

Going forward Stu is going to contribute to the Char Network, a somewhat off the radar effort to build a new bitcoin staking platform led by Jeremy Rubin, the developer who designed and proposed CTV. He plans to continue working on his personal side projects and contributing to open source projects as well, with the eventual goal of starting to contribute to Bitcoin Core itself. 

Stu had this to say about Bitcoiners’ priorities going into the future: 

“Our number one focus should be on making self custody better. It really sucks right now, and I think more Bitcoiners in general need to admit that. Backing up 12 words does sound simple, but it really isn’t that easy, and no one is doing it.” 

This is the first article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in depth breakdown. 

CHECKTEMPLATEVERIFY (CTV), put forward by Jeremy Rubin with BIP 119, is the most mature and fully fleshed out covenant proposal, not only out of the proposals we will be covering, but out of all of the covenant proposals in their entirety. As I mentioned in the introduction article to this series, there are many concerns in the ecosystem regarding covenants that are too flexible enabling things that wind up having very detrimental consequences for Bitcoin. 

CTV was designed specifically to constrain its capabilities tightly enough to avoid any of those concerns. To first understand how CTV functions, we need to understand the individual parts of a Bitcoin transaction. 

This is a very high level view of a Bitcoin transaction. It has inputs, or unspent coins (UTXOs), and outputs, the new unspent coins that the transaction will create when it is confirmed in a block. There are a lot more pieces we will go through, but this is the highest level view of a transaction’s structure. 

Every transaction also has a version number field for the whole transaction, indicating applicability of new versions of rules or features. There is also the marker and the flag, which are set to specific values to indicate the transaction uses Segwit. After this is the input count, the number of inputs in the transaction. Then come the actual inputs. 

Each input contains a TXID of the transaction that created the unspent coin being spent, a VOUT which marks what output in that transaction is being spent, the size of the ScriptSig, and the ScriptSig, which is the unlocking script proving the input being spent is authorized by its locking script rules, and finally a Sequence number which is used to ensure the input being spent is following relative timelock rules. i.e. the input has existed for a certain number of blocks or length of time since its creation. 

The output count is the next piece of data, the number of outputs in the transaction. After this comes the actual outputs, which contain an amount of satoshis assigned to that output, the ScriptPubKey size, and the actual ScriptPubKey, which is the locking script for that output. Lastly the nLocktime field applies a timelock value in timestamp or block height that applies to the entire transaction. 

Each Segwit transaction also contains a Witness section, where each input has a corresponding witness containing a Stack Items count, how many things will be put on the script stack, a Size field for each item, and the actual data Item to go on the stack. 

How CTV Works

CTV is an opcode that enables the most basic form of introspection and forward data carrying out of all the covenant proposals. It allows a script to take a pre-defined 32 byte hash and compare that against a hash of most of the fields of the spending transaction. If the hash derived from the actual spending transaction does not match the pre-defined hash, the transaction is invalid. 

The fields it commits to are:

• nVersion
• nLocktime
• Input count
• A hash of all the nSequence fields
• Output count
• A hash of all the outputs
• Input index (the place the input has in the transaction, 1st input, 2nd, etc.)

These are all the fields committed to by the CTV hash, in their entirety, and with no ability to pick and choose. This is the degree of introspection CTV enables, “does the hash of these fields in the spending transaction match the hash in the locking script of the input being spent,” that’s it. The hash commits to essentially the entire transaction except the actual inputs. There is a reason the hash does not include the inputs. In order to lock an output to a 32 byte hash with CTV, you need to know the hash of the transaction that you are ensuring is the only way for it to be spent. The input locked with CTV being spent will have to include this hash in order to be verified against CTV. That necessitates having the hash of that transaction before you create the complete transaction. That is not possible. 

You can also nest CTV scripts, i.e. have an initial CTV script commit to a transaction with outputs that also include CTV scripts. This is what allows CTV to “carry forward” data. All it carries forward in practice though is whatever data is contained in the chain of transactions. You can do this in theory to an infinite depth, but you are limited in practice to a finite depth because the nesting must be generated backwards starting from the end. This is because each level, or “hop,”  must have the hash of the transaction moving to the next one, otherwise you can’t create the locking script in the first place. If you don’t already know the next transaction, you can’t generate the previous one. 

What Is CTV Useful For

CTV allows you to restrict an output so that it can only be spent, according to consensus rules, by an exact pre-defined transaction. Some of you might be asking what the big deal is, we can already pre-sign transactions. If the level of introspection is so limited that it can only accomplish something we can already do just pre-signing, what is the value add? 

First, pre-signed transactions always leave open the possibility of the keyholder(s) signing new transactions and spending those coins in a different way. You have to trust that the keyholder will not do this, or will delete the key needed to sign with (which you also have to trust them on). CTV removes that trust entirely. Once the spending transaction is defined and the output locked to that CTV hash is created, there is no possibility of being spent another way, enforced by consensus. 

Currently the only way around that trust is to be involved in pre-signing transactions yourself using multisig. Then you can be completely certain that unless you choose to sign one yourself, no other valid transaction spending a coin in a different way can be created. The problem is the more people are involved, the more difficult and unreliable coordinating everyone to pre-sign a transaction at the same time becomes. Past small sizes it becomes a totally impractical problem to solve reliably. 

CTV gives a way for people to know a set of transactions is committed without everyone having to get online at the same time to sign them. It greatly simplifies the coordination process by allowing everyone to get the needed information to anyone else whenever they can, and once that person has everyone’s information they can create the chain of CTV transactions without anyone else’s involvement, and everyone can verify and be certain that the correct outcome is the only possible one. 

That is incredibly valuable on its own, but CTV can also enable even more valuable things in combination with other opcodes, which we’ll see in the next article. 

Closing Thoughts

CTV is a tightly restricted covenant that enables a degree of introspection and forward data carrying that is so limited it does not exceed the actual functionality of anything that can be done with pre-signed transactions. The value proposition is not in enabling new functionality in its own right, but drastically improving the efficiency, scalability, and security guarantees of what can be built currently using pre-signed transactions. This alone is a massive benefit to almost every currently deployed protocol using pre-signed transactions.

Here are some of the projects demonstrating how thoroughly fleshed out and explored this particular covenant is compared to the others:

• A basic payment pool example by stutxo. 
• A CTV vault implementation by James O’Beirne, who went on to propose OP_VAULT (which still makes use of CTV). 
• A proof-of-concept port of the pre-signed transaction based Ark implementation from Second by Steven Roose to use CTV instead.
• The Sapio Language by Jeremy Rubin himself, a higher level language for building contracts with CTV (also supporting the use of pre-signed transactions instead). 
• Timeout Trees, a proposal for a very basic coinpool design by John Law.
• Numerous other possible protocols, such as optimized Discreet Log Contracts (DLCs), non-interactive Lightning channels one party could open without the other, and even decentralized ways for miners to pool together. 

CTV is an incredibly mature proposal at this point, with a high value add, and no risk of enabling anything driving the concerns around covenants. This should not only be very seriously considered, but in my personal opinion should have been activated years ago.