Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Eric Lombrozo: Upgrading Bitcoin with Segregated Witness

Episode Date: February 8, 2016

In the midst of the heated blocksize debate one could be forgiven to think that there is very little Bitcoin developers are able to agree on. Yet, when core developer and Blockstream co-founder Pieter Wuille introduced the concept of segregated witness at the Scaling Bitcoin conference in Hong Kong most of the Bitcoin community quickly rallied behind the proposal. Eric Lombrozo, CEO of wallet company Ciphrex and responsible for running the segregated witness testnet, joined us to discuss the proposal and its implications. Segregated witness, it turns out, does not only provide an elegant way to increase the blocksize via a soft-fork, it also solves transaction malleability and greatly simplifies updating the Bitcoin’s scripting language. It’s a crucial topic and may well enable a new wave of accelerated innovation in Bitcoin. Topics covered in this episode: The various benefits of segregated witness The mechanics of segregated witness How segregated witness solves transaction malleability How segregated witness could increase the blocksize to 2-3MB with a soft fork What segregated witness means for wallet developers How segregated witness could facilitate development of off-chain networks such as Lightning Network The important difference between hard forks and soft forks How segregated witness will allow updates of Bitcoin’s script language via soft forks Episode links: Scaling Bitcoin Talk by Pieter Wuille Let's Talk Bitcoin! #277 Separating Signatures with Segregated Witness Gavin Andresen: Segregated Witness is Cool Bitcoin Magazine Series on Segregated Witness Part 1 Part 2 Part 3 Eric Lombrozo's company Ciphrex This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/117

This is Epicenter Bitcoin, episode 117 with guest Eric Lombroso. This episode of Epicenter Bitcoin is brought you by Ledger, now accepting pre-orders for the all-new Ledger Blue Developer Developer Edition, a Bluetooth and NFC touchscreen hardware signing device. Learn more about the LedgerBlue at LedgerWall.com and use the discount code Epicenter to get 10% off your first order. Hi, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and people driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kutjou. And my name is Brian Fabian Crane. We're here today with Eric Lombroso. He's the founder and CEO

of Cyfrix. And it's kind of a long, long-standing Bitcoin user, Bitcoin developer and also Bitcoin entrepreneur and Bitcoin Wall developer. And we have them on today to talk about segregated witness. Now, recently I was listening to a whole bunch of Bitcoin podcasts, and I I also listened to and learn a bit about segregated witness. And I was like, I'm a little bit out of the loop with Bitcoin, which I felt was a bit embarrassing. But also, this is really exciting, super exciting development and projects. So I'm glad we have a chance today to dive into segregated witness with Eric, who is also running incidentally the segregated witness at Test Network. So thanks so much for coming on today, Eric.

Thank you. Thank you very much. So, to get started, can you tell us a bit about how you got into Bitcoin and what has your involvement in the spaces looked like? Yeah, so I guess it was around 2011. I was at a party and some friends started telling me about Bitcoin and had some ideas for some games and I started, you know, tinkering with it. And I pretty much got hooked on it right away. And that's basically what I've been doing ever since. So I started building some apps first, and then I realized that there were some things that I would like to have as far as libraries or other kinds of tools.

And I started building that. And from that came Cyphrix. I don't know what kind of party you should go to. People are talking about Bitcoin, but that was definitely a good priority to be at. And so how long have you been, well, how long ago have you founded Cyphers? Cyphrix got started. I mean, it was based on the work that I've been doing since I first got into Bitcoin. But the company itself was created in 2014, and we incorporated last year.

And so we can talk a little bit more about Syfax later. Now, besides Syfx, have you also been contributed to, I think, Bitcoin Core, right, and done a variety of work? So how did you end up getting involved with the segregated witness work? Well, I mean, I've been working with Peter Ruella quite a bit. He was one of the first people that I really worked with when I first started contributing to Bitcoin Core. And he'd been working on this segregated witness idea for the side chain stuff that he'd been doing with Blockstream. And that was with, you know, the Yellowman's Alpha project. But it turned out that it was possible to deploy this on the Bitcoin mainnet with,

with a nice trick that was discovered not too long ago. This was figured out just a few months ago. And I started talking to him more about how we could actually deploy this and whether it was actually practical to do so. And it really started to look very promising. So after, you know, there was the Hong Kong Scaling Bitcoin conference where this idea was kind of presented for the first time completely. And he'd already been working on.

out some code and I started grabbing the code and running it and figuring out how we could start building this test and so we could deploy it quickly and we could start building apps. And I quickly started working on my own applications. I have my wallet, M-Signa and I started trying to just play around with that and hook it up to that. And yeah, so here we are. And so when in Hong Kong, how was it received this? of this proposal.

I mean, it seems like everyone liked it. I mean, it was definitely a hit. It seems like there's very few people that think there's any kind of downside to it, really. I mean, it's just kind of like the best of all worlds. It solves so many problems that we've been trying to fix with the protocol. It really enables a lot of things that were really difficult to do before, if not impossible.

And it gives us a whole new mechanism for being able to really upgrade the protocol and deploy new stuff, you know, this whole extensibility framework, which is really exciting because you know it's really hard to change consensus rules. And this gives us an opportunity to really be able to set up the system so that we can actually deploy things in the future in a way that's much more systematic. So with that in mind, what is the segregated witness proposal? So transactions have basically two components. One part is the part that moves the coins. So it says, you know, coins that are in this part of the blockchain

are not going to be in this part of the blockchain over here. And then there's the other part which authorizes the transaction. This contains the script and the signatures. The script and the signatures are only used to validate the transaction, to make sure that the transaction is actually valid. It's properly signed. Once the coins have moved, all the programs really care about is where the coins are and how many coins are there.

So by separating this out, it allows us to optimize a lot of things about the consensus layer and the protocol so that we can do much more sophisticated kind of scripting. We can do much more intricate, you know, chaining of transactions. It solves the maliability issue. We can do much better, you know, validation cost metric kind of stuff where it gives us much more freedom to extend the structure. And it allows us to do a lot of these stuff with soft works. So this is a really great thing because before it was thought that a lot of these things that would require basically an incompatible change to the software. Now we can actually deploy these things in a fully backwards compatible way.

So do I understand that correctly, right? So let's say you look at a transaction that happened, you know, a year ago, something like that. So you see in the blockchain, you know, it went from these inputs to those outputs. And you also see in the blockchain, you know, the signature. But of course, you could say that, well, it's actually enough. to just see that, you know, the inputs and outputs back then because a miner validated it back then and sort of everybody has built on that. So, you know, we trust all that history, hence we actually don't need that signature from back then anymore. Right. So that's one thing we can do is,

you know, we can do a lot of pruning. So ancient history can be pruned. You know, there's a certain a reduction of security, but if you go back a year, it's going to be really, really difficult for someone to reorg the blockchain that far. So you could pretty much safely throw away a lot of this stuff that's really old. Also, you might only be interested for some transactions to store this data. So you could do selective pruning. So there's a lot of interesting optimizations you can do with that, yes. So what are some of the cases where you would want to save that data rather than discard it

after a certain period of time or after this has been validated by miners? Well, if you want to be able to fully validate the blockchain, you're going to have to have this data. So someone on the network is going to want to store this data just so that you can do full validation, if you don't want to have to do checkpointing. So there is an incentive to keep this around for a long time, but you don't actually need this data to be able to construct transactions to spend the outputs from these other transactions. So it doesn't affect any of the future logic. Once the transactions in the blockchain, it's confirmed.

Basically, this data is no longer needed unless you wanted to validate for yourself. So there's been a lot of work, I think, on pruning the blockchain already. Why is this different and why is this interesting? Well, to be honest, the pruning part of it is interesting, but that's actually not the coolest feature of this. There's a lot of other stuff that we can do with this that's much more interesting. This is just something that it's nice to have. It's nice to know that we can throw this data away. But I'd rather get more into the other features, which I think are what people are really excited about with segregated witness.

Well, please, go ahead. Tell us what those features are. So the first feature that, you know, one of the main motivations for it was fixing the maliability issue, right? So transaction maliability is caused by the fact that the transaction ID, the, you know, the TXID, is the hash of the transaction, and the way that the system was originally designed, the hash included the signatures, which means that if you change the signature, it would change the transaction ID. And the way that the signature system works, you can have different signatures that sign the same transaction. Different signatures could be valid for the same transaction. So this makes it simple for someone to be able to maliate the transaction and change the transaction ID without actually changing the inputs and outputs.

So the transaction does the exact same thing, but it has a different ID. And this is a serious problem, especially if we want to go into off-chain protocols where we want to be able to change transactions. Right now, if you want to change transactions, you have to wait for one transaction to be signed before you can create the next transaction that spends that one. Because until you know the actual transaction ID, you cannot sign the next transaction. You cannot refer back to the transaction that you're spending. When you take this out, when you take the signatures out of the transaction ID, this means that you can actually sign transactions out of order.

You can create a whole sequence of transactions and sign them in whatever order you want. And of course, unless the previous transactions are signed, the dependencies, you're not going to be able to confirm the later ones in the blockchain either. But this allows us to construct much more sophisticated logic where you can have transactions that have contingency conditions where, you know, depending on what happened before, you know, whether there's some. certain transactions in the past get approved, you know, you can have certain, you know, ways of, you know, certain scenarios that you can make happen after that. And then this is very critical for certain things like the Lightning Network, you know, off-chain protocol transactions by directional payment channels where you want to be able to be doing most of the, you know, this smart contract negotiation off-chain.

You don't want to be going on-chain every single time. And you want to make sure that you can share transactions that are, going to be spendable on the blockchain without necessarily signing them yet. So people can be holding onto these transactions ready to broadcast on the network if necessary. But it's just, you know, most of them will actually never actually get on the blockchain. It's just you have that option to get them on the blockchain. This allows us to have much more flexibility in the logic that we can create with these smart contracts. Okay, so you can, okay, I hadn't thought of that.

So you could have just a bunch of transactions that are. chained, well, that are dependent of each other. So, for example, you could have one address sending money to another and that address sending money to another and that address sending money to another and not sign them until you, until they need to be broadcast to the network. And the fact that there isn't that ability to change the transaction ID makes that possible. Correct. Exactly.

So taking a step back, can you run a... through exactly how segregated witness works. So we've talked about, you know, separating the transactions from the signature. How does that then play out? What is done with the signatures? What is done with the transactions? So right now, transactions have scripts on both the inputs and the outputs. The input script is the one that usually contains the signatures. The output script is the one that contains the address. It's the, it's what you're sending, you know, coins to. And it indicates where you're going to be sending the coins to. That one usually doesn't have the signatures. So, with segregated witness, what we're doing is we're basically clearing the input scripts. The input scripts are

no longer going to be used as, you know, we're moving all that data off to a different structure, which is, which is, which can be sent together with the transaction when it's relayed. When it's, When it's broadcast on the network, it all goes together. But on the block itself, it's committed separately. So you have the main Merkel tree for the transactions, which is, the root is stored in the block header, the same way that it's working right now. And you have this other commitment. And this other commitment is just for the witness data. And this witness data commitment is something that we can extend further later on.

So even though there's a block size limit with the block Merkle tree, we can still add additional data. data to this other structure that's committed separately, which allows us the flexibility to increase certain things that otherwise would have required a hard fork. So we can actually do this with a soft fork. So you said the data is sent together. So for example, let's say a regular Bitcoin node, would that mean I can choose as a node, whether I want to look at the signature data and valid? that or I could say I'm just going to ignore that.

Do you have, for example, that choice? Right. So if you're running a full node, you'd want to validate everything. So you'd want to be receiving the whole thing. But you only need to receive the transaction data itself and not the signatures if you want to know the state of the blockchain, if you're not doing any validation. So for instance, for SPV nodes, they might not be requesting all the signature, I mean, all the witness data, which contains the signatures. That would be enough to know that they received, you received Bitcoins, and then they would be able to look at their entire transaction history.

If you want to validate, then you do need this data. But the key thing here is that even though it can be related together, it's committed separately. So instead of committing all the transaction data into the same Merkel tree, you have two separate trees in the block. And this data can be committed in two separate places, which makes them independent. This allows us to update the witness data independently of the transaction data. And so just briefly, when you say, you know, they're both, you have two different Merkel trees in the block. What do you mean is that, you know, this Merkel tree then determines links to all the witness data so that, you know, it's always clear what block and what witness data go together.

Sure, sure, yes. And where is that put in the blockchain? So initially we were putting it in, I mean, it has to go in the Coinbase transaction. This is an unfortunate way that the way Bitcoin was designed. The block headers don't have any more fields where we can stick stuff in. So the only place that really we can freely stick stuff in is the Coinbase transaction. You know, the first transaction where the miner actually gets the block reward. So the input of the Coinbase is where a lot of stuff used to be put in transactions.

And that's something that's been used for several things like identifying the mining pool sometimes puts their own identifier in there. The block height is stored in there, et cetera. But it turned out that some miners, some mining hardware had already been designed that made it hard to stick this data in there. And so we went for putting it into one of the outputs. So there's actually an op return output in the coin-based transaction. And this is where the commitment for the Merkel route for the witnesses is stored. So basically it's like an additional data field in the coin-based transactions. So that means, you know, if you talk about miners now, so if I'm mining a block and, you know, I'm just not going to do that, that then means that what does that again?

exactly mean. Is it possible to, for example, you know, mine a block with transactions, but I don't put the Merkel route to the segregated witness signatures in there? Well, once the soft for activates, all miners have to include the Merkel route. That's, that's what makes it a soft fork. You know, blocks before it didn't have to have this, and now it needs to have this. If it doesn't have this, it's not a valid block anymore. So as a miner, you would have to put the Merkel route for the witnesses in the coin-based transaction for the block to be valid. So it would still be a valid block according to the current rules, right? It wouldn't be a valid block anymore to the updated clients.

Correct, yes. If it doesn't have the Merkel route for the witness data. So what are some of the other advantages of this approach or things that we can do with, through secondary witness that we couldn't do before. Well, another really, really neat thing is that since we're moving the script data also into the witness, this allows us to have an upgrade mechanism for the script. We can basically replace the entire script with a new script. Before it was thought that this was very, very difficult to do without requiring a hard fork.

This was because you would have to have new opt codes that could do other stuff. with the stack rather than just either succeed or fail. This means that we can have op codes that can add new functionality that was very, very difficult, if not impossible, to do before. We can basically replace the entire scripting language with anything we want. Okay. Can you explain how this is possible? How does the signature relate to what type of scripts you can write?

Right. So as I said before, the script, is stored in the input right now. It's part of the input of the transaction. But we're moving it out into the witness. So now the input is clear. To old nodes, it looks like an anyone can spend transaction, right? This is the same mechanism that was used for BIP 16 when multisig was rolled out.

So since it's an anyone can spend transaction for old nodes, the new nodes can use whatever rules they want to validate the transaction. So it's a nice little way to get around this limitation. it allows us to create any kind of script. The old nodes are going to basically just ignore that script. They're not going to look at it and they're going to consider it valid. The new nodes are going to be able to look at the script and run the script, and we can put whatever we want there now.

So the first version of this is just going to be the script that we have now, the scripting language that we have now. But in the future, we're looking at adding other kinds of op codes or other kinds of scripts. Some of the op codes that we're looking at adding are new kinds of signature types. We're looking at the snore signatures and other kinds of interesting things that we can do with. Another thing that we can do is op codes that can manipulate the stack in ways that we can do right now. Right now we have all these new off codes that were added that are all just verify, you know, check lock time verify. These off codes can basically are either no ops or they exit with an error.

They basically exit false. with with with with with with with with with with with with with with with we can move it we can create new opcodes that that that don't need to be executed by the by the old clients this gives us a full flexibility to be able to create opcodes that do whatever we want so so this is a really really neat thing I mean it's just one of those things where it's like what can we do with it well pretty much anything I mean it's it's it's a whole new a dimension of you know of the you know of the you know of ideas that we can really explore here so

So by taking the script and moving it out of the block and into this witness part, what you're essentially doing is you're allowing those to choose, to create new codes that would be run sort of as a soft fork? Is that accurate? Yeah, exactly. Yes. So when we want to deploy a new scripting language or a new op code, it would be done as a soft fork. And so the script has a version byte, which tells you what, you know, which version it is.

And so every single time we want to deploy new one, we just bump that version up, and now we can have a completely different, you know, different scripting language with different op-goats and, you know, do whatever we want with us. Okay. So then nodes that would understand, notice that choose to run this new scripting language could and others would simply ignore it. Yeah, they would just ignore it and just return it. true. Okay. So could you give us an example of how this would work? And by that, I mean,

so if some group wanted to try new functionalities and implement new op codes, what would they have to do? How, like, they don't have to update their clients, I suppose. Right. So for this to be deployed, it would have to be deployed as a soft fork, which means that you would have to propose it, implement the code, put it out there, and then use an activation mechanism. So right now, we use 95% for activation. So as soon as 95% of miners signal that they support this new feature, that triggers the change and it locks it in. So after that point, you need to also validate that if you want to make sure that the block is valid.

Let's take a short break so we can go to Paris. I stopped into La Maison of Bitcoin, the House of Bitcoin, at the Ledger offices, and I met with Ledger CEO, Eric Lachsovec, so he could tell me all about the ledger wallet Chrome app. The Ledger wallet Chrome app is the perfect companion app for your ledger, HWN or Nano. We have very powerful and cool feature. You can use multi-accounts, for instance personal accounts, business accounts, this is very useful. Also when you want to make a transaction, we use a second factor verification. You can either use a physical security key or cryptographically securely pair your Android or iOS smartphone.

to your nano. This way, when you issue a transaction, a payment, the transaction will pop up on your Android or iOS phone and you will be able to verify the amount and destination address. Finally, the Ledger Chrome app has an API with which you can easily integrate third-party applications. For instance, if you want to create a multi-signature account with CoinCite or COPE, it will be done using the Ledger wallet Chrome app. Ledger is making hardware wallets easy and convenient without compromising on security. If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the code Epicenter to get 10% off your order. We'd like to thank Ledger for their support of Epicenter Bitcoin.

So you mentioned Bib 16 and how does that compare with Big C? So Big 16 was also a soft fork? Yes. Right. So the difference here is that. well with BIP16, there wasn't a version bit, right? So there's no like different things. And also how else is it compared to how a multisig was implemented?

Yes. So the multi-sig obcodes actually already existed. Satoshi put them in there from the beginning. But there was no simple way to use it. We have this, you know, BIP 16 basically was paid a scriptash. It allowed us to, instead of paying to a Bitcoin address, which is a hash of a public key, it allows us to pay to a hash of a script. And the script can be anything.

So this gives us much more generality. So it was also a soft fork because to old nodes, it looks like anyone can spend. Basically, these transactions, the whole script that is hash does not actually execute it by the old nodes. The new notes do have to execute that, and they check to make sure that it does return true. But with Segwit, it's not just that the script executes, it's that you can actually define different kinds of scripts. You can add a new kind of script. And to the old nodes, it would just be like, you know, they would ignore it, like you said. They wouldn't know how to evaluate it.

So they would just ignore it and return true. The new nodes can interpret it using the new synapsics. Right. But so you could really have used the same mechanism back when, you know, paid a script hash was implemented to do, you know, some other things that are more complicated, maybe some of the things we're talking about now with segregated witness. Yeah, actually, that's true. There was an opportunity there to maybe do some stuff. Unfortunately, at the time, it wasn't really, you know, people were not thinking that far ahead as far as, you know, these kinds of. of deployment mechanisms, it was really for the, you know, the main, the main objective there was

the multi-sig stuff, you know, to be able to use that and to be able to deploy, to use other kinds of scripts that used to be non-standard, to make them standard by being able to use a P2SH, paid a script hash to be able to have these transactions relayed. So, so I don't think back then, really, people were thinking about, but you're right. I mean, in print, this kind of mechanism could be used for something like that. It's very similar. I mean, Segwit uses a very, very similar mechanism. Right, very interesting.

So I saw someone mention that, you know, this could be used for Bitcoin to implement like Ethereum-like scripts. What could that look like? Can you have like a sort of full-blown smart contract language there? Well, yeah, I mean, in principle you could do, you know, a lot of things. The Ethereum scripting language has a... language has much more state space, you know, it's much more stateful. It has a, it's, it's got an execution environment that's much more complex than Bitcoin. You know, it's got this

whole random access, you know, model that makes it a much, much more complex to, to optimize and to make it actually, you know, run fast and scale and all that. So I think that with Bitcoin, really the focus is on trying to use the same. scripts mostly for the cryptographic stuff. There's other stuff that's also included in the scripts. There's time locks and hash locks and stuff like that. But the idea is, I mean, in principle, you could have much more sophisticated scripts, but we're really trying to find ways to not extend it to the point where it's really,

really, you know, two resources intensive, and it makes it really, really hard to scale this. You will still have the 10-minute blitzers. block them, right? Or could you have some sort of like, you know, sub blocks that, you know, maybe are more frequent only in that segregated part, but only, you know, there's kind of the money movement remains at the regular Bitcoin block interval. Would something like that be possible? Well, I mean, I don't think that with this proposal right now, you know, we're really looking to do something like that. In principle, I mean, there's been several proposals for those kinds of, you know, side blocks or, you know, ghost or other kinds of schemes. I don't, I think that,

you know, most likely we're not going to be looking to do anything like that in the very near future. So we had identified a list of things here that are made possible by this. And some of The other improvements that it can offer is something called fraud proofs for SPV clients. Can you talk about what that is? Yeah, sure. So in the original Satoshi White Paper, it was mentioned that SPV clients, if there was a way to have fraud proofs, it would improve the security because it would only require one whistleblower on the entire network to notice that a block is invalid. and then all SPV nodes could know more of that block. So right now, if you're running an SPV client,

you get a block that confirms a transaction, and unless you are able to validate the block, you just accept the transaction's confirmation because the rest of the network seems to think it's okay. But of course, miners might not be, you know, they could be cheating or, you know, they could be running buggy software. This has actually happened before

where miners are not validating correctly. And then SPV clients are going to, going to see confirmations that are not actually real. So this is an issue which Satoshi considered fixing, you know, a potential fix would be if it was possible to make it so that, you know, even if proving that the block is valid is expensive, it still requires downloading the whole block and checking it, maybe making it so that proving that the block is invalid could be made cheap. So you could have a very short proof that demonstrates that the block is invalid. And if you could create this, that means that it will only take one note on the

entire network to, you know, to construct this proof and propagate it. And then all the nodes would know immediately to ignore this. But there's a significant problem with this, which is that it requires extreme censorship resistance. Like, for instance, if you're connected through your ISP and your ISP decides to block these messages, there could be potential attacks there. So it requires, you know, it requires more security assumptions. But on the other hand, It does mean that, you know, the incentives model shifts more towards, you know, people actually wanting to validate because it's more likely, you know, validating correctly because it's easier for someone to, it's harder for someone to get away with it.

So just the knowledge that if you try to do this, it'd be harder for you to get away with that could make it so that people are less inclined to try it. So fraud proofs are a really interesting thing. They still have a lot of problems in principle, and I think that some of these things could potentially be fixed. With the original way that the Bitcoin was implemented, this was something that seemed very, very difficult to do, because if you want to check whether a block is invalid, you need to have partial proofs for different things. You need to be able to check, for instance, that the coin-based transaction that doesn't pay the minor too much, that the fees are correct in all the transactions, that all the transactions to spend coins that actually exist, et cetera, that the signatures are valid. So if you can separate all these different checks and make it so that you can prove that any particular one of them failed, that would be enough for a fraud proof. So for instance, if you can just prove that one of the signatures and the transactions is invalid, if it's necessary, that's enough to show that the whole entire block is invalid.

Or if you can prove that the minor paid himself too much in fees, that also is able to prove right away that the block is invalid. So with Seg, we can do this because now that we have this extensible commitment structure, the second Merkel tree, we can insert their additional data about the transaction, about the transaction inputs in particular, that allows us to do back references where we can actually see where the coins came from and use that to prove, to construct short proves that, for instance, a particular coin that was spent doesn't actually exist. You can actually go back in the blockchain and look in that location. And if the coin that's supposed to be there is not there, then you know that that block is invalid.

So this is how it lets us do these kinds of things. But I should note that for the first release of Segwit, we won't be doing fraud proofs right away. This is something that's for some, potentially some later release. One of the nice things is with this extensible structure, it allows us to do incremental deployments. We don't need to put all the features and pack them in right away. We can put the features in later on as we have. have already tested the whole system and we've done more research and figured out how we can actually do this. So just a little bit more on the fraud-proof question.

How exactly would that work? So who, now I'm a miner. I'm mining a block and I'm also this, this extended, segregated witness data with all the the signatures, where would I include a fraud proof in there that relates to who? Or how exactly would that work? So what happened with the fraud proof is that you need to have a commitment structure that can track the stuff necessary for someone to construct the fraud proof. The commitment itself would not have the fraud proof.

In a valid block, you don't have a fraud proof because there's no fraud, right? The fraud proof is constructed when a block is created and propagated on the network that is invalid. So someone would look at the block and run all the tests to validate the block. And if any of those tests fail, they would be able to point to exactly what failed and how it failed by using that commitment structure. For instance, if the commitment structure stores the input values, right? So it knows exactly how much each particular input spent and it knows the output values, then you could calculate the fees from that. You can see that the fees actually add up correctly

and the miner is not paying him or herself too much in fees, right? Okay. So do I understand that correct? Basically, right, today with a block, like I can validate it. I may see that there is something invalidate about that block, but the problem is I can't like prove to someone else bit like very easily that it's something invalid because of the way Bitcoin blocks.

or constructed. But now with segregated witness, we can think ahead and you can say, okay, let's construct the segregated witness data in a way that makes it really easy to prove if something is invalid, so I can submit that. Exactly, exactly. Okay, that's very neat. So let's talk about one of the other advantages of moving to segregated witness, and that is addressing in part the scalability issue.

Now, it addresses it by allowing us to add more transactions into a block because essentially as we remove the signature part and move it to some other data structure, those transactions are much smaller in terms of the data footprint. And essentially, we can fit more transactions into a one megabyte block. Now, you mentioned that that wasn't the biggest advantage, although to some, it may seem like such a huge thing because we've been talking about block size for so long and trying to come up with solutions on how to put more transactions into a block without affecting decentralization, without affecting having too much bandwidth go through to miners. Can you describe to us broadly what segregated witness brings in terms of scaling Bitcoin to have more transactions in the block?

and what are some of the pros and cons of that solution? Sure. So, I mean, short term, yeah, I mean, growing the block size can provide more throughput. You can stick more transactions in a block. But long term, that's not going to be a viable scaling solution because if you want to, you know, scale this to global size, we're talking, you know, several orders of magnitude. It's not just going to be two times or four times or 20 times. And we have to scale this up a thousand times to compete with, you know, the large payment networks right now or more, right? So to be able to reach these kinds of numbers, the block size.

alone is probably not going to be able to get us there. But at least in the short term, it does provide a bump. And I know that a lot of people in the industry have been kind of craving this bump because, you know, allows them to at least, you know, hold on, you know, a bit longer until we have better technology. But I think that, you know, the neat thing about doing this with Segwit is, you know, the compatibility aspect. It doesn't require everyone to upgrade right at the same time. It's not going to fork the blockchain. It converges. You still have a single blockchain, and it allows people to upgrade incrementally, and it's backwards compatible.

So these things mean that it's much, much safer to deploy this than to deploy a hard fork block size increase. If we just increase the block size, you know, by changing a constant in the code, yes, it's easier from the perspective of, you know, fewer lines of code that need to be changed, but it's much more of a hassle in terms of the network. stability. It actually causes some very, very severe problems in network stability, both on the technical and the political levels, as we've been seeing recently. And this is a direct result of changing something that makes it not backwards compatible. So the backwards compatibility aspect is huge. This means it gives us a much, much, much bigger safety margin. And it's something very similar to what we've already done before, like we saw with BIP 16 with the multi-sig stuff. And that was deployed very, very safely. You know, no incident.

there. Multisig is super secure, everything's working fine. This is something where we discovered that we can actually get an effective block size increase without breaking old clients. And this is huge. This is something that means that it gives us a roadmap that can lead us to having short-term bump. And also it gives us the other features that I talked about, particularly the maliability stuff. If you fix the maliability issue, this allows the develop. of second layer networks. So like lightning network and off-chain protocols. And once you start the innovation there, you can have a lot more, you know, several

orders of magnitude scaling in the sense that no longer does everything need to be propagated on the Bitcoin network, you know, throughout all the peers, not all the peers need to know of all transactions. You can actually have, you know, smart contracts negotiated directly point to point between different peers. And they only need to commit, you know, they only need to settle. at the end of, you know, once everything happens. So if a whole bunch of transactions happen on the network and the net, you know, they all net out to zero,

nothing needs to happen on the blockchain. You know, only whatever is net out from that needs to be committed to the blockchain. So the Malibility Fix allows us to really, you know, start looking at other kinds of approaches that I think are really what people are much more excited about than just the block size increase. Of course, people want block size increases. We've been talking about it forever. and we still get that. We're still going to get, I mean, it's not just the virtual block size increase.

It's a real block size increase. It's just that we're not increasing the block just, you know, the same portion of the block all together. We're separating out a part of it, which is being counted differently, which makes it back, which allows us to make it backwards compatible. Right. So if you think about scaling, because the thing people have always been worried about when it comes to increasing the block size and I think the most convincing argument was always, is that this actually creates centralization pressure

for miners because bandwidth plays a big role. So if blocks propagate more slowly, it helps big miners. Now here, that doesn't really change anything, right? So if you had like a three megabyte block that, you know, the core block plus the secondary witness part, that's really equivalent from a sort of decentralization perspective as if it was, you know, just a three megabyte block. Is that right?

Right, yeah, right. I mean, that's true. And so basically we have a choice now. We can either do this Segwit thing, which is going to have the same bandwidth implications, or we could try to actually, you know, do a hard fork. But, you know, the hard fork is just going to be a bump. I mean, immediate bump. It's not going to give us any of the other scaling benefits.

And it has all the destabilization issues, you know, especially with the political stuff and the potential for future attacks. You know, contentious, hard forks, people in the future deciding that they want to try to control the consensus rules and, you know, jumping in with, you know, trying to, trying to get all miners to do something and basically forcing people to move to a different network. So, so, so, so we're really trying to avoid situations that are conducive to that kind of dynamic because, you know, if you really think about the implications of that, it doesn't bode very well for the network, you know, for the, for the long-term stability of the network.

So I honestly never really understood that argument, because it's, seems to me that, you know, if you looked at like BIP 101 or something like that, right, you had that mechanism that you had to have a large majority of miners, you know, agree to it. And then you had like a fairly long period where, you know, they had agreed. So it was clear it was going to happen, but it wasn't happening yet. So it essentially gave, you know, people on a network a long time to upgrade their clients. Now, why is that such a risk? Well, it's a risk because, you know, what if it doesn't reach the 95%?

What if it stays like a 50% for a while, you know, 60% or 70%? You know, it's a lot of uncertainty. And once it breaks one way or the other, you're talking about two incompatible ledgers, basically. People that did not want to change into the new rules are going to be, for. forced to either change to the new rules or are going to be thrown off the network. With a soft fork, you have better security if you upgrade, but you're only adding more rules. You're not changing, you're not eliminating any of the old rules that you had before.

And the dynamics make it much harder for any single entity to come in. The most important factor here is that it will always converge. you always have convergence for the soft fork. As long as there's a super majority of miners, one of the chains is always going to be the main chain. In the case of a hard fork, even if there's only this 5% that kind of like don't change, the users of that network might not necessarily even know

that there was a fork, and they might see just like the hash rate suddenly drop, right? And it could be much more easily attacked. So I think we're seeing right now is a situation where people, people can, can do a lot of posturing and, and, you know, kind of like, give the impression that there's going to be a majority of, you know, of hash power on a particular fork. But, but maybe they'll play a different way. You know, people don't have to tell the truth. You know, when you're, when you're signaling that you're going to be forking,

miners don't necessarily need to indicate which fork they're going to do. And there's a lot of loopholes there and potential attack vectors that happen there because once you have these two different forks that coexist, you know, you can double spend one of them and, you know, without risking losing the coins and the other. So you can have like these kinds of situations where the two chains, you know, can kind of be, you know, fighting against each other. Or you might even have, you know, more than two parties, more than two different sets of consensus rules that are being deployed on the network. And it just, it doesn't seem like it's a very stable, you know, it doesn't lead to stability. Okay. So, you know, this all seems

really great. I mean, all these things that you can do with segregated witness seem like a big breakthrough, right? What are some of the security implications? Are there any downsides to doing this? Well, it does increase the

bandwidth requirements, and you know, since it's a more dynamic kind of limit, it depends on on the sum of both the non-witness part and the witness part of the transaction, there could be situations where you could get blocks that are a little bit bigger in attack scenarios. But I think that that's something that's still very costly to pull off. It's considered to be, you know, kind of like those cases where just, you know, the cost

of the attack is substantial, which greatly disincentivizes it. But I think, you know, some people might be concerned with things like, the degradation of security of other nodes. And I would just say that in any kind of consensus rule change, there's always an inherent risk. And this has happened every single time that we've deployed softworks. And we've already done it several times. And actually now we've actually gotten softworks down to a science.

So it's something that I think we've gotten it pretty much about as safe as we can possibly get it, get any kind of consensus rule of deployment. And I think that, I mean, obviously, with any new thing that we're doing, there's always possibilities that there could be some issues. But we're running tests, you know, we're making sure to run a barrage of tests to try to, you know, make sure that everything works as intended. So regarding tests, you've set up a test net. Yes.

How many notes do you have? How many people are running tests on this new? test net? I believe, hmm, I believe it's like, you know, maybe 10 to 20 nodes on the, I have to check right now. I actually don't have the exact number. It's been a couple of days and a lot more people have been joining, so I don't know the exact number. But it's been growing. It's been growing a lot. And I think that, you know, I mean, it's still small. It's still mostly for developers. So we've gotten a lot of the wallet developers and a lot of the library developers to start tinkering with it and, you know, they seem to be enjoying it. And so I think, you know, there's also,

there's, you know, there's also the need to do more stress testing and see exactly like, you know, if you can push the limits to see, like, if anything is, you know, if there's any issues with, with the other aspects of the system that could possibly potentially break, but everything has been running really smoothly until now. I mean, there hasn't been any issue. So we're very optimistic that we'll be able to roll this out onto Mainnet pretty shortly. Today's magic word is witness W-I-T-N-E-S-H. Head over to Let's TalkBitcoin.com to sign in, enter the magic word, and claim your part of the listener award.

You mentioned a volatile developer, you're a volatile developer yourself. What does that mean for, you know, let's say wallet developers that when you use Segrated Witness transactions. This is a big change? It's actually not that big of a change. The wallet developers that we've worked with, you know, were able to implement it within a couple days, you know, less than a week. It's something that it's not very, very difficult at all. It does require some changes. It's something which some of the, some people in the space of kind of, you know, we're hoping that they wouldn't have to change anything. But I think that as far as changes go, this is a very, very minor change. It does require having to, uh,

recognize this witness data and look at the signatures in there. But this also makes it much simpler to develop a lot of better applications, especially in like the multi-sig space. Multi-Sig transactions with SegWit are much cleaner in a lot of ways. It allows us to stick the signatures into the structure in a way which is much, much cleaner than the way we're doing it right now. So I think that the benefits for, and also, Also, with multi-sig transactions, the throughput increase is greater than with the non-multesib

transactions. So once we, I think that there's a lot of, I don't think that it's something that's really, really that complicated to do. It took, as I said, most wallet and library developers have been able to integrate most of this stuff in a couple of days. Okay, it's really interesting. So what does it look like? seems like there's a kind of universal support for this or you know very strong support

which is an extremely rare thing in in bitcoin land you know it is generally people disagree on most things so what's what's the plan now what's the roadmap and when can we expect this to be integrated well i mean a lot of the the libraries are already you know It's in a pretty advanced state of integration. Once these libraries are, you know, have these are integrated, then applications that use these libraries can start integration. And so the whole ecosystem can can upgrade that way. We think that we are probably going to be able to deploy something onto Mainnet.

You know, we're hoping by April to have something deployable at least. So at this point, it would just be the code that's necessary to activate it. it wouldn't actually activate until there's a minor super majority, 95%, which can happen anywhere from a few weeks to a couple months down the line from that. We're hoping that, you know, we'll see very quick adoption, and we're hoping that, you know, people can immediately start making use of the new features of this. And we're really excited about the, you know, the new kinds of stuff that we can start building, especially the second layer stuff is going to be really, really exciting because

that really, you know, once we start getting into the second layer protocol stuff, we really remove a lot of the innovation out of the consensus layer, which means that a lot of the politics go away. We don't have to deal so much about arguing about, you know, how we're going to change consensus rules and forks and all this stuff. There can be competing networks that can be exploring different ideas without breaking everything for everyone. You can have two different lightning networks. They use completely different structure types or whatever. As long as the consensus layer is the same, no problem. I mean, you know, we obviously want to standardize these things for the whole network.

some point, but it allows us to really experiment with these things without breaking the network. And so what is your, so we were talking about this earlier. And once miners agree to implement segregated witness and we start having wallets and libraries implementing this, is the ambition for everybody at one point, at some point to start using segregated witness transactions to move to segregate witness transactions? Or do you think part of the network will use the old type transaction and part of the network will use SegWitness? Well, for a while, there's going to be both. I mean, not all the wallets are going to upgrade right away. Old wallets are going to work fine. They're not going to need to do anything to be able to

send and receive transactions. You can send transactions from a Segwit wallet to a non-Seguit wallet without a problem and vice versa. You want to upgrade to Segwit. You want to upgrade to Segwit, for all the features that it offers those. So I think that there's a lot of economic incentives just built into this already. People are going to want to do it because it just, you know, it makes it possible for them to give better products

to their users. So this in itself provides the incentive for people to, you know, be doing this. And I think that once we have enough people really using this, you know, everyone's going to want to use it at some point. How long that'll take? I don't know.

I mean, P. When we first deployed a PTA script hash, it took a while until people started to, you know, adapt to the new address types. Here you actually don't need to have new address types. Everything is fully a P2SH address compatible, which are the addresses that start with three in Bitcoin. So any wallet that can send to those addresses can send to a SeWit wallet without any modification right now. And so we're going to probably see a time period where, you know, there's going to be a mix. there's going to be a hybrid. Not everyone's going to upgrade.

But I think as soon as people really start to see the benefits, they're all going to want to migrate to this. And hopefully it won't take that long. I mean, hopefully it'll be much quicker than the migration to multisigig and pay to script hash that we've still been taking a while. And there's also an incentive in terms of transaction fees, right? Because as we mentioned earlier, transactions will be smaller. You can fit more transactions into a block,

which implies that transaction fees should be. Tell us a bit more about how this mechanic. Yeah, correct, correct. I mean, in principle, you know, that this means that, you know, the transaction footprint itself in the block is going to be smaller. Minors can fit more of these transactions in a block. So, yes, this means that the fees in principle can be lower. So this could be another advantage.

Right now, fees are still a very small part of the minor, you know, the minor rewards is, you know, the subsidy is still the vast majority of the minor reward. So if we start to see more competition for fees and prioritization of transactions based on fees, we could expect this to definitely be a significant economic incentive. I think that the initial incentives are probably going to be more just the fact that wallets that support this can offer much cooler stuff for their users. But definitely, yes, I mean, the fees are definitely going to be lower. So I have another question that right now, one of the challenges that I see, right? So if you have different clients, one of the problems with Bitcoin, you know, in my view,

is that there's this kind of one client, and it's really hard to make, like, have a variety of clients because there's a, you know, there's a risk, there's some sort of consensus bug, and then, you know, they'll leverage. And so you have a strong incentive as a user to be sort of on the main client. Is it possible that Segregated Witness would help there to have it more possible to have, you know, different implementations of Bitcoin at the same time? Well, for that to happen, I think we really need to separate out the consensus code itself. We're working on a consensus library. SegWit could potentially help modularize some aspects of it, perhaps.

Modularization here would be key. If you can modularize these things and have libraries that implement these different consensus rules, you can have different. applications reuse the same code, which is going to, you know, in principle, behave the same way. And so, yeah, one of the issues with consensus code, right, is that you have to replicate even the same bugs. So, so if two different programs have any, any kind of divergence and behavior, it's not which one is correct in the strict sense. It's, you know, which one is, you know, whether they agree or not. And if, you know, this happened in the, in the fork, and one was it, 2013 was it, where, the rule, the official consensus rules were actually not adhered to because it turned out that the majority of the economically important nodes were still using an older version that broke with the new rules.

So this is kind of an interesting situation where you really cannot just expect to have all these implementations to work side by side unless they can be rigorously tested against each other. This is a very, very major issue. I think that segregated widgets is probably not going to solve this in itself. I'm hoping that it encourages more modularization in general somehow. I think that breaking out the consensus layer and really working on developing a solid implementation for that and letting other applications reuse that would probably be the way to go. Okay, very interesting answer. Now, this sort of ties into the larger block size.

debate, at least partially, I get that there's a lot of other things going on here. What is your view in that? I take it you have a lot of concerns about hard forks, right? And so it would favor an approach like this. Is that right? Yeah. I mean, I think that unfortunately the whole block size thing got conflated with, you know, a lot of different issues.

And I think there was a lot of misunderstanding. I think that a lot of the non-technical community, and the public were not really witnessing exactly the whole, you know, development as far as what the developers were doing. You know, way back in May, we were already talking about, you know, considering these ideas when it was first proposed to the mailing list, and people were actually really, you know, trying to pick this apart and figure out all the things that could possibly go wrong. And it quickly became apparent that hard forks have very, very significant stability issues

and significant, you know, they can potentially open up attack vectors, you know, and things that they could be very dangerous for the network. So I am very concerned about hard forks. That's not to say that it's impossible to do a hard fork, you know, more safely. I think that the only way that that's viable is if there isn't this kind of, you know, contentiousness, if you don't have, you know, a lot of polarization and people kind of, you know, fighting with different things. If most of the network agrees on something, if something's pretty much uncontroversial, that's fine.

As far as the blocks side itself, I don't really think that there was much issue with bigger blocks. I don't think that many of the core devs actually said, no, we should never have bigger blocks. I mean, I think for the most part, the idea of having bigger blocks is something that was appealing. We should find a way to be able to have bigger blocks. We all want to have bigger blocks. But just increasing the blocks by changing a constant in the code presents a lot of very, very serious problems. So it turns out that if we want to do this and do it safely, we probably have to retrofit some stuff and do a lot more risk mitigation, which is what we're trying to do with this. I think that with SegWit, we kind of get the best of both worlds.

I mean, yeah, it's not a single constant change in the code. It does actually require a little bit of modification of applications, but it's not a very significant modification. and it's much safer from all the other aspects of it. You know, it really does not cause all the stability issues that just, you know, changing this constant does. So, you know, I think that to get back to the whole block size thing, block size was never really the issue. That was never really what people were arguing about.

It was much more about this hard fork thing, you know, whether we should do a hard fork or not. And now that we have a soft fork way to do it, it's almost like a no-brainer. It's like, well, of course we should do it with a soft fork because it's, you know, it's just got all these other benefits. Right. So, I mean, you know, I agree, right? It sounds like a no-brainer to me to do said witness.

But that being said, right, it only lifts the total amount for transactions by, you know, a little bit. Or, you know, like it doubles it or triples it, but, you know, it's still a fairly minor increase. So, you know, I take it you will need a hard fork anyway. So why not just do it now? and like what is the benefits to delaying it? Well, right now the network probably cannot take much more than two megabyte blocks. This is just like, you know, basic tests that have been done. The general consensus among the core developers is that going beyond two megabytes is probably, you know, too much right now.

So if we're going to go to two megabytes, you know, we can either do it with a soft fork or with a hard fork. If we do it with a soft fork and we get, with Segwit, you get all the, these other benefits that I talked about, you know, in addition to just the block size bump, and also it allows us to optimize for a lot of things, like, for instance, the UTXO set, you know, the unspent transactions right now with the current cost metrics, with just the block size, it doesn't provide enough incentive for people to clean that, you know, which is basically stuff that needs to be stored on all the validator nodes. It's just extra data that gets stuck there. And with Segwit, this adds an incentive to do that because this part of the block is more expensive.

So people want to clean this up by spending these. And, you know, the witness part is a cheaper part of the block. So the witness part consumes the unspent transactions. So that creates an incentive for the unspent transactions to actually, unspent transaction outputs to actually decrease. So there's a lot of benefits that we can get from this besides just the blockbub. And if we do a hard fork now, ignoring all the political and, you know, destabilization issues, assuming that we could do it safely,

assuming that we could actually deploy a hard fork safely right now. Now, we're stuck with the same cost metrics as before. We cannot optimize this. And we're not going to be able to do Segwit now without having to go maybe to four megs or eight megs, which is something we're not ready for. We need to build up a lot more infrastructure and better relay mechanisms to be able to support those kinds of things. So this would seriously delay Segwit, which would be a very, very major setback. I think that it would really setback development, especially on like the second layer protocol stuff. which would be very, very unfortunate.

Yeah, and of course, I mean, anytime you, I'm a strong proponent of just optimizing technology as much as you can. And if there's ways that you can optimize that and it's low-hanging fruit, you should just definitely put that in place. And it seems that there's been sort of consensus around implementing segregated witness as one of these sort of things that we should just do because it's easy and it solves a little problems. But above and beyond the block size debate, I mean, as we mentioned, It allows for so much more innovation and perhaps, you know, trying new solutions that we haven't thought of yet that would allow us to do more transactions or higher volumes at cheaper costs. So, yeah, I mean, it seems like there's really no reason why we shouldn't do this.

No, I agree. I can't disagree with that. So let's, before we wrap up here, let's talk about Cyprix. sorry, Syfrex. Can you tell us about your company? Yeah, so as I said in the beginning, I started working on tools and libraries because I was writing applications for Bitcoin, and there really wasn't anything out there that existed at the time that allowed me to do the kinds of things that I wanted. And right around the time that the multi-sick stuff started happening with the Peta Scriptash, I started thinking about ways that

we could combine that with BIP 32, which is the hierarchical deterministic key chains, and to create a platform so you could do, you know, enterprise-wide security policy configurations for Bitcoin account management. So you can have accounts where you can create, you know, Bitcoin addresses that have a security policy that's based on all these different signers that you can have in your organization. Or it could just be, you know, different machines that you have yourself, right? You can use your cell phone. You can use your laptop.

You can use your desktop machine, whatever. You can have a machine at work. You have a server that adds a signature. So just having a really flexible infrastructure for that. So that was kind of the killer app, if you want to say, that the kind of I was looking for in the beginning. But really, in the end, we're looking to, you know, we're looking at all these different ideas that are coming out right now.

And I think that, you know, the kinds of tools and, you know, the things, for instance, for smart contract design and, you know, smart contract authoring tools and, you know, script templates and, other kinds of, you know, more generalized mechanisms for being able to, um, to, to, to, to, to, you know, to develop on top of this. And so, so these, these kinds of things I think are, are, are looking very, very promising. And, uh, with this, with the whole, you know, second layer, uh, network stuff, off, off-chain transactions, lightning network, there's, I think there's a lot of, um, really, really interesting things that, that, that, that are happening that, that I'm really looking forward to.

So right now, we're really just exploring the whole space. And, and we're really, we're really, looking to see how we can collaborate with other industry partners and, you know, try to try to really build a whole industry because that's really what we're doing here. You know, we're trying to create a whole industry and no single company can do it by itself. I think that, you know, we're, we're pretty well positioned to do this, just, you know, given all the, you know, kind of the overview that we have with, you know, the developments are that are happening right now. And right now, we're looking at we're really looking at

more of like an infrastructure kind of platform based solutions rather than just, you know, like we started with a wallet, we do have a wallet, M-Signa, but Cyphrix is really about the whole infrastructure and platform. Cool. Well,

Eric, thanks so much for coming on. That was super interesting. And, you know, I'm I can join the consensus. I think this sounds like a an amazing idea, an amazing innovation. And I have to say, like, you know, sometimes I was thinking like, well, you know, with Bitcoin, the sort of development has slowed a bit, you know, there's people don't agree on anything

on how to sort of take the technology forward. And this really does seem it has the potential to just open up a whole new wave of innovation in Bitcoin. I think that's something that's extremely needed at this point. So I'm really excited about this. Yeah, absolutely. Yeah. We're super excited to see, you know, new ideas stem from this.

And we really want to get past this whole community division. We think it's silly for Bitcoin, you know, people to be against other Bitcoin people. It's like we need to be united as a community because we already have enough threats from the outside. And if we don't stick together and do this thing, you know, together, I think we're going to find that we're not going to, it's not going to be viable. So I really hope that the Bitcoin community can come back to. together soon and we can really work on this together because I think there's a lot of amazing stuff we can do and I'm optimistic on the future. I think that there's a lot of really great stuff coming. Yeah, no, absolutely. So thanks so much, Eric. Thank you. Thank you guys. Yeah, also,

thanks so much for our listener for listening. So we were part of the Let's Talk Bitcoin network, LTV network, so you can find lots of other great shows on let's talkb Bitcoin.com. And yeah, we put out new episodes every Monday. You can get it on all your podcast player and you You can watch videos on YouTube.com slash episode of Bitcoin. And yeah, if you're a loyal listener, you also, what you can do is you can leave us an iTunes review or review somewhere else. Send us an email at show at episodeobitcom. And then, you know, we'll send you one of those t-shirts.

So thanks so much for those who've already done that. And yeah, thanks so much. And we look forward to being back next week.