Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Adam Back: Why Bitcoin Needs a Measured Approach to Scaling

Episode Date: September 7, 2015

As the debate about forks, the blocksize and decision making in Bitcoin continues, we are joined by Adam Back. Adam is best known for his invention hash-cash which became one of the fundamental building blocks of Bitcoin. He is also the inventor of the sidechains concept and founder and president of Blockstream, the single biggest employer of Bitcoin core developers. With Adam we talked about the different blocksize proposals and how a decentralized cryptocurrency should be governed in general. He is an influential conservative voice in the current debate and has been warning that a rapid increase of the blocksize could undermine the decentralization of Bitcoin. Topics covered in this episode: Adam’s concerns with Bitcoin XT and the approach by Gavin Andresen and Mike Hearn Why Adam favors a slower blocksize increase to preserve decentralization How Bitcoin will function as a settlement network in the medium-term with the bulk of transactions going through the Lightning Network or sidechains Why forks are in Bitcoin are different from forks in other open source projects The upcoming Scaling Bitcoin workshop in Montreal Episode links: Scaling Bitcoin Montreal Event Blockstream Gavin Andresen's BIP 101 Jeff Garzik's BIP 100 Adam Back's blocksize proposal List of different blocksize proposals This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/095

This episode of Epicenter Bitcoin is brought you by Voltauro.com, the gold to Bitcoin exchange. Trade gold to Bitcoin instantly and securely, starting at just one milligram. Go to vaultor.com to deposits in Bitcoin and start trading today. Hi, welcome to Epicenter Bitcoin. The show it talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kutuja. And my name is Brian Fabian Crane.

We're here today with Adam Back. Adam Back is here the second time on this show. And of course, many of you will be familiar with Adam Back. He is the inventor of proof of work or of hash cache as it was called then. And so he's one of the few people who were cited in the original Bitcoin White Paper. And more recently he's been involved in with side chains and specifically Blockstream where he's the president and founder. And he's also been very vocal in the whole debate about scale in Bitcoin and about increasing the block size and if that should be done and how it

should be done and so we're super excited to have him on because so far we've sort of had a little bit too much we had a lot of one side on which is Gavin and Mike and we haven't so much the guys taking another viewpoint on and today we're having Adam on to fill that role and talk about a lot more so thanks so much for coming on Adam. Hi thanks it's good to talk with you guys absolutely So, you know, when we talked about the topics a little bit before, you said something interesting, and I think that might be a good way to start. So you mentioned that, well, it's also important to talk about what Bitcoin actually is.

And of course, I don't know if we had that question asked in that podcast. We've always sort of presumed that, you know, people knew. but why don't you share what you see, like what do you see in Bitcoin and what would you like to see in Bitcoin? Yeah, I mean, it sounds like a silly question, right? What is Bitcoin? Because people have been very enthusiastic and using it for a number of years now. Increasingly in the mass markets and all kinds of interesting applications. But, you know, there were a number of other electronic cash.

systems before Bitcoin. You know, we also have PayPal and things like that. And I think, you know, a lot of people may not have the history of it, but as far as I understand it, PayPal started as a bearer electronic cash protocol. So something much more Bitcoin-like on Palm Pilots and kind of migrated, presumably, for practical reasons, into kind of central web service where the web service has. your balances and can therefore apply policy to them. And PayPal is grappling with complex issues and attempts at fraud and civil attacks and gaming their systems.

So they ended up in a situation where they had to apply policy. And of course, they're a false positive. So there's a kind of ongoing gripe about your hear users who are complaining that PayPal froze their money and it took six months to get it back. And, you know, more often than not, the user didn't do anything particularly look wrong. They just tripped over some kind of semi-automated abuse policy. And so one thing that's exciting about Bitcoin is it's decentralized, so there's no central party that can, you know, that has to or can apply policy to your ownership. So, you know, if you have electronic cash, I would say generally speaking,

means that you should be in sole control of it. It should be the electronic analog. of, you know, paper notes in your pocket, Swiss francs or British pounds or US dollar notes. And there's nobody that can sort of, you know, make a policy decision, and the bank note in your pocket with a given serial number stops working. And in fact, there are very good reasons that this shouldn't be the case, because if people are end down as to the validity of their notes, they get very worried and try to take them to the bank as fast as possible. So this is the concept of fungibility and it's a long-established

principle that an electronic cash system, it's very important that it be highly fungible. And this dates back to presumably there are other precedents in other countries, but one of the early ones was a court case in Scotland in the 17th century where a wealthy merchant sent, some very large denomination bank notes to a business contact. And he was quite worried. He sent them in the post and he was a little worried that they would get stolen in transit. So he made little marks on them that he would recognize. And unfortunately, the notes didn't arrive.

And so he reported the problem and eventually turned up at the bank. And so he sued the bank in court to get the notes back. and that arrived at the precedent. So the courts eventually decided that no, it was more important that the currency remained fungible than this particular merchant be made whole. And their reasoning is quite interesting, which is that, you know,

the economy and confidence in the money as a unit exchange would be seriously damaged if the reverse decision would be made. And also you have this general problem that money changes hand many times and the discovery of the crime or the fraud is often delayed. So, you know, if you, if somebody robs a convenience store at gunpoint or something and makes off with some high denomination notes and they circulate through the economy a dozen times and you end up with one and you tried to deposit at the bank, chances are that that was nothing to do with you, right? So it's, and the crime may not be reported for, you know, a day and the investigation takes a while.

So the general principle is that electronic cash should be fungible. And then the other interesting thing is that you get with Bitcoin a kind of permissionless innovation. So, you know, anybody can, any startup or individual open source developer or power user care, and pick up some open source software and start writing applications. So there's an analogy people draw up between the early days of the internet. So before the internet, there were various large telephone companies. Quite a number of them were government state-run monopolies. And in order to bring to market a new telephony application,

you would have to go and negotiate a contract with a very large company. And they may easily say no. For example, if they thought it competed with one of their strategies, they might say no. And so once we had the Internet and Open Innovation, and many startups and individuals playing with open source software and communication applications, we got where we are today with, you know, everybody really enjoying the Internet and all the things it can provide in a very fast pace of innovation. And so one of the exciting things about Bitcoin is that it,

open for innovation. And if it, you know, if you run a thought experiment, what if at the beginning Satoshi had not been anonymous and he had gone and obtained some venture capital money and started Bitcoin.com, chances are Bitcoin wouldn't exist today, right? The first sign of any kind of political controversy in its early days and that company would have been shut down. And there are numerous precedents. So, digitcash went through a process like this. This was an electronic cash company using cryptographic protocols that are the central server

analog of things like zero cash. So David Chorn was a cryptographer that invented blind signatures with applications for electronic cash. And he started a company. At some stage, the company set up a demo server without even a connection to the existing banking system and the Dutch banking regulator called them in for questioning to say,

you can't just be standing up banking-related services like this and requested them to take it down. And nevertheless, there were people who were trading these coins just with a viewpoint that if people sold small things for them, they might create a floating value because DigiCesh had promised that the demo server, they would only ever release a million of these, beta bucks and they had a four set you could email them and they sent you a few coins to play with.

And so there was a bit of trade and there's a kind of analog of how Bitcoin bootstrapped in that story. But unfortunately, digit cash went bankrupt. And so people had coins, but they were useless because the central server went offline. So you can see in like these three stories that decentralization is basically the distinguishing feature of Bitcoin and why it succeeded where the other systems didn't. Now, you know, Digitcash went bankrupt, everybody lost their coins, PayPal became centralized, it lost its bearer e-cash properties, and they're grappling with ongoing abuse problems that have, you know, fallout for users, and it's prone to sort of account sieges and, you know, six-month-long kind of arbitrary dispute

resolution processes. And presumably, if you want to, you know, PayPal may be a fairly forward-looking company, but some companies tend to act in a proprietary way and will not give you access to their APIs. There are examples of startups that started out with an API and then they felt that got competitive to their existing product line or they develop a new product line and they close the API. So if you end up with something that's centrally controlled, you're ultimately beholden to the good behavior of that central control point. And so kind of summary level to think to say about all of that is that, you know, decentralization is the key differential of Bitcoin that allowed it to bootstrap. And you can build centralized things on top of Bitcoin. So, you know, there are many hosted wallet services like blockchain info, circle,

Coinbase, and the various competitors. And they're relatively centralized. You know, they have in some, in various forms custody of your coins. And they kind of do apply policies. each of them at times. So those are examples of centralized things. You can certainly build those on top of a decentralized system, but you can't build a decentralized system on top of a central system because it doesn't make sense, right? So I think what we need to do, generally speaking, is to hold onto and make sure we retain the decentralized nature of Bitcoin and its permissionless

properties. Now, of course, there's a question of scale and tradeoffs in there. We can certainly make trade-offs to, you know, improve scale and balance that against security and decentralization. And that's really what the current discussion in the public amongst the technical community is about. Right. So I think you touched some interesting aspects here, right? I think the aspects of permissionless innovation, I think we've talked about that so many times and there's like there's no question.

I think that that is just revolutionary. has so much potential there's so much potential there and it's really something where you know other systems just can't compete with an open system and decentralized system like Bitcoin and yeah I think fungibility and that sort of

cash right I think that's actually a very fitting that in the white paper you know how much he emphasized the role of this is electronic cash as opposed to you know some I don't know some settlement network or a payment system or something like that in my view

actually probably most people would agree with you like most people in the Bitcoin space in the cryptocurrency space would agree with you that those are you know fundamental critical features of Bitcoin and that those should be preserved and guarded at the same time you know what we've seen with the block size debate this has been a lot of disagreement and a lot of sort of heated controversy people being also quite really with each other, I find. So obviously, even if one agrees with some of these large principles, and then I do think there's quite a lot of agreement there in the community, that doesn't necessarily help with the actual decision making. And this is a conversation that we've started having

more and more and we're trying to start to have more. So how do you think that decisions should be made? I mean, you've mentioned some principles. Do you think those are, anybody should hold them? What if people disagree with those principles? What is your, what is your view? How should basically decisions about where Bitcoin's going to go? Who should make those decisions? And how should they be made? Right. So I just step back briefly to the. So I think if you're talking about sort of requirements of properties of Bitcoin, there's generally relatively wide agreement. And when you talk about scalability, you know, clearly everybody wants to scale Bitcoin because in in the security domain, like internet security domain, there's a concept of delivered security, which means, you know, the amount of security you deliver to users is based on the amount of security you deliver to each user multiplied by the number of users that manage to use it and benefit from it. So it's, I mean, that introduces all kinds of things into security considerations, for example, it should be usable.

It should scale because, you know, it's also not interesting if only, you know, a few hundred or a few thousand users can benefit from security. So sometimes PGP gets criticized on this basis because it's difficult to use. Or, you know, Bitcoin also, I mean, there are millions of users of Bitcoin, but it can also get criticized that, well, it doesn't scale very. far right now. You know, with the current parameters and sort of security scale trade-off, you have, you know, seven transactions a second or thereabouts. And while that's, you know, generally that adds up to quite a lot on a yearly basis, and the blocks aren't actually full now. And, you know, Rusty Russell did some statistical analysis to show that. I think it's 45% of the transactions in those sort of one third to 40% for blocks are less than a dollar in value.

So you could probably make a reasonable argument that the people that potentially, you know, if you are transferring very small amounts of money, change tip or something that is but tipping or, you know, moderately centralized. but if policy crept into it and somebody seized a couple of dollars on change tip, for most people that wouldn't be as concerning because they could switch to a different tipping service or a different hosted wallet. Whereas if Bitcoin itself became centralized to that degree,

it would present a problem. So, right. So, I mean, I think if you look at it, that scaling is a trade-off between secure, as it relates to decentralization and scale, the sensible thing to do is to pick some kind of pragmatic starting points. And so we've had a number of proposals. So there's Jeff Garzik's BIP 100, which was published first,

and then a little bit later, Gavin's BIP 101. Jeff did a BIP 102, which is a very simple one. That's just a two-megabyte block size. Jeff Skalsick's was kind of similar to Gavin's in some ways, but had some minor voting, which he proposed as a form of balance so that the block size wouldn't automatically grow, but the miners would have to collaborate to grow it as it made economic sense kind of thing. And then there's more recently BIP 103 from Peter Ruler, which is using the Cisco scaling numbers. and also has another sort of small minor advantage. And the other quite interesting one is by Greg Maxwell and Mark Friedenberg, which is the FlexCat proposal.

So, and that is, allows a bursting of block sizes in reaction to, you know, sudden demand. And also for miners to pay for bigger blocks. So, you know, if the blocks at a given point in time are too small to meet, the demand, that means there are excess transaction fees that are left on the table. So if miners can see that, you know, if there's excess transaction fees they can collect and they have the mechanisms of pay to increase the block size, they can increase their profitability and solve the scaling problem. Adam, let's wait for a second before we go into that discussion and let's talk about how

the decisions actually will be made. Because right now when you talk about bibs, right? So when you talk about bibs, then, you know, those are basically sort of proposals, you know, pull requests, I guess, but there's sort of outlines of changes to be made. And then they might be integrated in Bitcoin core, right? But then one of the interesting things about Bitcoin is that in the end, the software, you know, Bitcoin core, of course it has a lot of weight because, That's what most people use. But in the end, what matters is, you know, the software people run. So how do you think of those two?

Do you think is the right way to try to discuss what's the right BIP to do and then integrate that in Bitcoin Core? Or is it the better way that maybe some people say we won't go that way? Other people say we want to go that way. You know, they have different implementation software. And then you try to convince the miners and the wallet providers. and exchanges to switch to, you know, how do you think about that? Right. So, there is, I mean, you know, not everybody's aware of it because it's a kind of

small technical community, but there is a relatively formalized BIP review process, and it's described, so BIP Bitcoin Improvement Proposal, and BIP1 is a kind of, a kind of charter and framework for how BIPs will be, you know, so there's a process for how BIPs will be, will go through from sort of outline, review. So, I mean, the process specifically is you, you discuss on a Bitcoin development list, your outline of, of an idea of how you think, something could be improved, that could be scalability, or it could be a new feature or what have you, or a bug fix. And then there is review discussion.

And if it's not obviously broken or defective, then there's a BIP number assigned. And then you specify in more detail. You provide a draft implementation. There's testing. And then there is a planning of how to deploy that. And all of the changes so far have been softforks. with the exception of a sort of accidental hard fork that was fixed in a rush, basically, to a much earlier time.

And so with a soft fork, you have miners bringing it in, you know, triggering it. So soft forks are backwards compatible. And, you know, to change the scaling in this way, it's a hard fork, and it's the first planned hard fork. So a lot of people may not realize that a soft fork, like the average time from a soft fork starting to be deployed in the network until it triggers and becomes active as six months. So a BIP 66 was the most recent one. And upgrading a Bitcoin network is potentially a high risk thing. And in fact, the BIP 66, when it finally triggered, nearly created a network fork. I mean, in fact, it did create a network fork.

it was just that people manually fixed it. So that kind of illustrates that even something that everybody is agreeing with, it's just fixing bugs and adding features. Even that can potentially go wrong. So on that basis, you know, it's far lower risk if everybody agrees on a way forward and works together to try and make it happen. So the other thing to say, because there also seems to be some confusion in the wider Bitcoin community is the difference between a software fork and a network protocol

fork. So, of course, in open source software, it's known that people can fork software and it's encouraged. That's why there are open source licenses and GitHub makes it easy to fork things. And the idea there is, as you said just a moment ago, that if some group of users decide that a particular user interface skin or a focus on a different feature, you know, if some group of users decide, you a particular user interface skin or a focus on a different feature set is interesting. They can go right ahead and do that, and whichever one becomes popular, that will tend to win in the market. But typically, it's not a binary decision, right?

Both versions can exist in the market and compete, and users can use them based on their preferences. Now, unfortunately, with a blockchain, it's not really a software fork that's concerning. We already have lots of different pieces of software that can connect to Bitcoin. I mean, many different wallets, actually also different implementations of Bitcoin core. And that's just fine. But a network fork is essentially a new altcoin. Yeah, I mean, that's one, I mean, that's, that probably wouldn't be a very popular thing, a way to express it to some people. But it's certainly the case that having, you know, that Bitcoin's consensus,

model requires all of the nodes in the network, basically, the vast majority of them, to run a bit-wise compatible protocol version. So you mentioned the BIP process, and there is some formalization around how that occurs. Now, with regards to some more controversial changes like the block size, there are multiple BIP BIPs trying to address this, which come from different perhaps ideological background, people coming from different ideological backgrounds or having different visions of what Bitcoin is or what Bitcoin should be. In this case, it doesn't seem like a clear process of how to implement the BIP would help

in establishing consensus on what we should do. we have to come back to the, to the, I guess, higher level discussion of what Bitcoin is or what Bitcoin should be. How can we come to consensus on these sorts of decisions? So, I mean, I think there has been some, you know, because of the nature of online discussion forums and, you know, Twitter is a very concise communication mechanism and people on Reddit sometimes get into some kind of heated debates and people misread, in online discussions that maybe wouldn't arise in a face-to-face discussion, there is tended to be this sort of, you know, black and white thing that it's claimed that, you know, particular set of core developers don't want a block size to change at all. They want to keep it at one megabyte and somebody else wants to increase it. But that's significantly miscategorization, I think, because, you know, for example, Greg Maxwell has proposed FlexCamp, which is a way to increase scale via increasing the block size, to Willa has proposed another one that increases the block size. Jeff Garzik has proposed another one, and Gavin has proposed another one,

and I proposed a couple myself as well. So it seems that pretty much everybody wants to scale Bitcoin. The question is it's really complicated, and we're not, you know, there is no silver bullet. So what we're, you know, what the technical community is trying to do is to figure out which is the sort of pragmatic,

safe, secure way to do this. And I think, you know, outside of, so just in evaluating the bit process, the bit proposals, that's a discussion that, you know, frequently can happen in within the Bitcoin development, bit process. You know, I mean, that's happened many times in the last four years. And many complex new features and security defects have been fixed in that way. And so there's no reason to suppose that couldn't be the. continue to be the case. So another concept that's been put forward is that this concept of whether

it would move faster if there were one person who were the final decision maker. And I think Mike Hearn was the first person to propose this. And I think the danger with Bitcoin is that there's a lot of other people's money at stake, right? So there's, you know, four billion. dollar economy. And, you know, as we go forward into the future, if Bitcoin sees adoption in certain segments, you know, for international settlement or as a gold, a competitor to gold or something, that could turn into a $4 trillion economy. And if you turn around and think for a few minutes about, you know, would you personally like to be the final arbiter, I think you'll find the answer would be no, because you would be subject to, you know, immense amounts of international

pressure, potentially blackmail, you know, people bugging your equipment or trying to sabotage. And if you have children or something, you might be worried they'd be kidnapped. You know, even governments and central banks employing like Nobel laureate economists struggle to, you know, avoid moral hazard and influence of pressure on them. So I think Bitcoin's like attempts to avoid those kind of, you know, security risks or another kind of risk is that a particular individual may have a hidden agenda or be working for, you know, a criminal organization or a foreign government with a conflict of interest or something, that if there's a peer review process where a group of diverse people have to review changes

and approve it, that's the best we know how to do in terms of avoiding, you know, those kind of influences creeping in. So, of course, with Bitcoin, this is what's so different than from other, open source projects is there's so much at stake, sort of immediately at stake and directly at stake. And but so it seems like, I mean, the the benevolent dictator model may be difficult to implement for Bitcoin. However, the bit process only seems to take into account sort of technical considerations and is very much centered around the technical community and the core developers. and, you know, there's also the voting with mining, which does also include other industry actors' opinions, but not all of them, only the miners, not, for example, like payment processors or companies providing services to Bitcoin.

What do you think about, like, creating a working group in the Internet Engineering Task Force, for instance, or like we do with HG. or other network protocols where there's an actual working group of people coming in from the industry and different industry actors weighing in a real review process, which takes into account everybody's considerations. Right. I mean, I think that's basically what the bit process tries to do. And you certainly see, so we didn't talk about this just now, but there is a workshop, like a technical workshop in Montreal on a 12th. 1 1st of September, which is basically a physical meeting, which is a continuation of the BIP reviewer discussion evaluation process. And there are certainly many types of people going there, and there are something like 14, 15 sponsors, commercial sponsors on the website and also academic sponsors. And there are a range of people there, you know, from Bitcoin technical enthusiasts to

companies sponsoring and sending technical people, people from academia and people from the mining community, all present to have this exact discussion. And, you know, while the core developers have to implement things, they would also be the first people to tell you that they are not there to make decisions, you know, that affect users. They're there to do what is in the best interests of the users and to hear and balance the requirements from different constituents. So I think the main thing to keep in mind is that, you know, it's a trade-off between security and decentralization and there are multiple parties involved. There are users and Bitcoin ecosystem companies and miners.

And if you favor one particular feature, you will disadvantage somebody else, right? So, you know, miners' profits will fall or something. It's time for our work from our sponsors, Voltauro.com, the goal to Bitcoin Exchange. Now, we all know there's been no shortage of Bitcoin exchange scams and hacks in these recent years. And that's why when Philip and Josh, the two brothers behind Voltau, decided to start that exchange in the wake of the Mount Gok's disaster, they wanted to do things differently. So they're really pushing the bar forward and innovating in terms of security, transparency, and auditability to ensure that customers,

funds are safe, secure, auditable, and so there's no, there's none of this Mount Gox, you know, stuff going on. It's all on the up and up. So if you've been listening to the broadcasts, of course, you know Voltaur and perhaps you like Voltura and you like what they do. Well, something new is happening, something really exciting is happening and that's, Voltaire is doing an equity crowdfunding campaign through bank to the future of Simon Dixon, of course, you know as well by this point. So if you're interested, you now have the chance of actually owning some equity in a startup, which is sort of a new thing, equity crowdfunding, and not just a startup, but a great Bitcoin startup,

a great startup in the space, and you can even invest with Bitcoin. So if you're interested, check it out. That's on Bank to the Future, so BNK2TheFuture.com. And of course, we'll put a link in the show notes. And we would like to thank Vultura for their support of Websterner and hope they're going to have a fantastic crowdfunding campaign. Adam, so of course it's all sounds good and sounds reasonable, right? But like what then happens? Let's say in this example that we've been talking about with a variety of different bibs about increasing the block size, what happens when people just can't agree?

You know, there's positions that just can't be reconciled. There's no consensus can be reached. What happens then? Does that just end in an assessment? stalemate or is there some process then you go after that that will actually resolve situations like that? Well, I mean,

I think it's the, you know, the task at hand is complicated and so there is also a value to not acting in a hasty or rash fashion, right? Because you know, there's nothing worse than

rushing a change and breaking Bitcoin, you know, accidentally introducing a bug or something. So But I do think that, you know, there are plenty of prior examples of complicated technical discussions within Bitcoin that reached a consensus and something got implemented. What if no consensus? What if no consensus is reached here? I don't think we're there yet.

And also, I think that... Right, but let's just, if we stay on the governance thing, right, then it doesn't matter whether we'll reach a consensus here or not, because I'm pretty sure. that there will be lots of decisions about the future of Bitcoin where no consensus will be reached. And maybe with the block size thing, you can say that's really an engineering question, right? So because I personally, I agree with you. I think everybody wants to scale Bitcoin. I don't believe Blockstream wants to keep it intentionally small.

I think that's idiotic. And I think just as much Mike Earn and Gavin all want to scale Bitcoin. And they also want to keep it decentralized. I think everybody wants to keep you decentralized. But people disagree, right? But then let's say in the future maybe there are things where actually people want Bitcoin to do different things and that's why there's no agreement.

So there needs to be consensus is not enough, right? It's not going to, you won't be able to reach consensus, I think. Right. So, I mean, I think there are there are some short term and some longer term trends that help this. So, you know, to, be clear that side chains arose significantly put forward block stream, right? And in fact, the reason I became interested in side chains is because when I got interested in Bitcoin and caught up with all the protocol details, then I tried to find ways to improve Bitcoin. And I'm

from an electronic cash cryptography background, so I found a couple of ways to improve Bitcoin's fungibility and privacy and things like this. And so then I said, you know, went to talk to the core developers and said, how about implementing this? And it became apparent that, you know, because what I was asking for was like relatively complicated, you know, somewhat high risk because of the amount of code involved, they were quite interested in the features, but it was very difficult to implement them in a really short period of time. And that's basically a symptom that, you know, the core protocol is about providing a secure and usable base that people can build things on top of. So you could think of it maybe a bit like TCPIP or something.

You know, all the internet stuff is built on top of TCPIP and the TCPI basic protocol once the basic R&D was finished, it was like pretty much been static for decades, right? So once I discovered this problem, you know, as many other people have encountered, right, that Bitcoin does, you know, does have a fair amount of forward progress. There's quite a lot of code being written, interesting new features get in there, but it's, you know, there's a sort of bottleneck around security assurance and careful validation and focusing on the most important things first to ensure Bitcoin security and safety. It doesn't progress as fast as general, you know, like internet stuff that people are accustomed to. And so that's where I started

focusing on, okay, well, how could we, you know, add a layer. or a way to do this faster. And that's what sidechains are. It's a way for different people to work on different features independently and without them having to be in Bitcoin Core. So sort of layering so that you do things at layer 1 instead of layer 0. And, you know, so to take this specific example, you know, if some of these extension, generalized extension mechanisms

that allow people to implement novel features or features that maybe not even mutually compatible in parallel, So if that kind of extension framework, which might be site chains or extension blocks or something proposed by other people, if that were implemented before the block size, before we got close to some kind of scaling issue, the answer would have been quite different, which is somebody would have used the extension to make a higher scale opt-in extension, for example, right? So I think the further future is more clear, right? I think in the future it's reasonable to suppose that we will have additional layers with extensibility and also additional ways to get to scalability like lightning, which preserves Bitcoin's properties. And I think the way to bridge where we are now is to focus on shorter-term, simpler solutions. So something that will create the time.

and space in scalability terms so that, you know, we don't have immediate scaling problems for the technical community to develop and validate those features, you know, to, for example, see the lightning scales. Adam, so let me just paraphrase if I understand this correctly. So, I mean, I think in the long term what you're talking about, I mean, I think the side chain's vision has always been compelling, right? It's always been compelling that you can have like sort of this innovation with different chains and then move the Bitcoin's there. So you have some of the same network effects, the same value, et cetera. So that has always, you know, at least from sort of a big picture,

been a compelling way to go about it. And I do agree that, you know, once side chains are implemented and functioning, et cetera, that this does partially solve the issue of reaching consensus and adding new features and stuff, right? Because you can do it on the side chain. And then where you don't have to get the agreement and just users vote with their coins and with their usage. So that makes sense. But then when you talk about the core Bitcoin protocols, I mean, of course, the implications of what you're saying is that then you think the core Bitcoin protocol should basically, you know, remain the way it is or do as little, make as little changes as possible. And then we still have the issue, right? What about those changes? How are those decisions made?

Yeah. And I wouldn't say as little as possible. I would say as much as it's safe. And, you know, there's been a lot of changes that have gone into Bitcoin in the last year, even to do with scalability. For example, the LibSec P256K1 that Peter Willer and Greg Maskell worked on, which increases the digital signature validation speed by a factor of six to eight. And when you're talking about scaling Bitcoin, you know, if it weren't for that work, increasing the block size, you know, wouldn't actually help because the CPU would be the bottleneck. So, you know, there is progress. There are new features. You know, there's check lock time verify coming in soon.

There's version bits. There's a bit on relative check lock time verify, which helps lightning become more efficient. And, you know, looking backwards in time, there are. quite major new features such as the P2SH feature. So I wouldn't want to characterize it that Bitcoin doesn't progress because there's a lot of interesting features and a lot of progress happening. But just to say that, you know, it's interesting to try to structure Bitcoin

in the longer term such that there is a base that has core required features and then there are other layers that allow people to do things more quickly. So, I mean, you see it right now already in the sense that, you know, there are existing layer one things if you want to look at the hosted wallets as layer one and the Bitcoin exchanges and the applications that are built using Bitcoin's P2SH features like, you know, trustless escrow or trustless custody and trustless exchange. All these kind of things are built on top. So what we want is the core to be flexible enough to allow people to build things directly on top and also for the core to be flexible enough to allow people to be flexible enough to allow people. people to extend Bitcoin. I mean, you know, if you look at Bitcoin currently, one of the problems is it is a one-size-fits-all, right? So, you know, you've got, you've basically got to trade off the interests of different people who have, you know, so minus want to maximize profit and collect fees.

Users and merchants would prefer low fees. So they can't both have what they want, right? So what ends up happening is a general compromise. And you've got people that want to scale Bitcoin. coin like micropayment scale and maybe, you know, trade off a fair amount of decentralization to get there. And you've got people who really value the decentralization and permissionless features that you get from that. And so again, you can't, you know, you can't swing to one extreme. You've got to do some kind of balance in the middle. So you mentioned decentralization. And I'd like to come back on this because we mentioned it earlier. And one thing that's sort of interesting about decentralization is that unlike centralization, you have to keep fighting to

keep it. I mean, and this is true at Bitcoin, we see that the Bitcoin community keeps trying to keep it decentralized, whereas you can have a central system and it will stay centralized as long as you want to. Now, that's sort of one of the core values of Bitcoin, and we recently had Stefan Thomas on who argued that the decentralization was not an end in itself, that what was important was censorship resistance and security. Do you agree with this? Yes, I mean, that's true, but decentralization is the only way we know how to do that right now. And also to say that, you know, there are specific electronic cash protocols. So I mentioned in a pre-discussion, and I think just earlier, the electronic cash protocols of David Chorn. So he was the first person

to formalize this. And that actually has much more robust. fungability, sort of cryptographic fungibility than Bitcoin, but it's centralized. And, you know, basically, I think that illustrates the point because digitcash is long bankrupt and everybody who had Digitcash coins lost them. And Bitcoin is here and running today and kind of reached a much, you know, reached mass scale adoption where Digitcash was unable to. And similarly, the other sort of story that I described was PayPal, which went from a sort of bearer electronic cash concept and ended up with a centralized service that succeeded, but is a frequent complaint amongst users as the arbitrariness of the kind of

free count freezes and things like that. So you know, centralized things are inherently vulnerable to policy choices by the centralized party, by, you know, permission seeking in all this, do any of innovation on top of it. They can cut you anytime they want, and we see that frequently in the, you know, wider internet ecosystem. So I think, you know, as I said earlier, that the decentralization is the key differentiator for Bitcoin, and it's always easy to build centralized systems on top of decentralized ones. So to give an example, I mean, there's no reason why, for example, the major Bitcoin hosted wallets, so many of them already provide in-service netting, which is to say, you know, if we're

both users of, let's say, Circle and I Pay You, that transaction doesn't hit the blockchain. And the same for two users of Coinbase. But you can go beyond that and say that these services could provide netting between them. So let's say, you know, Coinbase and Circle, they allow users on to pay users on the other system. So if I'm using Coinbase, you're using Circle and I want to pay you. Coinbase and Circle could send themselves a private message about that. And once a day when the transaction balance are netted out to like a million dollars or what have you in either direction, they could send one transaction on the Bitcoin chain. And that would allow, you know, the various hosted wallets to collaborate and scale very well, right? And that would cover presumably

quite a large percentage of Bitcoin users. So that's something that's open today. And Blightening kind of does something like that in providing a right caching layer for Bitcoin that actually preserves the decentralization properties of Bitcoin and could make that kind of, you know, sort of generalize that in a way that you less have to trust the hosted wallet service. So it's sort of interesting how what you're proposing essentially looks a lot like how banks, you know, settle their balances between themselves. So on decentralization, there's one other question I want to ask you. So, you know, we look at different things to see if Bitcoin is,

decentralized or not, you know, mining pool, number of mining pools, number of full nodes, number of wallet implementations. What is the most important metric or what are the, you know, the most important metrics to properly identify, like, how decentralized Bitcoin is or isn't? Yeah, it's a really interesting question because, you know, unlike conventional security measures where you can say you can fairly accurately measure the amount of effort that would be hypothetically needed to brute force a key or something, which we understand quite well at this point. The decentralization metrics are, you know, there are a number of factors and

it doesn't translate into a single number. But nevertheless, there are, you know, a number of indicators that Bitcoin decentralization is, you know, it's still functioning reasonably well, but it's a bit of an ebb right now. And so if you look at the main ones, you've got the number of pools or self-miners or vertically integrated miners and their percentages. So there are a number of quite high percentage hash rates, pools and vertically integrated miners,

such that arguably it would only take, you know, a policy decision by maybe three to six of them to sort of fairly effectively implement a policy. I mean, part of the way that Bitcoin achieves policy neutrality is that there are different people who will process a transaction. So, you know, potentially even if 75% of the hash rates wanted to sort of freeze or block a Bitcoin payment, say WikiLeaks had received a payment, and somebody wanted to stop them spending it, let's say. Now, still the remaining 25% would eventually process a transaction, so it would just be delayed, not blocked.

But nevertheless, there is a degree of centralization there, and it's, I think, much more centralized than people would have hoped if you'd asked about this a couple of years ago. People didn't really foresee how centralized things would grow, pulling kicked in and also another kind of metric is the number of ASIC manufacturers that are selling direct to the public or to you know small businesses or people that would buy 10,000 or $100,000 worth of mining equipment and put it in a in a small warehouse or in a garage or something and

the number of independent ASIC manufacturers is I think decreasing you know there are still a couple that will sell to the public but there are also more that have turned their attention to vertical integration or have merged or been bought and a few that have gone bankrupt through sort of poor timing in the market of, you know, a weak price and a late delivered product or what have you. And so those are two interesting forms of decentralization. Another very interesting one that people are, I think, largely not aware of, which is actually behind some differences of opinion, I think, at protocol level.

level is this concept of running it in a full node, it's of an auditing node. And so the percentage of economic interest in the network that is validating transactions that it receives via its own full node. And I think we're seeing evidence that that is falling as well. And that is an interesting and necessary part of the Bitcoin security picture that the proportion of economic interest in the network that is relying on a full node that it's under its control or trusted by it

should be relatively high. If it falls too low, there's no longer a security assurance for users because the miners are providing a service to users and particularly for SPV users and if there are no auditors, there's no kind of checkpoint.

There's only miners sort of, you know, balanced against other miners. So that's to say, you know, if we have a lot of, you know, a very high ratio of economically dependent auditors, we can tolerate a more centralized ratio of large miners and vice versa. Because, you know, miners fighting against each other, sort of vying for block rewards, partly hold each other in honest because of the,

sort of policy of not building it on top of incorrect blocks, that's a consensus rule, right? But what makes that a consensus rule is partly that, you know, full node auditors are looking at that. And I think I see in some of the, you know, more aggressive block proposals, articulation of sort of less emphasis on the importance of full node auditors. I've seen people be, you know, potentially quite content for full node auditors. auditors to over time be only possible in data centers and increasingly, you know, high bandwidth, more expensive data centers. Now, of course, you can't constrain the networks so that only somebody on, you know,

dial-up or, you know, a GSM modem or something really low-powered and with, you know, a Raspberry Pi or something, that would be too constraining and, you know, might already run into troubles, but it's, it is a balance and you do want to make it easy and, you know, not too onerous to run full node auditors because you want, you know, the majority of medium-sized and power users and so on to run full nodes to assure themselves more robustly about the security of the system. And actually, the security of the system as a whole benefits from that. It's not just something they do for themselves.

So they run it for their own security. the fact that they run it for their own security holds the system secure because they would reject payments that didn't check out from their full node and that information would flow back to the SPV users that sent it to them for example.

So I think that's actually one of the, if you boil it down, you know, going from the requirements about what Bitcoin is and why decentralization and permissionless is a key component of it and you translate that into, okay, what are the mechanisms that make Bitcoin secure, then the importance of full nodes and a decent ratio of full node auditors,

it's not just running a full node. If you just run a full node in a data center and you don't do any transactions, that's actually quite useless. So it's not the number of nodes. It's the amount of economic interest that is relying on those nodes and has sort of direct trust or control of them because that's what holds the system secure and validates, you know, a bigger percentage of transactions to a higher level. So the things that tend to degrade that are, you know, block sizes getting more full, CPU validation getting bottlenecked, memory getting bottlenecked, and also companies outsourcing running full nodes to third parties or running their entire Bitcoin business, foreign API from a third party, because then that kind of audit is done by them.

having said that there are trade-offs in that some of this software is relatively technical to run and if a very small startup doesn't have the expertise it can be more secure to outsource it. So it's a balance. But I think ultimately we do need quite a high proportion of full nodes. So again, it's a balance. Adam, do you think there's any way of getting that back? Because it seems like already today it is for the vast majority of at least sort of individual users, maybe not business users running a full node it doesn't I mean people aren't doing it right

because I mean I've tried it and I used to run a wallet with a full node and it's just I mean I use a laptop and it just doesn't work you know so right I mean I think this is any way of getting that back yeah so I mean there are you know there are some sort of uh inherent sort of, you know, bandwidth, speed of light, latency, kind of mathematical and network property constraints. But there are also a number of software and protocol constraints. And the software and protocol constraints have been, you know, people have been working hard on improving them to improve Bitcoin security decentralization so they can increase scale. So examples of that are the optimization of the CPU bottleneck, which isn't, you know, which isn't in Bitcoin yet,

but will be, I think, in the next major release. So that will make it much less CPU intensive to catch up with the network. And the other one is the header first change to Bitcoin that Peter Woolware implemented, going back a little bit ago. And so depending on when you last run a full node, it now sinks an order of magnitude faster than it used to.

Just in terms of the peer-to-peer transfer protocol was the first version of it was quite crude and inefficient. And so people would resort to using you know, BitTorrent to fetch it, but now the actual integrated catch-up protocol is much faster. And so the other thing is say is you don't need to run a full node all the time. You can just, you know, use your smartphones and small amounts of Bitcoin around. And if you at some point get involved in a larger high-value Bitcoin transaction with this new faster catch-up header's first optimization, you can just turn a desktop on or a laptop

and tell it to sink and it will, you know, take half an hour or something. and then you'll have your high assurance that, yeah, that transaction really cleared or something. But certainly for Bitcoin businesses, I think it's important that they do that. You know, if they're running a web server, running a full node shouldn't be onerous. And, you know, I mean, ultimately,

particularly if businesses have custody of client funds or they're, you know, selling things, and they have the expertise, then it's certainly a useful thing to do. there's a one form of kind of, you know, security standardization in the Bitcoin ecosystem is there's this cryptocurrency security standard, I think it's CCSS or something like this, that's been proposed. And I think they're discussing suggesting as a minimum bar that people with the expertise,

I think there are tiers of security so that, you know, to go beyond the kind of simplest security minimum bar, to go for the middle one, you know, you. it would be strongly recommended that you would be running a full node. And so the other thing to say is that, you know, the protocols get more efficient. So the other form of decentralization comes from the block transfer time. And there are protocols now that we didn't use to have to synchronize blocks much faster. So there's the relay protocol, a relay network protocol that Matt Corello implemented. and there are also, so that's a kind of add-on.

And I think at this point, the majority of the mining hash rate is actually using that. And it's, so basically what happens there is all of the transactions are already broadcast. You know, the current Bitcoin, like the native Bitcoin block transfer mechanism sends all of the transactions over the network twice, which doubles the bandwidth for block propagation unnecessarily. because you know, you've already received all the transactions and validated them, and then you transfer the block again, which serializes the transaction. So what the Relay Protocol does is it makes use of the fact that you've already got the transactions and it just communicates which transactions are in the block.

And typically that happens in a single TCP packet. So the, you know, the relay latency is massively lower. And that's not yet, you know, kind of... standardized and implemented completely enough to be integrated into Bitcoin core. But I think that's something that people were interested to do in the midterm. And so if that were to become a standard part of Bitcoin, we would have an opportunity to maybe increase scale or improve some other features. Because, you know, like block latency is what affects centralization.

So there's a ratio between the block relay time, how long it takes to transfer a block across the PIT-to-PIR network, which is claimed to be in order of 10 to 15 seconds, with the relay network, that sub-second. So you want a low ratio between the relay time and a block interval. So because if the block transfer time and the block validation, time in terms of validating all the signatures in it gets to be a significant portion, then your mining is basically dead, right?

While you're doing that validation, you can't build on top of a block. And so that favors larger miners because if they produced a block, they already know it's valid so they can immediately build on top of it. So you can tend to get a cluster of, you know, semi-trusting miners in a collusion who are building on top of each other's blocks immediately and people who have a slower network connection or more latency get disadvantaged economically and therefore they become unprofitable and tend to drop off the network. So these kind of network compression protocols are coming online.

Gavin also worked on IBLT, which is another mechanism to do it, and a few other people have worked on that as well. So there are a number of things happening in the network protocol and decentralization and scalability that are improving the experience of running full nodes closer to the bandwidth and latency limits, making it more lightweight to run a full node for the CPU side, and making it less prone to centralization by having more efficient, more intelligent, sort of network-compressed, block relaying. So things are progressing, I think, generally. Today's magic word is debate.

A-T-E. Head over to let's talkbidcoin.com to sign in, enter the magic word, and claim your part of the listener reward. So, I remember we're almost at the end of our show. Now, we can talk a little bit about block stream in a second maybe, but, you know, there's been a lot of this heated discussion, and I feel like if you, if you've seen a, some, you know, discussion forums, particularly Reddit. We've seen some side, especially I think Gavin and Mike,

they've done quite a lot to sort of articulate their points of view. I think we've seen that less happening, at least less, maybe it's happened on a Bitcoin dev mailing list, but not so much to the wider Bitcoin community of, I think the people working at Blockstream and some of the other core developers. So what would you like to, what would you like people to take away from here? And what would you like to sort of say to people who are, you know, engaged with Bitcoin care about Bitcoin wanting to be successful,

but aren't like deeply in that technical process of figuring out what the best way to go about improving it is? Yeah. I mean, I think what you said was true there that, you know, there has been, some attempt to sort of popularize a given implementation amongst companies. And I think it's, you know, it's hard forks are risky. Well, I mean, soft forks are already risky. We, you know, we nearly saw this failure with the Fourth of July fork.

And hard forks are potentially more risky. So the best hope to minimize risk is for the upgrade to be, you know, for everybody to be fully on board with making the upgrade. Because, you know, with a hard fork, it's not backwards compatible. So you essentially need everybody, you know, all the full nodes in the network to upgrade, you know, all the businesses and all the miners and all the people running full nodes really need to upgrade. And so the upgrade life cycle, as I said, like, you know, the soft fork upgrade time is typically six months. So I think it's, we'll actually get to a safer and,

faster upgrade of scalability if we take a month or so to get people to agree on what the best way to do it is because then once everybody's in agreement you can do an upgrade much faster because all you're waiting for is for everybody to upgrade right and i think there's some misconception also about a soft fork upgrade is triggered by miners but a hard fork upgrade is really triggered by the massive economic supermajority having upgraded their equipment. And miners are just one segment of that. So it's good that miners indicate they've upgraded, but that doesn't at all complete the picture. You know, if miners upgraded and the users didn't, we'd have a different kind of problem, which is the, we'd have a security problem because

the hash rate that is running on the network that the users are using would fall and they'd be vulnerable to attack until the miners, you know, kind of switch network or something. thing. So it's really the case that you want everything to be upgraded at the same time. And I've talked about sort of, you know, simpler proposals like, so something short-term that happens over a four-year time frame rather than a 20 or 35-year time frame. So particular parameters I propose, like two megabytes immediately, four megabytes after two years, eight megabytes after four and then reevaluate based on what we see from some of these new scaling features coming online. There are multiple in-flight right now, from seeing how lightning works out for scalability

and for seeing how decentralization progresses. There's also work on decentralization. There are some ways to improve mining decentralization with protocols, particularly related to pool protocols. You know, there's a get-block template type of extension, which gives you. the variance reduction, which is the main reason people pull, without delegating the block selection to the pool, you can do that work yourself and still have the pool help you with variance reduction. So those kinds of things have been working on, and I think would easily

be online within this kind of, you know, one to four year time frame. So I think within four years, you know, like say within three years, we start evaluating where things are, the world will look very different. I mean, four years is basically an eternity for Bitcoin. That's as long as it's been in the public eye. So I think that's, you know, plenty of long enough for a time frame. And if we start with something very simple, you know, an eight megabyte cap has been well validated, whereas if things stretch far into the future, you know, it's difficult to forecast the future, sort of like, you know, weather forecasting more than a few days out, it gets increasingly uncertain. and you'll either overshoot and, you know, Bitcoin will be insecure or the miners will be

unprofitable and not secure in the network or you'll undershoot and you'll have congestion. So, you know, if we do it within a short time frame, we can get, it's much more predictable, much more likely that everybody will get on board with the same proposal. And also, you know, it will be good to have a little bit of, focus also to see how the FlexCat proposal works. Otherwise, we're at risk of, you know, people jumping on the first simple proposal that has been put out there. I mean, it's incredibly simple, right? Just to change the parameters as has been done, it's basically a day of coding. So there's a risk of sort of jumping onto the first simplest proposal that's been articulated

or maybe articulated the most widely in a non-technical community at the expense of not taking benefit of much more effective proposals. So the FlexCat proposal can really effectively balance, you know, provide security while providing scalability and bursting capabilities that the other proposals can't provide. So it really protects against sort of the denial of service risks that come with increasing the block size because it's all within the framework of profitability. So miners can scale within what's profitable for them to do, which can allow than to burst and still makes DOS expensive, which is what you want. Otherwise, some miners could potentially engage in different sort of network optimization

approaches that could see blocks being constrained to push up fees or miners competing between themselves in a cartel and pushing up the block size to the maximum to squeeze out smaller miners or something like that. So the, you know, some of the proposals, I think Jeff Garzix is kind of interesting and flex cap is kind of interesting, but we really need to see some network testing and some analysis and the parameters to be selected and proposed for flex cap and reviewed so that we can make an informed debate. So I think the, you know, the scalability workshop in Montreal should be quite interesting. We can continue this kind of discussion we've been having here and talk about selection criteria

and see actual, you know, network measurements presented about latency and bandwidth. So, you know, it's more like the way that NIST goes about selecting, you know, the new AES standard of the new SHAR 3 standard, where there are a number of proposals, a series of workshops, and it's analogous in a sense that

for any encryption or hashing standard, there's a trade-off between security and speed. So that's in a sense quite similar to Bitcoin. And when they make that determination, you know, people put quite a bit of effort into actually measuring the speed. They will make, you know, actual sort of hardware circuit implementations. They won't produce them, but they'll run them in a simulator and evaluate which proposal is most efficient. And people will analyze the security properties of them.

And, you know, after a period of time, they will select one. And then those things are much better able to stand the test of time because it's extremely expensive to have a failure in the field within cryptographic protocols because it's very difficult to upgrade. And Bitcoin has that kind of property, but magnified, you know, Bitcoin is far more complicated than Shard 3 or DSA. And yet, you know, there's all this pressure right now to kind of, you know, jump on the first. proposal or curtail review of potentially better proposals. So I think it's fortunate, but I think that, you know, if we do the sort of validation of the proposals, we can still get to scalability and get the network scaling faster because the trigger mechanism is basically upgrade, everybody upgrading, not so much, you know, a minor hash rate or who has some code out there first. So

So if we get everybody, you know, all the companies and all the miners and all the users on the same page about a sensible compromise that, you know, doesn't have any obvious attacks, then we can see an upgrade in a really much shorter compressed period of time. Well, Adam, I think that's a great note to end on. And I certainly hope that will happen. And I hope that the workshop in Montreal will, you know, do its part to move in that direction. And, you know, I wish, I wish it was possible for me to take place as well. I'm sure it would be extremely interesting.

And I'm especially glad that, you know, different sort of different points of view come together. For example, you know, that Gavin and Driesan will be there as well as well as you guys who have clashed on some occasions in this discussion. So I think that's super valuable, that people actually come together and try to work out some solution. So we didn't have a chance to talk about Blockstream today. and side chains, but hopefully we can do another episode at some point down the line where we can speak about some of the actual things you guys are working on because there's some really cool and exciting stuff like this confidential transactions sounds great, so would love to come back to that at some later stage. So Adam, thanks so much for coming on. Yeah, thank you. I mean,

I think just to say about, you know, it's been portrayed that people have, you know, large differences of opinion, but I think basically if you look at all of the current BIP proposals and draft proposals, that they are all envisaging increases in block size, they are just making slightly different trade-offs on different time horizons. So things are actually quite a bit closer than, you know, it might sound reading some of the recent news articles or some of the kind of online discussions that, you know, maybe get heated and there are many people who who are not actively involved in the technical discussion, who obviously want to participate,

and it's difficult to, you know, get down to the fullest details and understand all these trade-offs because, you know, it's no criticism of anybody, really, that one may not fully understand the protocols in a sense that this is basically leaving edge, cutting-edge stuff, and even the people who, you know, are writing the code

are still learning new things about consensus limits and scalability limits. It's, you know, the coin is fascinating. it. So the pleading edge. Absolutely. Yeah. Before we wrap up, we are still doing the T-shirt contest. So if you want to leave us a review on iTunes or Stitcher and just send us an email at show

at EpicenterBitcoin.com, we will draw one T-shirt per week. And so just, yeah, leave us a review on iTunes or Stitcher or anywhere else, really. I mean, anywhere where you listen to us where you can review the show. definitely helps us in getting more audience and having the show be more known on those networks. Yeah, and I actually sent out a bunch of T-shirts last week to the U.S. to Italy and stuff. So some people will get them soon. Yeah, so thanks so much for listening. You know, we put out these episodes every Monday.

You can get them, of course, in your favorite podcast apps on iTunes or Android, etc. You can also get the video on YouTube and YouTube.com slash everything. and a PTC. And of course, if you like the show, we can support us by leaving a tip. The tip address will be in the show notes. So thanks so much, and we look forward to being back next week.