S16 E23: James O'Beirne on CTV, CSFS & Big Blocks

James O'Beirne's cat walked across his screen somewhere around the forty-two-minute mark, right as he was explaining how a bigger block could be validated without everybody needing the whole UTXO set sitting on their laptop. A little later I had to pause the recording to remove my own cat from the room. It was that kind of show, two hours and twenty-five minutes of covenants, block sizes and miner economics, interrupted by pets.

James is a Bitcoin Core contributor and a former Chaincode Labs employee. His current work is OP_VAULT, AssumeUTXO, and pull requests for CTV (OP_CHECKTEMPLATEVERIFY) and CheckSigFromStack. I opened by calling it "one of the most courageous moves someone can do in the Bitcoin space" to push for those upgrades in public, and James went straight to his own numbers: "I've had more lines of code merged in the last six months or so than like many of, you know, I don't know, the people, you know, others would think of as core developers." On the acronym, he said "CSFS is like the hardest acronym to say for some, everybody struggles with it." I had been fumbling it all evening, so I took that as a correction.

"This less efficient paper market"

My first question was why people like us should care about Bitcoin at all if our peers have forgotten what it was for. James said the clock is running: "I think that as more and more elements from traditional finance and government get involved in Bitcoin, it's going to be harder to change." He added that "Bitcoin isn't right now in a state where there's any realistic scaling solution aside from basically custodial services, which defeats the purpose of Bitcoin." His fear is a Bitcoin that decays into "this less efficient paper market for most people."

I asked him whether that is where we are headed, and I brought up Ethereum as the counterexample, since WBTC proves there is demand for DeFi elsewhere. James had a short answer for what Ethereum is: "Ethereum is basically just like a shitty version of AWS that's more expensive because you have to run a proof of work algorithm." On the rollup side he admitted limits to his own knowledge: "I don't really understand the ins and outs of roll-ups." He did say that the people building on those systems seem to him "much more ideologically similar to the kind of people I found in Bitcoin like eight years ago than the people who are chiefly involved with, say, core development at the moment."

When I asked what he made of Citrea, he stayed on first principles: "Bitcoin exists to disintermediate." Projects that bolt a trusted party onto Bitcoin, he said, are "still missing the point of Bitcoin."

MEV, unknown unknowns and the JPEG question

Most of the covenant opposition, as James describes it, comes down to a fear of MEV, miner extractable value. For CTV and CheckSigFromStack he said "those things are pretty well understood by everybody not to have any kind of MEV risk." For anyone worried about a different proposal, his advice was to "make sure you believe the MEV risk is real first."

Then there is the objection that nobody can predict what people will build once a new opcode exists. James turned that around: "So the point is like this unknown unknown situation cuts both ways," and "you want to allow for some amount of innovation that nobody's anticipated." I pushed the other side with OP_CAT, which already runs on Bitcoin Cash and Liquid, so the testing argument has some weight there.

I also asked whether JPEGs belong on the blockchain. "I've never understood really the objection to the JPEGs on the blockchain," James said. His concern is what happens to Bitcoin's budget for securing itself, because empty blocks are a long-term threat: "If we don't have people paying into the miner security budget long term, that's a very troubling situation." He put the mechanism plainly: "if the total security budget of Bitcoin goes down, then it makes the system as a whole easier to attack."

I raised a pushback of my own, that a big pool could simply drop out and wait for the difficulty adjustment. James agreed on the mechanics and not on the conclusion: "mechanically the difficulty would adjust, but if you're not paying for security, then the system isn't really going to be an effective store of value, and that's a huge problem."

His preferred answer is fee smoothing through CTV congestion control. Peter Todd's tail emission proposal is a different matter, which James called "totally beyond the pale." That was the topic of S15 E46 with Peter Todd on covenants, tail emission and OpenTimestamps.

Thousand flowers and a tennis racket

The mempool policy fight came up next. Luke Dashjr's filtering, as James sees it, barely does anything: "The strongest argument you can make that the policy in Bitcoin Core prevents the so-called spam is that it provides a slight impediment to just relaying it by default through the network." He added that "if you want to create a four megabyte transaction, you're gonna do it. You're gonna pair with miners or you're gonna use Slipstream or mempool accelerator or whatever."

His image for the whole exercise was "trying to stop a rainstorm with a tennis racket." He thinks it eats attention that belongs elsewhere: "it feels like a distraction from the bigger questions about where is the protocol going." His preference is to "let a thousand flowers bloom."

I said that from the outside the fight looks like a symptom of a bigger political problem, and I joked that Bitcoin Core is about as political as an organization gets. James agreed that outsiders underestimate that: "You didn't realize that you were walking into one of the most deeply political environments like in existence right now."

Blockstream, small blocks and James's old stance

I asked what happened to the James O'Beirne who was "a pretty outspoken small blocker." The change came gradually. Two of the pushes, in his telling, were Tadge Dryja's talk at OP_NEXT, which he credited with reopening the debate, and Hijacking Bitcoin. "I was prompted somewhat by him, I was prompted somewhat by Hijacking Bitcoin, prompted somewhat by just seeing the sorry state of the scaling conversation, you know, to take a look at block size again."

On Blockstream he said: "you really can't get around the fact that Blockstream kind of existentially was predicated on this idea of small blocks being the only way to go forward." He also said "I don't think anybody at Blockstream, at least to my direct knowledge, set out to start Blockstream with the intent of sort of crippling Bitcoin in this sense or constraining it." My earlier episode with Matthew Haywood was S5 E9 on the Liquid sidechain and his work at Blockstream.

The old argument that blocks have to stay small is, in his view, "kind of the product of fiat money," and the existing hierarchy among developers has the same flavor: "you had this sort of existing trust hierarchy."

How small is small?

I asked how small is small, and where James lands today. His claim is that blocks could grow 10x to 100x with "no material increase in centralization because of existing technologies," meaning compact blocks, AssumeUTXO, weak blocks and Utreexo. Utreexo has a catch he spelled out himself: it "requires everybody to have at least a UTXO." For 32 megabyte blocks he was categorical: "I really don't think you'd see any notable decrease in decentralization at all."

He described the current limit as arbitrary, and he is not interested in defending it for sentimental reasons: "my chief objective is not to preserve some kind of aesthetic engineering design choice that, you know, graybeards came up with whatever 13 years ago." Anyone who thinks the present limit is fine for the next decade is, in his phrase, "taking a bunch of inherited wisdom for granted," and the claim "makes absolutely no sense" to him.

His scenario for why this matters is a regulatory one. If regulated entities in G7 countries were forced onto specific software, "all of a sudden you're going to see this huge demand shock for block space and we're not going to have any kind of an answer for it." And after that, in his words, "that's basically de facto game over, you know, the system's captured."

Later he put a number on what full-scale use might demand: "you need something like 765 megabyte blocks." He also mentioned designs that sit between the usual categories: "there are designs where you can do things that are not quite hard forks, not quite soft forks."

The soft fork window and what other chains already did

James thinks time is short. "The window for interesting soft forks is closing," he said, and the reason he gave is where the coins are going: "BlackRock wants people to own IBIT. They don't want people necessarily to own on-chain Bitcoin." Contrast that with what he sees as an easier political sell: "very rote mechanical changes like a time stamp fix." He also said "I have a lot of skepticism about quantum."

Small, well-scoped proposals, he told me, now face higher barriers than the big packages did. He called Bitcoin "traveling kind of the same path that gold did at this point, in terms of being locked away in warehouses and rehypothecated."

I pressed him on other chains. Litecoin shipped MWEB, Zcash pushed privacy forward, Bitcoin Cash has run big blocks with real money for years. James agreed with the credit: "these other chains deserve so much credit for pioneering this stuff," and he called the work "sowing the prerequisite seeds" for Bitcoin. On inflation bugs in other projects, he wasn't hunting for scandals: "if they have had an inflation bug in the past, nobody can really prove it." He still ranks the priorities clearly: "The most important thing about Bitcoin is preventing inflation and preventing censorship." On my suggestion that people in the Bitcoin world should look at those ideas, he replied "that may be true."

On Bitcoin Cash in particular, James's later line was that "there's a lot to learn from Bitcoin Cash as a project," and "a lot to learn from people who have been actually doing it with real money for a while." I told him my own version of that: Bitcoin people "somehow developed a religion where you're not allowed to look in other places." I later recorded Amaury Séchet on forking Bitcoin twice and Calin Culianu with Steve Thurmond on nine years of Bitcoin Cash, if you want those two perspectives.

OP_VAULT, TXHASH and crazy Uncle Jeremy

The covenant history was the most personal part of the interview. I asked why proposals returned to CTV after all those detours, and James explained that Jeremy Rubin's original design was early: "he was five, six years ahead of his time, if not more." He called him "crazy Uncle Jeremy," which sounded affectionate. Then he turned the lens on himself. OP_VAULT was his attempt to sidestep the controversy around CTV, and he now says that "was kind of a cowardly move on my part." What he realized later was "I didn't know it at the time, but I basically reinvented it poorly," followed by a reaction from someone else along the lines of "dude, this is just CTV."

TXHASH, the competing design, he finds "10x more complicated" and "10x riskier to do than CTV," with "like 30 different bike sheds that people are going to latch onto and debate over for forever." His position now is simple: "I think CTV, CheckSigFromStack are ready now." The bigger Great Script Restoration he considered unlikely, because it is "so big and so sprawling," and nobody is dedicated to carrying it. His description of the Bitcoin scripting community is "the Steely Dan of Bitcoin," which I will leave to musical listeners to decode.

He also had a working patch set at one point: "I had a working patch set for CAT plus CTV plus CheckSigFromStack." In practice, his plan is "making whatever forward progress we can." On Paul Sztorc's drivechains, he said "I would say I'm drivechains agnostic."

The covenant debate also has its own episode here, Andrew Poelstra on OP_CAT versus OP_CTV, and Jeremy Rubin came on later to talk about CTV.

Why a hardware wallet user should care

I asked the practical question: why should a normal hardware wallet user care about CTV? James answered that what CTV does is concrete: "what CTV basically allows you to do is commit to a future graph of transactions." That graph of transactions is how vaults and congestion control get built. He also called the cost modest, since "hashing is a very fast operation." What it could mean for an ordinary holder is "hardware wallet level security from simply having a cell phone and either having some friends or a custodial account."

He did not defend the framing that everybody needs the feature: "just silly that every single user of Bitcoin needs to make use of a proposed feature."

Layer twos were his other warning. On unilateral exits, the scenario is "all of a sudden, I need to exit back into Bitcoin," and the problem is "a kind of no free lunch hidden gotcha about layer twos that we haven't really reckoned with." He sketched a design where you "commit to this one 32-byte CTV hash," and he gave a speed comparison for verification: "something like five minutes of computation" down "to a second."

On Lightning, he said the economics are less favorable than previously assumed: "it's not actually even economical to enforce, to guard against theft of the funds in your channel," and as he put it, "the economics of Lightning are not as rosy-eyed as we thought a few years ago." I noted that Lightning had been "responsible for some of the largest Lightning fees," meaning the user-facing cost of failures, and that the fee market there has teeth. I later recorded Keagan McClelland on Lightning metrics and covenants for the other side of that argument.

"Another stock ticker" and the story of how we got here

Near the two-hour mark we got to the part where I vented. I told James I was disillusioned with the Core maintainers, and Ava Chow came up by name. I said "Seems like we are winning this side of the war, but we're losing our principles and we forget why we got here in the first place." I also asked whether it is more dangerous for Bitcoin to not change at all, and said that "it's more dangerous for Bitcoin to not change and stay this way."

James said "I think we're being bought off," and described what he sees among the people steering development: "technocratic, fairly myopic people." The outcome he fears most is "Bitcoin slowly not changing and just drifting into this state where it's just another stock ticker, which we're dangerously close to." He added that "Bitcoin is just another human system and we have original sin, we're all flawed. Any human system of sufficient size just ultimately kind of crumbles and people lose their way." He compared the cultural substitute to a faith: "a placeholder for religion."

I told him that the concern I hear from fewer and fewer people is the original one: "I don't see a lot of people who are kind of genuinely concerned with like money printer really bad, you know, censorship really bad, fiat order really, really bad." That was how he diagnosed it. Our conversation then turned to the supply cap. James said he would "rather not even think about you know, something like the 21 million supply cap until like we're really in a foxhole." On the 2010 overflow bug, I called a certain stance "the ultimate cope," and James said "it does seem like probably programmer error."

I compared the situation to developers who may go to prison while Richard Heart's case plays out differently. James kept to what he knew: "I'm not privy, of course, to the details of the case." His broader read of enforcement was that "They pick high visibility targets, go after people, and then hope that everybody else falls into line via osmosis."

Never sell, ten years out, and a quick no

I threw "never sell your Bitcoin" at him, since it is half a meme. James called it "a convenient catchphrase for people who want to operate a Bitcoin warehouse where the Bitcoin never leaves." We also went through the ten-year outlook. His answer was that "I think it's going to be a subtle, boring mixture of all of it," and that "Bitcoin isn't going to be a major challenge to the fiat order, but it will at least galvanize an anti-fiat class and sentiment." He added "it's better than Bitcoin not existing."

When I asked whether any serious pushback had come for these ideas, his answer was that "There was no real pushback." On the question of whether Bitcoin should compete with other chains on speed or feature count, he said "Bitcoin shouldn't compete on those terms in some sense." On a different yes-or-no from me he said "No, no, absolutely not." On the theoretical side, his reminder was that "you can build a computer using black and white pebbles if you have enough of them," which was his way of saying Script is not as limited as people claim. About manufacturing, he said "I think we're good at doing things in software. We're not very good at doing things in the physical world anymore, which is a shame."

The last stretch got lighter. Earlier I had told the story of Peter McCormack's Aston Martin, supposedly bought with BlockFi referrals, and James laughed it off as a symptom of a certain era of Bitcoin media. Near the end, when I asked about my own audience's wishlist, he looked back at the cat that had jumped on his desk again. We both agreed that the biggest contribution of 2025 to the industry was still the animals that wander on camera.