Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dave Collins & Jake Yocom-Piatt:: Decred – A Hybrid Approach to Blockchain Governance

Episode Date: July 26, 2017

Dave Collins and Jake Yocom-Piatt join us to talk about Decred, a cryptocurrency which introduces an innovative system of community-based governance into its blockchain. Decred implements a hybrid Proof of Work and Proof of Stake system in which miners validate transactions, while users can vote on new features and upgrades to the protocol. This clever approach enables efficient blockchain governance, which has demonstrated to be successful in a recent protocol upgrade on the live network. Topics covered in this episode: Dave and Jake’s respective backgrounds in the blockchain space The challenges addressed by Decred, specifically regarding blockchain governance Decred’s hybrid Proof of Work/Proof of Stake approach to governance How users of the network vote on protocol upgrade with “”tickets”” Possible downfalls and attack vectors to this approach How Decred’s governance model successfully implemented a hard fork on the production network Decred’s approach to development funding Episode links: Decred Website Decred Documentation This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/193

This is Epicenter, Episode 193 with guests, Dave Collins, and Jake Yocom Piat. This episode of Epicenter is brought you by Ledger and the Ledger NanoS. Half piece of mind in knowing your private keys are protected by industry standard physical security. Go to ledgerWalt.com to learn more. And by Shapeshift.io, the easiest, fastest, and most secure way to swap your digital assets. Don't run the risk of leaving your funds on a centralized exchange. Visit Shapeshift.io to get started. Hi, welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution.

My name is Sebastankujuu. I'm here, Roy. Today, our topic of discussion will be governance, and we are talking to Dave Collins and Jake Yacompuyat, who are the development lead and project lead of the Decred Project. D-Krit stands for decentralized credit. This is a cryptocurrency system that has made some interesting governance innovations, and we'll go through how they handle changes to the protocol of the cryptocurrency system. So with that, let's begin.

Dave and Jake, great to have you on the show. All right, thanks for having me. Glad to be on here. Nice to see you, gentlemen. Thanks for having us. So tell us about your background story. How did you end? up starting the Decred Project? Oh, the Decred project began as an outgrowth of a white paper that was posted on Bitcoin Talk in April of 2013. So in April of 2013, a white paper was posted for a coin called Memcoin 2.

And it was posted by someone named Adam McKenzie, and basically it was an idea to hybridize proof of work and proof of stake, instead of just having a proof of work dominated system or even a proof of stake dominated system is to hybridize the two so that they sort of have their incentives aligned and it allowed for on-chain governance. And then from there is, you know, that's what really led to the start of decred. Adam McKenzie and another user named InSock pursued contact with me, starting something. time in approximately July of 2013. And then they pushed me for several months to pick up Memcoin 2 as a project. And ultimately, Decred is what came out after that process started in

roughly March or February of 2014. Yeah. So from my perspective, I got involved slightly after that point. One of the things that I was really excited about it is because we really, we really kind of started to see the governance issues that Bitcoin had. Up until that point, we had started developing BTC Suite, which is an alternative, full-node Bitcoin client. And after going through that process and getting a little bit further into it, it really became apparent that there were going to be issues around governance. And so we started looking at the decred model and the proof of activity-based model,

we started to see that, okay, yeah, this is elegant. solution to the issue. And that sort of kick-started the process even further. I think that was probably the point when we started paying a little bit more attention to the petitions. Yeah. I mean, people were pushing to get a hold of, you know, to get a hold of us and to get us to work on their project. But, you know, the more involved we became with Bitcoin, the more clearly we saw that there were serious governance problems with Bitcoin and that, you know, any, you know, a model that allowed people to vote on chain for, you know, to make all kinds of different decisions, had a lot of merit to it because in Bitcoin, there just, you know, there was no infrastructure

like that. And, and, you know, things weren't very bad in 2013 by any means, but in throughout 2014, it became a lot more apparent with the, you know, with the rise of block stream and sort of the centralization of Bitcoin development. So back then, as you mentioned, you know, the the idea of governance of Bitcoin, it was a topic that wasn't really put on the table as it is now with these governance issues that have come up in the last, I'd say, two years or so. What was the reception from the community to your idea of sort of decentralized governance and governance that is managed by a decentralized protocol? I think that the idea really resonates with some people.

You know, if you spent enough time in the Bitcoin community, you've become, you know, educated involuntarily on the problems with governance. So over time, you know, more and more people have sort of switched on and said, wow, you know, you guys really do have a point and you did see where, you know, sort of where the train was going. and but early on there were a lot of people who were like whoa there's nothing you know it's it's fine it's absolutely fine and the room's on fire and we're like well we realize the room is fire we're going to go to this other room over here and you know the number of people who who see that has definitely grown over time I mean without the people who saw the merit in that sort of you know in that you know in the problems that we you know that we presented before we launched DeCred in February of 2016, without those people, we wouldn't have had much of a network to begin with.

And that's really, you know, ultimately where value comes from in terms of these cryptocurrencies. And so before working for Decred, you had developed a Bitcoin client. Can you tell us about the motivations for that project? Did that Bitcoin client also include some of these decentralized governance systems? So, yeah, the main motivation that we first got started writing it is that, We started getting involved in Bitcoin, and like everybody else, we saw the value of it. And they're like, hey, this is a great idea. But one of the problems that we noticed way back then, I think we're talking about 2013 now,

it was that there really was only a single client on the network. And we saw that as an issue, because if you look at pretty much any other, you know, internet scale or any big protocol like TCPIP, there are multiple implementations, multiple stacks. And we think that it's really important for there to be multiple implementation, so that if there's a bug in one implementation, you're only going to affect that specific subset of the network as opposed to the entire network. And that was kind of the driving motivation

that got us started working on BTC Suite. At the time, the only thing we were focused on was re-implementing everything so that there was actually a replacement for Bitcoin Core that you could run either one. You can completely validate all blocks, the exact same rule set, and have a viable alternative

so that you weren't locked into a, single implementation. So, so tell us about the consensus mechanism of Decrit. What have you innovated on with the consensus mechanism and how the network works? Well, what we've done differently than other projects is historically, or to date, the bulk of the, the bulk of the consensus models, at least for determining consensus on the network, were proof of work-based, some of them were proof of stake-based. And there were a couple that took a stab at hybridizing proof of work and proof of stake.

And the way, you know, the way Decred is different is that instead of proof of work miners being the only, you know, the only group with right access to the shared ledger that, you know, that comprises your cryptocurrency, we added the ability for, we added the ability for the stakeholders to overrun. ride the proof of work miners. So that in the instance, I mean, even back in say 2013 and 2014, you would see things like empty blocks mined with Bitcoin. So when there's an empty block mine with Bitcoin, it's really a low-grade denial of service attack. That is, it's a minor going, listen, I just want to get this block reward. I'm not going to put any transactions in this block. I'm just going to push it out and get my 25 bitcoins or whatever. And that process, we saw that as just bad on top of the fact that these people really controlled all the consensus rules. So, you know, the hybridization takes the power away from people who own specialized expensive computer equipment,

A6 or GPU farms, and who have access to artificially, and oftentimes artificially cheap power. And it puts the power back in the hands of the people who actually, you know, buoy the value of the currency, the people who hold the coins. So that's really the idea with the proof of, you know, the hybrid proof of work proof of stake, which is that, Proof of work matters, and we definitely want those people to participate, but we don't want them to absolutely run the show, so the people who run the show are the people who hold the coins. And in some cases, those two parties actually overlap. You know, you might be a minor who never sells any of your coins. So in terms of it being different, it's also a feedback mechanism where people can make on-chain submissions about their opinion on various issues that we put up for vote, which was part of the original system proposed in the MC2 white paper. So this is an interesting concept.

Because if we sort of compare this to what's happening in Bitcoin now, there are a series of mechanisms by which miners and users are signaling their support for an upgrade to the network. And we go into all of those different proposals. But essentially, they sort of seem like hacks, right? Like signaling your support through like a bit that you're voting on. when mining a block. And then, of course, there's a user-activated software,

which isn't really a user-activated software. It's just sort of forcing the network to only take into account certain blocks that basically closing your eyes to other miners that are not signaling support for the blocks that you want to support. So this is a very different type of. of mechanism where in fact you're not only allowing miners to have right access to the database, but also allowing users that hold coins to signal support for certain types of upgrades. Can you talk about what scenarios you think this would be useful in? Like if you compare this to Bitcoin, is this, have you thought about how this could be used to, say, for instance, upgrade the Bitcoin network to like a

can make up like blocks or segregated witness or any one of these proposals that we have today. Right. So obviously that's the elephant in the room, the scaling debate in Bitcoin. And so one of the first votes that we actually had in Decred was on the test network was to raise the block size to sort of prove that the system works or not. So, you know, one of the, to answer your question a little more concretely, really the, what I think is so exciting about the system is that it allows the stakeholders to basically completely control the direction. I mean, we're not just talking about block sizes here. We're talking about, for example, when quantum computing becomes a little bit more relevant,

you want to switch over to a quantum proof cryptography or anything like that, quantum resistant cryptography. You can change the signature algorithm. You can change the encoding mechanisms. You can change pretty much any parts of the system. And we think that's really important because, while, you know, right now the system may seem great, and the technology is fantastic, things advance over time.

And so you definitely have to have some way to continue to upgrade those rules, and the chain as time moves along. And that really is, as you mentioned, I think one of the fundamental mistakes, really, in my mind, in Bitcoin, is the fact that there really is that lack of governance. there is no way to trustlessly signal that this is really what users want. As you mentioned, I mean, there's like polls on Twitter, there's Reddit, there's these coin-based polls that are coming out now, forums, but all of the cases, they're not actually

polling people who necessarily own the currency. It can be anybody who just says, who doesn't have any skin in the game, who really doesn't care what happens to the currency because it doesn't really affect them going, ah, I want that, or no, I don't want that. And so with the decred proof of stake system, the thing that I think is so novel about it is that the people who are actually making those decisions are people who are actually directly,

that people actually directly own the currency. They are the stakeholders. They have skin in the game. It really affects them. So that's, in my view, that's why it's so important. So there are a few other protocols that allow and sort of include decentralized governance. Of course, Dash is one of them.

I think we mentioned another word earlier. I forget the name. So this idea is not new, and we'll talk about it later in the show, but you have demonstrated that this can be done. You've in fact done a protocol upgrade using this voting mechanism. Why do you think this is something that isn't really on the table for a protocol like Bitcoin that obviously, as we have seen, sorely needs this type of governance system?

So, in my opinion, I think the biggest reason that Bitcoin doesn't have it is because it requires quite a few changes to the core protocol, and therein lies the problem. I mean, we're struggling over to change something as simple as whether or not we're going to increase the block size. When you start talking about actually having an integrated, transparent, cryptographically secure voting system on chain, you have to make changes at the consensus level in order to enable that. And so, you know, convincing everybody without a formalized system of governments to begin with to put a system of governments in place, it's sort of like the chicken and egg problem, right?

And so, you know, to be honest, like, I don't see it really happening in Bitcoin because of that fact. There's really you have to change a lot of things at the fundamental level in order to enable it. I guess what I should talk about a little bit when you're talking about the other systems. So one of the key differentiators I think with the KRED versus some of the other government systems that are out there is that most of them are sort of, how would I say, kind of like opt-in in a way. You know, you might have some other nodes that exist out there or a signaling mechanism of some form of. another but the reality is in all those systems user signal hey I want something and then it's up to the developers to go and actually implement it and then somebody one of those developers they basically flip a switch they're like okay these are the new rules they're active the end we approach that

a little bit differently in decrit in the sense that we develop it up front we put the rules into the code they're just dormant they're inactive so they don't take effect unless the stakeholders actually vote them in. But the difference is, is that rather than saying, we want this, and then you're not sure what the actual final implementation you're going to get is in that scenario. You can say, I want, you know, whatever, we'll just say smart contracts. Like, eh, the stakeholders say, I want smart contracts. Well, what the developers actually finally deliver may not be what the stakeholders originally envisioned, right, because the final product, the final developed product, it may be something completely different. So, you know, with our system, we have it there where

the stakeholders are actually voting on the final product. They know exactly what it will do, what it gives them, and what it doesn't give them, you know, the pros and cons of that specific implementation, and then, you know, they either activate it or they don't. And so that is really kind of the biggest difference between all the other governance systems that I've seen in the other projects to date. I think that Dave has a good point here with, you know, with the conflict with Bitcoin. I mean, the way I can, you know, one way to view Bitcoin is that it's essentially a deadlocked corporate entity in the sense that, you know, what can happen if you have, like, let's say you have four founders and everybody has 25% ownership of a company. What can happen is

you can get into the situation where it's only, you know, you have groups of two, two versus two, so it's 50% versus 50%. And that's typically not enough to form a majority in a, you know, in a normal business. And then as a result, the company deadlocks. And I've actually experienced this myself firsthand, which is, I think, part of the reason why we were sensitive to what we saw as issues within Bitcoin earlier on, which is that, you know, we see it and we're like, I see where this is going.

And this is going to lead to a deadlock or fighting or something along these lines. And just like Dave pointed out, the unfortunate reality is that the amount of changes that need to happen in order to get to the point where you can have, a decentralized system like this that's binding and on-chain, it's a lot of changes. I mean, it took, it took like a solid, you know, real solid year of development to make that happen, and that was without a multi-billion dollar system running underneath it. So, you know, trying to fix a deadlocked company is very, you know, serious business. And in a lot of cases, what ends up happening is that a deadlocked company has to be dissolved. And then you have to

form a new company and sort of, you know, keep the ball rolling with that. So as much as, you know, I think we all want to see better governance in Bitcoin, I think that the probability of them adopting a system like the one that we have is exceedingly low. This episode of Episcenter is brought to you by Ledger, makers of the best hardware key security solution on the planet. But Ledger is more than just a hardware wallet. It's your path to eternal bliss and happiness and peacefulness. Do I look like I'm losing sleep? I am.

But it's not because I'm worried about my cryptocurrency, my Bitcoin or my Ether, and that's because I use a Ledger. Ledger devices for multiple cryptocurrencies like Bitcoin, Ether, Zcash and more. And you can even secure your ERC, Ethereum tokens with them. Or you can add the security support from Ledger to some of the wallets you already love and use like Electrum, Copay, My Ether Wallet, and others. All your keys and segregated accounts are derived from one unique seed. Seeds are generated on the device and are never exposed to the host computer.

So when you make a transaction, your ledger will present you with the details and kindly ask you for your confirmation before signing. How polite is that? So the best choice right now for anyone looking to invest in security is the Ledger NanoS. It's a key chain size device that fits in your pocket. has a screen and buttons and connects your computer or Android phone using USB. Look, if you're holding crypto and you're storing your keys on your computer, on your phone, or worse, in exchange, you know that's a disaster waiting that happened. Don't be the person that loses their keys

because they were careless with them. So don't wait any longer. Secure your Bitcoin, secure Zcash, secure ether, go to ledgerwallet.com and get your Ledger NanoS today. We'd like to thank Ledger for their supportive epicenter. So presumably, more systems like this will continue to enter the space. You know, there's Tazos, there's Decred, there are other systems, as we've mentioned. What do you think will happen to Bitcoin if it doesn't on board, or if it doesn't adopt a system like this? I mean, if it just keeps lagging behind, I mean, on the one hand,

it is the largest cryptocurrency with the most market cap and the most use, the most usage and the most number of users. But on the other hand, if it cannot evolve to support these types of mechanisms that will be presumably current in all other currencies and all other public blockchains, what do you think the future holds for Bitcoin then? It's hard to say for sure, but there is another viewpoint that I think hold some value, and that is the sense that perhaps one of the good benefits is, I think, hold. ultimately there are going to be multiple currencies, right? I mean, I don't think there's going to be the one to rule them all, so to speak, just like in the real world we have dollars, euros, and everything else. So I think there are ultimately going to be multiple currencies,

and the different currencies will each have their strengths and weaknesses. So, you know, it could be that one of the strengths of Bitcoin ultimately ends up being that, you know, it isn't change that it's just straight immutable, that, like, it's impossible to change. There is some value in that in my mind. I think that it does pose problems in the future when you start talking about how you want to keep up with it being used as a currency. However, if you just want it to be a settlement layer, if you really just want it to be digital gold as its tagline is, you don't really need it to change for that, right? You know, to use it as a currency, yes, you definitely need to change,

but just as a store of value. So perhaps if, you know, from that perspective, there will still be value in it even, and that value may be derived from the fact that it just straight can't change, that it is the immutable store of value. So I think that's, you know, and so I think that's, a valid viewpoint. As far as I mean but in my opinion I think that it's usefulness as a currency if it can't come up with some form of governance system some way to continue moving forward will be greatly diminished over time. One of the challenges with Bitcoin is that ultimately like you can think of like the coin holders as like this as the ultimate shareholders of the system right.

But now these shareholders are sort of recruiting these miners in order to secure the chain. And in Bitcoin, what happens is that the shareholders are completely held hostage to the miners in order to upgrade the chain. It's like only the mining community can really upgrade the chain and like the shareholders, the actual shareholders don't have a say in the upgrade process. I don't have much say in the upgrade process at all. I think this is a fundamental problem with proof of work, right? Whenever there's proof of work, you're going to have these two different communities, the coin holders and the miners, and they might be at odds with each other. So when you were building decred and it was like going to be a system that is focused on governments,

why did you choose proof of work at all? Why not go for a pure proof of stake system and cut out the mining community? The reason we decided not to go with a pure proof of stake system is that The issue with a pure proof of stake system is the, there's nothing at stake problem. The idea being that, let's say you start the currency, whoever has the largest balance as of point X in time, well, they're going to continue to grow their share of the currency substantially over time. So basically, it becomes too much of a, without proof of work, that is some way for people to show up who don't necessarily yet have, you know, skin in the game in the form of coins.

Without a system for people to show up and put their skin in the game, you know, in a physical way, the people who own the currency first end up holding the gross majority of it. And so it's sort of like, you know, it's sort of like an oligarchy in that sense. You know, if you showed up and you're Duke so-and-so, you're always going to be Duke so-and-so, and, you know, so all your kids and everybody who's related to you. And, you know, whereas with proof of work, work, it's a little bit more like, hey, you know, I could show up and do something really useful for you and you'll pay me for it. So there are some useful mechanics to proof of work. And I can't

deny the things that you said about how it affects the governance. That is, there's the people who own the hardware and who make, you know, most of the decision or all the, really all the decisions in proof of work currencies. And then there are, you know, the proof of stakeholders. And I feel like if we completely got rid of proof of work, we'd be throwing away something that we know works and we know it works pretty well, but we know it doesn't work when it comes to governance. So, you know, in terms of a sort of zero-th-order way of decentralizing a ledger, it works great. But then once you start to get into the intricacies to be like, well, where are all the A-6, who's paying for the A-6?

Our government's subsidizing that power, you know, there's all kinds of nastiness that gets involved there. So we saw it as proof-work works, but just not out on, you know, in a governance context, which is why we left it. So let's then walk through your sort of governance system or, yeah, like the governance system of decry, right? So you have this system of tickets, which is like a mechanism by which like shareholders can influence their, can exert the influence on blocks and like future changes. So explain to us this system of tickets. So the concept is, is that you, every block is, every block is.

approved by, it's kind of like a two-factor authentication system. The proof of work miners create a block, and then the proof of stake miners have, their tickets are called the vote, and then those votes either approve or disapprove of the previous block. So the way that these votes occur, though, is that the proof of stake miners first lock up some coins. There's an algorithm that determines how many coins need to be locked up in any given time. in order to maintain a target pool size of these tickets that are outstanding to be chosen from. However, so at a high level, the stakeholders lock up some coins for an average of 28 days. However, it could be up to 142 days.

There's a range in there. It's just like mining, and there's a Poison distribution. There's a target, however, it varies depending on probability. So they lock up these coins for this period of time, and then their ticket is randomly selected from the pool. And when that ticket is selected, it's given the power to vote. And there's where five of those are selected per block. So that's kind of the thousand-yard view of how it works as far as the tickets are concerned. Well, I think another thing that's worth pointing out here is the high-level approach,

which is that say when we talk about proof of work to connect to your prior question, proof of work is basically a gamification of the timestamping system. So basically it creates a game out of timestamps. It goes, hey, guys, let's create a time. stamp so that none of us are the one timestamp creator and we can, you know, basically keep this ball rolling. It turns into a game, people mine their computers. So based on your relative share of hash power, it's like a lottery where you get the

machines, you spin them up, you go to the lottery and, oh, you won the ticket 10% of the time because you have 10% of the hash. With DECRE, what we've done is we've gamified the governance layer and the proof of stake layer at the same time by going, there's these tickets. And then the idea is that you buy tickets. And buying tickets is supposed to be analogous to purchasing hardware for proof of work mining. The idea that you're going, I have some skin in this game. I'm going to sort of put some money on the table and like, you know, let's hope they call my numbers.

And by doing that, what the gamification means that we spread out and distribute the process of, you know, validating blocks and steering the currency. because ultimately proof of stake sort of trumps proof of work in decred. So this ticketing system where, and there's a ticket price that goes up and down internally per Dave's explanation, that allows for the gamification to incur internal to decred, as opposed to having to have some other mechanism like follow the Satoshi or a more standard proof of activity algorithm. One thing that I'm not quite understanding is the relation to this and governing updates in the system, So as far as I understand it right now, I mean, what you're describing is you're describing block validation.

So the miners will mine a miner will mine a block and then that block will be voted on in a in a proof of stake with a proof of stake algorithm. But that's that's to validate blocks and and write them into the blockchain. How does that tie into blockchain governance such as like we need to update the protocol to like, say two megabyte blocks and we're going to use this system to do that. Whenever those votes take place, there are actually some additional things. We call them vote bits, but a signaling mechanism essentially is what it is, that allow, whenever an upgrade is or something is up for vote, those bits get assigned certain meaning. So, for example, if you're voting on upgrading, which we've already done, the ticket price algorithm,

or in the case of if you wanted to vote on increasing the block size or anything really, that bit has a certain meaning. And so the stakeholders, whenever they cast their bit or their vote, excuse me, they'll set those bits according to whatever their preferences are. And then the consensus rules, that is every node on the network all agrees and every node does this, is they will end up tallying up all of those votes that got cast and the bits across a certain interval. And, you know, it either passes or it doesn't. And so it's a pretty complex system, and I think later on we'll go into it a little bit more.

But the general idea is that these votes, when they get cast, in addition to approving the previous block, also allow preferences to be set. Or that way they're actually voting on specific issues or agendas. And then those are, in turn, enforced by consensus to, consensus basically says, okay, well, there was a yes vote. We're going to activate the new rules. there was a no vote, we're not going to activate it. And there's no way to change that.

That's why you can change it over time, but that's the, there's no user interactivity there, right? I mean, the vote happens and it succeeds or it doesn't. And then the rules themselves enforce that result. So, for example, if class 5 as a no like decredit, we ultimately have 21 million coins. This is the same as Bitcoin, right? and maybe about four or five million of them already exist.

So assume like I'm a relatively large holder, I own, let's say, 100,000 coins. Then the way I can participate in this governance gamification, this governance game is, I lock up these 100,000 coins and these 100,000 coins, when I lock these 100,000 coins up, there's a variable amount. There's a variable amount of time from 28 days to 142 days. And when that variable amount of time is up, I will be issued some tickets. And the system sort of balances in such a way that there are like 40,000 outstanding tickets at all times. And like once I get one of these tickets, I can, it's like when when a block is created, there are 40,000 tickets in total.

of these tickets will be chosen to vote on accepting the previous block. As well as the outstanding agenda is correct. As well as the outstanding agenda. So basically when I'm locking the coins, I'm getting a claim on the future tickets that will be issued. And once I have these tickets, those allow me to sometimes randomly become part of the pool of five tickets that will vote on. the block issues. Correct. So the one thing is when you,

instead of, like you lock the coins up, but when you're locking the coins, you are locking them in exchange for a ticket. So that process, as opposed to being delayed, it happens right then and there. You get a ticket. Technically, there's actually a day

that it has to wait for maturity reasons, but after those maturities is over, your ticket goes into that pool. And then from that pool, the five are randomly chosen each block. And that is why there's a variable amount of because there are no, every ticket in the pool has the exact same probability. It's all independent probability. And so, you know, you could buy a ticket and it goes into the pool and it could vote

the very first block that it's eligible to vote or, you know, it could expire all the way. There's a very small chance that it will expire without ever voting. And so the reasoning for that is kind of, I think, where you were going with your question is that, you know, you don't want to have a system where it's easy to gain the results, right? You want to make sure. sure that it's fair for everybody involved. And so by having to lock up those coins and by making it an independent probability for every ticket, you're not giving any unfair advantage to any individual person or an individual entity. It's a completely independent probability. So let's say today a million coins are being locked up in order to get these tickets, right?

And suddenly for some reason, in the next five days, an extra million. also get locked up, right? Like for some reason, like people go crazy, like everyone wants tickets now. In these five days, a lot of new coins come in locked up. And I had locked up my coins previously, so my 100,000 coins for the part of the early million. Will it be that when more people lock up their coins, I will get less tickets? The way the ticket price algorithm works is as follows.

In order to maintain a stable ticket pool size of roughly 40,000 tickets, the price will go up in response to demand for more tickets. So in the scenario you described, let's say you have a million coins staked. The way it works is that there's effectively, you know, over time, if you average everyone's ticket purchases and you go, what's the average price of a ticket in the ticket pool, that you're going to pay somewhere near that number before the second million coins show up. So the first million you got them in there, you got them at price X.

then when the second million comes, the price of the tickets is going to surge in an effort to basically prevent the ticket pool size from bloating. And the reason we do that is so that we can maintain sort of, you know, we can manage everyone's expectations. People have an understanding that there's going to be roughly 0.5% of the tickets expire without voting. You don't really lose any money. You lose a fee from that. But then the rest of the tickets will vote and they're, you know, with a rough average of 28 days. until they vote from the time that they've matured and after you bought them. It's funny that you mentioned this idea, what would happen if a million of these coins

show up. In the previous system, now we recently changed the ticket pricing algorithm. With the old ticket pricing algorithm, it would have gone absolutely berserk and the price would have gone all over the place. But we actually modeled this as part of our design of the new ticket pricing. algorithm. So that in the case that the price surges, you know, the pool size will surge for a little bit, but then it will come back down over time as a function of basically the ticket price shoots up, people stop buying tickets and wait for it to come back down, then it comes

back down and people slowly start buying tickets again and then it comes back to a, you know, like a stable ticket price. And what that will do is that won't affect tickets. It could affect tickets that you bought in the sense that the amount of time until those tickets vote is longer, but it won't affect the price you paid for those tickets. So your rate of return is really mostly a function of what you paid for the ticket. If the pool size surges a bit, it'll affect your returns a bit, but it won't drastically change your returns. So then if you're the person who showed up and bought the second, you know, the second, you know, raft of, you know, million coins worth of tickets, you're going to get a higher ticket price and your return will be lower.

And if, you know, there's more demand for tickets in general, the price of tickets goes up and then the yield from those tickets goes down over time. So with the system, once the proof of stake users have voted on blocks that have previously been mined by miners, what prevents minors from ignoring these votes and just continue mining blocks as they were mining them previously, are presumably not implementing changes that would have been voted on by the proof of state validators? Right. So again, that comes down to the consensus rules that are encoded in all of the clients.

One of the, I don't think I mentioned it, but one of the requirements is that a block has to have three votes. The minor must include three votes. And since the minor can't choose those votes, it's chosen specifically by this lottery process. They don't have a choice. They have to include those votes or their block simply will be rejected by the network. So they have to include, there has to be at least.

three of those five votes. That extends a bit, I think, where you were going when you start talking about forks and things like that. Like, why don't they just keep, you know, why don't they ignore the new rules? Yeah, why can't they just fork? Right. And so the reason for that is, is because you think of it this way that the majority of the votes follow the majority, well, whichever way they voted. So they're going to follow the majority chain in that case. And because they're not going to cast votes on the other chain, the other chain can't continue. It won't get the votes. So because every block requires those three votes to even extend the chain, now they can keep trying. I don't want to go too much in depth there, but the fact is there, there is a way that

you can remind the block to change the hash, which will in turn cost different tickets to be chosen. So you can keep trying, but it's so much more expensive to try and keep that old chain going that way because you're not getting the votes. People, people aren't, nobody's voting. So you have to keep trying again, and again, you keep mining the same block over and over. And the further back you get, it's worse, right? Same principle as whenever you have a reason you don't have very long reorgs in Bitcoin is because the fact that the further, the deeper it gets, the lower the probability gets that something, that people are going to go back and mine that many.

And it's the same principle here. You can't get the votes on the minority chain. It gets increasingly more expensive, and then the chain just dies. I think there's another point to add here, which is that beyond the three-vote minimum, per block, there's a linear scaling of the proof of work reward. So if the proof of work block that you mind includes all five votes, you get 100% of the proof of work subsidy. And then for every vote less than that that you include, it scales it down by 20%.

So if you only include four votes, you're going to get 80%. Or three votes, 60%, and then anything less than that is not a valid block. So there is a real tangible penalty for trying to omit votes from blocks that you mine. And speaking of mine blocks, can this voting mechanism, for instance, roll back the blockchain? So could proof of stake miners decide that a set of transactions shouldn't be included into the blockchain? I don't know, say for instance, after some sort of wallet being hacked or, you know, some sort of contract executing a replay attack, could the proof of stake miners decide, okay, we don't want these transactions to be included in the blockchain? So technically, yes, it would require a hard fork vote in the sense that, you know, somebody would have to, somebody being developers would have to code up the new rules that say that, okay, we're going to, you know, either ignore these transactions or undo them or whatever the case may be.

And then that would create a hard fork and it would have to go through the majority vote. So theoretically it is possible. However, I think one of the big differences is that rather than there being some benevolent dictator that just says, oh, too bad, we're doing it. You need majority stakeholder approval. Everybody has to vote on that for it to happen. And I personally believe that such a vote like that most likely won't pass because it's a pretty gross violation of trust, right? I mean, one of the biggest fundamental things is that, you know,

somebody else can't mess with your wallet, right? I mean, if you're going to try and steal coins from somebody else, what's going to stop anybody else from trying to steal coins from you? And, you know, I think that most stakeholders understand that that is a, you know, it's sort of a slippery slope. So I personally believe you would have a very difficult time getting a majority stake to vote on doing that. So your, your ticketing system is... You're saying it's complex, right? Yeah.

Yeah, it's actually quite involved, right? Like, there's a coin, and then these coins allow you to get tickets when you log these coins up. And then some tickets are randomly chosen to vote on each block. Has there been any academic study of the suitability of this system and on, like, how people could game this system using some kind of strategic behaviors? There has been some exploration of that topic with, there's a proof of activity paper, which was, I think it was released sometime in 2014. So it was released six to, you know, six to 12 months after the original MC2 coin paper.

And the, what had ended up happening was they looked at this attack from the perspective of a proof of activity where it had to follow the Satoshi prescription, but it was the same idea that there's proof of stake and proof of work and their hybrid. And then they ask questions, how much would it cost to execute a successful attack on a currency that has a hybridization system like this? And basically the conclusion is that, yes, there are attacks where you basically own a big chunk of stake and a big chunk of the mining and you collude. But the cost of executing one of those attacks is substantially greater than just proof of work alone. And I think that Dave is much more familiar with the details of the cost of the attack than I am offhand. But I believe it, you know, it's a substantial multiplier over the 51% attack cost. So, you know, in terms of its attack resistance, it has been looked at. And the analysis provided in the paper by his Leem Izrazi, Leem, Izrahi Rosenfeld, and I think there's a fourth author. Mentov. Mentov. Okay. Benetov.

And so their paper really covered this attack vector, and it does apply fully to Decred as far as I know. The only caveats being that, you know, in terms of how much stake you need to control, it's a question of how much of the staked funds you need to control relative to how much, and it's not quite an apples to apples comparison, but it's very close. Maybe you can say more about it, Dave. This is a little bit outdated information, but it still holds true. You know, in the proof of work system, you only really have to purchase 51% of the hash power. And if you calculate all that out, it actually is roughly around $500 million right now to carry out that.

attack. If you assume the exact same price of the Bitcoin has, the same number of coins that are outstanding, the same hash power that it has in order to do an apples to apples comparison, underneath the decred system, that same attack would be roughly $2.8 billion. And the reason is because you have to purchase a lot of the stake, too. So you have to own a lot of the currency in addition to hash power. There's actually a formula that is in that proof of activity paper that allows you to specifically calculate what percentage of each you need in order to successfully carry out any kind of attack against it. And so, you know, we've used that in order to calculate these figures. There is one other piece of that that is relevant that the formula doesn't take

into account, and that is, in order to acquire that much stake to begin with, you're going to cause the price to go up even more because a lot of remember that we you know you a lot of these coins are staked so they're not on the market so they're not for sale so if somebody wants to come in and try and get 30% 50% of the stake or whatever the coins aren't even available first of all because they're locked up but even if they could in order to purchase that many coins on the market you're going to cause the price to skyrocket because you're trying to buy up every single outstanding coin so it makes the attack even more expensive than just that formula shows.

So, you know, in short, it is it is really a more robust system. It is a whole lot more expensive to attack than a pure proof of work system. This episode is brought to you by ShapeShift, the world's leading trustless digital asset exchange.

Quickly swap between dozens of leading cryptocurrencies, including Bitcoin, ether, Zcash, Gnosis, Monaro, Golem, Auger, and so many more. When you go to Shapeshift.com, You simply select your currency pair, give them your receiving address, send the coins, and boom. Shapeshift is not your traditional cryptocurrency exchange.

You don't need to create an account. You don't need to give them your personal information, and they don't hold your coins. So you are never at risk from a hacker or other malicious actor. ShapeShift has competitive rates and is even integrated in some of your favorite wallet apps like Jacks. So you can swap your digital assets directly within your wallet just as easily as putting on your slippers. Whenever you see that good looking fox, you know that's where Shapeshift is. So to get started, visit Shapeshift.io and start trading, and we'd like to thank Shapeshift for their supportive Epicenter. So let's move on to this idea of hard fork voting.

Can you describe how the hard fork voting works? And then afterwards, let's talk about a real live example of a hard fork vote that was carried out on decred. Sure. So it's a pretty involved process, but I'll try to keep it pretty high level, so we can get through it quickly. The basic process is that first the developers code up whatever the change is. And there also, it has to be a company with technical documentation that describes what the change is, what the pros and cons are, so that stakeholders.

or informed enough to be, or educated enough to be able to make an informed decision. So the first stage is that, that you code it up, and you actually put it into the software, and it's put in an inactive state. There are versions, we have several versions involved here that have to basically happen, and sort of in lockstep. So one of them is the block version. This is very similar to Bitcoin, and that is the proof that the proof of work miners have upgraded. They bump the block version to say they've upgraded.

Now, a big difference in our system, system versus the systems and other proof of work coins is that upgrading itself does not mean that the new feature is going to take place. And in most of the other systems, when you upgrade the block version, they're signaling, hey, I want the changes that come along with this block version. And Decred, that's not the case. The only reason the version exists is to signal that I have upgraded, therefore I am capable of understanding the new rules.

I don't necessarily agree with them. It doesn't mean I want them, but I can understand them. And should the rules become active, I know how to be. properly validate them. That's sort of that version. The other version that we have is on the stakeholder side because in addition to the proof of work miners that are creating the blocks, you also have the wallets, the people, the stakeholders that are casting the votes. So they also, obviously, not obviously, but as we discussed before, there are those vote bits that set the preferences. So those change over time, depending on what the agendas that are being voted on are.

and that means that the version in the proof of stake side needs to be able to understand what those bits mean too. I know what I'm voting on. I understand the agenda. This is what I'm voting on. So once those two things happen, there are some thresholds that have to be reached in order for those two things to proceed. But once those are done, then that's when the actual vote itself starts. The vote takes roughly it's about a month, and the primary purpose of that is that we want to make sure that there is a, at least one full turnover of that target ticket pull size that we discussed before.

We want to make sure that there's at least one full turnover so that there's a very good selection that we're actually taking everybody's voice into account that we possibly can reasonably. So after that month passes, you either pass the vote with a majority yes or you fail the vote with a majority no or you had somewhere in between. If there's a majority yes, there's a lock-in period. Those rules, and the purpose of this is that those rules will activate at that point. They were voted in, they are going to activate, but they're not activated yet. And the reason this is important is because, you know, you have businesses out there that

might have to make changes to their software because of these changes, whatever they are. And so you need to make sure to give the businesses time. This is like, hey, guys, you know, this will happen. You need to upgrade your software, not just businesses, but all the users too. Everybody who's running the software needs to upgrade. So it's to give them a sufficient period to do the necessary upgrades. And then after that lock-in period is done, it just activates. That's all, like I said, it's already in the consensus rules.

The new rules activate. And it's at that point that the actual hard fork takes place. So if you have not upgraded your software by that point, you get forked off the network, you have to upgrade. So in the very beginning, when you signal your intention to want to vote on a new PC, software, you said that you had to upgrade your software so that you can understand those bits. Does that imply that the software is always sort of in two states, like one where it understands the current consensus model mechanism, but also can understand the potential future

consensus mechanism should it be voted upon? Is there like an in-between state where the software understands two consensus mechanism? You can think about it like this, right? Which is that you come in with one set of consensus rules. And what you're voting on is you're voting on changes to those consensus rules. So you have consensus rule set one, and then you're voting on whether you should change it to rule set two, which has some modifications or leave it the same. In the future, we might have multiple knobs that people can turn it to. But the upshot really is that hardfork voting is just for voting on consensus changes.

and, you know, these are some of the most contentious and difficult to execute changes. I mean, typically, you know, if we're talking about Ethereum or Monero or, you know, or any of these other sort of, you know, less governance focused, you know, coins out there, which is that when they execute a hard fork or when they execute a hard fork, there's someone there literally like throwing the switch. There might be a soft signaling mechanism to say, oh, we want to hard fork, per Dave C's comments earlier, earlier in the talk. But the hard, you know, switch throwing act is something that, you know, the hard fork voting is basically we wire up a switch in the track and then everyone votes on which

switch of the track we take. And in doing that, you know, there's some soft signaling that needs to happen. And like you said, you know, there's this issue of, are you interpreting two consensus rule sets or one? And really, you're only interpreting one. And then as of a certain market, which is at the end of the activation waiting period that Dave described, only then does the consensus rule set to activate if it had enough votes. Okay. So can you walk us through an example? So recently there was, you put this into practice by upgrading the difficulty algorithm.

So there was an upgrade to the consensus rules. Talk about how that went through. Was it successful? How that sort of happened and played out? The old algorithm that we had, we mentioned earlier in the talk, that you want to try to maintain that sort of target pull size so that everybody's expectations are managed. You know approximately how long it's going to take before your vote happens, and approximately what your expiration percentage is going to be. So those are all tied to that pool size. The old algorithm did a pretty good job of maintaining that pool size.

It's a little over target, but overall it did pretty good. But the price swung wildly. It would go from a price that was really low, so everybody would want to buy tickets, and there was this huge mad rush where everybody was like, I want these cheap tickets, my yield is really high, and there's a whole bunch of competition, and that caused the fees to get really high. And then the price would jump up a significant portion outside of the range that people were willing to pay for three more periods,

and then it would return to that low period. And so it created this resonant cycle where all the ticket purchases were happening, in the low wind intervals, and it was not a very good user experience, and then there was some other negative consequences of that as far as the hash power is concerned. Basically, the proof of work miners realized that, hey, I get more fees if I point my hash power at decredit during this low interval when people are paying higher fees on the tickets, and so it would cause this sort of perverse incentive to direct your hash power at the network during a very short interval and then take it away.

And, of course, that would cause some, not really havoc per se, but it would change the expectation of how quickly blocks are being produced. So it would speed up during the period and then elongate during the other periods. And so, you know, we realized and we saw that this was going to be an issue. It was becoming one more and more as more people wanted the stake, and the stake participation was rising. And so we created the new algorithm. We did an entire simulation framework for it.

We simulated it. It was all open on GitHub. We got feedback from several different community members. We tried, I want to say, in total, I ran something. something like 350 simulations. But in the end, we landed on an algorithm, we implemented it in the code, and then we started the, you know, we let all the stakeholders know what was going on, and we started the vote.

The vote progressed. And so I think an interesting point here is that it was actually a controversial change because of the fact that, as I mentioned, the fees were really high during those periods. So part of changing this algorithm so that the ticket purchases are spread out more evenly across the blocks means that the proof of work miners earn less fees. So they didn't want to change. Even though it's better for the decred as a whole, it's solved a lot of the other things that I talked about, some of those issues. And of course, proof of stake miners wanted it. The proof of work miners really didn't want it because it's going to reduce the amount of money

that they can make. And so the interesting thing, though, was that after the vote ended up going through, it ended up being like a 98%, I don't remember the exact percentage, maybe 98.6, but a high 98 percentage of voters who voted yes for the algorithm. And the primary reason for that is that a lot of times when you have what seems to be or what appears to be a lot of contention, because there's a lot of people on social media, there's one or two guys out there being really loud saying, oh, you know, this is terrible. End of the world's going to happen, whatever. The contentiousness usually comes from a very small minority of people. And the reality is that when you actually have these on-chain voting mechanism and you can actually pull people in a trustlessly in democratic fashion,

you'll find that a lot of times there isn't as much contention as there seems to be. And that was actually the result here. It looked like there was a ton of contention. But when the vote actually came down, it was 98% positive. And so the vote happened. The new algorithm, you know, it happened exactly as planned. There was a lock-in period. The new algorithm, took effect and we could show the chart at some point if you want to, but it went from having a sort of sinusoid pattern in the ticket price to being almost a straight line now. And the number of ticket purchases are spread evenly across the blocks, which is a much preferred situation. It improves the user experience for the users and it got rid of the perverse incentives for

the hash power that I was speaking of earlier. And something else that I think is relevant here is that all of this happened pretty recently. The first hard fork vote on, you know, on the ticket price algorithm. I think we pushed the code out sometime in April. These, you know, the proof of work miners and the proof of stake miners upgraded per the process Dave described. And then the voting began. And I think the voting began in early May. It ended in early June. And then the new rules activated, I think it was either July 8th or July 9th. So, you know, so all of this, you know, at least it working in production is a very new thing. And one of the reasons that you and everyone else might not have heard

about it is because we didn't want to publicize it too much and then, you know, not have it work when we when we had it running on main net. So, so that's, so that's the sort of recent history of, of this vote. Is this like one of the first heart swaps? Like, so for example, When this ICO, one of these selling points was, okay, there's going to be a protocol and like while the chain is running, you could change the rules, like while the chain is running. But it seems that you have already done it. Yeah, it's their goal is basically the same thing that, you know, they want to have a way to vote on consensus changes that just happened whenever the vote succeeds. and that is correct. That is exactly what Decred does and it has already happened.

Is there any other project that has a capability like this? There are none that I know of. There are projects that have voting type systems. However, they're all, what I was speaking of earlier, is that they're all pretty much at a layer where it's sort of soft signaling, and I think Jake mentioned it too. It's like, hey, we want this, but ultimately it's up to, you know, one guy to flip the switch, right?

It's not actually on-chain. you know with this system the the rule change is put in place and then you know we could all go get hit by a bus it doesn't matter it's going to happen if the stakeholders voted in right there's nobody that has to flip the switch it's built into the protocol it's transparent it's provable it's cryptographically secured totally trustless and i don't know of any other system that actually and i know tezos once the tessus i've you say i know that that's their ultimate goal but it you know that they don't have it yet. And that's the only other project that I know. The hard part for us, too, you know, when we're answering questions about Tesos is that until we, you know, until there's a

production code base that we can look at and go, oh, this is how they're doing it. It is legitimately difficult to do a compare and contrast. Like say in the case of Dash, you know, I think Dash is a production system. They beat us to the governance thing. I'll give them that. But their system is, per Dave's comments, it's a soft signaling system, at least it is right now, where changes will be proposed and people can have a snap vote that occurs very quickly. So they can get, you know, they can assess their, you know, what, master node sentiment very quickly. But even if the master nodes all vote, yes, someone, you know, someone within the project has to go wire up the consensus changes, just, you know, just like we were discussing. And then, you know, they have to throw a centralized switch as opposed to the way we've done it, where we pre-wire all the changes and go, we can go whichever way you guys want.

we didn't wire this up in vain, but if you guys don't want to do it, it's not going to happen. And one of the key points there that I find really attractive is that a lot of times people only look at it from the standpoint of, you know, oh, did this get activated or not? However, a key point is that it's actually quite important that if something doesn't get activated, that if you get a majority no vote, that is actually a very desirable outcome too. Sure, you may not be happy that you put the work in and your, you know, whatever didn't get activated, but that tells you move on, right? Find another solution. You're not going to spend the next two years arguing about it.

It's done. It was a majority no. You know, find another way. Let's move on and just keep things rolling. Cool. Like, yeah, this system sounds really interesting. Like, yeah, the idea of like pre-wiring all the clients to understand both the old chain and the new chain. And then they're being a vote and an automatic like hot swap from the old consensus rules to the new consensus rules while the chain is running.

Yeah, this to me somehow it feels like, yeah, this is the, this is at least one of the directions, all cryptocurrency systems will end up going going to one way or another. But yeah, congratulations on being probably one of the first to implement it. So that kind of brings us to the final topic, which is that with the credit, as far as I understand, part of the block reward actually goes to the development. which in this case is you and your company. And we like to understand how much goes to the developers and like how are these funds, where do these funds go to and how are they utilized and how do you seek to evolve that system?

So the way the development subsidy works right now is 10% of every block subsidy gets sent to a multi-sig address. address. That multi-sig address corresponds to what is currently a centralized entity that manages development called Decred Holdings Group LLC. It's a Nevis LLC, and I'm a manager of the LLC. So the way we've been doing this is that in terms of how the development organization fits into the development of the project overall, is that people show up and some of these people are very interested in decred. There's a lot of people who are just, you know, who show up in our Slack, they want to talk, they want to hang out. Some of these people are even more interested and they go, you know what, I really want to take

a close look at your source code or, you know, I want to help you build this software, I want to help you market, or I'm really good at documentation, and I notice there were some gaps in your documentation. So people show up and are interested and, you know, what we've been doing is that Company Zero is really sort of the main contractor at this point, and they, and they, And that's the company that I run. And what we do is that we do all the development work, you know, in-house, and then we bill the project for that work at no markup. And the purpose of doing this is that, you need money to build out one of these systems.

Bitcoin is a great example of a tragedy of the commons in the sense that, you know, say before Blockstream, there are some, you know, the Bitcoin core developers, there are some very talented people there, but no one was really getting paid. So it creates a tragedy of the common situation. We've sort of fixed that by having this developer subsidy. But this is just a short-term arrangement. The idea being that over the next six to 12 months, what we'll be doing is we'll actually be dissolving the development organization

and placing these funds that are currently in a multi-sig wallet into what might be a pay to script hash or another form of storage. And then those funds will be controlled by the stakeholders via a proposal system where, I mean, let me give you an example. You might be, you know, someone who's a marketing contractor. You show up and you have a really great idea for a marketing campaign. You talk to some of the marketing people, they go, oh, that's a pretty good idea. You make a proposal, and then people vote on it.

If enough of the stakeholders say yes, it will get funded and your work will be paid for from what is essentially the decred DAO. It doesn't exist yet, but we're sort of building backwards to get to the that point. So the way everything is funded right now is we have a stopgap, which is a centralized entity that pays contractors. Basically, if you're interested, you show up and you do some work and the work is good, we'll talk to you about, you know, paying you to continue doing this work. And that's sort of how things are running now. And, you know, we hope to basically continue a similar model, but one where stakeholder approval is explicit and on-chain. So tell us about

the current use case for decred. I mean, it's a currency. There's a, there's a market cap, there's a price. Is it being used as a currency? Are merchants accepting it? Are there use cases that are being built around it? There are a handful of merchants who, you know, are services that accept decred as a means of payment. YREX is one of them. Another one is coin payments. Coin payments had, I think, had the payment that, you know, had decred offline for a little bit. The upshot, I mean, the way I see it is, is that any of these projects, whether it's Bitcoin or any of, you know, or any of the follow-on cryptocurrencies that we've seen over the past several years, it's, it almost always starts out as a store of value first. And then, you know, after that store of value sort of

gains some, you know, legitimacy, people want to then start spending it as opposed to just trading it in a speculative context. So, you know, I feel like we're still in the, you know, I feel like we're still in the phase where it's more a store of value than it is a, what is it, a means of transmitting that value. And I think that the reason that people consider it an attractive store of value is because of the returns you can earn from being a staker, in addition to the fact that you get to participate in the governance at the same time. So it's, you know, we're more in the store of value phase right now, but, you know, as the project matures, we're really going to be focusing a lot more on merchant acceptance and payment processing.

Okay, great. Well, Jake and Dave, thank you so much for coming on the show today. It's fascinating to learn all about Decred and the interesting work that you're doing around governance and will be interested in hearing developments about Decred in the future. And as you roll out more features and as the community and the currency itself can continue to grow. Thank you. All right. Thank you for having us. And thank you to our listeners for tuning in. Epicenter is part of Let's Talk Bitcoin Network. You can find this show and lots of other great shows at let's talk bitcoin.com. Of course, if you like the show, there's multiple ways you can support us.

You can leave us a tip, and the tipping address will be in the show description. And if you don't want to leave us to leave us a tip, you can just leave us an iTunes review. Go to iTunes, leave us a review. It helps people find the show and for the show to get referenced there. So thanks so much, and we're looking forward to being back next week. You know,