Will 0:04

I'll just kick off by giving by saying a few things. The first is. I know that we've had sort of a lot of governance recently. So I just wanted to say thanks to everybody who's active and participating in those proposals. Because obviously, it's for the really important stuff for the DAO. Right now we have the snapshot that was put up by Jake yesterday for TIP 28|29, you guys know what that one is. We have the DAO Governor Bravo test run. That's that one's exciting, actually, because it's on-chain. We're actually using our governor Bravo contracts for the first time through boardroom. You can also use with Tally if you want, but we're kind of rocking with the Boardroom recommendation. You just go there, connect your wallet. And then you can vote. But make sure you're connecting via the account that you have delegation weight on, or that you actually have your own own weight on. And then we're working towards the last one that you guys will hear about pretty soon here is we're working towards a on-chain token mint proposal. So we already did the snapshot for that one, which we're just counting as like the temp check. And we're just going to move it straight into Governor Bravo, even though it was pretty much already validated by the DAO, but we actually have to have the DAO mint, more tokens, on-chain for inflation based rewards for node operators on the network. Pretty stoked about all that. And then the one other thing that I wanted to say was, I thought that the announcement from Ash and John today was super cool. I definitely want to, going forward, like continue to highlight more of the stuff that the guilds are doing in announcements to increase visibility there. So that's my spiel about governance and l some other cool stuff. With that, I'm gonna pass it over to Beau.

Beau Shinkle 2:02

Hey, everybody. If you are not clicked into sort of my Discord stream, this would be the time to do it. I'm going to be doing some whiteboarding stuff as well as talking over it. So video is going to be at least half of what's going on, it would be useful. I have a nice nine item list of Agoristen’s wonderful questions to go through. I'm going to do those first. And then we have some other ones. I think they'll be nice as well. First up, how is the audit going? I have to be a little bit evasive here. Unfortunately. We have an audit from Trail of Bits and Least Authority. Trail of Bits has been more communicative than Least Authority has been. We've gotten some weaknesses identified. And and shoring up those weaknesses may take some additional time. But also we might be able to deliver as, as intended. How's the client work progressing? Still according to schedule? Yeah, as far as we can tell, we are on schedule. So things are still going well, client side. And then getting into the sort of the meat of it. Can you explain the relay used in v2? And how it differs from v1? Who funds it? And the potential risks and centralization risks with the relay? This is a this is a huge question. I think it's like, it's an incredibly important one. And so I want to go through a lot of the context here. Starting sort of like from the beginning. So in order to explain what a relay is, what the v2’s relay is and what and how it differs from v1. If this were to explain, like what we what what we're trying to relay and why we need to relay information in the first place. Like why we have to tell Bitcoin about or Ethereum about Bitcoin and what exactly we're telling them. So the idea is that whenever we make a deposit or a redemption, or whenever we want to make a deposit or redemption, for tBTC, we need to prove that that actually happened on Bitcoin side, otherwise, the system would be vulnerable to like rampant fraud. Hopefully, that is, that part's clear. So this is. The idea for Bitcoin, which is a proof of work network, is that. That was a weird sound. Yeah, we got recordings set. The idea for Bitcoin is you have a bunch of transactions. So you have like TX one, TX two, like TX three. And then this all makes up, like a block.. And what we're going to do is we're going to hash this. So this goes through something called SHA-256. And so when you put this through SHA-256, it's going to spit out a, this huge sequence of, of hex numbers. So like, in the same way, you have an Ethereum address that might look like 0x19F2, like whatever, it's gonna spit out a huge sequence of numbers, that 256 numbers or, bits long. So the idea is that we want to hash this whole block, and it's going to spit out a singular, hex string. And whenever you hash this block, it's always going to spit out the same thing. So what we're looking for, is to hash a block and have this hash number, cause this is always a number, be less than a difficulty. So that's, the first person that can find that wins. The issue is that whenever you like, are trying to hash a block, you're always gonna get the same thing. And so like a miner takes all of the transactions they want to include. And then then they hash it. If it if this number is greater than difficulty, they didn't solve the problem. So then they're stuck. So rather than picking a new set of transactions, to potentially hash, they include a nonce. Which is just like, their favorite number. So for instance, like maybe this is seven, or maybe this is like 1932, or 4,392,800 935. And so they're just trying like random nonces. And every time you pick a different nonce, you're gonna get a totally different hash, and that totally different hash might be less than the difficulty, which never changes, for this particular problem. And so the idea is that the only way you can, you can get a hash because you can't know what the hash is going to be until you actually hash it, is by trying different nonces. So you pick one to start, and then just increase it by one over and over and over, hashing it over and over and over until you randomly arrive at a hash that's less than the difficulty. And then when that happens, you've done a lot of work. So if this difficulty is like, if this number is very low, then the chances that you would randomly pick a hash that are that low, is very low. And so we on the Bitcoin network, people are just making so many hashes all the time that we set this difficulty number to be low enough that out of all the computers on the network, only one person solves this problem once every 10 minutes. And that's how we get one block every 10 minutes. And in addition, when you're creating your transaction set, we also include the hash of the previous block. And that's the blockchain. So that's Bitcoin. You have the hash of the previous block, all the transactions in the block, and the nonce at the block. And then that's and it just keeps going. So part of the trouble is that this is like a lot of data. And so we have this idea for a Bitcoin header. So one of the problems that often comes up is, like, let's say we want to store information about this chain in a compact way, that allows us to say like, Hey, like transaction two happened. And I want to prove that it happened without showing that like showing the entire block. And that the fact that transaction two is part of this whole block, and that when we hash this whole block it includes the hash of the previous chain, which includes the hash of the previous chain, all the way back to the original ones and those all paths difficulty, that's like, that's how you would do the whole really involved proof. Like, I sent money to you, that’s transaction two. Transaction two is part of the block with the nonce, we hash it, it's part of part of the difficulty, it includes the previous block, that one's also verified all the way back to beginning of time, thus, my money is valid. That's way too involved. So instead, what we typically want to do is we just want to include three things. Sorry let me write this a little better. All we care about is do the headers, we have the previous block, this block, previous hash, this hash, then we had something called the Merkle root. So rather than including this whole giant list of transactions, what we're going to do is transform these into the Merkle root. And then we're going to store just that information every time. And then the way that this works, is like this. so say you have a transaction, whose ID is 0x Alice, and just like picking nice simple names here for demonstration. And then like her block, imagine, for demonstration your block only has four transactions, you've got a 0x Alice, got 0x Bob, you have 0x Carol, users transactions names, then you've got 0x David what we can do is we can hash 0x Alice and 0x Bob together, and then this is this might give us like, a get like Alice plus Bob hash is gonna give us something, when we run that through SHA-256, it's gonna be this long string of letters and numbers. But let's say for convenience sake, this is gonna give us 0x dog and then if we hash Carol and David this might give us like 0x cat, it won't but like, I don't want to write out what it actually would be. If we hash 0x cat and 0x dog, maybe that gives us 0x apple. The point is that we hash these two together we get this, we hash these two together, we get this. Then, we do this and it looks like you know, like a final four NBA or college basketball tournament bracket. This is the Merkle root. So the idea is that we can take the whole transaction list and then hash everything up into this like tournament bracket and end up with just one hash at the end and then store just that one hash. And then if anyone ever wants to prove that for instance, Bob was in the block, then they can do so by providing Bob, Alice, and then that with dog yields the root of Apple. Sorry, that's going to make dog and they need to provide cat. So this is like their bracket path. So if you like imagine like your favorite basketball team is, is the Bobs and that the Bob's are going to play against the Alice's, and then once they win, they're going to play against the Cats. And then the grand winner is the Apples. And so when you want to prove that Bob was actually in this tournament, you provide your bracket path. And that ends up with Apple. Because we know that Merkle root which was published on-chain is Apple, that's proof that Bob was in the bracket. And so that lets everyone know that Bob was in there, he was one of the transactions that made up this Merkle root. Otherwise, you could have never gotten there. And so what this does is it makes it so that we can prove that transactions are in blocks. While on-chain, the only thing that we're storing is 0x Apple rather than this whole huge list, which could be you know, like a 1000 transactions per block, or like even more. So it massively cuts down on the storage space, in exchange for having to do this longer proof every time you want to show that something is in here. So that's part of it. The next thing is that Bitcoin, every 2116 blocks, changes its difficulty number. So the difference between the full relay that tBTC v1 uses is that tBTC v1 uses the header, which has the previous block, this block, and the Merkle and then, you know, uses that again, previous, for this Merkle it does that every 10 minutes. It publishes this information. So one ID, one ID and then one ID. So it's publishing three pieces of information from Bitcoin to Ethereum, every 10 minutes, that's the v1 relay. And then whenever you want to prove something like a deposit or redemption, you prove, you find the block that your thing, like your your Bob transaction was associated in and then you you you show the whole transaction path that gets you to your Merkle root, and that shows that that your transaction was valid. On top of that you normally also provide the next six blocks to show that like you're not in in like a weird offshoot of Bitcoin. That's additional complexity I don't want to get into. But that's the basic idea. So every 10 minutes, the current v1 relayer is publishing information to Ethereum. The light relayer. The main thing that it's doing is that it only it only publishes the blocks immediately surrounding when the difficulty changes. So Bitcoin does a retargeting, which means that it's changing its difficulty every 2116 blocks. And that means it like the number you have to get when you hash a block in order to to make a block part of the chain changes. And so what we want to do is take some number I think we picked 10. So that we want to publish the 10 blocks before and after the difficulty changes. and just those. So rather than publishing all 2016 blocks, we're just publishing, like 20 of every book of every 2016. So it's like way less, then, when you actually want to prove that you're part of the Bitcoin, like, when you want to prove that your transaction is valid, what you do is you show A, that you, your transaction has the same difficulty, as the as the most recently published, relay block, and B, that it's held up by an appropriate amount of work. And so the amount of work that's held up by is demonstrated by the fact that each of these headers that you're publishing, couldn't have been made, unless enough computing power, could have found all of the blocks via these hashes to find the correct difficulty, so like, because it's so difficult to find the hash of something the hash of a block where the hash is less than the difficulty. And then, if you do find one where the hash doesn’t meet the difficulty, that must mean you were either a insanely lucky or be there was a lot of work done. And so when you provide multiple blocks in a row, where the next block includes the hash of the previous block, that means that like, you're either getting, like, out of this world lucky, or the work was actually done. And so now, this is proof of a lot of work, but but it might not have been on the correct chain. But then when you show that the difficulty is exactly what it should have been, according to the relay, that now we're also sure that it's on the correct chain. And so when the different one, the proof of work is done, and it's on the right chain, according to the relay, because we're checking based on this retargeting, then then we're good. So we have drastically reduced the amount of on-chain storage, from every block to, like 20 out of 2016 blocks. So we're able to, in current estimates, reduce the amount of costs from the current v1 relay to the v2 relay by about a factor of like 500, which is good, very, very good. So that's what we got relay wise. I know that was really dense, but wasn't sure how else to answer in like a, in an honest way, how relays work. Alright, so next up, do we have enough nodes? What is the minimum? And what is an ideal amount? So the way that the way that nodes work, and I can draw this. It’s kind of a complex question, because there's a lot of balancing between economics and sort of like security going on and also optics that and that makes it confusing. So I wanted to, here's what I mean by that. We are at launch, and this is subject to change, a 51 of 100 multisig on every new wallet. On every

East 24:16

I’m sorry Beau, Beau?

Beau Shinkle 24:21

Hey, what's up?

East 24:23

No, I think you got some questions from the previous subject.

Beau Shinkle 24:28

Yeah.

East 24:29

From Agoristen in the in in chat in call chat.

Beau Shinkle 24:34

In call chat. Let's see. Agoristen says who is pressing the buttons publishing on ETH? Oh, yeah, centralization risk. So the idea is, anyone can publish information to the relay and It is checked by, by like the Bitcoin targeting algorithm. Right now it's like, I think it's trust, it's, it's trusted maintainers. So you have to be approved by the DAO, I believe is how that works. I would need to check with Piotr. But it's like a list of clients run the the maintainer code, or the relay code. And then they are constantly monitoring the Bitcoin network. And then if they, once they see that we're like approaching the 2016 number, then they then they start publishing again, or at least it's like how it worked for, like the v1 maintainer. The idea is that we would create an allow list of operators voted by either like the council or by the Staker DAO. For their light relay for who could publish that data is like one approach. But I would need more clarification there. What happens if those people conspire to publish bad information? I would need to look at the actual like solidity but the, what I do know is that Bitcoin itself has a lot of regulation arounds, what the targeting information is, so for instance, like it uses a sliding window of of what their what the retargeting difficulty can be, like, there are hard and fast rules. And so if people conspire to feed the wrong information, then what you end up with is like, you really quickly can find that out and it desyncs. I don't know what would happen in that case. I would need to think through that more. Let me get back to you. I think there should be a lot of like, ways to guarantee that really egregious information can't just be published. But I'm not sure about more like insidious attacks. So let me get back to you after I find out more. Yeah, yeah, exactly, John. Like, especially because like any, all those block headers have to include the hash of the previous block. And so to anyone watching it, it just won't. So I'm trying to think like, like, when you saw me sort of staring into my eyes, that was me trying to figure out if there is like a way to falsify that to make it also not look like it was false. And while I was struggling, yeah, let me before I just tell you that it's foolproof. Let me find out if it actually is. And then I'll circle back. All right. We got notes. We have a 51 out of 100 on every wallet. And the idea here is that we have we have like a lot of operators, and in the case where we have 1000s And everyone has just like one stake this is really simple. So I think it's like much more interesting to consider cases where you have a lot of centralization because I think that's what people are are worried about. So for example, let's say that like Alice controls like 30% of the network. And Bob control 20% and Carol controls 20%. What are we up to now? 70 and David controls 10%, I'll just give David 20. Ever controls the remaining 10, we have our actors. 30 50 70 90 100 is myself. So these are our, these are our players. And when we create these wallets, it's with replacement. So this is all of the stake on the network, it doesn't matter how many nodes you're running. What matters is like how much stake you have. So Alice could have, be running like five nodes. But split between those five nodes is her 30% stake, Bob could have their 20% stake on one node, but what matters is like is your stake weight. So what ends up happening is we have to get, you know, our 100 seats. So you get like, seat 12345. And then there's gonna be like, 20 of these, right. And so when we go to select seat one, we're in a slight dip with these probabilities. So you're gonna roll your 100 sided dice, and it's gonna come up, you know, like, 23, so that's probably Alice. This might be like, 62, so that'd be like, Carol. And so if someone could generate, you know, number between one and 100 for me, and it would come up the case, that around 30% of these seats are going to be Alice's and around 20% of the seats are going to be Bob and so on. So maybe the final numbers look like this. Alice has 31 and Bob has like 23, Carol has like 18, David has 14 and Eve got really lucky. As a man, I don't want to do math 31 34 54 72 76 86 14 Yeah. So that's what, that's how it might randomly play out. So these don't guarantee how many stakes you have, these are just like your, these are your relative probabilities of getting a particular seat with replacement. And so, what ends up happening is at the end, you have you have all these people with this number of seats on the wallet. And when you go to sign, you just need to make sure that you have 51 of 100 people able to sign any particular message so that's like confirming that a redemption happened or trying to send funds or confirming the deposit happens all those sorts of things. It's also the case that any fees are divided evenly for a while. Take me for example, if if after like a month of the system running, we generate 10,000 T, then Eve or Alice is going to get 3000 and Bob is going to get 2000. Carol 2000 and David and so on right. So people get like whatever fees are generated as a whole in the system are split up regardless of whether or not you're a part of a wallet, by how much total weight you have in the system. Which means that the more people who decide to run nodes and to stake, the lower the APY of everyone there is. And so when I started thinking about this on like an economic level, what I think will happen is that if the APY, or tBTC v2, as an operator is really good, we'll see more people as independent node operators, or even like, stake like using staking providers join the system, to, because it'll be like, a really good opportunity in the market. And when when more people join, there is less of the pie for everyone else. And so, like 20%, might become 18%. And then when more people join then 18% becomes 17%, until the market saturates, and you're getting like 15%, just like every other opportunity, or whatever it is, in terms of like, USD on your on your stake. And then what happens is, you know, if, if operators start dropping out, then everyone else starts making more money. So that's like, that's the economic side, the optics side is that we want, we want to be able to say that we have like a decentralized system, that we don't have a lot of stake centralization. And so we want to have a lot of nodes. And so just having five people control, this massive amount of stake is really bad for that. From a security standpoint, we we want to make sure, for example, that like, Alice can't just DaaS a wallet. And so if as long as Bob, Carol, David and Eve are online, they they all have enough weight by themselves, to sign any message. So Alice currently can't do that, even though she owns 30% of the whole thing. As I think the last time I checked, the largest single stake was like 11% of the network, or maybe like nine somewhere around there. So I think we're safe in that department. Could be wrong about that number. And then the other side is that if enough people come together, a bunch of colluders come together and they gain above 51 of 100, then they can sign messages fraudulently. So for example, if there is like $10 million worth of Bitcoin, in in a wallet, then those 51 seats have nowhere near that amount of T stake, to serve as collateral like to be slashed, so they could potentially take the underlying funds, forfeit their T stake, and then just be gone from the community. So that's like, we'll get into this when we talk about like honesty and the honesty assumption. But that's like, always a potential risk factor. And so you want to have enough like independent operators, that it becomes more and more difficult for people to collude like that. Because it would be like the more sort of parties you have to convince, to install, like modified clients, the harder that becomes. And so to answer the question of like, do we have enough nodes, I think, on a, on a practical level, the the amount of nodes that we have currently is enough in terms of both security and profitability. But I don't know enough about the marketing to know if it's enough for the optics. So I'll leave that to people who are more knowledgeable than me about like how the space feels. All right. So then, should node operators, run one node each, no matter their T stake size, or is there any reason and advantage to run multiple nodes. So from a protocol level, there is no reason to run multiple nodes in terms of like gaining economic incentive. But from a practical level. If you're like a big whale, you should split your stake up into multiple availability regions because If you have all of your eggs on like the AWS East basket, and AWS, or AWS East goes down, that's bad. And so it would be better to run like multiple nodes like AWS East, West, maybe as well as maybe like Google Cloud like, like split your stuff up so that if datacenter availability hits that way, like you aren't wrecked. This is just part of like, just like not being centralized, even in your own computing. And I think that should make sense intuitively. But in terms of, like economic incentives, there aren't any. Hopefully, that part makes sense. But is there any relationship between T staked and responsibilities in the network, and then are all node operators equal no matter the stake, so the more T that you have staked, the more operator seats that you'll get in each of these wallets. And thus, the more impactful, your decisions to stop staking are. So for example, we have this parameter called like a heartbeat Threshold. So we have these 51, of 100 wallets. And we also have a heartbeat of 70. And what that means is, periodically, all of the clients will check on each other, and be like, Hey, you still there, you still beating, everything's still okay. And everyone will like, signal to each other, they're still around. They do so but I think like by signing an Ethereum block, make sure that they can still sign stuff, their private key material is still kickin. But the idea is that if if some number of signers is less than this heartbeat, governable parameter, then the wallet goes into emergency mode, and starts trying to transfer its funds to another wallet. And so if you control a large number of seats on the wallet, so for example, like let's say that at the most recent heartbeat, there were, like 75. And then you're like an Eve type, you've got 10% of the network, I think that's like the biggest we have last time I checked. So then you've got 10 of these seats. If you decide to drop, then maybe like, also, notably, we are creating a new wallet every week, if you own 10% of the network, you probably unlike tBTC v1, you probably have 10 seats on every wallet, like there abouts. So if if a particular wallet is at 75, and you decide to drop out, then this 75 is gonna go to 65. And so that's going to trigger that wallet to start transferring its funds to another wallet. And so what ends up happening is that the more stake you have, the more important your particular decisions are to the wallet lifecycle as a whole, because your individual decisions have a larger impact on like whether or not a wallet is safe for heartbeats. And whether or not it's going to be able to transfer funds. And so like, for instance, if Eve controls Alice controls 30% of the network. If a wallet is originally at 70, like 71 or something, then when if Alice drops out, it's gonna go from 71 to 41, which immediately goes from like passing heartbeats to not being able to sign messages. So like Alice is hugely influential, it's like that's not a spot we want to be in. And so something that would be really important for governance is paying attention to how like, what's the largest staker and checking, see if there's a someone like Alice, and you're like, Okay, well, it turns out that, like, every wallet has 30 Alice's in it. And so we need to make sure that heartbeat, this number is at least, like 35 higher than this number. That way if like an Alice ever leaves we still have enough to sign with everyone else. That way there just like a huge buffer or something. So that's that's part of how those things all play together l. Let me see, check chat real quick. Right, and I don’t see anything there. Okay is there want to learn more about Sybil attack and honestly assumptions. So the Sybil attack stuff plays into it messing with governances ability to, to do this effectively is. So there is not any economic incentive. But there is a cause chaos, if that makes sense. So like, because governance needs to be able to set parameters based on what they think, like largest stake size is people can like make themselves look independent. And then perhaps governance, like sets parameters, assuming that there's a whole bunch of independent node operators, when actually, it's a lot of like, closely correlated, not actually 100 operators, and then they all decide to leave the wallet at the same time. And then that really hurts the system. So like, and then, because that hurts the system, maybe tBTC, as a token, starts losing in value. And that node operator is also short in tBTC in some position, and that's the attack like so that's, that's a vector. So that would. As far as, as honestly, assumption wise, I think here's the, here's like a really simple way to think about it. So, let's say that I'm in, I'm in like, a really simple loan business. And the way my loan business works is, I give people ten dollars and I want them to give me back eleven in a week and that's, that's my whole business. Really dumb. That's it. I don't do a credit check. I don't do. That's my whole role. I've got this pile of cash, you come to me, you need 10 bucks, I give you 10 bucks. And I'm like, okay, in a week, I just need eleven and, and we can like model how well this business works. And like a really simplifying assumption for this model. As they say, there are some percentage of people H, that will actually bring me back eleven. And for those people, I make $1. And then, for everyone else, which is one, one minus H people. I'm going to lose $10. Right. So profit is equal to this. H times one plus the opposite of H, times negative 10. That's my product. So if you think about it, if everyone's honest.L, then on on every time I do this, I make a dollar, if H is one, right, because one plus zero times negative 10 is one. If you think about this in terms of Sybil attacks, if you've got one guy who is totally dishonest, and like sort of glossing over the idea that you have like honest people who just couldn't come up with the 11, we're calling those people dishonest to make this easier. If you have like a dishonest person who's like, hehehe, I'm going to take the 10, and then I'm going to put on like a clown nose, then I'm going to come in, I'm going to take another 10, then I'm gonna put on thick mustache, and you've just, then all your money's gone. So you've got this, you know, ignoring that, all you're doing is you're giving out 10 bucks, there's a percentage of people, H, that are honest. And there's one minus h people, that's the other percent that are dishonest. And this is your profit. And so if you expect the, you know, for instance, at 50%, honesty, and you'd be getting, you know, point five, here, plus negative five. So on average, you'd be losing 4.5 dollars per offer, horrible. So you can calculate what percentage of honestly you need, in order for this sort of gamble to be an effective business. And it's pretty high. I don't want to do the math right now. But it's probably like in the 90s, someone else will plug this into Wolfram if you want. But tBTC runs on sort of like the same, the same idea, where what we say is like, there's some percentage, H, of like, honest folks, who want to run the protocol and earn money, and who aren't going to modify the client to do anything nefarious or otherwise uncouth. And with that honest number, we can calculate. Like, what's the probability that a, that a wallet will get taken over and and then like, we can go from there. And so like, in the exact same way, I can calculate profit given like an honest, H, number, I can calculate wallet security, given a percentage of people who don't want to, like learn how to modify client code and deploy it, or don't want to collude, you know, so it's the same deal. And so once we're now in like probability lands, then we can do the same thing with buying insurance. So it's like given an honest percentage H, of operators, there is a probability that a wallet loses its money and a probability that it won't, because it's, it's like very, very difficult probabilistically for a dishonest majority, to take over a wallet, that's 51 out of 100. But like they could, and so. And if they did, it'd be bad, like if we were completely uninsured. And so if we have a coverage pool, then we can pay the coverage pool to insure us for like a cut. Or even like partially insure in the case where they don't have enough money. So like segwaying into number nine, it's like, what are the estimates for how large the coverage pool must be? That like, it's got a bigger inch. So for example, if, in the beginning of this system, I think we wanted to have caps on how large these wallets can get to, like, as we're sort of like battle testing and hardening parameters, and all that stuff. The idea there being that, like, the more money that is in these wallets, the the more incentive, you have to be dishonest, and to steal the underlying funds and to modify your clients. And so we, as we're like, sort of testing this out and making sure, or even like even making sure that the code that we wrote is good, because like auditing goes only so far, testing can go so far, we want to make sure that this works on like mainnet. As we're doing this, we're like we want to make sure that the coverage pool is there. And if if any amount of the funds get lost, like start thinking about what actually happens, like to the token to the tBTC itself. So you have you have lost underlying Bitcoin and you have tBTC floating around in DeFi and it doesn't just immediately go to zero, like it, it probably loses value, but not all of it. And the coverage pool can like reinsert Bitcoin to to the protocol, but it probably doesn't have to insert all of it. It doesn't have to insert all of it all at once. Like if people believe that it will eventually be made whole or that like you'll eventually be able to get it out then the token will still have like partial value it just might slightly depeg or you know, so it's like it's really hard to predict exactly how much the coverage pool needs to pay, in my like, but that makes me uncomfortable, in my ideal the coverage pool has enough money to cover whatever the biggest wallet is, is how much I would like but I think we're like pretty far off from that currently. All right, and then, let’s see what else we have. Pants asks, I have a crippling gambling addiction that has proven to be more stubborn to kick than I thought, will tBTC v2 do anything to curb this addiction if not, are there plans for this in v3? Well, pants I have some good news and some bad news. The good news is is that tBTC v2 is going to enable your gambling addiction so what we want to do is, alright let me whiteboard this.  Gambling so first I I don't know if this is a serious question. I'm going to assume it was like mostly a joke. But I think it's fun to talk about anyway in in v2, and then for like for forgetting Bitcoin on to Ethereum in general, I think the sort of like main use case that I see for it is you you're like a holder of Bitcoin and you want to have your Bitcoin be on Ethereum and give you some sort of a financial benefit so it's people who want financial benefit on Ethereum. Ah but feed pleasure to Bitcoin because if you didn't want to keep your exposure to Bitcoin, it's really easy to just like, sell it, buy something else. But if you want to hold tBTC it's because you want an asset that gives you some sort of financial benefit, but you want your asset to track the price of Bitcoin. So that's why you're doing it to me at least. And so when we talked about why you want like the sorts of financial benefits on Ethereum that's to me I think there's like two main ones, there's like yield farming opportunities. And then there's like leverage opportunities. And the second one, if you like, sort of look to see how Bitcoin like how WBTC or REN is actually being used is way bigger than all of the yield opportunities. And so, what we want to do is make sure that you can have really easy access and deep liquidity for any of these sort of like like lending protocols and in order to do that, and this is for this and the reason I titled this gambling is because if if your plan is to take your tBTC and then convert that into USD and then convert that into tBTC for leverage. You are gambling and hopefully this is feeding your crippling addiction but in order for you to do this effectively, we need to have deep liquidity pools and, like either Uniswap or SushiSwap or whatever in trading pairs of tBTC, to either ETH or thUSD or USDC. So those are the big ones. So what this ends up doing is when you think about how you interact with like one of these leverage pools, you take your tBTC you lock it up, and then you get thUSD, right, like that's how that works sort of like fundamentally and then you take your thUSD and you have to sell it to buy more tBTC and then once you buy your tBTC you need to lock it back up again to get more thUSD but you then sell to buy more tBTC, to lock back up, into your that you're getting your leverage, They can gamble because you think Bitcoins gonna go up. And so if there isn't enough deep liquidity in these trading pairs on like Uniswap or SushiSwap or whatever, then you're getting wrecked by slippage. Big ol frowny face. So you have to make sure that there's not slippage, or you can't gamble. So that’s what we're trying to do so that's the point. It's the master plan in regards to gambling. Hopefully that helped or didn't help. Oh, all right. What else we got? Remember, there is one more question from Will about governance, governable parameter is I talked a little bit about it with regards to the governable parameter about the heartbeats which is super important. The the other ones are the actual security parameters. So like, wallets are 51 of 100. Both of these are governable. And both of those are really important. They’re very difficult to change it takes like a bridge upgrade rather than just like a vote but watching to see sort of like how the system is evolving rather than like thinking about it in terms of launch will be like this is gonna be the most important decision that we make, is what those numbers are set at. The The other thing is setting the number for how Bitcoin is dispersed between wallets after a wallet decides to close and what I mean by that is the following. So let's say you have a, you have wallet one, wallet two, wallet three and wallet four and they have different amounts of Bitcoin in them, like this one might have like 100, 200, 150 and 350, wallet one is the oldest here and so, say that wallet one just failed a heartbeat or failed redemption or whatever reason it has to close, so this one is closing. So, if we say that the max transfer is 200. And what it's going to do, is it just going to it's going to like sort of randomly pick one of these wallets. It's going to like transfer. And then now this is 250 Bitcoin, right? Because all of its 100 goes to 150. Now it's 250. So that would be if the max transfer is 200. If instead, this max transfer was 50, then we would have to transfer like 50 here and 50 to here, to get 250. And 400. The issue is that this over here, this causes there to be like less wallet Bitcoin variants. But this costs more money. And it's more chance for something to go wrong. Because it's a bigger proof. And so, every time something like this happens, there's no one to charge. Because there's no, there's no user doing this. So this is something the protocol has to eat. And it comes out of the like, the donation fund essentially so governance pays at the end of the day, for these. Fortunately, we only make 52 wallets a year. And these sorts of like these sorts of proofs don't cost that much. And the Bitcoin transactions also don't cost that much. So the marginal cost in transferring is low. And so it's like unless Bitcoin gets like egregiously expensive or gas costs is egregiously expensive, in my opinion, this parameter should be low so that we're trying to balance out all of the money to all the different wallets rather than like dumping one Bitcoin one wallet completely into another one. That's like another really important governable parameter. There's just basically watching the fee markets, balancing wallet risk with fee risk, and operator fees. All right. Um, and then, like, the other really important for like, governable parameters are just all about the actual fees we're charging, because otherwise we’re not making money. So we have, like, how much it costs to, to go like from Bitcoin, on a deposit, much like how much of the Bitcoin we're taking on a deposit and then how much of the Bitcoin we're taking as a cut on the redemption in terms of. And I mean, we want those to be set both pretty low in the beginning of promote growth, but eventually, we're going to have to start being profitable. And it's up to the community to decide when that is. So that's like, an important thing to, to look at. Alrighty, What else we got? I think that was all the ones. Oh, yeah, I see on from Taylor. Honesty is great with majority but when it comes to money, competition, or even instead of tours, then desperation and greed can over take some, we factually live in a dishonest world. So should we be building from a security POV with slower pace or scope with risk? What would be the impact if just one person with 51 of 100 Threshold recoverable or wiped out? This has been done before in other decentralized networks, so anything different here? So if if one person was able to control like 51% of the stake, if that’s what you're asking, then then it's cooked. Basically, if one person is both dishonest and has that much of the network share, then then then they would be able to like modify their clients if they had the technical know how, and would be able to take the funds that takes an egregious amount of money, like a ridiculous amount of T tokens. And the upside is that those T tokens are owned by like us, like not just the community but by like people with, like, locked up in contracts with like in staking contracts that actually can't be touched because of like signed, signed disclosures when we joined, like Keeping and NuCypher and all those things, contractual obligations. So I don't think that a 51 is. interruption

Beau Shinkle 1:10:33

So yeah. So I think that the 51 is currently not possible in terms of what would happen if like, you had a big, dishonest majority. I remember doing some math for a community member a little while ago, about like, what are the chances that a, like the biggest three players, if they were dishonest, could have a 51%? And so I think that together, the biggest three players make up around 30% of the network. And so the question is, is like, what's the probability that someone who owns 30% of the network is able to get randomly chosen to have 51% of the seats? And the answer is that it's like, somewhere on the order of one times 10 to the negative 21st power, like it's like, not going to happen. If that helps with your fears. It could be the case that those parties own more than the numbers we were able to figure out because they split their funds, but hopefully not. What else? Check in calls chat? Oh, I see. Do we currently have a mechanism for doing that analysis? Sufficient buffer, even if the largest nodes drop out? Are you talking about in terms of like, what happens if, like, like, what should we set the heartbeat to? And, like, in terms of governance to that, a given knowledge of whoever owns the most stake, who can properly set the heartbeat? I don't know that. That we currently have any way to answer that like concretely. But we should definitely. That's definitely a good tool to build like to have at least like some spreadsheeting done on that. It's a good idea John. Agoristen asks, even if most people are honest, what if some rich group conspires given the cost of buying T and gain majority stake weight is less than tBTC amount secured? Does that become an attack vector? So I think that like because of how much T is both locked up, and also owned by the sort of like, doxxed, and like company people involved, it would be not feasible to get a majority share, but you could get enough to to DaaS wallets, which is a problem. So you're able to get enough to cause like heartbeat problems or to cause like a lot of disruption. So, rather than having attacks where you're able to steal the underlying funds, you're able to do these sorts of economic attacks, where like, someone goes to try to redeem their tBTC into Bitcoin. And then these people with like large amounts of stake, say, like, we're not going to sign and thus, like because this wallet was already at risk, you're not going to have enough signers like unless you pay me a hostage fee or something. That's something I've thought about. But yeah, so that's like, that is a vector. It would still take like, it would take so much. What would it cost to buy enough T to own 51% of what is staked and bonded to tBTC split across multiple anonymous nodes versus the value of the Bitcoin, the network might eventually control what would stop somebody from obtaining and maintaining 51% of the nodes and waiting until the Bitcoin in the wallets that they control grows meaningfully enough above their cost basis. So this is always fluctuating with market dynamics. If like, if you think about that, how the system works, if there's tons of Bitcoin flowing through it, then that means that we're like, we're paying people a whole lot of T, right? Because we're taking Bitcoin fees, and then using those fees to buy T tokens on the open market, which is creating upwards price pressure on T, and then using that T to pay operators. And so people want to be operators, they're buying more T in order to get the minimum and stake. So the price of T is going up. And then so like buying enough of that T, to become 51% is becoming like outrageously expensive. And so I think like that helps offset it. Eventually, like, say they do this, and they're able to steal a lot of that Bitcoin. And so like so for example, like, say the, they're able to get onto a wallet, or multiple wallets, where there's like $100 million dollars, worth of Bitcoin. And they are there are 100 of those, or they are 51 of those, those operator seats. So 100 million split 100 ways would be like, a million each. And so they would be getting like, you know, they're $100 million. And then they've put down, god this is hard to do in my head. But yeah, so like, the you know, the higher a wallet gets, the more incentive you have to to be dishonest. And so like when we start getting higher and higher amounts of, of tBTC coming into these wallets, like we want to start offsetting that, with like with raising the Threshold, like instead of having 51 of 100, we might be wanting to look at like for instance like, like 70 out of 90 or like 70 out of 100 signers or whatever. In order to to make it harder and harder to be a controlling dishonest majority. So that is what I was talking about with like maintaining. Hopefully that helps there. Yeah, the the honesty stuff is tough. For sure. All right, we have, I’m like at 5% battery, I probably have time for a couple more questions.

Will 1:18:41