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.”
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.”
