John Light is a Bitcoin researcher who recently published a paper exploring how Validity Rollups might work on Bitcoin.
In our conversation, we first explored what zero-knowledge proofs and rollups are, we discussed the different ways in which rollups could be implemented, the risks and rewards to implementing rollups on Bitcoin, and the ways in which rollups and the Lightning Network could be complementary to each other.
→ Bitcoin Rollups: https://bitcoinrollups.org/
→ Unexpected Tradeoff from Bitcoin Soft Forks: https://bitcoinops.org/en/newsletters/2022/07/13/#x-only-workaround
→ Voltage: https://voltage.cloud?utm_source=kevinrooke&utm_medium=Youtube&utm_campaign=1mo
→ Stakwork: https://stakwork.com/
This show is a Lightning podcast. That means instead of asking for likes or shares, I ask for sats.
The best way to show your support is to download Fountain from the App Store, load your wallet with some sats, and send them over the Lightning Network to firstname.lastname@example.org.
→ Fountain: https://www.fountain.fm/
→ More Episodes: https://play.fountain.fm/show/P6XXuSPg6f2rj4ECB0fT
→ Lightning Address: ⚡email@example.com
→ Stack Sats: https://www.stacksats.how/
→ Twitter: https://twitter.com/kerooke
→ Books: https://www.kevinrooke.com/book-recommendations
→ Blog: https://www.kevinrooke.com/blog
00:00 - Intro
02:26 - John Light Intro
10:31 - What are ZK-Proofs & Rollups?
18:23 - How Might Rollups Help Bitcoin Scalability
27:57 - Privacy Implications of Rollups on Bitcoin
34:25 - Rollup Security
39:44 - How Might Rollups Be Implemented on Bitcoin?
44:14 - The Case Against Rollups on Bitcoin
52:26 - Unintended Consequences of Bitcoin Soft Forks
1:00:45 - Validity Rollups vs. Lightning Network
1:11:06 - The Lightning Round
John Light - 00:00:00:
After looking into the details of how bitcoin worked, I realized that bitcoin could be the solution. I decided to dedicate my life to try to have as many people as possible adopting bitcoin. In my report, I talk about basically three different types of rollups. One is an account model roll-up. Another is a UTXO model roll-up. And the third is a shielded UTXO model roll-up. Almost all of the rollups on Ethereum today their security model. When you actually look at how they've been implemented, they devolved to a multisig security model. What I would like to see is that once a rollup actually goes into production on mainnet, that it actually have the true rollup security model, where state, transitions, validity proofs, the contract interactions are all secured by layer one consensus and cryptography using the validity proofs. And that's it.
Kevin Rooke - 00:01:11:
John Light is a bitcoin researcher who recently published a paper exploring the idea of rollups on bitcoin. In our conversation, we started with a definition of what rollups and zero knowledge proofs are. We then went into the ways in which rollups could be implemented on bitcoin. We discussed some of the risks and the rewards of implementing rollups on bitcoin, and then we finished with a discussion about how the lightning network and rollups could be complementary to each other. John has asked to have his share of today's show splits cents to the Human Rights foundation. So if you enjoyed this episode and if you learned something new, the best way you can support the show and the HRF is to send sats over the Lightning Network using any Podcasting 2.0 app. Just a quick shout out before we get into the episode. Today's show is sponsored by Voltage. Voltage is the industry standard and next generation provider of Lightning Network infrastructure. Today's show is also sponsored by Stakwork, and Stakwork is a Lightning powered transcription tool that takes the best of AIs and humans and combines them to make better, faster, and less expensive transcripts. We'll have more from Voltage and Stakwork later in the show. John, welcome to the show. I'm excited to talk about a very technical topic today, which is bitcoin rollups. You've done a lot of research on this topic. Why don't you start with a background of yourself, tell listeners about how you got into bitcoin and why you decided to study this topic.
John Light - 00:02:44:
Sure. Thanks for having me, Kevin. So I've been in the bitcoin community for a while. I've worked on a number of different bitcoin startups. I think a lot of people might be familiar with one of the startups I worked on called Bitseed, which was one of the first hardware plug and play bitcoin full nodes. Currently, I'm working on a project called sovereign zero, which is a decentralized borrowing protocol and stablecoin protocol on the rootstock bitcoin side chain. And I got into bitcoin because I saw what happened in 2008 with the financial collapse and how the government build out a bunch of banks who gave their bonuses to all their executives. And it just struck me as something that was so antithetical to the values that I was raised to believe in, such as free markets and competition. I believe that if businesses engaged in bad practices, they go out of business. They don't get bailed out by the government and the taxpayers. And I thought to myself, I don't want to participate in that system. If I can, I would like to remove myself from that system and participate in a truly free market. And so I started looking for alternative monetary systems, alternative financial systems, and there weren't really that many great options at the time, but there were a lot of experiments, small scale experiments, and I eventually found bitcoin. And after looking into the details of how bitcoin worked, I realized that bitcoin could be the solution that I was looking for, at least to solving the monetary problems of creating a truly free market, sound money. And I decided to dedicate my life to try to have as many people as possible adopting bitcoin. I started doing education about bitcoin and working on bitcoin startups to try to make bitcoin easier to use and more useful to use for those who already adopted it. And that's what I've been spending my time on ever since.
Kevin Rooke - 00:05:21:
Awesome. Now let's talk a bit about this transition from learning about bitcoin, deciding this is what you want to spend your life on, to now discussing rollups and where do they fit into this picture of making bitcoin more usable. It's a term that I think is often heard in crypto circles. It's heard in the Ethereum community primarily. There's a lot of rollups on there. What do rollups look like on bitcoin? What is this idea all about? And how did you come to decide that this is what you want to study next?
John Light - 00:05:58:
So in 2020, I started looking into the different cross chain bitcoin protocols that existed at the time. There were a number of different protocols that had been built to basically transport bitcoin to different blockchains. And those protocols all kind of had different security models or trust models that they used to pull off this trick. And they ranged from like fully centralized, such as WBTC, to much more decentralized and closer to the realm of trustlessness that we consider the ideal as bitcoiners, such as TVTC. And then there's a whole spectrum of projects in between. And I wanted to understand these different security models and trust models to think about which ones might actually be worth using as a bitcoiner who's looking to get some kind of utility from these other chains that isn't available or maybe even possible on the bitcoin main chain. And so I started doing research into these protocols. And what I discovered was that although some of the more trustless ones, such as TVTC, do have some crypto economic guarantees that when you move your bitcoin over to this other blockchain, you'll actually be able to get your bitcoin back on the main chain. None of them had a true cryptographic guarantee, the same way that somebody who's actually holding bitcoin on the bitcoin main chain has a cryptographic guarantee that as long as they can sign a transaction with their private keys and get it confirmed on the bitcoin main chain, they can always move their bitcoin to another address. So I started doing more research about would it actually be possible to have a fully trustless bridge to other blockchains where you have basically the same security model or ownership guarantees that you have with bitcoin on the bitcoin mainchain. And what I found was that validity rollups. Which was a new technology at the time that was just getting developed for Ethereum mainly. And some other blockchains like that. Actually is able to implement this trustless bridge that enables people to move their bitcoin to a different blockchain and have a strong trustless or trust minimize guarantee that they can get their bitcoin back onto the main chain. And I found this very interesting. And then fast forward to earlier this year. I saw that the Human Rights Foundation, along with Starkware and CMS Holdings, were sponsoring a grant for a fellowship where the person who won the fellowship would do research for a few months and then produce a report about validity rollups and how they could work specifically on bitcoin. And I thought to myself, well, I've been doing all of this research into cross chain bitcoin protocols. I've also done some research already into validity rollups. I could take this knowledge that I have and come together with other experts in the industry to produce this report for the fellowship. And so I submitted an application, I got the fellowship, and just about a week ago, I finally published my report, validity rollups on bitcoin.
Kevin Rooke - 00:10:31:
Very cool. We'll definitely link the report in the show notes here, but let's maybe start with some definitions for listeners who aren't familiar maybe have heard these terms before but aren't familiar with the technical details of how they work. Can we define first, zero knowledge proofs and rollups. Those two terms appear frequently in the report. Want to give listeners a better idea of what they are?
John Light - 00:11:00:
Yeah, sure. So a zero knowledge proof is a proof that contains no additional knowledge other than the correctness of the proposition in question. So the idea is that you're able to, as a prover, somebody who wants to prove a statement to somebody else who would be a verifier, you're able to run some computation, or I should say, you're able to answer a question by running some computation and convince the verifier that you know the answer without actually revealing the answer to the question. So a classic example of this in terms of how you would do this in the physical world would be to take a really large sheet of paper and then a smaller sheet of paper with a where's Waldo puzzle on it and you would cut a hole in the larger sheet of paper that was just the size of Waldo and the verifier would stand on one side of the sheet of paper and you would have the where's Waldo puzzle on the other side of the sheet of paper and you would move the where's Waldo Puzzle around until Waldo was showing through the hole in the much larger sheet of paper. And by doing that you would be able to show the verifier that you know where Waldo is but because they can't actually see the where's Waldo puzzle because the much larger piece of paper is covering it up they don't actually know where on the puzzle Waldo is. So this is actually a physical example of like a zero knowledge proof where you're able to prove that you know where Waldo is without actually revealing where Waldo is to the verifier and zero knowledge proofs in the digital realm are basically ways similarly to prove that the correctness of a statement without actually revealing any information about it. And a validity proof is a more general version of this where you're able to run a bunch of computation over some information and prove the correctness of certain statements to a verifier. In this case a verifier is just a different piece of software or another part of the same piece of software and the applications of this are seemingly limitless but in this case. In the case of validity rollups the application is you want to prove the correctness of or validity of transactions within a block without requiring layer one bitcoin full nodes to have to actually replay all of those transactions themselves to verify the correctness because the way a bitcoin full node usually works is that it receives a block from the miners who have produced a bitcoin block and they will actually rerun all of the transactions in the block or replay the transactions in the block to make sure that they are following all of the rules of the bitcoin protocol. And then once they have replayed all of those transactions then they either consider the block valid or invalid. And if the block is valid then they will add it to the chain tip and it becomes a part of that full nodes blockchain and then that process repeats itself for every new block that gets created with a rollup block what happens is that this different network of full nodes. A layer two network of rollup full nodes will take a will take a block that is produced by a layer two rollup a block producer and then they will the rollup block producer will put the block data or a compressed version of the rollup block data into a layer one bitcoin block as a single bitcoin transaction along with a validity proof. So they'll basically run some computation over all of those transactions within the rollup block. And the output of that computation is the validity proof which basically says to the layer one full nodes this I shouldn't say, it says issue proof to the layer one bitcoin full nodes. All of the transactions within this rollup block are valid according to the consensus rules of the layer two rollup protocol. And when that transaction gets included in the layer one block, the layer one full nodes, rather than having to replay all of those transactions that are in the rollup block, in order to verify their correctness, all they do is they look at the validity proof and they run the validity proof through the Verifier software. And if it checks out, basically if it comes back as valid, then they just accept the block as valid and they move on to the next block or the next transaction. And so this could potentially be a great scaling benefit because one of the bottlenecks in scaling bitcoin is computation, actually running the computations that are needed to verify every transaction, to check the signature, to check the script, make sure that the UTXO isn't being double spent and so on and so forth. And the validity proof enables you to basically skip all of that and all you do is you just check the validity proof. Does it come back as valid or not?
Kevin Rooke - 00:18:21:
Makes sense. This is a very helpful explainer here. I've already learned a ton. I want to try and understand the magnitude of improvement here. When you talk about scaling, scaling something like bitcoin, what is that potential for improvement when it comes to transaction throughput that could be achieved from validity rollups?
John Light - 00:18:50:
It's a good question and it really depends on the implementation details of the rollup that gets built on bitcoin. But in my report I talk about basically three different types of rollups. One is an account model rollup, another is a UTXO model rollup and the third is a shielded UTXO model rollup. So I'll explain what each of those different models is and the differences between them. So I'll start with the UTXO model rollup because your listeners are probably most familiar with UTXO model blockchains because bitcoin itself is a UTXO model blockchain. So this is where coins are represented as unspent transaction outputs. That's what a UTXO stands for. And users basically own collections of unspent transaction outputs. And then when they want to make a transaction, they will select some of those UTXOs as inputs for their transaction and then they will define the recipient and potentially a change address which will create new UTXOs from their transaction. So those are the outputs of their transaction. So you've got inputs which are UTXOs that the user already owns or maybe somebody that they're collaborating with to create the transaction already owns. And then you've got outputs which are all of the destination addresses. And this is a great way to run a blockchain because you're able to parallelize a lot of operations, but it also produces a lot of information about the transactions because you might have multiple inputs, you might have multiple outputs, and this is just adding data to your transactions. An account model rollup will reduce the amount of data that is needed for a simple spend transaction, because there's only a single sender address and a single recipient address. And rather than a user owning collections of unspent transaction outputs, they just own an account. And that account has a balance. And when they spend money, their balance on that account is simply debited to take money out of their account and transfer it to a different account. And so the way that you can communicate these debit operations is very simple. You just have Alice sends X number of Bitcoins to Bob. It's like a very small, succinct amount of information. And using some compression tricks, you're able to compress that amount of information down to as little as, like, twelve bytes per transaction compared to a similar UTXO model transaction, which might be more like 150 or 200 bytes. So that's already over or less than 10% of the size of, like, a UTXO model transaction. And then the third blockchain state model that I mentioned was the shielded UTXO rollup. And the shielded UTXO rollup is basically a way to encrypt your transactions. You apply zero knowledge EndToEnd encryption to your transaction so that the sender addresses, the recipient addresses, and the amount of Bitcoin that is being sent are not publicly visible on the blockchain. The transaction just looks like a bunch of ciphertext on the blockchain because it's encrypted. The tradeoff that you're making is that these transactions are much larger in size in terms of, like, their bytes. So those transactions are like six or 700 bites at a minimum, and so they're a few times larger. But you're able to get so much more privacy from those kinds of transactions because all of your transaction details or most of your transaction metadata is end to end encrypted. So it might be worth the trade off to pay a little bit more for those kinds of transactions because you're getting so much more privacy when you look at these different rollup models. And there are other models that people could come up with, I'm sure. But I look at these because these are, like, easy frames of reference for people. You've got the really small transactions. You've got the transactions that are closer in size to, like, Bitcoin transactions today, and then you've got transactions that are a little bit larger, at least in terms of raw bites that end up inside of a block. And what I suggest in my paper in the report is that we could actually apply the witness discount that was introduced with SegWit to all of this rollup transaction data. And the reason why I suggest doing that or suggest that it might be acceptable is because layer one full nodes don't need to replay any of these transactions. So there is no additional computational cost to putting these transactions into a layer one block. They do have to store this data, but storage is generally considered cheaper than computation. It's less of a bottleneck than computation when it comes to scaling. And so if we apply the witness discount to all of this transaction data, then actually the shielded rollup transactions end up just being a little bit bigger in terms of weight units, which is how Bitcoin transaction capacity is technically measured in Bitcoin now. So the weight units or the weight of a shielded roll of transaction is just a little bit bigger than a normal one input two output UTXO transaction that you would do on layer one bitcoin today. Those transactions are about 500 bytes. And like I said, the rollup transactions are 600 or 700 bytes. The shielded rollup transactions and then the normal UTXO rollup transactions, if you apply the witness discount, they're only about 170 bytes compared to the 500 bytes of a layer one UTXO transaction. So, you could say it's about three or four times more transactions per block for a normal UTXO model rollup if you apply the witness discount to that data. And then if you take the account model rollup with those small 12-byte transactions and you apply the witness discount to that data, then you could fit as much as say 250,000 transactions per block compared to 2 to 3000 transactions UTXO model transactions, which you might fit in a layer one bitcoin block today. So, it's a much greater approximately 100x throughput improvement for the account model transactions in the rollup.
Kevin Rooke - 00:27:56:
Makes sense. I appreciate the clarity there. I want to now dive into the effects that rollups have on privacy. Can you give an overview of like what are some of the privacy implications of rollups? Do they improve user privacy? You mentioned the shielded rollups. What's just your overall sentiment on how privacy changes if rollups are on Bitcoin?
John Light - 00:28:26:
Yeah, good question. So again, it depends on the model, the state model that you use for your rollup. With the account model rollups that I just described, with those small 12-byte transactions, you're able to get those transactions so small because users are effectively reusing addresses. So rather than having spending UTXOs and then generating a new address to catch the change from many of your transactions. So basically having a new address for every transaction, users would reuse their addresses over and over again. They would register their address as an account which then gets represented as up to four byte account number and then they just Give that account number with their counterparts whenever they want to receive a transaction. And by looking at the rollup block data, you can see that account has received this much money and sent that much money. It's a typical address reuse like privacy model, which is like not very much privacy, because as soon as you share your account with somebody, they can see your entire transaction history very easily. Whereas, like, with a UTXO model, you can at least do some things to introduce some ambiguity as to what is the change output. Were these two inputs to a transaction really owned by the same person? And that kind of thing to kind of like mess with the heuristics that blockchain investigators might use to try to connect addresses together. So, if they use a UTXO model, a plain UTXO model rollup, then the privacy is basically the same as it is on bitcoin today, which of course varies depending on how you're actually using bitcoin. There are ways that you can use bitcoin that are very private, and there are ways that you can use bitcoin that are not very private. And even if you're using bitcoin very privately, if you make any mistakes, it could unwind all of the effort that you've taken so far to try to preserve your privacy. So what's most exciting to me are some of the new privacy models that we can get. New. Stronger privacy models that we can get by building new types of rollups with new state models. Such as the shielded UTXO model rollups that I described earlier. Where all of your transaction metadata. Your sending address. The recipient address. The amount of bitcoin that you're sending. Or even the asset that you're sending are all encrypted. Which creates basically a fully ciphertext blockchain where you look at it and you just see a bunch of gobbledy gook. And there's no way computationally, no feasible way using current computational capabilities to decrypt that information without the private keys, which just creates basically as good a privacy as you could possibly get using computational technology and cryptography today. I think that having transactions that are that private on bitcoin for bitcoin in a way that is totally trustless is really the holy grail. And what personally makes me most excited about having validity rollups on bitcoin.
Kevin Rooke - 00:32:31:
Right. How does the shielded transactions compare to something like ZCash using ZK snark proofs?
John Light - 00:32:43:
Good question. It is the same technology. So you're using the zero cash protocol or a variant of it, which is what ZCash is based on, to do these z to z is what they call it in the bitcoin or the z cash community. These z to z transactions that fully shield or end to end encrypt all of your transaction details makes sense.
Kevin Rooke - 00:33:08:
So do I have it right then that we can have any one of these approaches on bitcoin? We can use whichever one we prefer and potentially multiple different approaches on bitcoin?
John Light - 00:33:20:
Yes. So as long as bitcoin layer one has the capability of verifying the validity proofs that are used to prove the validity of these rollup blocks. You can build any type of state model on top of bitcoin. You can restrict the type of state models that could be built on top of bitcoin by restricting the computational capabilities of the proofs that bitcoin is capable of verifying. But the more you loosen or expand those restrictions, I should say the more you loosen those restrictions or expand those capabilities, the more different types of state models you would be able to support with greater and greater amounts of power or expressiveness.
Kevin Rooke - 00:34:24:
I see. Now I want to get into security because that's a primary feature of bitcoin as a store value, is its ability to secure your wealth over time. I think in your paper you mentioned that on Ethereum, rollups are secured by a multisig rather than the base chain itself. Correct me if I'm wrong there, and I'd love to learn more about the different security trade offs that you have with rollups on Ethereum today versus the rollups you describe in your paper.
John Light - 00:35:00:
Yeah, it's a good question. So it's true that almost all of the rollups on Ethereum today, their security model, when you actually look at how they've been implemented, they devolve to a multisig security model because maybe a multisig is able to unilaterally update the contract code that is used to actually verify the zero knowledge proofs or hold the funds on layer one, which users are transacting with on layer two. But the ideal rollup implementation, I almost wouldn't even consider those rollups yet, but they're more like proto rollups or something. They're an early stage of development that eventually will become a true rollup. A true rollup is a blockchain that is secured by a contract, like on layer one. So, layer one consensus and cryptography using the validity proofs to guarantee the correctness of withdrawals that are coming out of the rollup, and state transitions that happen on the roller low the rollups as they exist today on Ethereum, I wouldn't really consider them rollups yet. But if you ignore the multisig, they superficially look a lot like rollups. They have a different blockchain, that is with some block producers that are putting the block data inside of layer one transactions. They might even be producing like validity proofs and sending them to the contracts. But if the contract can be the contract logic can be changed by multisig, then the multisig is able to change the contract logic to say the multisig can take everybody's money. And so that's not the rollup security model, that's a multisake security model. And I think rollups, when they're built on bitcoin, I think that kind of security model might be acceptable while the rollups are operating on testnet or something like that. But what I would like to see is that once a rollup actually goes into production on maintenance, that it actually has the true rollup security model where state transitions, validity proofs, the contract interactions are all secured by layer one consensus and cryptography using the validity proofs and that's it. Because that's how you're able to really get the benefits of a rollup compared to something like a federated side chain. Because if you want a multisig security model, there are federated side chains such as Liquid or Rootstock that use a multisig to secure the bridge and they work quite well. Those are both, I would say, acceptable blockchains to use if you are okay with that security model. But I see rollup as like the next step along the path to like full layer one security because it has that security from layer one consensus and the validity proofs that are verified by layer one full node.
Kevin Rooke - 00:39:13:
I hope you're enjoying the show so far. I just want to give a quick shout out to our sponsor, Voltage. Voltage is the industry standard for Lightning Network infrastructure. Creating layer two applications and services on top of Bitcoin starts with Voltage where you can spin up nodes, get access to liquidity, optimize your node and much more. Voltage is leading the way as the next generation provider of Lightning Network infrastructure. And if you want to get a free trial and start using Voltage today, you can do so at voltage.cloud. How does something like how do rollups on Bitcoin happen? Like, what is the step by step, you know, progression here from you writing this paper to it being implemented on Bitcoin? What has to happen along the way?
John Light - 00:40:03:
That's a good question. This isn't a definitive answer because there is no official process to like adding changes to Bitcoin consensus and so these changes tend to happen different ways. Or if you look at the way that consensus changes have happened to Bitcoin, the story of how they've happened is different from one change to the other. But I think the process could look something like finding other developers who are interested in this idea and working together to define the requirements for adding support for validity rollups to Bitcoin, looking at the different ways that those requirements could be implemented and picking the way that seems like it would be best for Bitcoin and Bitcoin users over the long run. Because we have to remember that any changes that we make to Bitcoin are going to be a part of the software effectively forever and then do a lot of implementation work and testing to make sure that it's working correctly and get invite people from the community to help with the review and testing. And at the end of that, if the development and testing and iteration and testing, et cetera goes well and you come out with a piece of software that you consider robust and secure and usable, then you would submit a pull request to Bitcoin full nodes, software repositories such as Bitcoin Core, BTCPay, litbitcoin, other implementations that you want to support this validity rollup technology. And you have discussions with the community about how you want to schedule activation of the soft forks that would be needed to implement support for validity rollups on bitcoin. And once you agree on the activation parameters, then you add those into the software and then publish the software and ask for the community to adopt it so that you can get so you can meet the activation criteria and ensure that there is a sufficiently large part of the bitcoin economy that is enforcing the soft fork rules. So that when miners are producing blocks that have validity rollup transactions in them, we can be sure that the rest of the bitcoin economy or a large part of it is checking to ensure that those blocks are actually valid.
Kevin Rooke - 00:43:53:
Interesting. Now, I wonder
John Light - 00:43:54:
By the way, that describes the change process that you could do for any kind of soft fork.
Kevin Rooke - 00:44:01:
John Light - 00:44:03:
But like I said, there is no real official process. So that is just one way that you could do it.
Kevin Rooke - 00:44:12:
Yeah. Now, if someone was listening to this conversation and has read your report and they said, you know what, I've weighed all the pros and cons and I think it's a bad idea, what would their reasoning be? Can you make that argument that we don't need bitcoin rollups?
John Light - 00:44:33:
I can try. So, I think you could come up with a few different objections to doing validity on rollups, like either in the near term or ever. One of those objections might be, well, the validity proof technology that is used to guarantee the correctness of rollup blocks is too new. Like even though some of the underlying cryptographic assumptions are actually older than the cryptographic assumptions that we're relying on in bitcoin today, such as Starks, which rely on hashes for security, whereas bitcoin signatures today use ECDSA or elliptic curve cryptography, which is a newer form of cryptography than hashes. Even though the cryptography might be older, the implementations are newer than, say, ECDSA or the Schnorr implementation that just got added to bitcoin for Schnorr signatures. So you might say the technology is newer and so we want more time to pass for the technology to mature to both ensure security, but also for the performance benefits. Because over the past, say, five years, cryptographic proof technology has gone from having extremely large proofs that are taken extremely long time to produce to extremely small proofs that are extremely fast to produce. I mean, relatively speaking. So you'd have proofs that are like, you know, hundreds of kilobytes in size that take many minutes to produce to now having proofs that are less than a kilobyte and only take a couple of seconds to produce. This is a huge difference in performance. And so the argument might be, well, if we wait another five years, your proofs are just going to get that much more performance and that much more secure. So that's an argument you could make. You could also say, well, to get the throughput, like the maximum throughput that you're advertising like 250,000 transactions a block or something like that, you have to make blocks bigger on average. The way that you get that much throughput using a validity rollup is by stuffing the block full of transactions to their maximum, like 4 million weight unit limit. Whereas blocks today, yes, they're getting stuff to their 4 million weight unit limit. But the bytes that are actually stored on disk are like, you're talking about blocks that are no bigger than, say, 2.77 megabytes is like the largest block that has ever been found, whereas a 4 million weight unit block that's been stuffed with rollup transactions would be closer to four megabytes. So your blocks might be about bigger and some p eople might say that's a cost that's unacceptable. There are ways that you could design rollups that restrict the amount of rollup data that you could fit into a layer one transaction so that your blocks would still be no larger than 277 megabytes. But you're going to decrease your transaction throughput when you do that. You're limit the number of transactions that you could theoretically fit into a layer one bitcoin block. So there's a trade off there. I see. Some people might say that there could be unexpected side effects of enabling validity rollups on Bitcoin. Like, even if you think that your proof system doesn't allow or isn't powerful enough to support certain kinds of transactions that some people might consider to be dangerous, like maybe they enable new forms of minor extractable value that mess with the minor incentives or something like that. Even if you think that the proofs are powerful enough to enable those kinds of transactions, maybe it turns out that they do. Somebody just figured out a way to construct the transaction in such a way that the proving system that you thought was too limited to support those types of transaction, turns out it is actually powerful enough to prove those types of transactions if they're constructed a certain way.
Kevin Rooke - 00:50:16:
John Light - 00:50:17:
So that's the kind of thing that it's hard to know ahead of time exactly, or how people are going to use the system. They might come up with a creative way of abusing it to construct smart contracts that some people might consider harmful.
Kevin Rooke - 00:50:44:
Right. So for the wrap up, the overall risks and rewards here, the high level rewards are we could potentially get up to two orders of magnitude more transactions, potentially get very private transactions. And those downsides maybe being that, like, maybe these implementations for rollups are newer and less tested than some of the ones used in Bitcoin today, maybe it requires blocks to be slightly larger and that there may be some sort of minor extractible value. Is that a high level assessment of the pros and cons.
John Light - 00:51:26:
Yeah, makes sense. I would say so. And I think there are ways to design the rollups or the soft forks that would enable the rollups in such a way that mitigates a lot, if not all of those downsides. But as with the case of the validity proofs that I was just mentioning, maybe people get creative and still are able to kind of work around those restrictions to do things that you didn't anticipate. It's something that needs to be considered. And it wouldn't be the first time that people have realized after a soft fork has gotten to bitcoin that things they didn't think were possible are now possible, or things that they thought were possible actually aren't possible.
Kevin Rooke - 00:52:26:
What are some of those examples? Maybe in the past of software coming in and then people realizing that I didn't think that was possible, but it is.
John Light - 00:52:36:
Well, I think one example would be, which is more so, the latter example that comes to mind of like something that you might have thought was possible but isn't, or you didn't anticipate, say a certain restriction is with the Taproot and Schnorr signature upgrade that just happened. I don't actually remember the technical details off the top of my head, but there was some discussion about a particular use case and they realized like, oh, actually, the way that Schnorr was implemented, it doesn't actually support that use case, which was not expected as far as I could tell from the discussion. I wish I had the details off my head for that one, but I don't. I could send you a link later. Maybe you can share it in the show nodes or something as a reference for people who want to look at that. But I think one example of like things that are possible that maybe people didn't anticipate. Where things like counterparty or Omni I think it's called now Omni protocol. Which are like new types of financial protocols that people are building on bitcoin that can do things that you can't do with normal bitcoin script. But people are doing different types of tokens and like DEXes and a bunch of defy kind of things that you might associate with like MEV or some of these other more kind of harmful types of smart contracts that you see on other blockchains. But you can do those transactions now on bitcoin because of off return and other types of ways of embedding data in the bitcoin blockchain. And so I would say that is either an unanticipated or at least maybe undesirable way of using the bitcoin blockchain. In some people's opinion. When you first look at bitcoin, it's not intuitive that it could be used for that way, but people have figured out how to like hack hack bitcoin in a way to use it for these totally different types of use cases. Like not necessarily peer to peer electronic cash, but actually building financial protocols with different types of assets on top of Bitcoin.
Kevin Rooke - 00:55:41:
Right now I want to shift the conversation a bit to the Lightning Network and how these two ideas interface with each other. Right. Lightning as payment channels and then rollups. What are the similarities and differences? Do they complement each other? Is one a replacement for another? If rollups are implemented, how will these two interact?
John Light - 00:56:13:
So, I'll start with by talking about comparing Lightning and rollups. So perhaps the most important difference is the state model. So, rollups have a global state model, meaning that all users of a rollup, and indeed perhaps the entire world, is aware of the state of the rollup because it's publicly published in layer one bitcoin blocks. Whereas Lightning has a local state model where only the parties to a channel know what the current state of that channel is. And this has implications for the usability of these different protocols, or like how the protocols are used. So with Lightning's local state model, the implication is that users have channels open to each other, those channels have balances, and the users are only able to send or receive as much money as they have liquidity for in their channel. Whereas with a global blockchain state model such as rollups, users are able to send as much money as they want to other people, as long as they actually have that much money in their address without needing to open any channels with these other users. And they're also able to receive as much money as they want from other users as long as those other users have that much money. So the same way I can just open my bitcoin wallet and send you an arbitrary amount of bitcoin that I have in my address to your address, you can do the same thing on a rollup. Whereas with Lightning I can only send you as much bitcoin as we have available as liquidity in the path between my node and your node. It's a different model of usability, imposes different constraints on how the protocol is used.
Kevin Rooke - 00:58:48:
John Light - 00:58:50:
I would say that those are the main differences in terms of usability. Another difference is in terms of the functionality. So Lightning transactions can be like no more complex or like no more powerful than bitcoin layer one transactions. And the reason for that is because Lightning is settled on Bitcoin layer one. So bitcoin needs to be able to interpret the scripts that are used to send and receive bitcoin over Lightning. Whereas with a rollup layer one, full nodes don't need to be able to directly execute the logic of transactions that are happening in a rollup. All they need to be able to do is to verify a validity proof. So you could in theory have a blockchain that supports, you know, like EVM style smart contracts written in an EVM compatible language like Solidity and have those transactions executed off chain and then verified by layer one full nodes simply using a validity proof. They don't need to know how to speak EVM or any of the languages that are EVM compatible. They don't need to know how to actually execute those transactions. All they need to know is how to verify a validity proof. And so the types of transactions that you're able to do using a validity rollup is like, you know, they can be arbitrarily complex or expressive or powerful, however you want to word it.
Kevin Rooke - 01:00:44:
So I want to make sure I understand correctly then, that validity rollups could be used for more complex transactions, maybe higher value transactions, where you're not dependent on a, you know, channel capacity like you are on Lightning. And Lightning is going to be bitcoin only send receive transactions, and it's probably going to be lower value transactions because there is some capacity limitations when it comes to the channels you're connected with. Is that roughly the right idea?
John Light - 01:01:18:
Yeah, exactly. And then maybe the last thing I'll mention is the difference in throughput. So although you are limited to the channel capacity with Lightning, you're not really limited in terms of your throughput, except how fast can your node send a message to another node over the internet and how fast can that other node verify that message and maybe send you a response? So basically, Lightning can be as fast as your computer can do like ECDSA operations and send messages over the wire. So Lightning fast, right? And you can do that an arbitrarily large number of times as much as you're willing to pay the routing fees, if there's a routing fee involved. Whereas rollups, their throughput is limited by how many transactions can fit or how many rollup transactions can fit in a layer one block. So, I mentioned with the account model rollups, you could fit theoretically like as much as say, 250,000 transactions per block. That's your upper limit of like, how many transactions you can do within a 10-minute period of time on the rollup. Whereas with Lightning, you could imagine an application where you're sending one transaction every few milliseconds or something like that, and you could have thousands of transactions happening or millions of transactions happening in that same ten minute window of time. And it's totally unconstrained by the layer one block space that's available.
Kevin Rooke - 01:03:17:
John Light - 01:03:17:
So, rollups might be most appropriate for like, higher value, lower latency, lower volume, more expressive, or more private transactions, whereas Lightning is really great for lower value, higher volume, higher throughput transactions.
Kevin Rooke - 01:03:45:
Right. Now in your paper you mentioned Lightning Network, as I'm just reading here, one of the most popular off chain transaction execution protocols. And you also go on say that these off chain protocols are designed to take resource load off of the base layer full node network. So now that Lightning has been out for four or five years, what is your assessment of how well the Lightning Network is accomplishing that goal of taking resource load off the base layer?
John Light - 01:04:20:
That's a really good question. It's hard to answer because of the way that the Lightning Network is constructed. Like because nodes can do transactions directly between each other off chain, it's hard to get, maybe even impossible to get an accurate picture of how much transaction volume is actually occurring on Lightning. You can talk to individual node operators and maybe some of the operators of the more popular nodes to just get a sense of like how much volume is coming through your node in a given period of time. But due to the topology of the network and the overall way that the protocol works, I would say it's impossible to really know how many transactions are really occurring on Lightning. But based on some of the anecdotes that I've heard from node operators that present at conferences or talk about these things on podcasts and such, it does seem like there's a significant amount of volume that is getting taken off of the bitcoin blockchain and it's now occurring on these higher level networks, Lightning specifically. So I would say as much as Lightning has been adopted, it is doing the job that it was designed to do. I use Lightning quite often. I would say as much as I can. The opportunity isn't always available when I go to buy something online, but when the opportunity is available and the transaction is below a certain threshold, I'll use Lightning because it's just a better payment experience in my opinion and I personally find that it does the job that I expect of it when I go to use it. So I'm a happy customer.
Kevin Rooke - 01:06:30:
Are there any interesting Lightning apps that you've been trying out lately or you want to give a shout out to?
John Light - 01:06:38:
Good question. I mostly just use the Lightning Network to buy things. So, I think BTCPay server is probably the most user friendly, like, merchant tool that I've seen for doing Lightning transactions. As somebody who's paying to a BTCPay server, the experience has always been pleasant for me. I think in terms of Lightning Wallet, Bitfinex is a go to like recommendation that I give to people if they're just getting started with Lightning. Blue Wallet is another good one that I've been playing around with recently is called Breez. Breez Wallet has a built-in podcast player so you could actually listen to podcasts that support the value to value protocol and actually tip, like send tips to the podcasters as you're listening to the show over Lightning. And I think that's like a really cool feature to be able to monetize your content and have that like a direct financial or economic relationship with your listeners. I hope I see more podcasters doing that and more podcast listeners using value to value podcast apps and throwing some sats in there and supporting the people who are producing the content they're listening to. I think it's a better incentive aligned model maybe for producing content. Those are the ones that come to me off the top of my head.
Kevin Rooke - 01:08:34:
Very cool. Yeah. I can speak to the value for value we've had. I get about 100 plus listeners that send in sats. I can't remember every week or every month, but sometimes we've had a few hundred listeners. I believe that was like maybe 400 in a month. Different listeners sending in different amounts, sometimes really, really small, sometimes big. And it's cool to see the participation. There's always comments. I know there's a bunch of shows that are even doing more volume and getting more sats sent in than my show, but it's cool to see the ecosystem is like, really growing. I started this podcast actually about one year ago, and I think the very first sats that were sent to me were from the creator of Fountain. And it may have only been just him, it may have just been one or two, I can't remember exactly. I'll have to pull up that episode. But I think it was only a handful of people in that entire week after publishing the episode that had sent sats. And now we're looking at like dozens, hundreds. The numbers are easily 10x higher. So it's very cool to see that growth in the last little while. I want to finish up what's that you said?
John Light - 01:09:54:
Number go up?
Kevin Rooke - 01:09:55:
Yeah, number go up with I think.
John Light - 01:09:59:
I called that value to value. You're right, it's value for value.
Kevin Rooke - 01:10:02:
Oh, yeah, that's what I meant to say. I want to finish off with one round I do at the end of every show. It's called the Lightning round. Some rapid fire questions. Are you ready?
John Light - 01:10:14:
Let's do it.
Kevin Rooke - 01:10:15:
I hope you're enjoying the show so far. I just want to give a quick shout out to our sponsor, Stakwork. Stakwork is a Lightning powered platform that generates high quality transcripts from all of your audio or video content. They combine AI engines and hundreds of human workers all over the world who are paid over the Lightning Network to assemble these transcripts. And that's what lets Stakwork create better, faster and less expensive transcripts than anyone else. I've used Stakwork to transcribe all of my episodes on my personal website. You can check that out. I just get the Stakwork file, copy paste and go. No additional editing required. If you want to learn more about Stakwork, you can visit stakwork.com. That is s-t-a-k work.com. Alright, if you have to guess today I believe there are about 250,000 bitcoin transactions happening every day. I believe on chain how many are happening on Lightning right now.
John Light - 01:11:25:
Every day? Like I said earlier, man, it's really impossible to know.
Kevin Rooke - 01:11:31:
I figured from guests on this show I'll eventually converge on, like a reasonable estimate, but I know, yeah, it's impossible to figure it out for sure, but interested in your guess?
John Light - 01:11:45:
Yeah, if I had to guess based on how many nodes there are out there, I guess it's maybe like between 50 and 100,000 transactions. But that could be wildly off. I have no idea.
Kevin Rooke - 01:12:02:
I'll take it if you had to guess when rollups will be implemented on bitcoin, what do you think we're talking? Is this something that maybe is going to come in the next couple of years? Is this something that's a five year or a ten year thing? What does that time frame look like in your view?
John Light - 01:12:22:
That's a really good question. I think it's going to take more time for the community to even just learn about it and digest this idea before we can even start talking about timelines. But if I was optimistic, I think we could do it within five years.
Kevin Rooke - 01:12:42:
Yup, makes sense. Are there any books that have meaningfully changed your view of the world?
John Light - 01:12:53:
That's a good question. I think one of the books that helped me understand what was going on during and after the financial crisis was Ron Paul's End the Fed book, which gave me more resources to look up and more explanations of what was going on. That led me to look up more information and just help me in general kind of like level up my knowledge about what was going on and potentially what some of the solutions might be. So obviously that was a formative book along with his book Revolution. Another book that has been impactful was Samuel Edward Konkin III’s New Libertarian Manifesto and Agorist Primer. Kevin Carson's book. The Desktop Regulator State was really inspiring. Yeah, those are some of the books that come to mind.
Kevin Rooke - 01:14:18:
I got some great recommendations. I've got my weekend reading all set up. Now if you had to hold one asset for the next decade with all your wealth in it, it couldn't be bitcoin, what asset would you hold?
John Light - 01:14:34:
It couldn't be bitcoin. I held it for the next decade. One asset that's really tough because other than bitcoin, I think it's good to diversify because different assets have different, like, security properties, different, like different potential for growth. So, yeah, for me it would be a toss up between like, gold or maybe like square stock or maybe some other crypto assets. Like SOV which is asset for the sovereign protocol, which I'm a contributor to, or maybe like yeah, you said one, so that's already three. It's a tough but yeah, it's really hard. It's really hard to pick because different assets have different, like, risk profiles. And for me, if you didn't exclude bitcoin, I would just say bitcoin hands down. But yeah, if you take bitcoin off the table, it's really hard to decide.
Kevin Rooke - 01:16:09:
Yeah, I think it would be a boring question if I didn't take a bitcoin off the table because probably every guest on this podcast would say bitcoin. Just one more question for you. If you could give a shout out to a builder in the bitcoin space, maybe a company you admire, a person you admire, someone who's building something cool that not enough people know about. Who's your pet? Who do you want to give a shout out to?
John Light - 01:16:40:
That's also a really good question because there are so many builders in the space that I respect and have a lot of appreciation for. I guess one guy I want to give a shout out to is Reuben Thompson, who does a lot of interesting research into bitcoin protocols, like cross chain bitcoin protocols. And he's, like, helped me think through a lot of different ideas that I've been working on, projects that I've been working on in the cross chain bitcoin space. So he's like, a pretty good thinker in that space. If you're interested in side chains and other, like, layer two ish kind of next generation bitcoin protocols.
Kevin Rooke - 01:17:54:
Nice. Thank you so much for the time. This was incredible. I learned so much in this discussion. I'm sure listeners did as well. Where can listeners go to learn more about your work?
John Light - 01:18:08:
So I have a website at Lightco in that's L-I-G-H-T-C-O.in, and I have links to my blog and different projects that I'm working on on the website. Links to my Twitter page where I microblog fairly often, but, yeah, that's the best place to follow what I'm working on.
Kevin Rooke - 01:18:39:
Awesome. Thank you again for the time and I hope we can do it again soon.
John Light - 01:18:43:
Yeah. Thank you, Kevin.