Q&A session with Rusty Russell and Julian Moik, co-authors of the Great Script Restoration BIPs. The recording started a few minutes into the session so some of the beginning of the call was cut off. Audio from my mic was also not captured very well so I re-recorded my questions and spliced them in. Enjoy!

Great Script Restoration project links

• BIPs

• Bitcoin Dev mailing list thread
• Restoring Bitcoin’s Full Script Power
• btc++ talk: The Great Script Restoration Project

Questions answered in this Q&A

What is the current status of the project, other than publishing the BIPs?

Are there instructions for people who have a low-powered machine and want to run the benchmarks and report the results back to you?

Do you have any plans for something like a dedicated “GSR-net” testnet that devs can build and deploy apps against using the GSR features?

Should there also be a separate GSR-only testnet so that we can test those changes in isolation?

What would you say is left to do before getting GSR on some testnet?

What are some applications that you are most interested in seeing built or building yourself using GSR?

Would GSR be a new segwit version? Or backport to tapscript with a switch?

How can people contribute to GSR, other than running those benchmarks or looking over the BIP text?

Where do you see the limits of your involvement? Will you work on activation clients?

We have seen how the OP_CAT discussion went, do you expect it to be the same for GSR (which includes OP_CAT)?

Why GSR and not Simplicity?

With the recent debate about bitcoin’s OP_RETURN limit reaching a resolution, attention has recently turned back to the question of soft forking to add covenants to bitcoin.^{1 2} It’s not obvious to everyone why this functionality is worth adding to bitcoin, so I thought it would be helpful to share my reasons for why Bitcoiners should support covenant soft forks.

1. There is good evidence of their utility

There are hundreds of thousands of BTC worth ten of billions of dollars locked in products that use some kind of trusted multisig in place of what could be a trustless covenant.^{3 4}

However despite the very real traction that trusted multisig-backed products have, as a product manager who has helped build products on Rootstock and is currently working on Alpen (a bitcoin rollup), I have spoken to plenty of users who remain on the sidelines due to concerns about counterparty risk in these trusted multisigs. Trustless covenants expand the total addressable market for all products currently relying on trusted multisigs to include these more conservative BTC hodlers who are further down the risk curve.

Furthermore covenants enable concrete improvements to the usability of Ark, DLCs, Lightning, and self-custodial multisigs that will make products built with these tools more accessible and more convenient, expanding their addressable market as well.^{5 6 7 8}

Beyond these more visible examples, we must also consider the extent to which custodial services broadly speaking are serving as a stop-gap alternative to self-custody due to a lack of covenant soft forks. Is someone using a custodian because they want a “password reset” button? That could be implemented using a covenant!⁹ Is someone using a custodian because they want cheap and easy Lightning payments? That could be implemented using a covenant!¹⁰ Is someone using a custodian because they don’t want to reveal their transaction history or wallet balance to everyone they transact with? That could be implemented using a covenant!¹¹

And what about the people who don’t own any BTC at all, because they are worried about both the counterparty risk of custodians and the complexity of self-custody? Covenants could give them a solution that provides the best of both worlds while mitigating the associated risks.

2. The benefits primarily accrue to users

Like any change in bitcoin, developers will be the first to get their hands dirty working with covenants. But covenants are not an exclusively developer-facing improvement the way that, say, a refactored API would be. Yes, developers will be the ones who are primarily writing software to use covenants, and that software will by and large be written for the benefit of everyday bitcoin users.

As described in the previous section, the benefits of covenants for end users include improved security for products that currently rely on trusted multisigs, and improved usability for products built on Ark, DLCs, and Lightning. And who knows, maybe one day the software will get so good and so easy to use that users will be able to safely create their own covenants, similar to what wallets like Liana, Nunchuk, and Rewind offer today.^{12 13 14}

Covenants also enable scalability and privacy improvements that benefit bitcoin users. Covenants enable higher self-custodial throughput, enabling more people to hold and use BTC with minimal counterparty risk, all else being equal.¹⁵ Covenants also enable better self-custodial privacy, including e2e encrypted transactions — the strongest privacy ever invented — using protocols such as Shielded CSV.¹⁶ Whether you are saving BTC for the far future or spending BTC on every day purchases, strong privacy is important to shield your wallet balance, spending graph, and activity pattern from hackers and wrench attackers.

3. Covenants do not introduce any new risks

There have been extensive technical and philosophical discussions and analyses of the risks of enabling various kinds of covenants on bitcoin.^{17 18 19} As far as I can tell, aside from the implementation risks — which exist in any change to bitcoin software, even “non-consensus” changes, and can be mitigated with audits, testing, etc — a covenant soft fork would not introduce any new risks. On the contrary, barring the implementation risk, a covenant soft fork is a strict reduction in risk, by removing the need to trust third parties or key deletion ceremonies when using covenants.

The logic here is simple: covenants can already be emulated on bitcoin. So every bad thing that you can imagine happening with covenants is already possible on bitcoin, only with some added trust assumption. As we know, “trusted third parties are security holes”.²⁰ Ergo, soft forking to eliminate the need for trust when using a covenant is a strict reduction in risk.

Go ahead, do your worst… think of the scariest risk imaginable for covenants.

Yep, that risk exists today!

Now think of another one.

That risk exists too!

Get it?

That is not to say there are no risks — just no new risks. The likelihood of an existing risk (such as some form of mevil becoming a significant source of miner revenue) could increase. Similarly, no one can guarantee that there will be no negative consequences for anyone, ever if we get trustless covenants. This is not only not a guarantee that can be made for any change, it’s not even a guarantee that can be made in the case of no change.

As a hypothetical negative consequence of soft forking for covenants, we can imagine the scaling improvements enabled by covenants leading to induced demand that counterintuitively increases transaction fee rates, pricing out lower-value use-cases from using bitcoin L1, pushing them out to higher layers or alt-chains.²¹ I would consider this outcome “a good problem to have”, which I look forward to worrying about after we get a covenant soft fork

As a hypothetical negative consequence of not soft forking for covenants, we can imagine a future where new holders of “BTC” continue to opt for trusted custodians due to the poor user experience or lack of functionality available when using self-custodial wallets. Eventually, the vast majority of people’s experience of “using bitcoin” will be just as permissioned, and thereby vulnerable to seizure and censorship, as the fiat system bitcoin was designed to replace. Everyone in this hypothetical world who loses access to their “BTC” due to abuse by their custodian can assign some of the blame to a covenant opponent for their loss.

I am not claiming either of these negative outcomes will occur under the given scenarios. I am only pointing out that action and inaction are both decisions that could bear negative consequences.

Closing thoughts

Any cost:benefit analysis of covenant soft forks has to weigh the costs and benefits of both changing and not changing bitcoin, and think through what is both seen and unseen — the first order effects, and the higher order effects.²² Having done the analysis myself and compared notes with other researchers and engineers my conclusion is that covenant soft forks would be overwhelmingly good for bitcoin and nearly every class of stakeholder in the ecosystem, including hodlers, spenders, merchants, miners, and developers.

(Some exceptions I can think of: trusted custodians may be obsoleted and need to find a new way to provide value; and the blockchain surveillance firms will increasingly find their tools ineffective as more transactions are e2e encrypted. Sorry not sorry!)

I support covenant soft forks, and everyone else who wants to see bitcoin continue to improve and grow in usage as p2p electronic cash freedom money should too.²³

Footnotes

1. Bitcoin users can “emulate” covenants today using either a trusted third party or a trusted key-deletion ceremony. When I say “covenants” in this post, know that I am referring to the trustless opcode-enforced variety, unless I explicitly note otherwise. ︎
2. Technically, “We can already do covenants on Bitcoin, now we are simply negotiating the price.” ︎
3. https://www.bitcoinlayers.org ︎
4. https://defillama.com/protocol/babylon-protocol ︎
5. https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602 ︎
6. https://covenants.info/use-cases/dlcs/ ︎
7. https://covenants.info/use-cases/eltoo/
   ︎
8. https://bitcoinops.org/en/topics/vaults/ ︎
9. https://arxiv.org/pdf/2401.11735 ︎
10. https://www.coindesk.com/tech/2023/06/02/solving-lightnings-inbound-liquidity-problem-is-focus-of-new-layer-2-bitcoin-protocol ︎
11. https://gist.github.com/RobinLinus/d036511015caea5a28514259a1bab119 ︎
12. https://wizardsardine.com/liana/ ︎
13. https://nunchuk.io/how-it-works ︎
14. https://rewindbitcoin.com/ ︎
15. https://bitcoinrollups.org/#section-4-scaling-improvements ︎
16. https://eprint.iacr.org/2025/068.pdf ︎
17. https://bitcointalk.org/index.php?topic=278122.0 ︎
18. https://bitcoinrollups.org/#section-6-the-costs-and-risks-of-validity-rollups ︎
19. https://delvingbitcoin.org/t/on-the-possibility-of-evil-covenants-and-implications-for-soft-fork-proposals/1703 ︎
20. https://nakamotoinstitute.org/library/trusted-third-parties/ ︎
21. https://en.wikipedia.org/wiki/Induced_demand ︎
22. https://fs.blog/second-order-thinking/ ︎
23. Preferably following the Roose roadmap ︎

Privacy is the absence of information leakage and that implies it comes from value at rest, not value in motion. And privacy at rest can only be gained in a meaningful way by baking it into L1, not by adding it to higher layers.

He goes on to make a number of arguments to bolster this claim. However, I believe the arguments fall short in important ways, leaving intact my view that shielded L2s can be just as effective at protecting privacy as shielded L1s.

I encourage you to read Braun’s full post for context. I have quoted the parts I found most relevant throughout my responses in this post.

Addressing the problem of fungibility

Braun’s first supporting argument is that, “the less deeply integrated privacy is into L1, the less fungible tokens become.” He elaborates on this point, saying:

In crypto assets like Bitcoin and Ethereum, if a user uses some form of mixer technology in an attempt to increase their privacy this is easily detected by now commonly used chain analysis technology, which makes the coins less fungible. If you don’t believe me, try to pass a source-of-funds screening at a modern “crypto friendly” bank after you moved your entire stash through a mixer. Good luck. A lot of Bitcoin Maxis will have a rude awaking if they want to buy houses when BTC finally hits $1M and they realize that they listened too much to the “privacy experts” on their favorite podcast.

A crypto assets (sic) either has normalized privacy, like in Monero or Zcash, or the tokens are simply not fungible.

Of course, your banker could also complain about you using a privacy coin in the first place, that’s a valid counterargument. However, we have to draw a line in the sand somewhere I still think it’s both better for privacy and on principle to use systems which offer privacy all the time.

What would be more suspicious to you: Somebody using PGP to encrypt their emails (some of the time) or somebody using Signal?

To answer the question about PGP vs Signal, it depends on how often that person is using Signal, doesn’t it? If they use email or SMS most of the time and use Signal only occasionally, that would be “suspicious”. So it would seem to me that it is not the constant availability of encryption in Signal that avoids raising suspicion, but rather it is the constant use of Signal that avoids raising suspicion (assuming that the use of Signal itself is not suspicious, which by now, with it being a relatively mainstream app, is likely the case).

Braun says “we have to draw a line in the sand somewhere” and says it should be drawn at “systems which offer privacy all the time“. But why is this made as an argument against shielded L2s? If someone were to deploy a shielded L2 on bitcoin today, would this L2 not offer privacy “all the time” in the same way that the Orchard pool on Zcash offers privacy “all the time”? This is a rhetorical question. The answer is “yes”, but that’s beside the point: it’s not the frequency or duration of availability that makes a shielded pool conspicuous or not, it is the consistent (and widespread) use of the shielded pool that ensures that it is “normalized”. A shielded pool that is seldom used is irrelevant at best and dangerous at worst (due to the false sense of security it may provide) whether that pool is on L1 or L2. A shielded pool that lots of people often use is powerfully effective, whether that pool is on L1 or L2.

If we want to be able to use a shielded L2 to buy a house with BTC, we need to normalize using a shielded L2, the same way that Zcash users have had to normalize using their shielded pools (vs t-addrs), and Monero users have had to normalize using RingCT (vs using a transparent alternative such as bitcoin). There’s no fundamental difference in the essential nature or difficulty of the task at hand here. A shielded pool does not magically become normalized because it is “baked into L1”. That normalization must be fought for and won over one average everyday user at a time. Cypherpunks know this all too well as e2e encryption has gone from being perceived as the exclusive haven of the four horsemen of the infocalypse to being mainstream technology adopted by hundreds of millions of people around the world.

Addressing the problem of custody

Braun’s second argument is based on “the problem of custody”. He says:

privacy comes from value at rest, not value in motion. And in order to get privacy at rest you need to let your tokens rest. And if they rest in a (somewhat) custodial L2, then long rest periods become a problem, but long rest periods are exactly what you need.

The first problem with this argument is that it assumes that L2s are (somewhat) custodial. Yet Braun acknowledges that Tornado Cash both provides privacy at rest and is non- (or, as I prefer to say, self-) custodial:

The famous Tornado Cash “mixer”, employing zero-knowledge proofs in a smart contract on Ethereum, has some privacy at rest, but is non-custodial in nature (the employed smart contracts have no admin keys).

Interestingly, he acknowledges this and moves on as if it has no further relevance to his argument. But Tornado Cash actually serves as a relevant counterpoint to his argument about custody: Tornado Cash is not “baked into L1”, it is an application-layer addition to Ethereum, much like an L2. And in the time since Tornado Cash was invented, we have seen self-custodial shielded pools deployed on Ethereum that, unlike Tornado Cash, even support internal transfers, same as Zcash shielded pools, with Railgun being the most prominent example. Given their self-custodial nature, according to Braun’s argument, what’s to stop Tornado Cash or Railgun from delivering privacy at scale?

Braun goes on to suggest that users of custodial L2s won’t get sufficient privacy because their funds will not be at rest long enough due to constant switching between custodial L2s:

While I still think that the various ecash designs, like Cashu and Fedimint, hold great potential for fast, cheap, and private payments I now have sincere doubts about their ability to deliver privacy at scale, mainly due to the incompatibility between custody and value at rest: Their custodial nature (federated in the case of Fedimint) requires the user to monitor them continuously and move funds to different mints, if necessary, which is in conflict with the requirement that privacy comes from value at rest.

Setting aside the fact that there can be self-custodial shielded L2s: the quoted paragraph may describe how people use mints today, but I expect that once more “legitimate”, well-established mints emerge that mints will become stickier, in part because anonymity loves company, and also simply because people are creatures of habit and the devil you know is often preferable to the devil you don’t.

In a more mature and stickier shielded L2 ecosystem, I can imagine a usage pattern where users deposit lump sums of funds into a shielded L2 and then gradually spend down their balance over days or weeks at a time, and that there will be enough users who do this that there’s plenty of “cover traffic” to hide who exactly is leaving the shielded L2 at any given time.

This usage pattern matches how people already use custodial bank accounts: money comes in on payday, some of it is automatically moved into a retirement account, and the rest is gradually spent down until the next payday and the cycle starts again. Then if the bank goes bust, the retirement account is fine (it is insured or held somewhere else) and at most only a few weeks of income is at risk (similar to how bitcoin users can keep spending money on L2 and their life savings in a self-custodial wallet on L1). Because of this relatively low risk, despite bank accounts being custodial, people generally don’t switch banks very often, and so most banks have more than enough customers and transaction volume to provide a healthy anonymity set to hide in.

Addressing the problem of compliance

Braun’s final argument concerns the “problem of compliance”. After describing the legal troubles that the developers of Samourai Wallet and Tornado Cash have had, he concludes:

having privacy solutions at higher layers not only poses problems to the necessity for value at rest, but always comes with significant compliance risks, where people regularly go to jail.

The problem with this argument is that these cases do not show that shielded L2s are categorically more legally risky than shielded L1s, or that shielded L1s are categorically impervious to compliance risks! I am not a lawyer, but my reading of these cases is that the legal troubles had more to do with their idiosyncratic operational details than their fundamental nature as “higher layer” privacy solutions.

I could imagine a shielded L2 that is just as decentralized as a shielded L1 with anonymous developers, no premine, permissionless mining, etc. I could also imagine a scenario where developers of a shielded L1 are just as exposed to compliance risks as Samourai Wallet and Tornado Cash due to inflammatory marketing messaging, governance using premined tokens, rampant usage of the system by criminals, etc. It’s not the “layer” that matters, it’s the totality of facts and how the legal system interprets them and finds ways to intervene, if that is even possible.

Long live shielded L2s

We can theorize and debate about shielded L2s on the internet all day but it’s hard to argue with reality. And the reality is that Tornado Cash is still running and providing effective privacy to users to this day, as is Railgun. And there will be more shielded L2s such as Aztec (a rollup on Ethereum) and zkCoins (a Shielded CSV implementation on bitcoin) coming online in the months and years to come. The evidence to support (or disprove) their value will become clear in time.

My own prediction is that at least one shielded L2 will eventually find the combination of features and usability to attract a mainstream audience and do for money what Signal did for messaging, providing a secure and private way to transfer value at scale. But if not, it won’t be because it’s an “L2”.

We covered a lot of ground during the debate. You don’t necessarily have to watch the debate first for this post to make sense, but it might be helpful context, and worth watching in any case if this stuff interests you. Justin also posted some comments on Twitter a few days after the debate that are relevant to the discussion, so also worth a read.

In case anyone skips watching the debate and is ready to get out their pitchforks, I should clarify that my nuanced prediction and position in the debate is that while “true L2” zk rollups on bitcoin could obsolete Ethereum as a platform for money and finance (see my opening statement of the debate for the full argument) I could see Ethereum continuing to exist and specialize in other niches that bitcoin does not and likely never will excel at, such as higher-volume data availability. With that clarification out of the way…

Justin made several claims during the debate that we did not get to discuss in detail, due to limited time. But I believe they are worth further discussion, so I am responding to them here. I welcome further dialogue on these points from Justin or anyone else interested. Let’s dig in!

Using Strata as “a poster child”

Justin says at the beginning of his opening statement that he is “not here to defend Ethereum” but rather “to poke holes in what [I am] trying to build”. He then calls Strata (the bitcoin rollup I contribute to through my work at Alpen Labs) a “poster child” for what I am trying to build and spends much of the debate focused on why Strata won’t work, and why this means that zk rollups on bitcoin won’t make Ethereum obsolete.

I have to mention at the outset here that my argument assumes that bitcoin gets a soft fork to enable “true L2” zk rollups on bitcoin. However even if we are limited to BitVM-based rollups, I do think that bitcoin can become the preferable place for bitcoin DeFi, since a BitVM-based BTC bridge to a zk rollup on bitcoin requires only “1-of-N” assumptions for safety and liveness while bridges to alt-L1s require honest majority assumptions i.e. for the same reason validiums obsolete sidechains, BitVM obsoletes honest majority bridges — it is a stepwise improvement in security at a relatively low additional cost. Will that be enough of an advantage to reach the endgame I discuss in the opening statement I gave in the debate? That I’m less certain of, so I won’t defend that position here.

That said, there are points about Strata that Justin brought up that deserve a response. So I’ll still cover those points, as well as some other points he made that aren’t about Strata specifically.

Optimistic rollups incentivize 51% attacks on bitcoin

It is true that optimistic protocols such as Ark, Lightning, and BitVM create an attack vector for miners to steal from users and this could under certain scenarios incentivize a 51% attack.

(In the case of BitVM2, which Strata uses, stealing from the bridge requires collusion between the hashpower majority and at least one bridge operator from each BitVM2 instance that is being attacked; note that each deposit UTXO is held by a distinct BitVM2 instance. 51% attacks on Ark and Lightning similarly require collusion with a counterparty in those protocols for the attacker to directly profit from the attack.)

Before addressing concerns about this specific attack, I want to point out that miners can already monetize a 51% attack. Justin mentioned that when attacking an optimistic bridge, a miner can open a short to hedge against the BTC they steal becoming worthless in response to the attack. And this is one way miners can profit from a 51% attack today: by shorting bitcoin.

(An aside regarding this element of Justin’s argument: he mentions that there is currently “$40 billion worth of open interest” in bitcoin perps, referencing the Ethena APY dashboard, and uses that figure to infer the profitability of attacking bitcoin. “Open interest” is a measure of the sum of all currently open long and short positions. In contrast “short liquidity” would describe the liquidity on the books available for going short right now. So for a short-attack to work, either we are assuming that a sufficiently-large portion of open interest is already the attacker going short, or we assume the attacker must build their position from today going forward based on existing liquidity on the books and liquidity hitting the books in the near future. The mechanics of each scenario are quite different so I figured it’s worth mentioning this for context.)

A 51% attacker today could open a very large short position and then start mining empty blocks indefinitely — until either honest miners regain control, or the bitcoin community forks the attacker (and every other miner) off the network. In the meanwhile this could cause market panic that wipes out enough of bitcoin’s market cap for the attacker to profit off the short. For this outcome we have to make some assumptions about how large of a short position the miner could build, how much margin they could afford, how much the price of BTC would drop in response to this event, etc. Still, a possible scenario.

While profiting from a 51% attack by shorting the market is a possibility today, getting upside from a 51% in the form of BTC stolen from a BitVM bridge is new, in the context of bitcoin — but not something that hasn’t been discussed before.

As I have written elsewhere, while this attack is often referred to as the “miners can steal” attack, I prefer to refer to it as the “miners will steal” hypothesis, because knowing that the miners can steal is interesting but less interesting than knowing that they actually will steal. As we see with bitcoin today, just because bitcoin miners can 51% attack does not mean they will. We even see that miners don’t 51% attack even when it would be overwhelmingly profitable to do so, not only in the aforementioned empty-block shorting-the-market attack, but even in “miners can steal” scenarios.

While it is unclear exactly why miners have historically abstained from stealing from optimistic bridges, even when there are significant incentives to do so, putting my “evil miner” hat on I can think of several conditions I would want to have satisfied before I conduct such an attack:

• The payoff from the theft or from shorting any assets whose value may be affected by the attack (or both combined) should be large enough to make the attack worth it.
• If I am relying on a short to profit, I must be sufficiently certain that I can build up a sufficiently-sized short position and then cash it out if I reach my target profitability. (Not always guaranteed!)
• If I am relying on a short to hedge my risk, and I am colluding with existing miners, I must be sufficiently certain that the process of organizing the collusion prior to the moment of attack does not leak and therefore cause the attack to be priced-in before I can enter a sufficiently-sized short position.
• If I cannot collude with existing miners, and must build out the mining farms to conduct the attack myself, then the risk-adjusted returns from the attack must outweigh any other use to which I could put my capital over the period of time required to build up the required mining capacity and launch the attack.
• I must be sufficiently protected against legal or extralegal retaliation due to the attack. (Not pinning the defense of bitcoin on physical violence, just pointing this out as a real-world consideration.)

I’m not saying it’s impossible for all of these factors (and others I may be missing here) to align. Just saying — it’s not as simple as someone looking at how much money is locked in optimistic bridges, looking at a chart of available short liquidity, and then concluding that the best thing to do with their scarce time and money is to 51% attack.

And if after all that the attack does happen? Then Bitcoiners admittedly have some hard decisions to make. Bitcoin (and any protocols built on bitcoin that are downstream of the attack) would take a hit. Yet as an antifragile system I believe bitcoin would grow stronger as a result as the community grapples with the new reality and decides on a path forward.

If we get a soft fork to enable “true L2” zk rollups on bitcoin then this attack vector will no longer exist, at least for those rollups whose communities choose to adopt “true L2” zk rollups or validiums.

Bitcoin will fundamentally never achieve EVM equivalence

Regarding Justin’s line of argumentation about native rollups:

Native rollups allow rollups to have an exact copy of the L1 EVM which is secured by the same consensus as L1, which means that by construction they won’t have bugs… There’s no way bitcoin will ever have this.

Let’s assume that bitcoin will never support an EVM precompile, and so will never have native EVM rollups (I agree with Justin that this is a safe assumption). Any updates to EVMs on bitcoin will either have to happen through governance or a new deployment of the latest EVM version. Where Justin and I may disagree is that I don’t think “EVM equivalence” will be a major factor determining whether zk rollups on bitcoin obsolete Ethereum or not. Oftentimes “good enough” is good enough, and I do think that non-native EVM rollups can be “good enough” for most people in the market for an EVM rollup.

(It’s also possible that at some point even the EVM on Ethereum will ossify due to hard fork coordination difficulty or community desire. At this point there will be no need for EVM updates on EVM bitcoin rollups, bringing these rollups and Ethereum to par in this regard.)

Strata will never achieve decentralized sequencing

I can think of several decentralized sequencing models that could work on bitcoin today (though may not necessarily be desirable for some reason)

• Based sequencing
• Proof of work sequencing
• Proof of burn sequencing
• Proof of burn or proof of work could be used to mint a proof of stake asset that is then staked for sequencing rights
• If we accept the 1 of N assumption of BitVM, then something like Babylon BTC staking could be built on Strata, without needing an honest-majority “covenant committee”

Strata will launch with a centralized sequencer because it’s a reasonable place to start: Strata doesn’t rely on the sequencer for safety, and we can even limit the sequencer’s ability to affect liveness for long periods of time. That said, the goal is to decentralize the sequencer and we don’t see any technical barriers to doing so.

Withdrawals from the Strata bridge take multiple weeks

Withdrawals through the Strata bridge only take multiple weeks in the worst-case scenario. In the best-case scenario, users will either ~instantly offramp via some swap service or they can do a withdrawal via the “cooperative path” of the bridge script, neither of which require waiting for the multi-week challenge period to complete.

If we get a soft fork to enable “true L2” zk rollups then withdrawal times could be reduced down to a single bitcoin block confirmation.

Bitcoin isn’t post-quantum secure

All systems that use quantum-vulnerable crypto need to plan for a migration to post-quantum secure crypto. The bitcoin and Strata communities are no less likely to address the quantum threat in time than Ethereum or any other serious project that currently relies on quantum-vulnerable crypto.

Data availability on bitcoin is limited

Justin points out that bitcoin has limited data availability (DA) capacity.

To me it’s a given that as usage grows we will want to increase onchain DA capacity as much as possible while keeping the base layer decentralized, to ensure that as many users as possible can have the highest level of security for their funds. And I have suggested implementing something like EIP-4844 on bitcoin to achieve this.

But even if bitcoin’s DA capacity does not increase, I don’t think bitcoin having 6.66 KB/s compared to Ethereum’s 31 KB/s (or whatever its long-term capacity is) will be the main factor determining whether bitcoin obsoletes Ethereum or not. But it is one factor, which may add up with others. So bitcoin block space will need to be as valuable as possible to remain secure and competitive. Which brings me to…

Strata won’t solve the bitcoin fee problem

The point about DA leads into Justin’s closing argument, which is that because bitcoin has limited DA capacity, most rollups will use alt-DA instead, which will siphon fees to other networks, and not actually help sustain the bitcoin miners:

98.84% of block rewards come from issuance not fees… Bitcoin L2s aren’t going to fix this because the incentive is to use alt-DA… So bitcoin is cooked, because it will become cheaper to attack over time, and because bitcoin is cooked, Strata is also cooked.

As background, and to confirm some of Justin’s premise here, as of the time of writing (Feb 2025) current cost % of transaction volume is around 1%. This means that the average transaction fee will need to 100x in order to equal the current fees + coinbase miner revenue. Given that the current average transaction fee in USD is around 0.92 USD this implies an average transaction fee of 92 USD per transaction to cover the difference once coinbase rewards go to zero in 2140 (or as the coinbase approaches 0 BTC, which happens much sooner than 2140).

Based on contemporary use-cases, across the blockchains that have had sustained fee markets at elevated rates (bitcoin and Ethereum) there appears to be a natural fee ceiling of around $60 per transaction before users either switch to a different chain or stop transacting until the fee rate drops again:

Sources: blockchain.info and etherscan.io

This implies that we will either need to find a new use-case and steady stream of usage that supports >$92 transaction fees or we need to increase transaction capacity and find a steady stream of “lower-value/higher-demand” use-cases to support proportionally lower transaction fees e.g. Shielded CSV enables bitcoin to do up to 100 TPS, or 14x the current 7 TPS, meaning blocks full of shielded CSV txs paying an average tx fee of $6.50 would be enough to cover the current block reward value.

Alternatively, of course, we could accept that the hashrate will drop (all else being equal). As a result, the network will become cheaper to attack, and due to the flood of mining hardware that would hit the market due to mining unprofitability, the network would be even cheaper to attack than it would be were there not a deluge of ASICs hitting the market. Personally I think it’s a worthwhile goal to sustain or even grow the hashrate from where it is today, mainly for security’s sake but also because I have friends who are miners and I would rather they have successful businesses as miners than not.

All that having been said, let’s return to the question: will rollups like Strata result in fee revenue increasing enough to sustain the current hashrate, or will fees remain relatively low due to the usage of alt-DA networks? It’s hard to make a prediction here but as pointed out above, we have empirically seen certain use-cases sustain fees in the neighborhood of $60 per transaction for extended periods of time. And use cases like shielded CSV can reduce the tx fee requirement from there by almost 90% to cover the current block reward value.

Rollups can both increase transaction capacity and support more use-cases, so to me the odds seem pretty good that rollups alone could pick up the slack. Even if most transactions move offchain (and I predict they will) there will still be plenty of users who want maximum security and therefore won’t want to rely on an alt-DA network, and will pay the cost to use onchain DA instead. Additionally, validiums and optimiums still have to pay L1 to settle their batches, and they’ll have plenty of transaction revenue to bid for settlement. On top of all that, these new use-cases will be bidding against all other/existing uses of bitcoin block space, which will further exacerbate fee pressure.

In short, I predict that through a combination of increased transaction capacity and increased usage due to new use-cases, we will be able to sustainably replace coinbase subsidies with transaction fees on the timeline that is necessary to sustain the hashrate into the future, and Strata will play a role in that outcome too.

So, is bitcoin cooked?

Based on my analysis, I give the outcome that bitcoin is cooked a relatively low probability. But why leave it to chance? Let’s enable “true L2” zk rollups on bitcoin, unleash developer creativity, grow self-custodial usage and capacity, and make bitcoin the undisputed base layer of digital money and finance.

Proof of Keys has two primary benefits. First, it reduces complacency among Bitcoiners by getting them in the habit of withdrawing to self-custody. Second, if enough people practice Proof of Keys, then we can reveal whether custodians actually have all of the BTC in custody that are supposed to match customer balances, or if they are secretly insolvent (as too many custodians have been in the past).

The strongest form of self-custody is when you use a wallet app that is backed by your own bitcoin full node. This type of wallet will verify that the BTC that you receive has actually been confirmed in a valid block on the canonical bitcoin blockchain. No trusted third party required! Examples of this type of wallet include Bitcoin Core and Electrum backed by an Electrum Personal Server.

A weaker form of self-custody is using a wallet that relies on a trusted third party to tell you whether or not the BTC that you receive has been confirmed. Examples of this type of wallet include desktop wallets like Electrum and Wasabi, or mobile wallets like Muun and Phoenix. There are many wallet options to choose from depending on how you intend to use your BTC and other preferences you have. Check out bitcoin.org and walletscrutiny.com for more information about picking a good wallet.

In addition to considering which wallet app you want to use, you should also consider how you are going to secure the keys to your wallet. Remember that your keys are used to authorize transfers of your BTC, so it’s important to keep your keys safe from hackers and anyone else who might mishandle them. A hardware wallet can be an easy and secure way to protect your keys. Ledger and Trezor are the most established and widely-supported options, though newer hardware wallets such as the Passport are also worth looking at.

The last big decision to make before you show your Proof of Keys is to decide how you are going to recover your BTC if anything happens to you or your wallet, for example if you get hit by a bus or you lose your wallet in some kind of accident (perhaps a boating accident). There are good options to consider here as well, including “collaborative custody” services such as Casa, Nunchuk, and Unchained, as well as steel backup tools (too many to name — see extensive reviews here). Again, what you choose largely depends on your own circumstances and preferences.

With all the options for a bitcoin self-custody setup, it can feel overwhelming to do Proof of Keys. So here is a quick step by step guide that explains a simple setup that should be secure and easy enough to follow for you to feel comfortable getting started. Taking some form of self-custody is the most important step, then you can optimize your setup from there as you acquire more knowledge, save up more BTC, have a change in life circumstances, or whatever the case may be. Feel free to send me a message if you have any questions about this.

How to do Proof of Keys

Step 1. Buy a hardware wallet. Any of the ones mentioned above will work well enough.

Step 2. Buy one of the steel backup tools with a good rating from the previously mentioned list.

Step 3. Set up the hardware wallet and back up your seed phrase (which is used to generate your keys) using the steel backup tool. Store the steel backup with your other valuables or important documents. Keep in mind that anyone who finds the backup will be able to access your wallet and transfer your BTC, so keep it away from prying eyes.

Step 4. Connect your hardware wallet to one of the wallet apps mentioned above and generate a new bitcoin address. You should be able to click “Confirm address” or something like that to verify the address on your hardware wallet screen, ensuring that the address really was generated by your hardware wallet.

Step 5. On the “Withdraw” section of your bitcoin custodian’s website, copy and paste the bitcoin address that you generated in Step 4 into the withdrawal address field. Click “Confirm” or whatever the button says to complete the withdrawal. After a few minutes (sometimes up to an hour or two later depending on network traffic and your custodian’s withdrawal processes) you should see the BTC appear in your wallet.

If you made it this far, congrats! You have demonstrated Proof of Keys and now have self-custody of your BTC.

Note: You could also follow the steps above, but skip buying a hardware wallet and steel backup, and use your wallet app to generate your keys on your computer and backup the seed phrase by writing it down on a piece of paper instead. Only do this for relatively small amounts of BTC and only if you are certain that your computer doesn’t have any viruses/malware on it.

Additional self-custody resources for further research:

https://btcguide.github.io

https://www.smartcustody.com

https://walletsrecovery.org

Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch! I will never sell, rent, or share your email address.

One question I am often asked is “how does a validity rollup compare to the Lightning Network?” To give a complete answer to this question, I will include comparisons to both validity rollups and validia chains.

Recall that the main difference between a validity rollup and a validia chain is that a validity rollup stores its state data inside the blocks of its parent chain, while a validia chain stores its state data in a data availability system outside of its parent chain. A validia chain can therefore support arbitrarily high transaction throughput, while the throughput of a validity rollup is restricted by the block size limit of its parent chain. However, this “offchain DA” model also means that a validia chain is not as secure as a validity rollup because the transaction data is stored in a less-secure offchain data availability system.

The following diagram provides a simplified visualization of how the data availability model used by validity rollups and validia chains differ. The diagram shows how a validity rollup stores both a validity proof and state data inside of its parent chain’s block (in this case a bitcoin block), while a validia chain will only store a validity proof inside of its parent chain’s block (via validia script state update transaction co-signed by some defined threshold of data custodians) and store the actual state data offchain with the data custodians.

For more information about exactly how validity rollups and validia chains work, see Section 1 and Appendix C in my rollup report, respectively.

User experience and features

Like a validia chain, the Lightning Network also stores its state data outside of its parent chain. The main difference between the Lightning Network and a validia chain is that the Lightning Network uses a state channel architecture whereas a validia chain uses a blockchain architecture. Another way of saying this is that the Lightning Network uses a local state model whereas a validia chain uses a global state model. What this means in practical terms is that in the Lightning Network, only the individual users involved in a transaction need to store and validate the state updates, whereas with a validia chain, all users of the validia chain need to store and validate all state updates.

These architectural differences result in a high level feature comparison that looks like this:

These features result in notable differences between the user experience of the Lightning Network and blockchains such as validity rollups or validia chains. For example, validity rollups and validia chains can be designed to provide users a guarantee that if the transaction they receive is double-spent, then the block producer who includes the double-spend will be penalized, making payments worth less than the penalty economically secure. This enables “trust-minimized zero-confirmation” payments, so users can immediately send and receive funds with low double-spending risk. In contrast, Lightning users must wait at least one onchain confirmation to be able to spend funds that have been pushed to them through a zeroconf channel.

There are also user experience differences when it comes to receiving payments. Lightning users must be online to receive a payment, while users of a validity rollup or validia chain can receive payments to their address even when they are offline. Additionally, Lightning users must monitor their channel balances to ensure they have enough liquidity to receive payments of a given amount and “rebalance” using a Lightning or onchain transaction if needed. In contrast, users are able to receive payments on a validity rollup or validia chain as soon as they generate a wallet address, and there is no inherent limit on the amount of funds they can receive at their address.

Another notable difference is in the different types of transactions that each protocol can support. The Lightning Network is limited to transactions no more expressive than what is possible on the mainchain e.g. p2p payments and discreet log contracts. But with the right verifier contract on the parent chain, validity rollups and validia chains could support any kind of execution environment that could be built on a blockchain: new smart contract languages, strong privacy, next generation scaling protocols — they make any kind of blockchain transaction or protocol imaginable possible, without needing any additional changes to bitcoin consensus rules.

These advantages of validity rollups and validia chains are not without their tradeoffs: as mentioned earlier, the throughput of a validity rollup is limited by the block size limit of its parent chain. And both validity rollups and validia chains require all users to validate the full state of the chain. In contrast, a Lightning node can support extremely high transaction throughput (in the thousands of tps) once a channel is open, and users only have to validate the transaction state of their local channels.

Ownership security

As described in my report, smart contract-based validity rollups are trustless, meaning they introduce no new trust assumptions compared to holding and transacting BTC directly on the mainchain. Users can unilaterally exit a validity rollup at any time, as long as they can get their exit transaction confirmed on the parent chain. However, this trustless security model comes at a cost: every transaction made on the rollup results in some marginal amount of bytes being stored on the parent chain, so the user must pay the prevailing parent chain fee rate to get those bytes confirmed. See my report for estimates on the number of onchain bytes required for different types of validity rollup transactions.

Validia chains and the Lightning Network both trust third parties (TTPs) with the security of funds owned in the system. With validia chains this refers to all funds owned by the user on the validia chain. With the Lightning Network this refers only to funds received by the user from their channel counterparty.

• The Lightning Network is vulnerable to hashpower majority collusion and flood and loot attacks, where the attackers can steal but not freeze the funds owed to their channel counterparties.
• Validia chains are vulnerable to data withholding attacks, where the attackers can freeze but not steal user funds. Refer to my previous post about validia chains for a description of different protocols designed to make this data withholding attack more difficult.

Both the Lightning Network and validia chains enable users to unilaterally exit as long as the protocol has not been attacked and the user can afford the fee necessary to exit. In the case of the Lightning Network, this means that as long as their counterparty hasn’t stolen the funds owed to them, the user can confirm a transaction on the parent chain and get their funds out of the Lightning Network. In the case of a validia chain, this means that as long as the data custodians make the full state data of the chain available to users, the user will be able to create the validity proof and parent chain transaction needed to get their funds out of the validia chain.

Complementary systems

While there may end up being use cases where the Lightning Network can accurately be considered a mutually exclusive alternative to validity rollups and validia chains, it’s also possible that these technologies will end up being used in a complementary rather than competitive way more often than not.

Global-scale payment networks like Visa and Mastercard handle tens of thousands of transactions per second. Even the highest throughput validia chains are unlikely to achieve this level of throughput without a significant risk to security, since all of this transaction data still has to be stored securely in a way that users will be able to access if needed. There remain open technical challenges to supporting private blockchain-based payments at this scale as well.

The Lightning Network is of course by no means perfect. It still has its own security and privacy challenges to solve (when zkPCN?). But by moving transaction data offchain and pushing it to the edges of the network, and routing payments only through specific nodes rather than requiring all nodes to download and verify everything, Lightning offers much better scalability than any blockchain could achieve. All of these different tradeoffs point at the different ways that these protocols can complement each other.

On one hand, the Lightning Network needs block space to open, close, and occasionally rebalance channels. Validity rollups offer a more efficient way to use available block space (relative to transacting directly on the bitcoin mainchain), and validia chains offer a straightforward and significant expansion of block space (with some security tradeoffs). And the ability to create new execution environments on validity rollups and validia chains opens up the possibility of evolving the Lightning Network in ways that can improve the security, privacy, and usability of the network.

On the other hand, validity rollups and validia chains need a trust-minimized way to quickly move funds between chains. We are already seeing the Lightning Network serving this purpose for bitcoin sidechains such as Liquid and Rootstock. Additionally, even the highest throughput examples of these rollups and validia chains won’t be able to reach the levels of scale currently supported by the fiat payment giants, all while remaining secure and decentralized. A payment channel network such as Lightning could be what is needed for these protocols reach global scale.

The Lightning Network, validity rollups, and validia chains complement each other well, playing off of each others’ strengths and weaknesses and giving users a broad range of options in the security/cost/usability tradeoff space.

I appreciate feedback on the proposal, but there is a lot in this note that I think is just flat out not true. Given Preston’s large audience I felt compelled to set the record straight. There’s also more speculative or opinionated statements I disagree with and provide an alternative perspective on. Quotes are from Preston’s note unless stated otherwise.

We don’t need the sound, pegged, money to move fast, we don’t need the money to do smart swoopty things, we just need it to be pegged, immutable, and digitally sailable to actually stop the madness of clown world.

I disagree that this is all we need. Gold is basically a slow rock that just sits there and look what’s happened to its revolutionary potential. Completely neutered. Digitization alone wouldn’t change this. Bitcoin needs to be more than “digital gold” if we do not want it to meet the same fate.

People spend money, no one is going to wait 10 minutes for a block confirmation at the store, so we need fast and secure payments. It took a change to bitcoin called segwit to enable the Lightning Network of today, which is at least a step toward solving that problem.

And storing money in a SPOF address that can be robbed immediately once compromised is just not secure, so we need at least enough programmability to do “smart swoopty things” like decentralize custody and give ourselves a chance to recover if we notice a critical compromise. This implies the op codes needed for multisig and timelocks, ~ all modern multisig uses P2SH or segwit which were soft forks, and modern timelocks were made possible by the CLTV soft fork.

Additional programmability to move bitcoin finance out of custodial tradfi and into p2p markets is also, maybe not needed, but highly desirable, lest we commit the Cardinal Bitcoin Sin of giving up our coins to custodians for the simple goal of liquidity. At a minimum, this again implies multisig, or DLCs which require Schnorr signatures, both enabled by earlier soft forks.

This premature ossification mentality is a privileged position that ignores the years of hard work it’s taken to get the changes into bitcoin that make it what it is today. Would Preston have been so gung-ho ossification 5-10 years ago? If not, why not? Why now?

The premature ossification mentality also ignores the technical need for changes to bitcoin. At the very least, we will need a hard fork before bitcoin runs out of block numbers and completely stops working. Additional maintenance changes will also be needed, and though not all of those changes will be consensus changes, consider the case of the BerkeleyDB bug. This database code wasn’t technically part of the consensus code but the bug still caused a chain split. Bitcoin’s code is going to continue changing out of necessity to prevent issues like this, and general coderot issues.

That said, Drivechain might not be a silver bullet for all of bitcoin’s problems but does have a lot of potential to improve upon existing techniques for programmability, privacy, and scaling. At the very least Drivechain allows devs and users to experiment with potential solutions in a trust minimized environment without having to making any additional changes to bitcoin. This is arguably a change that gets bitcoin closer to a state approaching ossification, since any new features people come up with could be implemented in a drivechain, lessening pressure to implement them on the base layer. This should be something cheered on by those who advocate ossification.

By introducing a whole lot of technical complexity to the base layer

BIP-300 and BIP-301 are not really that technically complex. We’ve done other soft forks (like segwit) that were much more complex, comparatively speaking.

potentially screwing with the incentives

Potentially…? I would prefer a more definitive claim and (logical or demonstrative) proof of this to justify blocking a proposal. Otherwise anyone can go around bandying the phrase “potentially screwing with the incentives” at any proposal and hold it up.

all so we can connect to a bunch of centralized shitcoin projects

This is a supreme misunderstanding of the purpose and functionality of drivechains. Have you read the original pegged sidechains paper? That would be a good place to start. Here’s a relevant quote:

The core observation is that “Bitcoin” the blockchain is conceptually independent from “bitcoin” the asset: if we had technology to support the movement of assets between blockchains, new systems could be developed which users could adopt by simply reusing the existing bitcoin currency.

No “shitcoins” needed.

A. Why the rush!?

Look at the date on this blog post:

https://www.truthcoin.info/blog/drivechain/

It’s been 8 years, Preston. 8 years!

B. Why not just go use Monero

I’m a Bitcoiner. I prefer to store my value and transact in BTC.

C. Why risk the king without deep understanding and testing of the technical risk and potential change to incentives?

afaict the person lacking deep understanding and testing experience is Preston. The first drivechain testnet I’m aware of was launched 4-5 years ago, and the community has been running various test versions ever since. You can run it and review it yourself, the software is available here.

We’ve seen live “real money” tests of the same hashrate escrow incentive model on other chains with tens of thousands of BTC worth of value at stake and the results were positive overall, I would say: https://lightco.in/2022/06/15/miners-can-steal-2/

I for one, have no use for drivechains (that doesn’t mean everyone is like me). And as a result, I will not be updating my node

Sure, run whatever software you want. But just because you personally don’t have a use for drivechains doesn’t mean you need to block other people from using them. I’m sure there are lots of things people do with their BTC today that you have no use for. Would you block them too, if given the chance?

A few weeks ago Eric Wall gave a talk at StarkWare Sessions where he left the audience with an intriguing idea: what if we used the same technique that inscriptions use to embed data in bitcoin to build a sovereign rollup on bitcoin?

This idea of using bitcoin as a data availability layer for sovereign rollups was also hinted at last month by Sovereign Labs in their Sovereign SDK announcement.

What is a sovereign rollup? Referencing Celestia’s conception of the modular blockchain stack, a sovereign rollup is a settlement (and maybe also execution) layer blockchain that uses another blockchain as its consensus and data availability layer.

A sovereign rollup built on bitcoin can have its own execution environment supporting custom logic, while obtaining bitcoin-grade data availability and double-spend resistance. Note however that like a sidechain, and unlike a validity rollup, there is no trustless BTC bridge.

The cost of obtaining bitcoin-grade data availability and double-spend resistance is an upper limit on throughput: a sovereign rollup can only support as many txs per block as it is able to fit into the available space in a bitcoin block (max 4 MB of data).

Validity proofs could still have a role to play in sovereign rollups, but for scaling rather than bridge security: a sovereign rollup could still include validity proofs in its block data, allowing many more transactions to fit into a block than would otherwise be possible.

The idea here is that rollup block producers can still use the same data compression techniques that are possible with validity rollups, such as referring to accounts instead of addresses and only posting state diffs with validity proofs, saving a lot of space onchain. Rollup full nodes would then scan bitcoin blocks looking for transactions that contain block data relevant to them, and if the attached proof validates, then they will add that block to their chain, apply the state diff to the state, and proceed to the next block.

Regardless of whether validity proofs are used or not, the only way to re-org a sovereign rollup block is to re-org the bitcoin block that the sovereign rollup block was confirmed in. That gives sovereign rollups their bitcoin-grade data availability and double-spend resistance.

“But,” you might wonder, “there’s no trustless bridge! What is this sovereign rollup thing good for?” Yep, if you want to use BTC, you still need a trusted bridge to the rollup. The benefit is, once you have that, then the rollup has bitcoin-grade data availability and double-spend security.

With a sovereign rollup built on bitcoin, one rollup confirmation = one bitcoin confirmation. That is a real security improvement over the sidechains of today, which, due to their lower security budget, are much easier than bitcoin to re-org. Also, building a sovereign rollup on bitcoin can provide a nice testing ground for devs and users to get a feel for what a validity rollup on bitcoin would be like. Yeah, there’s no trustless BTC bridge, but everything else (data availability capacity, block time, etc) is ~the same.

At my local BitDevs meetup, someone asked: how is this sovereign rollup technique different than blockchains like Stacks that put a hash of their blocks into bitcoin transactions?

The first difference is that unlike a sovereign rollup, Stacks is able to re-org independently of bitcoin. Worth noting that, unlike bitcoin re-orgs, attempts to re-org Stacks have to be made public from the start. This is described in SIP-001:

Like all single-leader blockchains, the Stacks blockchain allows the existence of multiple blockchain forks. These can arise whenever a leader is selected but does not produce a block, or produces a block that is concurrent with another block. The design of the Stacks blockchain leverages the fact that all attempts to produce a block are known to all leaders in advance in order to detect and mitigate block-withholding attacks, including selfish mining. It does not prevent these attacks, but it makes them easier to detect and offers peers more tools to deal with them than are available in existing systems.

The second difference is data availability. Because Stacks only stores a hash of its blocks in bitcoin transactions, not the full block data, Stacks has different data availability guarantees than bitcoin. We’ll come back to data availability and why it matters later.

There are other protocols that only put a hash of a blockchain into bitcoin transactions and yet do fully inherit bitcoin double-spend security. Commerce Block’s Mainstay is one such protocol:

Mainstay is a protocol that enables the creation of a cryptographic proof that a given system with changing state is unique and that the full history of that state is unique. This proof is generated from a linked sequence of irreversible and provably unique cryptographic commitments made to the Bitcoin blockchain which in turn derives its immutability and global objective state from the Proof-of-Work consensus algorithm. In this way, any independent system with state (and a unique history of state changes) can be proven to be as immutable as the Proof-of-Work blockchain it is secured by. The proof of immutable state (PoIS) generated by the Mainstay protocol is trustless and independently verifiable.

Mainstay differs from sovereign rollups in two key ways. The first difference is Mainstay’s reliance on third parties to maintain forward progress. If the third party fails, then the Mainstay chain will need to hard fork to restart.

An important property of the Mainstay protocol is that it does not require trust in any party, including the entity holding the staychain base private key (xpriv) to confirm that a given sidechain state is immutable. However trust is required in this entity to ensure that the mainstay is persistent, and that the system continues to operate (i.e. commitments continue to be generated). If the key was stolen then an attacker could steal the Bitcoin in the staychain tip output and prevent further confirmations. To remedy this, the sidechain would need to be hard-forked to reset the mainstay (i.e. to commit a new base transaction into the sidechain).

The second difference between Mainstay and sovereign rollups is, as with Stacks, data availability. Like Stacks, a Mainstay chain only puts a hash of its blocks into bitcoin transactions, not the full block data, so Mainstay chains have different DA guarantees.

Bitcoin-grade data availability is perhaps most important for rollups built on top of sovereign rollups. These rollups rely on the data availability guarantees of their parent chain (in this case, the sovereign rollup) so bitcoin-grade data availability is especially valuable.

I am looking forward to seeing any and all experiments that take advantage of this newfound use for bitcoin block space!

According to Matt, this validity sidechain protocol was never given a distinct name by its inventors, so I have decided to call it “Streamchain” as an homage to its origins at Blockstream. Here is a high-level explanation of how Streamchain works:

The streamchain creator generates a streamchain script address on the bitcoin mainchain that is capable of accepting BTC deposits and releasing BTC back to a mainchain address upon the submission of a valid withdrawal transaction. The first deposits to the streamchain script address are then used to build the genesis block of the streamchain, making mainchain full nodes aware of the hash of the streamchain genesis block. The consensus mechanism of a streamchain is Proof of Work-based Nakamoto consensus i.e. streamchain full nodes follow the heaviest valid streamchain that builds on the genesis block.

Users can unilaterally withdraw their BTC back to the mainchain by submitting a withdrawal transaction to the mainchain. This withdrawal transaction will spend coins from the streamchain script on the mainchain to a specified withdrawal address and contain a validity proof that convinces mainchain full nodes that the user owns the amount of coins they want to withdraw in a chain that descends from the genesis block and the user is allowed to make the withdrawal according to the rules of the streamchain.

A problem arises if the streamchain experiences a chain split: users now own “BTC” on two different streamchains! If a user wants to withdraw their BTC from one of the streamchains, how does the mainchain know whether or not to honor the withdrawal? There isn’t enough BTC locked in the streamchain script address on the mainchain to honor withdrawals from both chains. And it’s not enough to say that the withdrawal has to be “part of the heaviest valid chain…” The mainchain doesn’t know which chain is the most difficult chain. To solve this problem, streamchains utilize a withdrawal challenge protocol.

Withdrawals from streamchains are not processed by the mainchain immediately. Instead withdrawal transactions first enter a challenge period, the duration of which is defined by the rules of the streamchain script. During this challenge period, anyone can submit a transaction to the streamchain script address on the mainchain with proof that shows that, for whatever reason, on a heavier valid chain, the user who submitted a pending withdrawal transaction is not actually allowed to make the withdrawal (e.g. the proof could show that the user spent the coins on the heavier valid chain and therefore no longer owns them at the time of the withdrawal). If a successful challenge is submitted, the pending withdrawal transaction is cancelled. If no successful challenge is submitted, then at the end of the challenge period, the withdrawal will be processed.

The implication of the Streamchain protocol design is that the mainchain hashpower majority (“MHM”) can double-spend coins that they previously owned at some earlier point in the streamchain’s history. The attack happens in several steps. To pull off the attack, the MHM must:

Step 1. Deposit some coins into the streamchain.

Step 2. Transfer the coins to other streamchain users in exchange for some irreversible value.

Step 3. Go “back in time” to split the chain right after the coins were first deposited into the streamchain, but before the coins were transferred to other users. At this earlier block height, the MHM still owns all of the coins that they deposited into the streamchain.

Step 4. Submit a withdrawal transaction to the mainchain that spends the amount of coins that the MHM owns on the split chain back to the MHM’s mainchain address(es). The validity proof attached to the withdrawal transaction will convince mainchain full nodes that the coins were owned by the MHM in a valid chain that descended from the genesis block.

Step 5. For the entire duration of the challenge period, censor any and all mainchain transactions that could successfully challenge the double-spent withdrawal transaction from Step 4.

Step 6. When the challenge period ends, the coins will be spent from the streamchain script to the MHM’s withdrawal address(es). Profit!

Under an “honest majority” scenario, a successful challenge transaction could block the MHM’s withdrawal transaction from Step 4 because the MHM is not withdrawing coins they currently own on the heaviest valid chain. However, because the MHM is censoring challenge transactions in Step 5, the withdrawal transaction is considered valid by the mainchain full nodes and at the end of the challenge period the withdrawal is processed and the coins are sent to the MHM’s mainchain address(es), completing the heist.

This attack leverages the MHM’s dominant hashpower to 51% censorship attack the mainchain. Instead of needing to re-organize the streamchain to double-spend coins, the MHM is able to simply go “back in time” to before they spent their coins and then convince the mainchain full nodes to let them withdraw those coins by censoring any proof of double-spending.

A similar kind of attack is possible on state channel protocols such as the Lightning Network as well. In the case of Lightning, the MHM (or someone they collude with) can open channels with a bunch of Lightning users, drain those channels by sending payments through them in exchange for some irreversible value, then at any point in time close the channels using the state prior to sending any payments. Under normal conditions, the channel counterparty or a “watchtower” that the counterparty delegates the task to would see that the state used for the channel closure transaction is out of date and submit a challenge transaction that, if confirmed, would cancel the pending invalid channel closure and seize the current balance of the attacker’s channel as a penalty for the attack. However, the MHM can censor the challenge transaction for the full duration of the challenge period, which once complete will net them the full proceeds of the attack.

Matt points out that the Streamchain security model could be strengthened further by giving the mainchain some kind of way of tracking the difficulty of the streamchain as it progresses, for example by requiring withdrawal transactions to include a “proof of proof of work” that proves what the current weight of the streamchain is as measured in proof of work. Withdrawal validity proofs would then have to prove that not only does the user making the withdrawal own coins in a chain that descends from the streamchain genesis block, but that the coins are owned in a version of the chain that is at least as heavy as the heaviest known streamchain according to prior withdrawals.

With such a countermeasure in place, the MHM would need to re-organize the streamchain from the block that they went back in time to up to the current block, making the attack equivalent to a “traditional” 51% double-spend attack. Depending on the difficulty of mining the streamchain, this attack may not be as difficult as re-organizing the mainchain itself but the attack is still more difficult (maybe to the point of infeasibility) than it would be without proofs of proof of work.

Streamchains offer a security model and flexibility that could be considered for some use cases an improvement over alternatives such as state channels, optimistic rollups, drivechains, softchains, and statechains. Although streamchains are not as secure as validity rollups, their throughput is not limited by the mainchain block size limit in the same way that validity rollups are. Streamchains offer users yet another interesting option in the scalability/security tradeoff space of blockchain protocol design.

My gut answer is “privacy”. Whenever I’m teaching newcoiners, I’m always bothered by how many caveats and instructions are required to teach them how to gain some semblance of privacy when using bitcoin. And even after that, I come away from the conversation both uncertain that the tools recommended will actually protect the newcoiner’s privacy in the long-run, and also quite certain that even if the tools did work, the newcoiner will make a mistake at some point that will un-do the work they had done to protect their privacy up until that point. This is unacceptable and untenable. We need a solution that people can use to store and transfer coins in a self-custodial, p2p manner that offers privacy and ease-of-use as close to physical cash as possible. Bitcoin is too risky and inconvenient for most people to use otherwise.

Then I think, ok, if we somehow solved that, then what’s the next most important problem to solve? And the one after that? And after that? And so on. There will always be some new problem to solve, because human desire and creativity is neverending. And I realize that actually, perhaps the most important problem to solve is giving bitcoin developers the ability to easily solve ~any problem within the domain of electronic cash. I’m calling this “the bitcoin meta-problem”.

Currently, to solve some problem that users have, a bitcoin developer must either work within the limited confines of bitcoin’s existing scripting capabilities, or else propose consensus changes that require buy-in from the majority of miners and economic full nodes. If the developer can’t or doesn’t want to do either of those, then they have to convince the user to move their BTC into some (centralized/federated/collateralized) custodial system, sacrificing to some degree the core value propositions of bitcoin for some new functionality.

What is needed is a solution (a “meta-solution” to the “meta-problem”) that enables a bitcoin developer to build new functionality that solves their users’ problem without requiring the developer to either make consensus changes to bitcoin or convince their users to give up self-custody.

One meta-solution would be to directly add a fully expressive smart contract language to bitcoin, capable of supporting any kind of logic that developers would need to solve any kind of user problem. This is the approach pioneered by Ethereum. Bitcoin developers have so far rejected this approach because of the relatively heavy computational burden that it would place on bitcoin full nodes, and this consensus is unlikely to change. So we need to add one more requirement: the meta-solution can’t impose heavy computational costs on bitcoin full nodes.

Another meta-solution would be to add support for validity rollups to bitcoin. Validity rollups can enable developers to deploy new functionality without having to make consensus changes to bitcoin, convince users to give up self-custody, or put a heavy computational load on bitcoin full nodes. To support any kind of new functionality (new privacy protocols, new smart contracts, etc), bitcoin full nodes only have to verify a single cryptographic proof per rollup block.

Based on my research, I consider validity rollups to be the best meta-solution that has been invented so far. Validity rollups might even be the best meta-solution possible as a protocol that can check all of the relevant boxes: self-custodial (trustless), infinitely extensible, and easy for bitcoin full nodes to verify and stay in sync.

I look forward to seeing what progress we make toward solving the bitcoin meta-problem this year, 14 Anno Satoshi