Alpen Labs and Starknet have announced their partnership to build a unified rollup ecosystem on bitcoin. At the core of the partnership are R&D efforts to make Alpen’s Glock-based, zk-verifier accessible to other protocols. This R&D will be funded by a grant from Starknet’s protocol stewards, the Starknet Foundation, and will see the verifier be released as a public good, enabling any system to integrate with Glock and Strata (Alpen’s bitcoin bridge).

Having followed this space for a little over 3 years now, it feels that this Alpen and Starknet’s announcement has been a long time coming. Walk with me:

12 years ago, Starknet co-creator Eli Ben-Sasson presented on zero-knowledge proofs at a bitcoin conference in San Diego. He described how this emerging technology could help bitcoin scalability and add greater privacy to peer-to-peer payments. He was one of the first people to present research on this design space.

9 years on, Trey Del Bonis penned the first blog post on how a ZK rollup on bitcoin might be designed. A few months after this blog was released, John Light released the research report “Validity Rollups on Bitcoin” that was partially sponsored by StarkWare, the creators of Starknet. It was the first research report covering how validity rollups might improve bitcoin’s transaction throughput, create more expressive execution layers, and improve privacy. Both Light and Trey now work at Alpen Labs.

At the heart of this partnership are individuals who have long been advocating for the use of zero-knowledge proofs to improve bitcoin’s use as peer-to-peer money. Some for over a decade. It’s exciting to see this subculture come into bitcoin’s mainstream and bring novel protocols into production.

Still, there is nuance when we talk about “ZK on bitcoin”. Many people compare it to ZK systems being leveraged in other ecosystems. This comparison is unfortunate for two reasons. One, it undermines the efforts of researchers and developers who are trying to achieve what was once thought to be impossible. And two, it doesn’t fully articulate the trust assumptions and tradeoffs that these systems make to achieve their goal of verifying zero-knowledge proofs.

To cut through the noise, I sat down with Alpen Labs’ Technical Product Manager and bitcoin rollups pioneer, John Light, to discuss the recent Starknet partnership, unified rollup ecosystems, and if ZK is, in fact, the best way to scale bitcoin.

I’ve edited the transcript down for brevity and readability. Assume any errors are my own. — Janusz

Interview with Light

Janusz: A little over a year ago, I remember you gave a talk on this idea of interoperable rollups and execution layers. So I’m looking at this partnership and it makes me wonder, is this the ultimate goal? To build a network of interoperable execution layers that share a single bitcoin bridge?

Light: Well, I kind of gave the game away in that talk. It was certainly very forward looking, but we have had this vision for how our platform would evolve over time. In some ways this partnership with the Starknet Foundation is a big step forward towards realizing that vision. The plan is for them to be one of the first, if not the first, execution domain to run alongside Alpen on top of Strata (Strata is Alpen’s bitcoin bridge). Once you go from one to two, there’s a clear path to going from two to three, three to four, four to n, and you eventually have a world where a virtually unlimited number of execution domains can plug into this shared verifier. This gives different execution layers access to trust-minimized BTC without having to deploy a different verifier for all of these different execution domains on bitcoin Layer 1.

So I think we’re going to see a world where there are different heterogeneous execution domains plugged into bitcoin. These layers will benefit from trustless interoperability, potentially fast preconfirmations for transfers between them, and I think that’s going to ultimately result in a better UX than the fragmented alternative. The fragmented alternative being a world where everybody has to maintain their own verifier, bridge, and so forth. In that world, if you want to do transfers between layers, you either have to do atomic swaps or go through the very slow process of transferring funds on the base layer. The vision is to build an interoperable world of execution layers, not a fragmented one. The Starknet Foundation partnership definitely contributes to that.

Janusz: I mean this is definitely the endgame. The partnership mentions “Glock” specifically as a shared verifier, to enable the bridge. I assume it’s a type of “optimistic-ZK verifier” that we can do on bitcoin today. What’s the difference between Glock and the BitVM family of protocols that started this wave of ZK verification?

Light: I would consider BitVM and Glock to be two different techniques for achieving the same kind of trust model - this 1-of-N trust assumption. In BitVM, you’re doing this bisection game where you want to find the specific computation you know somebody did incorrectly and basically force them to equivocate. And that’s a game where the data is posted onchain and is where the game is actually played out. In the early iterations of BitVM, this required many rounds of interactivity. With BitVM2, the goal was getting this down to two or three rounds of interactivity so that anybody could be the challenger. We (teams from the BitVM alliance) have proven there is a way to do this and there are working implementations of BitVM2 on testnet today. We have one running on testnet right now.

But, the amount of data that you have to put onchain for the assertion and disprove transactions is very high. It ends up costing a lot in bitcoin terms, and that directly correlates to the amount of stake that each of the operators has to put up to be a part of the operator set. The stake has to cover the cost of running the challenge game. The high cost of putting all this data onchain ends up bloating the cost of the protocol overall.

The high costs affect the economic efficiency of the bridge and that inefficiency is eventually passed down to the user. So Glock, which is short for garbled locks, improves this by moving most of the data offchain. It uses garbled circuits to create this new primitive that we call “conditional disclosure of secrets”. In this model, if one of the participating parties lies about something, they disclose a secret (the secret being their private key).

It’s a very different way of achieving the 1-of-N trust model. The BitVM family of protocols and the Glock family of protocols descend into two different rabbit holes. Engineers can go down both and then make a decision on what to optimize for a given use case.

Janusz: My understanding is Glock is using a novel proving system to support this garbled circuits mechanism. Could you quickly highlight the reason for doing so?

Light: The thing that was interesting to us about using this novel DV Pari SNARK, instead of Groth16, was that it results in much less data that needs to be communicated, and stored, by operators and watchtowers; like orders of magnitude difference. We were concerned that without some pretty hardcore optimization, or additional breakthroughs to Groth16, that the setup process for operators would take months. You might even have to ship out specific hard drives that are capable of just dealing with the amount of data that had to be communicated and stored as a part of this protocol.

This isn’t impossible, but we wanted to make this more practical and have it to where someone could run the software on consumer hardware or a standard cloud setup. But, there’s been a lot of optimizations from the BitVM alliance as well around Groth16 which may make it more practical.

Janusz: I want to pivot a bit with our remaining time here. Three years ago, you released the Validity Rollups on Bitcoin paper. It was the first official write up on how rollups on bitcoin might work. Looking back on it, how has the journey been since writing the paper?

Light: It’s definitely been quite a journey, for sure. One of the big breakthroughs was Casey Rodarmor releasing the witness envelope technique as a part of the Ordinals protocol. Following that release, rollup developers figured out that these envelopes would actually be useful for building rollups and using bitcoin as a data availability layer.

That wasn’t obvious immediately. But it worked, and people were able to build what’s known as a sovereign rollups on bitcoin. Sovereign rollups are rollups without verifiable bridges.

It became more of a phenomenon as more people figured it out. Eric Wall was one of the first to present on the possibility of using bitcoin block space for sovereign rollups. Then, the Sovereign SDK was perhaps the first team to ship a proof-of-concept. Rollkit from Celestia built their own demo around the same time.

I think it quickly snowballed from there. For the first time, a large group of people were talking about building rollups on bitcoin. The obvious question then became “how do we get BTC onto the rollup”? For a period of time there, we were stuck in the pre-BitVM paradigm where you had to settle for an honest-majority multisig. It was the best we could do.

Then the BitVM paper dropped and changed everything. Suddenly we moved on from honest-majority multisigs, with at best some proof-of-stake baked in, to working on bridges that really had this 1-of-N trust assumption. From there, BitVM has accelerated from the concepts laid out in original paper to an entire family of protocols. As mentioned, we also have the new Glock family of protocols and there’s other implementations, such as BitVMX and BitSNARK, that were inspired by BitVM. Most people are now focusing on gabled circuits and it’s seen as the state-of-the-art for what’s possible on bitcoin right now.

Teams are working to improve all the things we mentioned earlier; economic efficiency, interactivity, the amount of data being communicated offchain and being put onchain, etc. Now, we’re pretty confident that we can get these costs down to a small amount of data; basically some proof data, and maybe a counterproof, onchain. With the latest optimizations, this is a relatively small amount of data and is practical for production use.

But, this is still a federation, right? We haven’t moved on from the “federation paradigm” for bitcoin bridges. Now, it’s certainly a significant improvement compared to an honest-majority multisig. Users only have to trust a single member of the federation. However, there’s clearly a next step that has yet to be realized, which I discussed in my paper, which is actually getting rid of the federation. We should look to build a trustless and permissionless verifier that people can directly interact with through bitcoin Script.

That’s going to require a soft fork. This conclusion has not changed. Currently the script size to verify a validity proof is too big to fit in a single bitcoin block. So a soft fork is still on the to-do list, but a lot of the other components are ready and it’s great to see teams building rollups within the restrictions that bitcoin has in place today.

That’s what people are excited about. People are pushing forward with improving the state-of-the-art because there are real improvements here. But ultimately, I think we should build rollups to ensure they have all the things we love about bitcoin; bitcoin native, permissionlessness, trustlessness, decentralization, and censorship resistance.

Why should we give up these properties just because we’re on an L2?

Janusz: The closing question I have is why should bitcoiners continue to follow the developments of rollups? What would you say to people who are reading this to motivate them to read the original paper and follow the development of Alpen and others?

Light: The benefits are nuanced. Rollups certainly improve the trust assumption regarding federated bridges for the average user.

You go from having to trust an honest-majority to only having to trust a single member of the federation to get your bitcoin out of the system. That’s a big improvement in my opinion since we have seen federations where multiple nodes have been knocked out. Raising the bar to fully compromise the system is a huge breakthrough.

And if you’re an operator, you have unilateral exit capabilities because you are 1 of the N federation members. So for operators, who are used to operating in bitcoin bridges where they need cooperation from other parties to get their funds out of the system, it drastically improves the trust model. I think that’s a big deal for them. Especially when you’re talking about operators who want to put a significant amount of bitcoin into the system. This assumption nearly eliminates their counter-party risk.

Beyond the trust model, there’s so much potential to build new execution domains that add new capabilities for bitcoin that we don’t see directly on the layer 1. Whether that’s bitcoin-like side systems with additional opcodes, or execution environments that are quite different from bitcoin (e.g. privacy systems or expressive smart contract layers), it’s going to be really cool to experiment with bitcoin the asset. This experimentation gives us a peek into the future of what it could be like if we had softforks that enabled trustless verification directly on bitcoin. I hope we don’t hold ourselves, and bitcoin, back from realizing the full potential here. There’s going to be glimmers and hints of what’s to come and developers are really going to push the limits over the next few years.

Based on what I’m seeing now, it’s really something that we should all look forward to. It’s exciting and I’m looking forward to seeing what the future holds.

Good afternoon Insiders. Today, admittedly, I’m double dipping. I’ve been thinking a lot about rollups and their supporting architectures since the start of the OP_RETURN war. So today’s post further expands on a tweet I previously wrote about Citrea’s state transition function.

In case you forgot (you didn’t, but just in case), bitcoin twitter sent Citrea through the wringer due to their impending use of OP_RETURN for their BitVM challenge transaction. It was the genesis of the Core versus Knots war. Everyone was up in arms about arbitrary data being posted to bitcoin. Some complained and suggested Citrea just use Liquid and others accused bitcoin core of “pathing the way for bitcoin rollups”.

Through all of this, it became clear to me that people, from both sides of the aisle, had misconceptions about how Citrea works. So, I decided to review their node implementation and state transition function. Buckle up, we’ve got a few things to cover.

Rollups

Rollups are alternative blockchains that apply their state transition function over data that is posted to bitcoin and made available by bitcoin full nodes. This means they use bitcoin for data availability. Rollups do this so they do not have to bootstrap their own consensus set. Anyone who runs a bitcoin full node can run a rollup full node, query bitcoin blocks, find transactions relevant to the rollup, and derive the entire state of the rollup, from genesis, to come to settlement with other rollup nodes.

Wars have been long fought over defining rollups from the lens of the bridge or the rollup itself. There are two camps. One says you should solely define a rollup based on which data availability layer it uses; for example, a rollup that uses bitcoin for data availability would be a “bitcoin rollup”. The other side says you should additionally classify rollups through the lens of the bridge. That’s why you hear the terms “zk rollup” or “optimistic rollup”. People are adding an additional word to distinguish the rollup based on the bridge that users socially view as the canonical one.

Bitcoin has further confused everyone with teams’ claims that bitcoin rollups are “optimistic zk rollups” even though they’re really neither of these things. Rollups are rollups. Bitcoin rollups are bitcoin rollups.

Why does the distinction matter? When you view rollups as a system that “verifies its state on bitcoin”, you’re led to believe that bitcoin is enforcing the logic of another system. This is not the case. The logic of the alternative system is enforced by its full node set which effectively makes rollups alternative blockchains.

Bitcoin does not enforce state transitions related to rollup systems. Bitcoin is incapable of doing this and is completely unaware of the rollup’s state. To bitcoin, the data that the rollup posts to bitcoin is arbitrary data that needs to be interpreted by another set of nodes and software.

Bitcoin does not enforce rollup state transitions and rollups do not inherit bitcoin’s double spend resistance. For rollups, bitcoin is the data availability layer that sees rollup nodes to derive their state from bitcoin and gives rollup nodes an ability to enforce finality based on the data posted to bitcoin.

When I created the first community site dedicated to bitcoin rollups (now offline), I looked at rollups through the lens of the bridge… which was wrong.

So we’re using this blog as a summary of my past writing to describe, again, how bitcoin rollups actually work using Citrea as an example.

Looking at Citrea’s state transition function

We’re going to break down a previous tweet I wrote on Citrea’s state transition function to show how the rollup comes to “settlement”. Settlement is when the rollup nodes agree on the proposed state transition from the rollup operator and finalize a state update. Additional commentary is italicized.

Citrea is a bitcoin rollup. This means that it uses bitcoin for data availability. It is live on testnet and is approaching mainnet.

To advance Citrea's state, like any blockchain, a state transition function is applied over the network's previous state to generate a new state. This is how it works in Citrea:

A state transition function is a set of logic that rollup full nodes apply over a set of proposed transactions. This means they execute the transactions. If the proposed transactions are valid, then all full nodes will additionally be able to execute them and finalize the state update for the rollup.

Citrea's users submit transactions to a sequencer - an offchain node that is responsible for preemptively ordering transactions and submitting them to bitcoin on behalf of users.

A sequencer is an enshrined node that is responsible for ordering transactions for the rollup network and submitting the transactions as a “compressed batch” to bitcoin. The order of the transactions is not finalized until it is posted to bitcoin. Citrea full nodes consider the transactions “preconfirmed” before they are posted to bitcoin.

As the sequencer constructs these L2 "blocks" offchain, Citrea's full nodes need to agree on the state that the sequencer is proposing. To do this, they connect to the sequencer directly, offchain, receive blocks, and execute/apply the state transition function over the transactions. This means they execute all of the proposed transactions that have been sent to the sequencer. After all of the nodes do this, a new state root is generated.

Periodically, the sequencer posts a commitment transaction with the latest generated state root. This commitment transaction attesting to the most recent state in Citrea, highlighting the differences in the previous state and new state. Full nodes additionally watch bitcoin to ensure that the commitment transaction, in fact, matches the most recent state they generated locally.

After Citrea full nodes verify that the state root in the sequencer commitment matches the one that they generated locally, they consider the state confirmed. This enables the rollup full nodes to come to “settlement”. For new nodes, it enables them to derive the entire history of the rollup from genesis.

The Citrea prover watches these commitments and computes the state differences between each commitment. If valid, it posts proofs of execution to bitcoin. After these proofs are posted, the rollup is considered final from the view of light clients (i.e. bridges). Citrea full nodes are also able to detect any errors in proof submission.

After the proof is submitted to bitcoin, Citrea full nodes view the state as “proven”. The state cannot be reversed at this point.

If the sequencer commitment, or proof submission, was invalid, the network would halt. Additionally, the prover cannot generate an "invalid proof" per se, so any light clients would not finalize as a result. So if the sequencer posted "malicious" data, the network would freeze (as would corresponding bridges).

This means that the sequencer does not enforce settlement/finality of transactions. A sequencer that posts an invalid batch of transactions would halt the system. The rollup nodes, who drive the finalization of the network, would not be able to execute invalid transactions. This means that the sequencer cannot force the rollup nodes to come to settlement on a state update they do not agree to.

Citrea full nodes do not need to keep a full history of this state as the data required to construct the state of Citrea is made available by bitcoin. After the commitments match the locally state generated, Citrea nodes discard the data. If a node went offline, they could sync their node directly from the data made available by bitcoin.

Rollup nodes do not need to keep a full record of the network state as the data is made available by bitcoin full nodes. If a rollup node went offline, they would catch up to the rollup network’s state based on data made available by bitcoin.

And by anchoring its state to bitcoin through SNARKs, Citrea is also able to provide a mechanism to convince bridge programs of the state of the rollup. Thus, finalizing them and giving them the ability to execute withdrawals based on the most recent state of Citrea.

This is the bridge part. Notice that it has nothing to do with rollup settlement and finality! The bridge is an external program that is convinced of the state of the rollup to process user withdrawals. It is a bitcoin contract that needs to be convinced of an argument to execute withdrawals. Remember, bitcoin cannot enforce the rollup state. So the bridge does not enforce the finality of the rollup system. Rollup nodes hold all the power!

Sounds complicated… Why build this?

It might sound complicated, but rollups are actually very simple. Look at it this way - there’s node software that dictates the rules that transactions need to abide by. If the proposed state contains valid transactions, then the full nodes can compute a new state by executing them. That’s it! It’s really how any blockchain works.

Still, bitcoin is really limited in throughput. It doesn’t make much sense, at a high level, to try and cram a bunch of rollup transactions into bitcoin blocks. Why do this?

Bitcoin is the “forever chain”

If you believe bitcoin is the forever chain, meaning that people will always run bitcoin full nodes and be able to make bitcoin transaction data available to other users, including rollup users, then it might make sense to post your systems data there for security reasons 🤷

This is useful for rollups who want to have an extremely strong (some say too strong) guarantee that their data will indeed be made available as long as bitcoin is running.

Rollups can build really good bridges

Okay… now, while bridges don’t directly enforce finality for rollups, rollups can build really good bridge protocols. People want improved bridge protocols so they can move funds into another system for more expressive applications. A lot of developers want to build these applications. Rollups look to satisfy this demand by offering the “best” sidesystem bridge protocol with the least amount of trust assumptions.

But how do they provide this? Let’s break it down:

Not reliant on the economic security of another system

If a rollup posts data to another system, and is therefore a rollup to that system, then we’re reliant on that system’s validators/full nodes to make the data available to rollup nodes to advance the rollup state. If there’s a lot of economic activity on this rollup, and subsequent value locked in its corresponding bitcoin bridges, the data availability layer may want a piece of that! The attack vector here is that the data availability layer withholds the data and doesn’t make it available to rollup full nodes. Without the data, the rollup would effectively halt and the data availability layer could hold the rollup at ransom.

If you post the data to bitcoin, this attack vector is invalid. That’s why bitcoin rollups are considered more secure than rollups to other chains from the lens of a bitcoin user.

Yes, I know you can socially hard fork the alternative DA layer and slash the malicious validators tokens if they did this. But you cannot deny it is an additional trust assumption and would cause quite the headache!

Light clients!

Bridge programs on bitcoin need to be aware of the current blockheight and blockhash, of a given sidesysten, to facilitate withdrawals. This is where a light client, a small program that tracks the blockheight and blockhash but not the full contents of blocks, is useful. A light client is responsible for relaying the latest blockheight and blockhash to a smart contract.

Bitcoin script is not expressive enough to execute a light client in an onchain smart contract. This is why we use BitVM - to execute a bitcoin light client that attests to the current state of the rollup. Because rollups post their transaction data to bitcoin, they only need to execute a bitcoin light client in their BitVM instance. This light client also attests to the sidesytem state root for that given bitcoin blockheight.

If the BitVM bridge is for another system, it must also execute light clients for the other chains. For example, if the BitVM bridge was between a sidechain and bitcoin, then the bridge must also execute a sidechain light client. This light client would follow the sidechain fork with the most economic weight behind it and view it as the “correct” chain.

Sidechain validators could be malicious! If a majority of validators created a private fork that attested to a malicious state that would see the bridge drained, then the BitVM challenge game would be invalidated. This is because the sidechain light client, in this instance, thinks that the malicious state is correct, as the malicious fork has the most economic security behind it.

This sees the bridge rely on a honest majority assumption from that systems’ validators, or a federation, to provide an honest attestation for the alternative chain’s latest state.

Because of this, rollups can build bridges that have fewer trust assumptions than sidechains.

One day… self-proposed exits

I don’t know how this would work on bitcoin, but theoretically, a rollup user could bypass the system's enshrined sequencer node and go directly to a bridge operator to facilitate a withdrawal. As long as 1 bridge operator is willing to work with the user, then the user can exit this system. Teams will argue (rightly) that this enables a users to bypass the rollup operator(s) and rely on the trust assumptions on the bridge alone if they wanted to get their money out. Citrea has designed this.

But… rollups can have many bridges!

Just because a rollup can have a more secure sidesystem bridge from BitVM doesn’t mean it’s going to be the only bridge! There’s no reason that a rollup can’t simply use a federation for its bridge program. It kind of defeats the whole reason to build a rollup, but you could still do it.

Al fin

That’s it! Rollups on bitcoin can be the most trust-minimized sidesystem. They are sovereign systems that use bitcoin for data availability. This enables the rollup full nodes to come to settlement without having to bootstrap their own consensus set, and it lets them build really good bridges if they want to use bitcoin, the asset, on their system.

Of course, this is all theoretical. In practice, bridges and other supporting infrastructure will have their own trust assumptions so a lot of the security assumptions for a user are asset specific. It’s important to analyze these trust assumptions in isolation of the rollup.

If you think anything I said here is wrong, @ me on twitter. This is a hill I’m willing to die on :)

–Janusz

There’s two conflicting camps in bitcoin scaling at the moment. One camp is insistent on taking technologies from other ecosystems and applying them to bitcoin. Examples of this include projects building rollups and EVM-compatible sidechains. The other camp is looking to build out what I call bitcoin-native protocols – systems that maintain compatibility with bitcoin UTXOs and enable users to unilaterally exit a protocol with pre-signed bitcoin transactions. Examples of this include Arkade and Spark.

Regardless of which camp you’re in, it’s worth reiterating that these systems don’t natively integrate with each other. For example, a user of a Spark wallet can not directly pay a user of an Arkade wallet. The systems are independent in their design and have different methods for coordinating offchain transactions.

To solve this, teams have consciously designed these systems to communicate with the broader bitcoin ecosystem. All systems coming to market are integrating with Lightning Gateways that connect their protocol to the Lightning Network. The idea of “Lightning as a connective tissue” has been touted by some as the logical path forward for the bitcoin layer 2 systems. Others, myself included at times, have called it cope.

The connective tissue notion argues that Lightning, while a self-custodial bitcoin L2, will trend towards institutional usage. The user complexity of managing channels has seen users opt for different solutions, but these new solutions will still be able to communicate with Lightning so that bitcoin has a universally accepted messaging layer and settlement system.

Not going to lie, at first, I thought this idea was bullshit. But as I’ve followed bitcoin L2 developments over the last 18 months, I can’t deny that all protocols coming to market, especially those that are truly bitcoin adjacent (meaning, no shitcoins), are leveraging integrations with the Lightning Network to ensure they can communicate with different protocols.

The connective tissue case was strongly made in Riga

This evidence was on full display in Riga last week. Ark Labs took Baltic Honeybadger by storm with their announcement that every payment that a user made at the event was facilitated by Arkade on the back end. Conference goers paid for goods and services with Lightning, and Lightning compatible, wallets (niftynei can confirm). But on the back end, merchants received Arkade VTXOs. These VTXOs are claims on Bitcoin L1 UTXOs that settle periodically with the help of the Arkade operator. How this worked:

To start the transaction process, the Arkade merchant gives Boltz a payment hash of the preimage. Using this hash, Boltz creates an invoice on their Lightning node that eventually gets sent to the paying user’s wallet. Let’s say it’s a Fedi wallet.

When a Fedi user scans the invoice, they take the invoice to their Fedimint Gateway. The Fedi user then locks up Ecash that will be spendable by the Gateway only after the gateway pays the invoice and receives the preimage as their proof of payment. Since the gateway charges a fee for this service, they’re incentivized to initiate the lightning payment. Boltz receives this payment “attempt”.

After receiving this attempt, Boltz, the Lightning Gateway for the Merchant, creates a VTXO contract, on Arkade, that is locked to the same hash that was provided by the Arkade merchant at the start of the transaction. The Arkade merchant then claims the VTXOs by revealing the hash preimage. Boltz uses this same preimage to claim the Lightning payment, and then the preimage is passed to the Fedimint gateway which uses the preimage to unlock and claim the Ecash from the payee.

The transaction is finalized.

A preimage is used as a “proof-of-payment” in the Lightning Network. After they’re generated by the recipient, only hashes of the preimage are initially given to payees. Payees then create contracts that basically state “I paid you this much if you can reveal the full preimage for this hash”. After the receiver reveals the preimage to the payee, the payment finalizes as the preimage satisfies the contract initiated by the payee.

After receiving VTXOs, merchants trust that the Arkade operator will collaborate with them to settle their newly received VTXOs into a new Ark round. Merchants no longer need to manage channels and inbound liquidity, but they must participate in a Batch Output transaction, with the Arkade operator, to settle the transactions and have unilateral, and irreversable, custody of their funds.

As mentioned in their Twitter thread, this doesn’t mean the merchants are operating Lightning infrastructure directly. It means that they operate a system that enables users of Lightning, Spark, Arkade, and even Ecash wallets to pay the merchant through service providers that communicate with each other over the Lightning Network. Any user of a Bitcoin second layer that interfaces with Lightning can transact with any other bitcoin second layer, since the protocols can execute swaps through Lightning, seamlessly handling inter-network exchange.

This arguably simplifies running a bitcoin point-of-sale system since merchants won’t need to care what network they’re users are on and vice versa.

This use case isn’t restricted to merchant payments. Also in Riga, two bitcoin developers engaged in an Ecash to Arkade transaction. Ecash notes can not be transferred to Arkade users directly. Swap providers, on both sides of the payment, execute the transfer across the Lightning Network.

In Riga, the Fedimint user initiated the payment request to their counterparty by swapping locally minted Ecash with the Fedimint Gateway. On the Arkade side, the user received a VTXO that was swapped to them via Boltz who generated the invoice, and received the payment, on the Lightning side. This payment was executed just like our example outlined above.

Users in this scenario don’t need to have channels open with each other directly. They don’t even need to be on the same network. Instead, they used systems that are able to communicate with a “bridge” protocol: the Lightning Network.

New bitcoin layers further confirm this trend

This trend is not isolated to events in Riga. It’s been gaining steam for months.

A few weeks ago, bitcoin Twitter was engulfed with Wallet of Satoshi’s Spark announcement. Wallet of Satoshi is building a payments wallet built on top of Spark, Lightspark’s implementation of a Statechain protocol. Instead of opening a channel with a counterparty, users deposit funds into a 2-2 multisig with the Spark Operator.

Having a central party, the Spark Operators, coordinate transfers across a network improves the user experience. Shortly put, the trust assumptions of a statechain are superior to custodial solutions but are greater than that of self-custodial Lightning. Plenty of users are willing to take on a stronger trust assumption related to the operator for an improved user experience. The reason can is because the Spark developers ensured that their network deployed Lightning Gateways from launch that accept Spark vUTXOs in exchange for paying Lightning invoices.

Wallet of Satoshi is not, literally, a “Lightning wallet”. It is a Spark wallet that can engage in Spark transfers. Users can use Spark transfers to engage with Lightning gateways that swap Spark vUTXOs for Lightning liquidity. Yes, Wallet of Satoshi users would’ve been able to pay for goods in Riga to merchants using the Arkade protocol. All through Lightning swaps.

“What’s most impressive? It’s completely invisible from the wallet experience. Users won't even notice Spark powering their wallet, and that’s exactly how we think infrastructure should be.” — Lightspark

Not competitive, but rather, an evolution

These developments aren’t competitive with the Lightning network. They’re an evolution of the network, from a purely peer-to-peer payments system, to additionally being a communication layer between various bitcoin-adjacent protocols.

Users will leverage different Bitcoin layers for different reasons. They might prefer distributing funds across various Ecash mints and leveraging multi-nut payments. Others might enjoy using Spark wallets as they have to deal with the complexity of managing channels and can receive payments directly on Spark without making a bitcoin transaction. Merchants may prefer to receive L2 payments over Arkade as it that them bitcoin finality without the need to manage channels.

Whatever the use case, it’s very clear that users of Cashu mints, Fedimints, statechains, ark protocols, sidechains, rollups, and more, will all be able to interoperate through the Lightning Network. Headlines will rightfully claim that this is a win for newly developed networks like Arkade. We should also maintain that bitcoin’s OG Layer 2, Lightning, is providing a platform that seamlessly facilitates instant, global commerce.

The connective tissue meme is playing out in real time. Enjoy it. It’s beautiful.

Want to see the different types of Layer 2 networks that are coming to market and integrating with Lightning? Bitcoin++ is hosting its Scaling Edition in September. Topics will range from new Layer 2 systems coming to market and the infrastructure supporting them. Tickets are onsale now. Use code INSIDER before August 21st to get 21% off your ticket.

Grab your ticket

As BitVM-based bridges near production use, I’ve started thinking about a topic known as “emergency upgrade” paths. With the help of the Citrea team, I was able to work through different ways to validate a BitVM bridge’s spending paths to determine if it has an emergency upgrade mechanism. This blog is an attempt to discuss how upcoming projects might implement these spend paths. Please note that emergency upgrade paths, and the multisigs that spend them, are not a “BitVM feature”. They’re a mechanism that are widely used in bridges secured by proving systems, and I believe they will be leveraged within BitVM-based bridge constructions. This post is exploratory and hopefully sparks a discussion on how we should disclose these types of spend paths.

Ever been in a jam where you need to withdraw money from your account instantly? Maybe your car broke down and you need to pay a mechanic. Or, maybe you found out your friend had a few too many cocktails and needs to get bailed out of jail.

Well, BitVM-based bridges probably want the same guarantees. We want bridge operators to be bound by the rules of the specific BitVM set up. But what if something went wrong? What if there was an exploit in the system that could see an attacker take all of the money with no recourse or cause funds to be permanently frozen?

If an honest actor finds a bug, they’d likely want a way to move all the money out of the bridge contract before an exploit occurs.

We achieve this with emergency multisigs – an additional spending path that can be implemented in BitVM-based bridges to enable a set of signers, or a single signer, to spend the funds out of a given bridge instance and bypass the challenge game and optimistic reimbursement mechanism entirely.

BitVM is a new technology and its corresponding bridge programs are nascent implementations. Some teams don’t want to ship these new bridge constructions without guardrails in place. Early partners who operate the bridge, and supply liquidity, may also want an emergency off switch that ensures their funds can be moved if a bug arises. Immutability doesn’t align with business incentives 100% of the time.

Emergency upgrade multisigs might already exist in live BitVM bridge implementations. More bridge constructions are coming to market and they’re likely going to launch with security councils – a permissioned group of signers that operate an emergency multisig. If the security model in these systems ultimately falls back to a permissioned M-of-N multisig (albeit a temporary one), users have a right to know.

I’ve spent the last two weeks diving into how these security councils might be set up and have thought through ways to validate their existence (with the help of some BitVM alliance members, of course).

The exercise raised an interesting “problem”. We can’t verify the spending paths, onchain, until they are spent. Meaning, some users may never even know that a permissioned M-of-N multisig is the ultimate trust assumption in a BitVM-based bridge if its participants never disclose it.

BitVM Bridges refresher

BitVM is a way to perform arbitrary computation on bitcoin pioneered by Robin Linus. It sparked a new wave of bitcoin development, and a number of teams are using this technique to build layer 2 bridge contracts. These contracts enable layer 2s to have multiple operators escrow bitcoin that backs wrapped bitcoin assets on the layer 2. But, most crucially, it additionally enables an optimistic fraud detection mechanism that can be used to dispute any malicious (or incorrect) withdrawal attempts from a bridge operator.

In the set up phase, a group of signers come together in an N-of-N multisig to presign the transaction graph for a given bridge. If someone deletes their key used in the pre-signing ceremony, then the UTXOs locked in the bridge contracts can only be spent by the pre-defined spending scripts.

In some designs, operators must front liquidity and then request a reimbursement from the bridge contract. The spending paths restrict the spending paths to the operators themselves after a certain period of time passes. Other designs enable users to work with honest operators who give them the private key needed to spend the funds out of the bridge.

In either design, an honest operator is required to process a withdrawal. If they are dishonest, for example, they attest to a withdrawal that conflicts with a sidesystem's latest state, then they can be challenged by a watchtower.

A watchtower is an entity, or person, that runs the BitVM verifier software and is able to challenge, and stop, fraudulent withdrawal requests from BitVM bridge operators.

An example of an incorrect withdrawal could be an operator withdrawing more bitcoin from the BitVM instance than they’re supposed to. This is why payouts from the bridge contract include a timelock. It enables a watchtower ample time to submit a challenge. The window of time between the withdrawal transaction being broadcasted and the timelock is known as a challenge window.

Operators (or users) should only be able to withdraw funds from the bridge after a challenge window has passed. In BitVM-based bridges, theft requires all operators and watchtowers to collude to rug the bridge. If 1 party is honest, regularly checks the chain, and their verifier is online and willing to submit a challenge, the funds cannot be stolen. This 1-of-N trust assumption is desirable because it means we trust less people than a standard federation where a dishonest majority can steal the funds.

The example above creates a more trust-minimized bridge set up than what’s currently on bitcoin today. But in practice, the core trust assumption will likely fall back to a permissioned multisig (albeit temporarily).

An introduction to emergency multisigs

As pointed out in the intro, teams can (and will) include an emergency spending path in their BitVM instances. Whether they should, or shouldn’t, isn’t really important. It’s more important to simply acknowledge that nearly all in-production BitVM-based bridges will include an emergency spend mechanism in their infancy. We should expect that teams properly disclose the nature of these emergency spend paths.

Emergency multisigs are not a feature of BitVM. They’re widely used in bridges secured by proving systems as a way to upgrade systems if a bug is found. Rollups in other ecosystems have set a precedent for deploying emergency multisigs.

BitVM bridges use v1 SegWit scripts to create, and pre-sign, the spending paths for their bridge contracts. Taproot Scripts use MAST to enable a variety of spend conditions for a single UTXO. When a leaf script is used to spend a UTXO, only the individual leaf script, that was used to spend the locked funds, is revealed.

The BitVM2 paper correctly states that pre-signed transactions can restrict an operator to only withdraw funds in a way that can be challenged. But, there’s nothing stopping the developers of a particular instance to include additional spending paths, that can withdraw funds from the bridge, in the Taproot tree.

Each spending path for a Taproot tree is called a “leaf” script. To unlock and spend the UTXO, only one of the valid leafs needs to be revealed.

Let’s look at an example: the first path, or leaf, is the standard withdrawal path with a challenge window. The other path is an emergency spending path that can bypass the challenge window.

Leaf A: the 1-of-N fraud proof, protected spend condition

OP_PUSHBYTES_2 <SomeDelay>
OP_CSV
OP_DROP
OP_PUSHBYTES_32 <OperatorPubKey>
OP_CHECKSIG

Leaf B: a 2 of 3 emergency peg-out spend condition

OP_PUSHBYTES_32 <pubkey1>
OP_CHECKSIG
OP_PUSHBYTES_32 <pubkey2>
OP_CHECKSIGADD
OP_PUSHBYTES_32 <pubkey3>
OP_CHECKSIGADD
OP_PUSHNUM_2
OP_NUMEQUAL

Leaf A is a normal withdrawal reimbursement in a BitVM instance. After a challenge period (<SomeDelay>) passes, a pre-defined operator can redeem the money from the bridge contract. If the operator who spends a UTXO locked in the bridge contract is dishonest, a watchtower can challenge them during the challenge window (<SomeDelay>, the time in between a BitVM contract spend and the expiration of the timelock) and prevent the dishonest withdrawal request.

Leaf A represents a pre-signed transaction constructed by the N-N pre-signing committee.

Leaf B, on the other hand, is an immediate spend path where a 2/3 multisig can immediately spend all of the funds in the BitVM contract. They can do this if the team detects an unexploited bug in the contract, or they decide to run off with all the money.

When I say “contract”, I’m referring to the BitVM contract that governs the spending conditions for a bitcoin UTXO.

Both of these spending paths can exist in a bridge’s Taptree. While it’s not necessarily desirable to have spending paths that bypass the BitVM challenge-response game, there’s no reason they couldn’t be implemented.

Still, the spending conditions within these trees can be quite flexible. In our example, we only display two spending conditions. However, teams can create trees that contain spending conditions with various types of logic. For example, an emergency that can result in user funds being stolen, can have no delay and be spent by a small 2-of-3 signer set. Whereas a broader protocol upgrade can be initiated by a 9-of-12 security council and be bound by a timelock.

Independent of the specific design, as they’ll vary across implementations, it’s important that we can verify the various spending conditions. An “issue” with modern bitcoin scripts is that you can’t publicly validate the script until it is spent. Strictly related to BitVM-based bridges, this means that we cannot verify the spending paths until a specific leaf is used to spend a UTXO. Remember, when a leaf is spent, the spending conditions of that leaf alone is revealed. So if we only have an instance where normal withdrawals are executed, we cannot verify if an emergency spend path exists and vice versa.

This can raise an issue. If the team inserted an emergency spend mechanism into the Taptree, but never disclosed it, users can never be sure that there isn’t a permissioned multisig, or one person, that can spend all the money locked in the bridge.

After mulling on this for a week or so, I’ve thought of some ways a team can disclose a bridge’s spend paths.

Disclosure methods

Simply disclose the spend paths in the docs

The simplest way to go about this is for teams to publish the various privileged roles in their docs. A team would simply publish who the bridge operators are, who participated in the pre-signing ceremony, who runs the light client(s), and who the watchtowers are.

Some disclosure is better than none, but we can’t verify the spending paths for the bridge based on statements in documentation sites alone. Being able to directly verify the scripts is more desirable.

Test transactions prior to deposits

Teams can, of course, spend test transactions for the various spending paths from the bridge addresses. They can spend some funds in a given instance, eventually reveal all the spend paths, and users can verify the spending paths themselves.

This requires teams to spend every leaf in the Taptree. But even with test transactions, we can never be sure that a team didn’t insert an additional spending condition that was never spent and revealed. Teams can always opt to not spend a specific leaf and not reveal the spending condition. This is typically a feature of Taproot MAST, but in the context of bridges, it can lessen users’ confidence that teams are in-fact revealing the entirety of the spending script.

Unfortunately, test transactions don’t provide the level of transparency we’re expecting as we trust the teams to test every valid spend path.

Leverage large covenant emulation committees

Another path forward is that teams leverage a substantially large covenant emulation committee, and give independent parties the opportunity to participate in pre-signing all of the transactions within the bridge's transaction graph. This would give independent parties the ability to verify the existence of emergency multisigs and how many signers are present within them.

But, this still requires users to trust the covenant committee’s participants rather than verify the scripts themselves. I’d still argue there is a path forward where we can give any user the opportunity to verify the bridge’s spend paths.

Create a standardized disclosure method

In my opinion, we should expect teams to publish the entire tapscript MAST that was created for the BitVM instance.

If teams provide the internal pubkey that created the tapscript, the entire set of script leaves, and the corresponding bridge addresses, we can do some magic.

With this information, we can take the internal pubkey that was used to generate the spending paths, and the merkle root derived from the Taptree, and add them together to produce a tweaked public key. If the tweaked public key matches that of the BitVM bridge addresses, then we’ve verified that the script is in fact the sole spending script.

Voila! We have a verifiable, disclosure method. If a team publishes an incorrect tapscript MAST, then the tweaked public key wouldn’t match that of the bridge addresses.

This disclosure method gives us a way to actually verify the key trust assumptions related to a BitVM bride instance. But it requires the teams to publish the entire tree and associated internal pubkey.

Importance for transparency

Even if we don’t disclose the signers’ identities, we still need the scripts to understand what the actual trust assumptions are. These systems are built to have 1-of-N trust assumptions. But if the trust assumption ultimately falls to a permissioned multisig, those who are depositing funds into these contracts have a right to know.

I expect most BitVM-based bridges to include this type of spend path. I hope that emergency multisig spend paths aren’t in place forever and we can upgrade to more trust-minimized designs. But, we can’t hand wave away emergency multisigs and say they aren’t the sole trust model.

The emergency spend path is quite literally the trust model as long as it’s in place.

— Janusz

During the craze of Paper Bitcoin Summer, the Bitcoin Conference released talks from the open source stage at Las Vegas. The talks covered a number of topics from new L2s to consensus changes, but one thing caught my eye in particular.

Transaction protocols that enable near-perfect privacy.

Shielded CSV (and its sister protocol zkCoins) is a payment protocol that can be built on top of any blockchain. But, its developers are focusing on leveraging it for scalable, fully private bitcoin payments. It leverages zero-knowledge proofs and only embeds a small amount of data on bitcoin. Basically - it’s a way to do Zcash-style payments that scales well.

Personally, I think it’s one of the most exciting things happening in the bitcoin layers space. Its sister protocol with a similar architecture, zkCoins, might have a reckless mainnet this year. These protocols combine scalability, privacy, and all the ZK magic that can help bitcoin scale with limited interactivity…

In my world, people are constantly discussing “new L2s”, their capabilities, and why we should change bitcoin to make them better. Unfortunately, systems like Shielded CSV and zkCoins are rarely brought up.

So this post is my attempt to explain its design and make more people aware of the construction…

This blog is based on reviews of both Shielded CSV and zkCoins. For this blog, I’m primarily referring to Shielded CSV. It’s my understanding that they are very similar, and if I swapped “zkCoins” for “Shielded CSV”, most of the blog would still hold. Also note, any implementation of what’s laid out here might use a different name in the future.

Shielded CSV’s design philosophy

Shielded CSV is a token transfer protocol. Really, you can think of it as another Layer 1 transaction protocol that is built on top of a data availability layer. This is similar to how bitcoin’s transaction execution layer is built on top of bitcoin’s blockchain and consensus engine.

It operates under a simple principle – only post a minimal amount of data to the blockchain to prevent double-spending. The rest of the transaction data should be sent directly to, and solely verified by, the receiver.

This approach significantly minimizes the amount of data that is posted to bitcoin. Shielded CSV transactions only require 64 bytes of data. The average bitcoin transaction contains an average of 600~ bytes of data.

How it works

Client-side validation

Client-side validation is a mechanism where users only need to validate the history of coins, and corresponding transactions, that they individually interact with. There is no need for keeping a record of anyone’s coins, or transactions, outside of your own.

In bitcoin, full nodes must keep a record of the entire UTXO set and validate all transactions that have ever been recorded on the blockchain. Shielded CSV is the opposite of this dynamic – you’re only responsible for validating data related to your coins’ histories.

This minimizes the amount of data that is posted on bitcoin, with the tradeoff that users are responsible for keeping a copy of their individual state (more on this later).

Nullifiers

Shielded CSV as a protocol has transactions and nullifiers. Nullifiers are commitments to bitcoin that ensure a specific coin can no longer be spent in the Shielded CSV protocol.

Users don’t post a nullifier for each individual coin they hold when they conduct a transaction. Shielded CSV introduces “accounts” that contain an account state. During a transaction, users submit a nullifier of an account state that nullifies their ability to spend a coin that was a part of a previous account state.

How Shielded CSV’s nullifiers might work

This is a stab at outlining the nullifier construction highlighted in the Shielded CSV paper. Future production protocols might have different designs.

The nullifier consists of the nullifier public key and a Schnorr signature. The signature commits to the hash of the Shielded CSV transaction that created the nullifier.

Users maintain a nullifier accumulator that stores nullifiers related to Shielded CSV account state transitions. Each time that a Shielded CSV transaction is made, it nullifies a prior coin that was created in the protocol. The accumulator adds the new nullifier, which makes it impossible for that coin to be spent again.

Nullifiers are committed to in bitcoin blocks. Shielded CSV nodes scan bitcoin to find updates. When they find new nullifiers, each nullifier is verified as a Shielded CSV commitment, and is then added to the accumulator.

These commitments are 64 bytes in size. To get it down to this size, the whitepaper outlines some techniques using Sign-To-Contract and signature half-aggregation. For a detailed description of the nullifier, check out the whitepaper.

Tl;dr - we post a commitment to bitcoin that prevents double spending in the protocol.

Zero-knowledge proofs

Zero-knowledge proofs are proofs that provide an argument, which do not reveal the contents of the argument, outside of proving the argument to be true. The end goal is to convince a counter-party of the current state of some system. In payments related use cases, they are used to send proofs that a certain payment abides by the rules of a system without revealing the sender, the receiver, and the amount spent. This obscures the transaction graph and creates a system with high levels of privacy. They also have scalability benefits as they can compress entire transaction histories into a compact, succinct proof that recursively updates as needed.

In shielded CSV, this can be used to send a user the history of a coin, convince them that said history is valid, enable them to verify they are the new owner of the coin, and keep the size of the coin history compact and constant.

Shielded CSV, as a concept, does not rely on any given proving scheme. Numerous schemes could be leveraged in this design.

Combining them

When you combine these concepts together, you’re able to create a client-side validation system where transaction graphs are obscured and the history of coins is kept constant size, making them more efficient to validate. Users only validate transactions related to their coins.

This means that the network benefits from the unchangeable ordering of transactions in bitcoin blocks. Shielded CSV users are able to rely on bitcoin for keeping a record of all nullifiers, making them available to clients & nodes, and being able to finalize Shielded CSV transactions based on this ordering.

The transaction lifecycle

Now that we’ve got the key concepts covered… Let’s talk about the transaction lifecycle.

Transaction creation

Alice wants to pay Bob. To do this, she generates a shielded transaction. This transaction attests to Alice's previous account state and all of the coins she held in this state, and then generates a new account state related to the new coins. One of these new coins is for the receiver. Then, Alice derives the nullifier nullifying her previous account state and committing to the new account state.

Reminder: When an account performs a state transition (i.e. makes a transaction), the single Account ID is associated with a number of coins and the state of that account is updated and a nullifier for solely the account state transition is published.

Submitting the nullifier to bitcoin

Alice submits a bitcoin transaction containing this nullifier. This nullifier is embedded into bitcoin as arbitrary data, and from the vantage point of bitcoin full nodes, it doesn’t mean anything. The data is interpreted by Shielded CSV users as they scan bitcoin to find the nullifiers related to the coins they’ve been sent.

Receiving the coins

After Alice has submitted the nullifier to bitcoin, she needs to send a “coin proof” to Bob through a private communication channel (i.e. a wallet, messaging app, etc.). But first, Bob scans bitcoin, processes all nullifiers related to Shielded CSV, verifies their signatures, and updates his nullifier accumulator client side.

After this, Alice sends a coin proof, attesting to the history of the coin being transferred, to Bob. Bob verifies this coin proof to ensure that it 1) attests to a valid transaction 2) follows the Shielded CSV consensus rules and 3) commits to an entry recorded in his nullifier accumulator. He also verifies that all previous transactions in the coin’s history were valid and cannot be double spent.

After transaction validation, and after the block containing the nullifier has sufficient proof-of-work behind it, both Alice and Bob can consider the payment final.

Because the coin proof is a zero-knowledge proof, none of the information about the sender, receiver, or amounts is made public. Only an argument that a valid transaction occurred is public.

That’s it… but some stuff can make it better

This is basically how a Shielded CSV-style protocol would work. Still, there’s things that can make the protocol better suited for bitcoin-denominated payments:

Bridges

In the example above, you may have noticed that I never said “Alice sent Bob bitcoin”. Well, that’s because Shielded CSV is an alternative network that needs bitcoin to be bridged over to use it.

I’m not here to convince you that bridges are good or bad, or which one is the best. But, we can cover some designs that we could use to create a two-way peg for Shielded CSV:

• T-of-N multisig: A multisig where T-of-N signers need to secure deposits and process withdrawals to users who want to leave Shielded CSV. Used widely today.

• BitVM: A bridge where a set of operators need to secure deposits and process withdrawals. A minority of them need to be honest and a distributed set of watchtowers (maybe permissionless) can force them to be honest. Multiple teams building this.

• Native Proof Verification: With additional opcodes, you could construct a bridge that verifies proofs attesting to the current state of balances in Shielded CSV. If the proof is valid, the bridge can execute withdrawals based on this state.

There are different tradeoffs related to these bridges, and even how they compare with other L2s (such as Lightning). But, analyzing that is for an upcoming post…

Third party publishers

Publishing nullifiers on bitcoin requires a bitcoin transaction. Having to submit a bitcoin transaction every time you do a Shielded CSV? Pretty bad UX. And, what if you don’t have any bitcoin to start off with? You wouldn’t have the funds to submit the transaction containing the nullifier.

Insert publishers - service providers who post nullifiers on users’ behalf. The publisher role collects nullifiers from many users, aggregates them, and then submits them as a batch to bitcoin. They receive a fee, on Shielded CSV, in exchange for posting the nullifiers on users’ behalf. Even within batches, users are still able to derive an individual nullifier associated with a coin they spent or received.

Why use a third party? First, you may not have some bitcoin. Shielded CSV, as a payments layer for bitcoin, should be able to onboard users who have never, and maybe can’t, use the L1. An active network of publishers means some users may never even have to interact with bitcoin itself; a win for scaling. Also, you may not want to wait around for bitcoin’s block times for lower value payments. Publishers might be set up to accept transactions nearly instantly. You can see that the publisher accepted the nullifier, and if you trust that they’ll post it to bitcoin, you can be on your way.

Third party publishers can offer some performance benefits as they post aggregated nullifiers, not individual nullifiers one by one. There’s likely some neat compression techniques you could employ to reduce the cost of submitting these nullifiers onchain (which is useful in a high fee environment).

Service providers have an incentive to not censor you through fees. And if they do, publishing the nullifier is permissionless. You just need a little bit of bitcoin to do so.

Remember, these service providers cannot steal your funds. They can only refuse to post the nullifier, which means your transaction can never finalize and you’d need to use another publisher or publish it yourself.

UX - some notable design tradeoffs

Some nice tradeoffs

Shielded CSV has some unique UX benefits when compared to other bitcoin payments protocols. First, it can rely on bitcoin’s ordering of Shielded CSV nullifiers to enforce double-spend resistance. If someone tried to spend a previously spent coin, the transaction validation in Shielded CSV would fail based on the nullifier data that bitcoin made available to Shielded CSV nodes.

The interactivity requirements are minimal. After a sender submits their nullifier to bitcoin, and the coin proof to the receiver, the receiver can come online at any time after the fact and validate the coin proof and corresponding nullifiers. The interactivity requirement is that the receiver needs to come online to receive the payment.

And finally, there’s no inbound capacity problem. Users do not need to free up liquidity, or have existing liquidity at all, in order to receive a Shielded CSV payment. With the use of publishers, they don’t even have to interact with bitcoin at all.

Some not so nice tradeoffs

In these styles of systems, users must keep backups related to their own coin histories. If they lost any of these backups, then the data related to their own tokens would be permanently lost. In Shielded CSV, you are the only person who has access to this state. Don’t lose it!

Generating and verifying zero-knowledge proofs on a mobile phone also might be infeasible. But, proving systems are rapidly improving. And, protocols like Zcash, for example, can generate zero-knowledge proofs client-side to send shielded transactions. I’d be very surprised if we couldn’t run a Shielded CSV-style protocol on mobile phones in the next couple of years.

Also, full nodes have to keep track of all nullifiers related to Shielded CSV transactions which are 64~ bytes in size. This is potentially a scaling bottleneck down the road. Zcash is currently researching different ways to lessen this burden on full nodes, and some of the tricks may be applicable to a Shielded CSV construction.

Lastly, because the system requires a bridge, bitcoin’s current scripting capabilities prohibit users from unilaterally exiting a Shielded CSV-style protocol. T-of-N multisigs are permissioned in practice, so they are more vulnerable to censorship vectors. For example, they could use a surveillance oracle against OFAC sanctions list that forces bridge operators to censor specific addresses if they’ve been flagged (this exists today).

BitVM is an interesting approach that reduces the assumption to a minority of operators, but users still trust, at least one in theory, operator to facilitate withdrawals. While most implementations might have training wheels in their first production release, it has the potential to create a more trust-minimized set up that is ideal for systems that require more censorship resistance – like Shielded CSV.

So… soft forks for “spam”?

As Shielded CSV co-creator, and Blockstream researcher, Jonas Nick pointed out, all bitcoin transactions are spam. Classifying the arbitrary data associated with Shielded CSV nullifiers as spam is short-sighted. Even so, what most people call spam are transactions associated with speculative token protocols and data related to systems who offer smart contracts for shitcoin lovers. The protocol I’m describing above isn’t that in practice.

It’s a payments system that does not require a soft fork to build on top of bitcoin. You can build a shielded CSV-style system that inherit ordering guarantees from bitcoin today. But, for the system to be truly censorship resistant, for bitcoin payments, we need a mechanism to construct a trust-minimized bridge to and from bitcoin.

Some teams are looking to accomplish this via BitVM. This is likely the best we can do right now. But, as Jonas Nick also pointed out, this system could be improved if we are able to natively verify validity proofs on bitcoin (within the block size limit). This would require a soft fork. Which soft fork proposal? I don’t know. That’s above my pay grade.

But it’s not above yours! If you’re interested in ZK research, click the link below learn more about the upcoming ZK conference in Istanbul. Got an interesting talk or workshop about native zk on bitcoin? We’re currently accepting talks → Apply for a talk here.

Head to bitcoin++

But, what’s described above is a fully-private payments system that takes some worthwhile UX tradeoffs compared to what exists today. When we discuss new layer 2s coming to market, and “which layer 2s” could benefit from potentially making script more expressive, protocols such as Shielded CSV should be considered.

–Janusz

Last week, Botanix Labs launched mainnet for a bitcoin-denominated, federated sidechain. In the announcement posts, and dozens of media posts covering it, the network was touted as “decentralized” and “built on bitcoin”.

Before we cover the semantics, I will add that I’ve used Botanix. Bridging over wasn’t the worst experience and it was nice to finally use an EVM-style blockchain that was bitcoin denominated. The fact that they publicly announced their federation before launch was refreshing. All-in-all, Botanix handled their launch better than most “bitcoin season 2” projects to date, and for that, they deserve some praise. They also have the most distributed, publicly-known federation for a bitcoin-denominated system (at least to my knowledge).

Botanix, while launching as a federation, claims that the network will one day have 10,000 validators who act as sequencers and signers securing the funds backing its pegged bitcoin asset.

This claim made me wonder how difficult it might be to build bitcoin-native proof-of-stake systems, bridges, and other blockchain-based constructions. This post outlines some of the design challenges these teams face.

The two main sidesystem designs “bringing the EVM to bitcoin”

In the “bitcoin-evm-aligned” design space, there are teams building rollups and there are teams building monolithic sidechains (like Botanix). Most sidechains see rollups as their main competition.

Monolithic sidechains are networks where its full node & operator set handle all facets of the network — transaction execution, finalization, data availability, and consensus.

Rollups, however, use bitcoin for data availability and consensus. This means that rollup full nodes execute transactions and update the state based on data that was posted to, and made available, by bitcoin full nodes.

Can we scale with Proof-of-Stake systems?

Let’s generally look at some challenges Proof-of-Stake sidechains might face while doing this.

Most proof-of-stake systems use CometBFT for their consensus client. CometBFT has known scaling limitations due to all-to-all communication between its consensus nodes. In practice, CometBFT has never scaled past 200 consensus nodes as it would severely impact latency and performance. To reach 10,000 validators, while maintaining sub-5 second block times, any project would need to design a completely new consensus architecture from scratch, test it, and scale it gradually.

While somewhat randomized, the right to win a block in proof-of-stake is heavily weighted against the amount of stake a validator puts up. More stake, more blocks, more rewards. If institutions, holding large swathes of bitcoin, want to take advantage of bitcoin staking’s yield generation properties (they do), they may stake large amounts into any given network. This weights the stake heavily towards a few parties who can effectively gain control of the block production pipeline. So let’s limit stake then? E.g. Cap the amount that each entity can stake? Well, institutions will just run more validators. In practice, the weight of stake, correlated with the legal entities/persons running all the validators, will be the same.

Ethereum is the best attempt at making a proof-of-stake system distributed. But as we’ve seen with LSTs, most users don’t actually want to run their own validator and stake. It’s more attractive to simply give your money to someone else, have them stake it for you, get a liquid token in return to play DeFi games, and then pay a percentage of the staking rewards to the LST issuer in return. This set up centralizes stake massively to a federation of stakers and/or alternative governance mechanisms. Through LSTs, distributed proof-of-stake systems look a lot more like delegated proof-of-stake networks where the majority of users simply delegate their stake to a permissioned set of validators.

But even if you can distribute the validator set within the system, you still need to figure out how to secure the two-way peg. Stake-weighted, rotating multisigs have worked in practice, as we’ve seen with Threshold tBTC, but making the system is permissionless is difficult. You don’t want just anyone buying up a bunch of stake and gaining control of the two-way peg wallet(s). Threshold tBTC is the most distributed two-way peg that bitcoin has seen to date, but it is still permissioned to 35 signers. All signers must be approved by the Threshold DAO before entering the set. Another option is using one multisig and updating the signing thresholds based on stake weights. Nomic does this today where its top 20 validators by stake weight secure the nBTC two-way peg. But, since their token isn’t transferable, no one can go acquire NOM on the open market and become a signer. It’s permissioned in-practice. Additionally, both of the systems mentioned here rely on another token.

The fact is, know one has ever built a two-way peg exclusively secured by permissionless staking.

Proof-of-stake is hard. Bitcoin staking? Even harder. There’s only two examples of bitcoin staking in the wild. One relies on a multisig to enforce slashing (since we don’t have covenants) and the other doesn’t have slashing at all. It’s easy to counter arguments against Proof-of-Stake with “well, we’re going to use bitcoin as the staking asset and this solves all the problems”. But we’ve never seen this play out in practice.

So even in a world where stake doesn’t centralize, it’s unclear how these systems stay distributed, fully censorship resistant, and not reliant on some federated multisig somewhere down the line. Some smart teams are working on this and there might be new solutions coming to market that approach the design space differently.

Some of the tradeoffs related to rollups

You might chalk this off as a win for the rollups, but not so fast. Rollups equally have their challenges. Those challenges are a result of… you guessed it!

Tradeoffs.

Rollups must use bitcoin as a data availability layer. The ability to trustlessly reconstruct the rollup’s state, from bitcoin, and build fully trust-minimized sidesystem bridges is the result of using bitcoin as a data availability layer. Do not let the rollup teams tell you otherwise! An alternative DA layer significantly introduces more trust assumptions in the system. You either trust a federation, or another network secured by an altcoin, to make the data available — a prerequisite for advancing the state of the system. I talk about this here:

Bitcoin only makes 4MB of blockspace available every ten minutes. This is very limited in throughput. Other rollup data availability layers offer significantly more throughput. This means that posting data to bitcoin will be more expensive and that cost is incurred to the user. This chart outlines how expensive it might get.

Also, building proving systems, on any blockchain, is really f*cking hard. Ethereum (sigh, he mentioned it again) has a significantly more expressive scripting language. And for all rollups with general purpose smart contract environments on Ethereum, there is no system in production that does not have, at most, a 9/12 multisig that can immediately upgrade the systems relevant contracts and steal all money locked in the rollup bridge. Ethereum has been building towards trust-minimized rollups for nearly 5 years.

On bitcoin, we can’t construct native proof verification (within the block size limit) and state-carrying covenants without additional opcodes. This simply means that:

• Proving systems on bitcoin are going to be complicated

• They’re still going to rely on some subset of operators to process withdrawals

• And they’ll probably be reliant on governance multisigs like their counterparts in Ethereum for some period time

Additionally, rollups rely on single sequencers to build their blocks. Running a full node in most rollup set ups is permissionless, so anyone can participate in verifying and advancing the state, but building blocks is usually confined to one entity. If this entity censored users, they theoretically could produce and build their own blocks, as they have access to the data and can run a full node, but we’ve never seen examples of forced inclusion and self-proposing in bitcoin. It’s likely another aspect in rollups’ decentralization roadmaps that needs to be built.

In my opinion, rollups are building towards the most trust-minimized sidesystem. Because they rely on bitcoin for consensus, they’re the only sidesystem that has the potential to be considered a true L2 (we’d need a softfork for this, though). And while complex, every problem that a rollup might face, there is ample research on how to potentially solve it.

But in the interim, sidechains, even as a federation, might be more trust-minimized.

A long road is ahead

Proof-of-stake sidechains and rollups both have their benefits and limitations. Equally, a lot of research and engineering work needs to be done to make these systems fully trust-minimized on bitcoin.

You can point out flaws in every construction. You can say “impossible” to anything. Most of the time you will be right. But let’s not waste our time. Tell users the tradeoffs, build towards more trust-minimized systems, and ship sick apps. Let a thousand flowers bloom, even if they rely on a centralized multisig in the interim.

–Janusz

Fellow Americans, Happy 4th of July. To those who weren’t born into citizenship-based taxation, congrats. And for those of us who at least get the day off of work, I hope you spend it offline, with family and/or friends, enjoying a hot dog and a beer.

This post isn’t an attempt to align America’s founding values with bitcoin. It’s a few-days overdue take on a subject I’ve been fascinated by – statechains. Spark claimed that the incoming Wallet of Satoshi application is “fully self-custodial”. Most rejected this claim. As a casual observer, I couldn’t help but think some nuance is missing. My take:

Custody is binary. You either have it or you don’t. Spark wallets can’t be not self-custodial and custodial at the same time. So what gives?

Spark, and its corresponding wallets, provide users with custody over their funds. Users hold a key in a 2-2 statechain multisig. They have a pre-signed unilateral exit path to claim their funds onchain if the operator goes offline. This is custody. When you deposit funds into a statechain, no one can steal your coins.

What Spark is missing is provable finality guarantees. As ArkadeOS correctly stated, Spark transactions never really finalize from the view of users (by finalize, we mean that a user never has provable assurances that they are the only one that can spend the coins outright).

Statechains essentially see users transfer around their private keys to 2-2 multisigs, holding L1 coins, offchain. The operator, who is the holder of the other key in the multisig, is responsible for deleting its key shares held with previous owners during transfers. If the operator does this, the operator and the previous owner cannot collectively double-spend the current user’s coins. But users can never be sure that the operator honestly deleted said key shares. Simply put, proof of deletion isn’t mathematically possible.

So, as Matt Corallo rightly pointed out, malicious statechain operators can pose as honest actors and trick users into thinking they have the unique ability to spend the funds collaboratively with the operator. But even if a user didn’t have this ability, it doesn’t mean they don’t have custody. It means that a dishonest operator didn’t responsibly delete the previous key shares, seeing multiple users have the same level of custody for the coins.

You might receive a private key for the 2-2 multisig, but if the operator never deletes its previously held keyshare(s), then the transaction shouldn’t be considered final. Remember, every previous owner still has their private key. You just want to be the only person who can immediately spend funds with the statechain operator. It’s the operator's job to ensure that you can do this. And as a user, you trust their reputation to be confident they’re acting honestly.

In my opinion, rugging, in statechains, is effectively undoing a statechain transfer. It is reverting finality. You would never consider a statechain transfer final if the operator didn’t delete their previously held keyshare. But you can never prove that they did. You trust them to do this.

When people talk about “L2 self-custody,” they are referring to users retaining a unilateral exit path and having a provable assurance that they are the only ones who can spend the coins that they custody. Spark can only provide the former.

I have an essay coming out arguing this next week.

You’ll get it directly to your inbox. Happy 4th 🇺🇸

This piece is an opinionated take. It is not an official stance of The Insider Edition or Bitcoin++.

Subscribe now