1 00:00:00,280 --> 00:00:04,240 Bitcoin, such a viable asset, such a strong security source, 2 00:00:04,400 --> 00:00:07,800 is totally isolated from the proof of state world, which is 3 00:00:07,960 --> 00:00:10,800 exploding. Is there a way to combine the 4 00:00:10,800 --> 00:00:14,400 two together so that the whole crypto system can benefit as a 5 00:00:14,400 --> 00:00:16,480 whole? And that's where the idea of 6 00:00:16,480 --> 00:00:20,280 Babylon comes from, which is to share Bitcoin security with 7 00:00:20,280 --> 00:00:23,520 proof of state networks. And we came up this concept of 8 00:00:23,560 --> 00:00:26,320 Bitcoin sticking. Although Bitcoin does not 9 00:00:26,320 --> 00:00:31,160 support smart contract like Ethereum does, there are still a 10 00:00:31,160 --> 00:00:34,880 lot of smart things you can do around it to make things work 11 00:00:35,120 --> 00:00:38,600 without a software. Oh, but the bridge over 12 00:00:38,600 --> 00:00:40,360 liquidity is the key to the story. 13 00:00:40,800 --> 00:00:43,520 Welcome to Epicenter, the show which talks about technologies, 14 00:00:43,520 --> 00:00:46,960 projects and people driving decentralization and the global 15 00:00:46,960 --> 00:00:49,720 boxing revolution. So my name is Brian Crane and 16 00:00:49,720 --> 00:00:53,640 I'm here with Sebastian Couture course Epicenter and we're here 17 00:00:53,640 --> 00:00:59,080 today with David say, who's a professor at Sanford and he's 18 00:00:59,080 --> 00:01:05,040 also the founder of Babylon. Babylon is, you know, very 19 00:01:05,040 --> 00:01:09,640 interesting project that's using Bitcoin security and Bitcoin 20 00:01:09,640 --> 00:01:13,280 staking to basically secure additional networks and 21 00:01:13,280 --> 00:01:14,760 services. And that's gotten a lot of 22 00:01:14,760 --> 00:01:17,560 fraction over the last year. So really excited to have that 23 00:01:17,560 --> 00:01:20,880 David on today. And just before we get in with 24 00:01:20,880 --> 00:01:23,000 David, a few words from our sponsors. 25 00:01:24,480 --> 00:01:27,600 If you're looking to stake your crypto with confidence, look no 26 00:01:27,600 --> 00:01:31,480 further than Chorus One. More than 150,000 delegators, 27 00:01:31,480 --> 00:01:34,600 including institutions like Bit Gold, Pantera Capital and Ledger 28 00:01:34,600 --> 00:01:36,120 Trust. Chorus One with the assets. 29 00:01:36,520 --> 00:01:38,880 They support over 50 block chains and are leaders in 30 00:01:38,880 --> 00:01:42,080 governance on networks like Cosmos, ensuring your stake is 31 00:01:42,080 --> 00:01:45,320 responsibly managed. Thanks to the advanced MEB 32 00:01:45,320 --> 00:01:47,880 research, you can also enjoy the highest staking rewards. 33 00:01:48,320 --> 00:01:51,360 You can stake directly from your preferred wallet, set up a white 34 00:01:51,360 --> 00:01:55,160 label note, restake your assets on Eigenia or Symbiotic, or use 35 00:01:55,160 --> 00:01:57,400 the SDK for multi chain staking in your app. 36 00:01:57,920 --> 00:02:01,040 Learn more at Chorus .1 and start staking today. 37 00:02:02,720 --> 00:02:05,920 This episode is proudly brought to you by Gnosis, a collective 38 00:02:05,920 --> 00:02:08,400 dedicated to advancing a decentralized future. 39 00:02:08,919 --> 00:02:13,120 Gnosis leads innovation with Circles, Gnosis Pay and Metri 40 00:02:13,200 --> 00:02:15,400 reshaping open banking and money. 41 00:02:15,720 --> 00:02:18,800 With Hashi and Gnosis VPN, they're building a more 42 00:02:18,800 --> 00:02:21,320 resilient, privacy focused Internet. 43 00:02:21,760 --> 00:02:25,160 If you're looking for an L1 to launch your project, Gnosis 44 00:02:25,160 --> 00:02:27,800 Chain offers the same development environment as 45 00:02:27,800 --> 00:02:30,320 Ethereum with lower transaction fees. 46 00:02:30,640 --> 00:02:34,640 It's supported by over 200,000 ballot errors, making Gnosis 47 00:02:34,640 --> 00:02:37,560 Chain a reliable and credibly neutral foundation for your 48 00:02:37,560 --> 00:02:40,840 applications. Gnosis Dow drives Gnosis 49 00:02:40,840 --> 00:02:43,240 governance, where every voice matters. 50 00:02:43,600 --> 00:02:46,880 Join the Gnosis community in the Gnosis Dow forum today. 51 00:02:47,560 --> 00:02:51,520 Deploy on the EVM compatible Gnosis Chain or secure the 52 00:02:51,520 --> 00:02:55,880 network with just one GNO and affordable hardware. 53 00:02:56,280 --> 00:03:00,000 Start your decentralization journey today at gnosis dot IO. 54 00:03:00,520 --> 00:03:02,160 David, thanks so much for joining us today. 55 00:03:02,160 --> 00:03:05,880 It's a pleasure to have you on. Great to be here, Brian. 56 00:03:07,440 --> 00:03:12,000 The question we'd love to start this show with is just what's 57 00:03:12,000 --> 00:03:14,120 your crypto journey? How did you get it first? 58 00:03:14,160 --> 00:03:20,800 Interested in crypto? Yeah, so, so my background is a 59 00:03:20,800 --> 00:03:23,640 researcher. So in my early days of my 60 00:03:23,640 --> 00:03:28,280 career, I was doing research on wireless communication, how to 61 00:03:28,280 --> 00:03:31,160 make cell phones work. Back in the day when I started, 62 00:03:31,560 --> 00:03:34,680 only 1,000,000 people have cell phones around the world, and now 63 00:03:34,680 --> 00:03:37,320 everybody has cell phone. So there was a revolution going 64 00:03:37,320 --> 00:03:41,200 on, and my research contributed to that revolution of making 65 00:03:41,200 --> 00:03:47,160 cell phones more efficient. So now we're forward, we're at 66 00:03:47,240 --> 00:03:50,960 2018. So at that point, this mobile 67 00:03:50,960 --> 00:03:54,800 wireless revolution has already quite mature. 68 00:03:54,920 --> 00:03:58,120 And I was looking for a new research area and I came across 69 00:03:58,120 --> 00:04:01,480 Nakamoto's white paper. And that was my first exposure 70 00:04:01,480 --> 00:04:03,920 to crypto. And I read that white paper and 71 00:04:03,920 --> 00:04:08,000 I got completely blown away by the beauty and elegance and the 72 00:04:08,000 --> 00:04:11,640 power of the ideas. And I started a research group 73 00:04:11,640 --> 00:04:16,320 at Stanford devoting exclusively to research in crypto. 74 00:04:16,320 --> 00:04:19,720 And I'm the at this point, I'm still the only research group at 75 00:04:19,720 --> 00:04:22,600 Stanford exclusively focused on crypto research. 76 00:04:23,960 --> 00:04:25,560 Crypto as in blockchain research. 77 00:04:26,080 --> 00:04:27,600 Yes. Oh, that's interesting. 78 00:04:28,760 --> 00:04:31,400 Yeah, yeah, 'cause I mean, Stanford has a long history, 79 00:04:31,400 --> 00:04:34,640 right, with blockchain research. I know there's like Dan Bonet, I 80 00:04:34,640 --> 00:04:40,240 think who is early on and I mean a lot of things that came out of 81 00:04:40,240 --> 00:04:42,600 Stanford know that's kind of blockchain related. 82 00:04:42,920 --> 00:04:45,360 Yes, correct. Dan Bonet is of course one of 83 00:04:45,360 --> 00:04:46,960 the world's famous cryptographer. 84 00:04:48,080 --> 00:04:52,320 His group however, is very broad, focuses on cryptography 85 00:04:52,680 --> 00:04:55,600 and blockchain is one of his applications. 86 00:04:55,920 --> 00:04:59,720 I would like to distinguish in our group the focus is 87 00:04:59,720 --> 00:05:04,280 exclusively on blockchain, so all our research is driven from 88 00:05:04,280 --> 00:05:06,760 blockchain. OK. 89 00:05:07,080 --> 00:05:11,080 And then how? How did that evolve into 90 00:05:12,160 --> 00:05:15,880 Babylon? Our journey our research journey 91 00:05:15,880 --> 00:05:18,280 started with Bitcoin, right? Nakamoto's white paper. 92 00:05:20,160 --> 00:05:22,720 However, what happened in the past few years is that the 93 00:05:22,720 --> 00:05:27,880 research and the development has entirely shifted the energy into 94 00:05:28,120 --> 00:05:33,000 proof of stick networks, which kind of left Bitcoin in the dust 95 00:05:33,200 --> 00:05:35,200 in terms of technology development. 96 00:05:36,240 --> 00:05:40,240 However, Bitcoin remains a very valuable asset at this to this 97 00:05:40,240 --> 00:05:43,640 day is 50% of the crypto market, more than 50% of the crypto 98 00:05:43,640 --> 00:05:46,360 market. And it's security is 99 00:05:46,360 --> 00:05:48,840 unparalleled compared to any other block chains. 100 00:05:50,000 --> 00:05:56,080 And so the idea we had at some point was, hey, Bitcoin, such a 101 00:05:56,080 --> 00:05:59,760 viable asset, such a strong security source is totally 102 00:05:59,760 --> 00:06:03,040 isolated from the proof of stake world, which is exploding. 103 00:06:03,680 --> 00:06:06,760 Is there a way to combine the two together so that the whole 104 00:06:06,760 --> 00:06:09,120 crypto system can benefit as a whole? 105 00:06:09,480 --> 00:06:12,160 And that's where the idea of Babylon comes from, which is to 106 00:06:12,160 --> 00:06:15,840 share Bitcoin security with proof of stake networks. 107 00:06:16,360 --> 00:06:20,320 And we came up this concept of Bitcoin sticking, which is to 108 00:06:20,320 --> 00:06:26,000 convert this one point, this point, I don't know, 1.51.61.7 109 00:06:26,000 --> 00:06:30,480 trillion asset to thinkable asset. 110 00:06:30,680 --> 00:06:36,720 And that's where Babylon arise. So I was in 2017 right as COO of 111 00:06:36,840 --> 00:06:39,360 Tiananmen to the company that started the Cosmos ecosystem. 112 00:06:39,360 --> 00:06:42,040 And I remember hearing about Babylon like some years ago. 113 00:06:42,640 --> 00:06:46,960 And I think the way I remember it back then was the idea that 114 00:06:46,960 --> 00:06:49,800 you could take these proof of stake block chains and they 115 00:06:49,800 --> 00:06:56,160 could basically use Bitcoin as a sort of time stamping server or 116 00:06:56,280 --> 00:07:00,080 a time stamping place, right, where you put the sort of a hash 117 00:07:00,080 --> 00:07:04,320 of the block block in there. So then if someone joins new 118 00:07:04,320 --> 00:07:08,480 right, some, some proof of stake networks, they could sort of go 119 00:07:08,480 --> 00:07:11,960 to the Bitcoin block chain and, and make sure that, you know, 120 00:07:11,960 --> 00:07:14,320 it's really the authoritative chain that they're talking with 121 00:07:14,960 --> 00:07:17,840 it. Was that the original idea or or 122 00:07:18,360 --> 00:07:23,600 how did this kind of evolve? Yeah, Babylon has a interesting 123 00:07:23,600 --> 00:07:26,000 story from in the point from point of view of evolution 124 00:07:26,000 --> 00:07:29,480 technology. So the North star of Babylon has 125 00:07:29,480 --> 00:07:32,640 always been sharing security from Bitcoin to approval of tech 126 00:07:32,640 --> 00:07:34,280 networks. That's always been our focus 127 00:07:34,280 --> 00:07:36,840 from day one. However, the means and the 128 00:07:36,840 --> 00:07:40,280 technology and the protocol by which it does have gone through 129 00:07:40,440 --> 00:07:43,920 an evolution. So the our original idea was 130 00:07:43,920 --> 00:07:48,760 actually an idea of Nakamoto which is called merge mining. 131 00:07:49,840 --> 00:07:52,880 So merge mining was an idea that was invented by Nakamoto in 132 00:07:52,880 --> 00:07:58,640 around 20/10/2011 time frame. The idea is that Bitcoin miners 133 00:07:58,800 --> 00:08:02,720 can simultaneously mine on another proof of war chain, and 134 00:08:02,720 --> 00:08:05,680 we were using that idea to see if we can share security proof 135 00:08:05,680 --> 00:08:09,160 of state networks. And then we turn out that we 136 00:08:09,160 --> 00:08:11,880 find out some security issues with merge mining. 137 00:08:12,040 --> 00:08:14,640 And so we moved on to this time stamping protocol. 138 00:08:14,640 --> 00:08:18,760 That was our second invention. That's what, Brian, that's what 139 00:08:18,760 --> 00:08:21,440 you talk about. Time stamping is basically 140 00:08:21,440 --> 00:08:25,600 sending a hash of the signatures of the validators of the proof 141 00:08:25,600 --> 00:08:29,800 of state networks onto Bitcoin so that you can have a time 142 00:08:29,800 --> 00:08:33,520 stamp on these blocks and it gives you Bitcoin security. 143 00:08:33,760 --> 00:08:36,520 However, time stamping has one drawback. 144 00:08:37,400 --> 00:08:40,840 And the drawback is that because Bitcoin is so slow, time 145 00:08:40,840 --> 00:08:44,520 stamping is a very slow process. So this scale security is very 146 00:08:44,520 --> 00:08:46,520 slow. And as you know, one of the 147 00:08:46,520 --> 00:08:49,800 strength of proof of stick networks is that you get very 148 00:08:49,800 --> 00:08:54,800 fast confirmation, a few seconds as opposed to Bitcoin which is 149 00:08:54,800 --> 00:08:58,240 minutes or even hours. And so time stamping doesn't 150 00:08:58,240 --> 00:09:01,800 really give us that fast confirmation strengthening of 151 00:09:02,640 --> 00:09:06,480 proof of stick security. And so our third idea was to use 152 00:09:06,480 --> 00:09:11,720 the Bitcoin, not the chain itself, but the asset to provide 153 00:09:11,720 --> 00:09:14,200 security. And that's what Bitcoin sticking 154 00:09:14,200 --> 00:09:16,160 came from. And because you're using the 155 00:09:16,160 --> 00:09:21,000 asset now, you can keep the fast confirmation of proof of state 156 00:09:21,000 --> 00:09:23,720 networks, but strengthen it by increasing the amount of 157 00:09:23,720 --> 00:09:28,480 capital, by adding the Bitcoin capital to provide a security. 158 00:09:30,080 --> 00:09:32,480 Yeah, it's, it's really impressive to see Babylon's 159 00:09:32,480 --> 00:09:35,760 evolution since those early days when you guys were working on 160 00:09:35,760 --> 00:09:37,840 time stamping. I, I did a podcast with Fisher 161 00:09:37,840 --> 00:09:41,960 at, at Cosmo versus Medellin. And you had just announced this, 162 00:09:42,960 --> 00:09:45,960 this Bitcoin time stamping mechanism that effectively as a 163 00:09:45,960 --> 00:09:49,640 product would allow the alligators on proof of stake 164 00:09:49,640 --> 00:09:53,880 networks to, to withdraw their capital faster, which was like a 165 00:09:53,880 --> 00:09:55,200 really interesting idea in itself. 166 00:09:55,200 --> 00:09:59,440 But then this proof, this, this Bitcoin staking idea emerge from 167 00:09:59,440 --> 00:10:01,520 there. I wonder, you know, coming from 168 00:10:01,880 --> 00:10:05,040 the research side of things and, and specifically, you know, as a 169 00:10:05,040 --> 00:10:09,120 product that aims to, I mean, effectively turn Bitcoin assets 170 00:10:09,120 --> 00:10:11,600 into a derivative that would then secure other networks and 171 00:10:11,600 --> 00:10:14,320 everything that that implies, you know, what was the reaction? 172 00:10:14,320 --> 00:10:17,640 What has been your interaction or your reaction with, you know, 173 00:10:17,640 --> 00:10:19,640 the the Bitcoin community, which typically is a little bit more 174 00:10:19,640 --> 00:10:23,920 conservative and you know, from from my perspective, perhaps a 175 00:10:23,920 --> 00:10:25,440 little bit more closed off to those ideas? 176 00:10:25,440 --> 00:10:28,920 And how has that conversation changed over the last two years 177 00:10:29,080 --> 00:10:33,040 as we've seen more and more Bitcoin L twos and more things 178 00:10:33,040 --> 00:10:36,880 being built on top of Bitcoin? Yeah. 179 00:10:36,880 --> 00:10:40,600 So when we started with this Bitcoin sticking idea, when we, 180 00:10:41,200 --> 00:10:47,080 it was about 2023, about summer of 2023, that's when we came up 181 00:10:47,080 --> 00:10:49,880 with the light paper for Bitcoin sticking and we start talking to 182 00:10:50,640 --> 00:10:56,120 various communities and indeed the Bitcoin oh geez, supposed to 183 00:10:56,120 --> 00:11:01,240 be quite conservative. However, I must say, overall we 184 00:11:01,240 --> 00:11:04,960 find a reception pretty good and I think we're helped by a few 185 00:11:04,960 --> 00:11:09,400 external forces. So if you remember earlier that 186 00:11:09,400 --> 00:11:13,960 year or notes started or notes started and that was sort of a 187 00:11:14,280 --> 00:11:19,400 mindset change to Bitcoiners that hey, you know what, Bitcoin 188 00:11:19,400 --> 00:11:24,960 has more use cases than just Hodo and a payment system. 189 00:11:26,280 --> 00:11:29,000 And I think that was a very important time change for us. 190 00:11:29,000 --> 00:11:32,720 And as you mentioned, at the later part of that year, Bitcoin 191 00:11:32,880 --> 00:11:38,640 L2 start emerging and so forth. And I think we kind of helped by 192 00:11:38,640 --> 00:11:42,920 that broader movement of sort of a new way of look at Bitcoin, we 193 00:11:42,920 --> 00:11:48,120 call it Bitcoin Renaissance. And I think we became sort of a 194 00:11:48,120 --> 00:11:52,680 leader of that movement because we started doing this research a 195 00:11:52,680 --> 00:11:55,320 few years back. And I think the timing was the 196 00:11:55,320 --> 00:12:01,640 helpful to us. So in this discussion right on 197 00:12:03,040 --> 00:12:10,680 Bitcoin and sort of what is enabled on the L1 and you know, 198 00:12:10,680 --> 00:12:14,840 should there be some kind of upgrades that allow more 199 00:12:14,840 --> 00:12:19,080 expressivity more, I don't know, some kind of minimal smart 200 00:12:19,080 --> 00:12:22,800 contract better bridging has been there for a long time. 201 00:12:23,520 --> 00:12:27,040 I'm curious, can you talk a little bit about, you know, the 202 00:12:27,040 --> 00:12:31,400 technical challenges because I mean Babylon, because I think so 203 00:12:31,400 --> 00:12:36,560 far still like the and not a lot of upgrades have happened in 204 00:12:36,560 --> 00:12:38,760 Bitcoin and it's still like very limited. 205 00:12:39,520 --> 00:12:44,160 So how did you guys manage to re enable that staking 206 00:12:44,160 --> 00:12:47,360 functionality in Bitcoin? Yeah. 207 00:12:47,960 --> 00:12:54,200 In fact, when we were discussing about Bitcoin staking, one of 208 00:12:54,200 --> 00:12:58,160 the early idea we had in fact was the through discussion with 209 00:12:58,160 --> 00:13:00,720 Sunny Algo while you're talking about the Cosmos ecosystem. 210 00:13:01,160 --> 00:13:05,280 So in fact, Sunny came to me and one of the you you remembered at 211 00:13:05,280 --> 00:13:09,320 the Cosmo verse in Medellin, Sunny talked about mass 212 00:13:09,320 --> 00:13:13,080 security, mass security, and that was the security between 213 00:13:13,080 --> 00:13:17,400 Cosmos blockchains and E Denver, which was in 2024. 214 00:13:17,520 --> 00:13:19,920 Very early. He came to me and said, hey, 215 00:13:20,240 --> 00:13:23,160 wouldn't it be great to do mass security with one of the 216 00:13:23,160 --> 00:13:28,120 producer security as Bitcoin? That would be great. 217 00:13:29,160 --> 00:13:32,120 And so the initial idea we were discussing with Sonia, I 218 00:13:32,120 --> 00:13:35,600 remember, still remember very, very vividly was, hey, would it 219 00:13:35,600 --> 00:13:40,080 be great if we can bridge Bitcoin to one of these Cosmos 220 00:13:40,080 --> 00:13:44,760 chains like Babylon or Osmosis and then share security through 221 00:13:44,760 --> 00:13:48,480 the mass security network? OK, So that was our sort of our 222 00:13:48,480 --> 00:13:53,600 initial thought, but then we had a problem because bridges from 223 00:13:53,600 --> 00:13:57,520 Bitcoin to any chain is well known to be very hard to build, 224 00:13:57,520 --> 00:14:00,520 to be secure. And to this day there's no 225 00:14:00,520 --> 00:14:04,400 secure Bitcoin bridge beyond just like a multi state bridge. 226 00:14:04,960 --> 00:14:09,160 And, and then we went back to history and we noticed that in 227 00:14:09,160 --> 00:14:13,840 21 five, there was an effort called drive chain, which is to 228 00:14:13,840 --> 00:14:17,240 upgrade Bitcoin to enable such a bridge to happen. 229 00:14:17,480 --> 00:14:18,960 It's called draft. You can look back. 230 00:14:19,200 --> 00:14:22,360 I think the first proposal came up around 2015 type frame. 231 00:14:22,840 --> 00:14:24,560 But then I, I, I talked to Stanley. 232 00:14:24,560 --> 00:14:26,720 I say, you know, Stanley, there's a problem here because 233 00:14:26,720 --> 00:14:32,480 today we are 2024 and this proposal was issued in 2015 is 234 00:14:32,480 --> 00:14:36,040 still not passed yet. So I don't think we should wait 235 00:14:36,040 --> 00:14:39,320 for this drive change to happen because this is 9 years down the 236 00:14:39,320 --> 00:14:40,960 road here. And who knows, we may have to 237 00:14:40,960 --> 00:14:46,240 wait nine more years. And so we start thinking so, but 238 00:14:46,320 --> 00:14:48,960 after this discussion was suddenly we, I came back to the 239 00:14:48,960 --> 00:14:53,320 team, we start discussing very actively and what we figure out 240 00:14:53,320 --> 00:14:57,440 basically to achieve Bitcoin sticking is really a way to sort 241 00:14:57,440 --> 00:15:02,560 of bypass this smart contract limitation and still enable 242 00:15:02,560 --> 00:15:04,800 Bitcoin sticking without any soft fork. 243 00:15:05,040 --> 00:15:10,760 And so sort of one of the key sort of new ideas this past year 244 00:15:10,760 --> 00:15:14,160 from a research point of view is that although Bitcoin does not 245 00:15:14,160 --> 00:15:19,000 support smart contract like Ethereum does, there are still a 246 00:15:19,000 --> 00:15:22,720 lot of smart things you can do around it to make things work 247 00:15:22,840 --> 00:15:27,960 without a soft fall. And so that has been sort of our 248 00:15:28,240 --> 00:15:34,080 sort of drive to accomplish that and for Bitcoin sticking, we 249 00:15:34,080 --> 00:15:37,800 accomplished that. And you also you may also know 250 00:15:37,800 --> 00:15:41,480 like new ideas like bit VM bridge for example, that is 251 00:15:41,480 --> 00:15:44,720 another way of sort of trying to accomplish that a different 252 00:15:44,720 --> 00:15:47,800 functionality bridging in that case without soft fork. 253 00:15:49,280 --> 00:15:55,520 How, how important is this, this opcat upgrade and maybe for 254 00:15:55,720 --> 00:15:58,800 perhaps would be helpful to provide some context here as to 255 00:15:59,280 --> 00:16:04,320 what that upgrade enables and why so many projects building on 256 00:16:04,320 --> 00:16:07,200 Bitcoin are just like waiting for that to come online. 257 00:16:09,040 --> 00:16:11,960 Oh, so opcat is actually a very powerful thing. 258 00:16:11,960 --> 00:16:14,480 Opcat is basically concatenating 2 strings together. 259 00:16:14,480 --> 00:16:16,960 Sounds like something stupid, something very basic. 260 00:16:17,080 --> 00:16:19,680 But yet Bitcoin scripting doesn't support that. 261 00:16:19,680 --> 00:16:23,360 And in fact, it was in the original version of the Bitcoin 262 00:16:23,360 --> 00:16:27,040 scripting language by Nakamoto, but it was deleted by Nakamoto 263 00:16:27,240 --> 00:16:29,720 himself. And so the effort here is to 264 00:16:29,720 --> 00:16:35,440 restore that that OP code. Now, one it, it can accomplish 265 00:16:35,440 --> 00:16:39,000 many things, but one thing it can accomplish through some 266 00:16:39,000 --> 00:16:42,600 trickery is this notion of covenants. 267 00:16:42,880 --> 00:16:47,000 This notion of covenants, that is you can write a Bitcoin 268 00:16:47,000 --> 00:16:50,720 script to define how you spend the money. 269 00:16:50,720 --> 00:16:54,560 In other words, you can't just spend the money by signing and 270 00:16:54,560 --> 00:16:57,680 then send it to anyone else. There you you can put 271 00:16:57,680 --> 00:17:03,360 restriction on where and how and how much to spend to who. 272 00:17:04,560 --> 00:17:07,119 That is not possible in the current Bitcoin scripting 273 00:17:07,119 --> 00:17:12,200 language and enabling that turns out to be rather powerful and it 274 00:17:12,200 --> 00:17:15,599 could make many things much simpler and significantly 275 00:17:15,599 --> 00:17:17,560 cheaper in terms of transaction fees. 276 00:17:17,760 --> 00:17:21,119 In other words, when instead of writing a lot of code and having 277 00:17:21,119 --> 00:17:25,359 to allot a huge script, you can get by with a much more compact 278 00:17:25,359 --> 00:17:29,960 script, and that's what opcat enables. 279 00:17:30,920 --> 00:17:33,120 Does it also enable multiplication? 280 00:17:33,120 --> 00:17:37,480 Is is is it useful in the ability to do proofs on chain as 281 00:17:37,480 --> 00:17:40,480 well? Yes. 282 00:17:40,480 --> 00:17:46,120 So there's a lot of effort by Stocknet and a few and a few 283 00:17:46,120 --> 00:17:55,080 teams to do so-called a ZK proof verification on chain using 284 00:17:55,080 --> 00:17:58,960 OPCAT. And I'm not an expert in that 285 00:17:58,960 --> 00:18:01,440 area and my research does not cover that problem. 286 00:18:01,600 --> 00:18:05,560 But I do believe it does help with some field multiplication. 287 00:18:06,120 --> 00:18:10,000 I think the stock, the virtual stock is called Circle, circle 288 00:18:10,000 --> 00:18:14,200 stock and that enables some multiplication, but I'm not an 289 00:18:14,200 --> 00:18:16,040 expert in that area. So yeah. 290 00:18:16,520 --> 00:18:19,440 OK, got it. I mean, are you, are you aware 291 00:18:19,440 --> 00:18:24,160 of any of the current attacks and and presumably like the ZK 292 00:18:24,160 --> 00:18:27,520 proof that was done on chain by the Bitcoin OS team and some of 293 00:18:27,520 --> 00:18:31,320 the work being done over by by the Bitlare team to do a proof 294 00:18:31,320 --> 00:18:35,840 on chain? So to be clear, to be clear that 295 00:18:35,840 --> 00:18:38,600 these efforts are not doing proof on chain. 296 00:18:39,520 --> 00:18:41,680 The proof is generated off chain. 297 00:18:42,760 --> 00:18:46,760 And so the challenge here is to verify whether the proof is a 298 00:18:46,760 --> 00:18:50,600 correct proof on chain so that you can tell Bitcoin to spend 299 00:18:50,600 --> 00:18:53,240 the money in the appropriate to the appropriate person. 300 00:18:53,440 --> 00:18:55,000 Yeah, my statement was was inaccurate, right? 301 00:18:55,320 --> 00:18:56,640 You want to verify the proof on chain. 302 00:18:57,200 --> 00:19:00,360 Yeah, because proof generation is typically a very expensive 303 00:19:00,360 --> 00:19:02,360 process, and so there's no way you can do that or check. 304 00:19:02,600 --> 00:19:06,920 But the verification typically is much cheaper than proof 305 00:19:06,920 --> 00:19:09,760 verification. But for Bitcoin, even that proof 306 00:19:09,760 --> 00:19:13,680 verification is very tricky to do because of the primitiveness 307 00:19:13,840 --> 00:19:15,120 of the Bitcoin scripting language. 308 00:19:15,120 --> 00:19:17,360 And so all these efforts are trying to do that. 309 00:19:17,560 --> 00:19:22,240 So, so here there are two efforts, two types of two 310 00:19:22,240 --> 00:19:24,040 approaches to solve this problem. 311 00:19:24,520 --> 00:19:27,400 And one is, as you mentioned using. 312 00:19:27,480 --> 00:19:31,560 Assuming OP can't is passed, then you can implement more 313 00:19:31,560 --> 00:19:35,280 efficient, say multiplication that you mentioned. 314 00:19:35,360 --> 00:19:40,000 OK, so that's one effort, but that effort has a problem 315 00:19:40,000 --> 00:19:45,520 because it assumes OP can't. And I don't think we're close to 316 00:19:45,600 --> 00:19:47,400 seeing OPI cat pass at this moment. 317 00:19:47,960 --> 00:19:55,160 And so the other effort is not assuming OP cat, but using an 318 00:19:55,160 --> 00:19:58,080 approach called optimistic verification. 319 00:19:58,760 --> 00:20:00,800 Optimistic verification which means what? 320 00:20:01,640 --> 00:20:05,880 Which means that in optimistic case you don't verify anything, 321 00:20:05,880 --> 00:20:10,920 you just assume that the bridge operator is correct in the 322 00:20:10,920 --> 00:20:16,440 assertion, but only when you are challenged by an external 323 00:20:16,440 --> 00:20:19,600 challenger, then you do the verification. 324 00:20:20,200 --> 00:20:24,720 And that verification you can do cheaper because the challenger 325 00:20:24,720 --> 00:20:28,400 can pinpoint a specific part of the computation or the 326 00:20:28,400 --> 00:20:31,320 verification is like, hey, you know what, I think this part 327 00:20:31,320 --> 00:20:34,400 you've cheated. Please show me the correct your 328 00:20:34,400 --> 00:20:38,560 verification of this part and I can convince Bitcoin that you're 329 00:20:38,560 --> 00:20:41,800 actually wrong. And so, and this is a bit like 330 00:20:41,800 --> 00:20:46,240 the Abatron type ideas. And I think that approach is in 331 00:20:46,240 --> 00:20:48,840 some sense more practical because it doesn't assume, oh, 332 00:20:48,880 --> 00:20:53,320 we can and I'm I myself is doing research in that direction. 333 00:20:55,600 --> 00:21:00,440 So can you talk a little bit about how the Bitcoin staking 334 00:21:00,440 --> 00:21:03,120 works like right now? So if somebody says, hey, I have 335 00:21:03,120 --> 00:21:08,520 some Bitcoin and I want to, you know, basically deposit this in 336 00:21:08,520 --> 00:21:14,800 Babylon and stake the Bitcoin, what actually happens on 337 00:21:14,800 --> 00:21:16,440 technically on the Bitcoin chain? 338 00:21:18,040 --> 00:21:19,600 Yeah. So very importantly, Bitcoin 339 00:21:19,600 --> 00:21:23,920 sticking is a completely native Bitcoin use case. 340 00:21:23,920 --> 00:21:27,000 So it's direct interaction with the Bitcoin chain. 341 00:21:27,320 --> 00:21:31,560 So what happens here is that if you have one Bitcoin, your one 342 00:21:31,560 --> 00:21:33,800 Bitcoin is held in a so-called UTXO. 343 00:21:33,880 --> 00:21:39,760 UTXO, OK, so now you create another UTXO yourself and you 344 00:21:39,760 --> 00:21:43,000 send that Bitcoin to that UTXO still under your own custodian 345 00:21:43,560 --> 00:21:47,560 now, but that utexo has a few special spending conditions. 346 00:21:47,560 --> 00:21:52,560 Spending conditions. The what for one is that is a 347 00:21:52,560 --> 00:21:56,960 time lock, is a time lock that locks your Bitcoin and you 348 00:21:56,960 --> 00:22:00,800 cannot withdraw it until a certain time or until you send 349 00:22:00,800 --> 00:22:03,640 another request, which is like in the Cosmos chains, an 350 00:22:03,640 --> 00:22:06,320 unbounding request. So there's a time lock 351 00:22:06,320 --> 00:22:11,360 mechanism. 2 is that there is a slashing mechanism and that's 352 00:22:11,360 --> 00:22:15,480 this is the crucial part of how this Bitcoin can provide 353 00:22:15,480 --> 00:22:22,880 security to a say Cosmos chain or a roll up is that this 354 00:22:23,000 --> 00:22:29,000 slashing condition is activated with associate with a what we 355 00:22:29,000 --> 00:22:32,320 call finale provider or in more standard proof of stick 356 00:22:32,320 --> 00:22:35,880 language, a validator. This valid is in charge of 357 00:22:35,880 --> 00:22:41,560 securing a proof of state chain or blow up and the contract here 358 00:22:41,560 --> 00:22:45,880 is that as low as this value is honest, this slashing condition 359 00:22:46,160 --> 00:22:49,440 is never activated. Never activated. 360 00:22:49,600 --> 00:22:52,960 However, if it does something bad, then this slashing 361 00:22:52,960 --> 00:22:58,160 condition can be activated and your fraction of your one 362 00:22:58,160 --> 00:23:01,840 Bitcoin can be spent through the slashing and sent to a burn 363 00:23:01,840 --> 00:23:05,120 address. So this is roughly how it works. 364 00:23:06,080 --> 00:23:09,960 So you as a sticker has to pick one particular phonetic provider 365 00:23:09,960 --> 00:23:13,000 that you stick to, and it could be yourself. 366 00:23:14,640 --> 00:23:21,640 Can you tell us a little bit about, so now someone is staking 367 00:23:21,640 --> 00:23:26,240 the Bitcoin and then we have these Bitcoin secured networks, 368 00:23:26,240 --> 00:23:28,440 right? So these are some networks that 369 00:23:28,440 --> 00:23:30,640 now are relying on this Bitcoin security. 370 00:23:30,640 --> 00:23:33,040 How do the Bitcoin secured networks work? 371 00:23:34,840 --> 00:23:39,040 So just to clarify, we are right now in phase one of our main net 372 00:23:39,040 --> 00:23:44,280 launch, OK, the Babylon protocol is launched in Phase 1. 373 00:23:44,280 --> 00:23:50,360 So in phase one only staking only locking of the stick occurs 374 00:23:50,880 --> 00:23:54,440 and there are no Bitcoin secure network yet. 375 00:23:55,000 --> 00:23:59,040 Oh, in phase two and three, we'll launch a more we'll launch 376 00:24:00,680 --> 00:24:07,040 Bitcoin secure networks now. So so example of such networks 377 00:24:07,040 --> 00:24:12,600 could be, I don't know, osmosis or roll up like this this this 378 00:24:12,600 --> 00:24:14,400 world called corn that we work with. 379 00:24:14,960 --> 00:24:21,000 So how does it work? OK, so there will be daily right 380 00:24:21,000 --> 00:24:26,840 now on our network, there are 200 around 200 finale providers. 381 00:24:26,920 --> 00:24:32,080 OK. So Figment and P2P etcetera or 382 00:24:32,080 --> 00:24:34,800 Cosmo station etcetera, these are finale providers. 383 00:24:35,760 --> 00:24:40,320 And now when these BSNS, Bitcoin secure networks are launched, 384 00:24:40,680 --> 00:24:45,040 some of these finale provider will choose to secure these 385 00:24:45,040 --> 00:24:49,040 networks, OK. And to secure these networks, 386 00:24:49,040 --> 00:24:52,200 they will sign some special signatures to certify these 387 00:24:52,200 --> 00:24:58,000 blocks as Bitcoin secure. And their job is to make sure 388 00:24:58,400 --> 00:25:03,920 they sign only one block at every height to make sure that 389 00:25:04,040 --> 00:25:05,920 you have a linear blockchain going. 390 00:25:07,760 --> 00:25:13,160 And so their slashing capability is to make sure that they do 391 00:25:13,160 --> 00:25:15,760 that. In other words, they cannot 392 00:25:15,760 --> 00:25:19,400 double sign two blocks to try to fork the chain. 393 00:25:20,240 --> 00:25:22,560 And this is where the security comes from. 394 00:25:22,920 --> 00:25:28,840 So in so when a client in one of these networks sees many these 395 00:25:28,840 --> 00:25:32,000 finale providers signature, then they know, wow, this block is 396 00:25:32,000 --> 00:25:35,480 really super secure and I can trust this block and I can trust 397 00:25:35,480 --> 00:25:36,920 the transactions in these blocks. 398 00:25:39,160 --> 00:25:42,600 And then let's say if we take the Osmosis example, I mean 399 00:25:42,600 --> 00:25:47,800 Osmosis has its own staking token, OSMO and it has, you 400 00:25:47,800 --> 00:25:50,880 know, a significant number of validators already. 401 00:25:51,760 --> 00:25:58,440 If that now becomes Bitcoin secure network, then like how 402 00:25:58,440 --> 00:26:03,040 does that interact with the existing security system that 403 00:26:03,120 --> 00:26:05,280 that's already there? Yeah. 404 00:26:05,480 --> 00:26:07,520 So that's a very good question. That's right. 405 00:26:07,520 --> 00:26:10,080 Osmosis already evaluated signing the blocks. 406 00:26:10,240 --> 00:26:14,240 So why do we need these Bitcoin secured signatures? 407 00:26:14,480 --> 00:26:20,040 Well, so you can think of a good analogy, AUS analogy would be 408 00:26:20,040 --> 00:26:26,320 like a House and a Senate. OK, so legislation avoided by 409 00:26:26,320 --> 00:26:28,800 both the House and the Senate. Very American, sorry, very 410 00:26:28,800 --> 00:26:30,680 American example, but I do live in the US. 411 00:26:31,080 --> 00:26:35,240 So so the same similar system would be happening in the 412 00:26:35,240 --> 00:26:38,320 osmosis case. So the osmosis validators would 413 00:26:38,320 --> 00:26:40,240 sign on the block as the first committee. 414 00:26:41,520 --> 00:26:44,480 And then on top of that, there's another committee, which are 415 00:26:44,480 --> 00:26:48,840 these Bitcoin secure signatures because the finale provided 416 00:26:48,840 --> 00:26:51,560 signatures that signs a gain on top of this block. 417 00:26:52,280 --> 00:27:00,040 So a client we'll check both the Osmosis interest and the finale 418 00:27:00,040 --> 00:27:03,440 provider signatures and see that, OK, both committee have 419 00:27:03,440 --> 00:27:06,920 signed. And so this block is now getting 420 00:27:07,120 --> 00:27:08,960 you can think of additional security. 421 00:27:08,960 --> 00:27:14,280 So think about it, I don't know Osmosis security could be say 422 00:27:14,280 --> 00:27:19,200 300 million worth of osmosis, I don't know what exact number 423 00:27:19,360 --> 00:27:24,480 today, but example 300 million. On top of that you have another, 424 00:27:24,480 --> 00:27:27,720 I don't know, 1 billion of Bitcoin stake security. 425 00:27:28,040 --> 00:27:32,040 Well then you have a total of 1.3 billion worth of security on 426 00:27:32,040 --> 00:27:35,120 top of osmosis. Much stronger level of security 427 00:27:35,280 --> 00:27:37,720 than just the Osmosis stake by itself. 428 00:27:39,680 --> 00:27:42,720 What what's the utility? I mean like you know, for, for 429 00:27:42,720 --> 00:27:47,080 chains with like arguably good security like Osmosis or the 430 00:27:47,080 --> 00:27:50,080 Cosmos Hub that are secured by like large amounts of stake, 431 00:27:50,600 --> 00:27:53,520 what's the tangible benefit for users to have that additional 432 00:27:53,520 --> 00:27:57,800 layer of security, you know, purely on the security side, I, 433 00:27:57,880 --> 00:27:59,920 you know, I understand that there is like implications here 434 00:28:00,080 --> 00:28:02,880 in terms of having the ability to bridge over liquidity 435 00:28:02,880 --> 00:28:05,040 etcetera. How does that play out? 436 00:28:06,600 --> 00:28:09,040 Oh, but the bridge over liquidity is the key to the 437 00:28:09,040 --> 00:28:13,600 story. So, first of all, the security 438 00:28:13,600 --> 00:28:16,800 should be proportional to the amount of liquidity that you 439 00:28:16,800 --> 00:28:20,680 maintain on the chain, right. So you want to have a lot of 440 00:28:20,680 --> 00:28:23,880 liquidity, a lot of asset on the chain, then you should have 441 00:28:23,880 --> 00:28:27,320 corresponding amount of security to protect that asset. 442 00:28:28,680 --> 00:28:32,440 So therefore the value of for osmosis of increasing the 443 00:28:32,440 --> 00:28:38,320 security is precisely to absorb or to attract more liquidity, to 444 00:28:38,320 --> 00:28:40,640 attract more liquidity into the tax etcetera. 445 00:28:41,400 --> 00:28:45,040 Now actually there's a very tangible way. 446 00:28:45,040 --> 00:28:46,400 So this sounds like very abstract, right? 447 00:28:46,400 --> 00:28:48,520 So how do you get more? You get the fact that you have 448 00:28:48,520 --> 00:28:51,160 more security doesn't mean you have more liquidity is a 449 00:28:51,160 --> 00:28:55,160 necessary, but not sufficient. However, in the case of Bitcoin 450 00:28:55,160 --> 00:28:58,480 sticking, there's actually a very tangible way of these 451 00:28:58,480 --> 00:29:03,680 chains getting liquidity. And that liquidity is precisely 452 00:29:03,680 --> 00:29:07,520 because of a very recent development, which is all these 453 00:29:07,640 --> 00:29:11,200 liquid sticking tokens on top of Babila. 454 00:29:11,960 --> 00:29:14,480 So Babylon provides the sticking layer. 455 00:29:14,840 --> 00:29:18,520 But what happened in the past six months is that several 456 00:29:18,920 --> 00:29:23,280 rather prominent projects have built liquid sticking protocol. 457 00:29:23,480 --> 00:29:26,080 That is they stick on Babylon, but at the same time they mint 458 00:29:26,080 --> 00:29:29,120 an asset. So now that mint asset could 459 00:29:29,120 --> 00:29:34,160 appear on the Osmosis chain. So now Osmosis is getting both 460 00:29:34,160 --> 00:29:40,640 security from Bitcoin sticking and also liquidity from the LST 461 00:29:41,360 --> 00:29:44,120 and now you get both liquidity and security and now they 462 00:29:44,120 --> 00:29:47,280 proportion to each other and that would increase the economic 463 00:29:47,280 --> 00:29:52,840 activity of osmosis. Yeah, I, I agree. 464 00:29:52,840 --> 00:29:56,360 I think that's really where you have a very big unlock, right? 465 00:29:56,360 --> 00:29:59,560 Because I think if you can tell a chain like osmosis, look, 466 00:29:59,560 --> 00:30:02,960 you're going to get additional Bitcoin security, but also 467 00:30:02,960 --> 00:30:05,760 Bitcoin liquidity, right? And now, you know, in addition 468 00:30:05,760 --> 00:30:09,120 to whatever a billion dollars worth of Bitcoin security, you 469 00:30:09,120 --> 00:30:14,280 get like as maybe a few 100 million or something in, you 470 00:30:14,280 --> 00:30:17,360 know, Bitcoin liquidity and you can have like really liquid 471 00:30:17,880 --> 00:30:20,520 Bitcoin markets on there. I think that's where it starts 472 00:30:20,520 --> 00:30:25,520 to become like really attractive is, is this the case then? 473 00:30:25,800 --> 00:30:31,720 Because the security can be used on on different chains at the 474 00:30:31,720 --> 00:30:35,600 same time, right? But the liquidity that can only 475 00:30:35,600 --> 00:30:38,360 go to one place, is that right or? 476 00:30:39,680 --> 00:30:42,680 Correct. Liquidity can only go to one 477 00:30:42,680 --> 00:30:47,200 place. Security can be shared and 478 00:30:47,200 --> 00:30:51,120 that's really up to the users. So the user takes the one 479 00:30:51,120 --> 00:30:52,880 Bitcoin, right. In the example, Brian that you 480 00:30:52,880 --> 00:30:57,360 had one Bitcoin, the user can say OK, I want this one Bitcoin 481 00:30:57,360 --> 00:31:02,680 to only secure osmosis or it can take this one Bitcoin and do 482 00:31:02,680 --> 00:31:07,160 what we call multi sticking or restaking, which is to stick 483 00:31:07,160 --> 00:31:10,080 multiple chains. That's an option entirely from 484 00:31:10,080 --> 00:31:14,520 the stakers perfect perspective. The liquidity is directed to one 485 00:31:14,520 --> 00:31:18,240 particular chain, correct? So when the user says hey I want 486 00:31:18,240 --> 00:31:23,920 to secure multiple chains and and basically restake the 487 00:31:24,000 --> 00:31:30,480 Bitcoin or or stake or multi stake the Bitcoin, then would 488 00:31:30,480 --> 00:31:37,280 this also involve some changes on the Bitcoin side like some 489 00:31:37,280 --> 00:31:43,080 additional transactions or if that happens purely through the 490 00:31:43,120 --> 00:31:48,280 activity of the finality provider that the user states 491 00:31:48,280 --> 00:31:53,040 the Bitcoin with? Everything should, everything 492 00:31:53,400 --> 00:31:58,000 should be reflected on the Bitcoin chain, right? 493 00:31:58,000 --> 00:32:02,720 Because the Bitcoin chain is the final aperture of what happens 494 00:32:02,720 --> 00:32:05,080 to the stick because the stick always sits on the Bitcoin 495 00:32:05,080 --> 00:32:09,240 chain. Now if you remember, I said that 496 00:32:09,400 --> 00:32:14,840 the sticking has a thing called spending condition for slashing. 497 00:32:15,560 --> 00:32:18,360 OK. So if you have, if you decide to 498 00:32:18,360 --> 00:32:21,560 stick only on Osmosis, then you would only have one slashing 499 00:32:21,560 --> 00:32:25,880 condition associated with the finale provider on Osmosis. 500 00:32:27,000 --> 00:32:30,080 But if you decide to stick on two chains, Osmosis and I don't 501 00:32:30,080 --> 00:32:36,560 know Cosmos Hub, then you will have two slashing conditions, 1 502 00:32:36,560 --> 00:32:39,360 associate with a Fernando provider on Osmosis and one 503 00:32:39,360 --> 00:32:42,800 associate with a Fernando provider on Cosmos Hub. 504 00:32:43,640 --> 00:32:48,240 So that's how it's reflected on Bitcoin through having more 505 00:32:48,320 --> 00:32:53,080 slashing conditions. And in the scenario of a 506 00:32:53,080 --> 00:32:58,480 slashing actually happening, is the Bitcoin basically? 507 00:32:58,480 --> 00:33:02,440 Burnt, yes. Not the entire Bitcoin, but a 508 00:33:02,440 --> 00:33:06,640 fraction of the Bitcoin. This is this is where I'm I'm 509 00:33:06,640 --> 00:33:10,080 not clear. Maybe you can elaborate here. 510 00:33:10,320 --> 00:33:16,160 So as a as a staker, So if I'm holding Bitcoin and I want to 511 00:33:16,160 --> 00:33:19,360 stake my Bitcoin with Babylon the Bitcoin, you you said 512 00:33:19,360 --> 00:33:22,120 earlier that there's no requirement to send that Bitcoin 513 00:33:22,120 --> 00:33:26,080 to a third party address. So because it's it's self 514 00:33:26,080 --> 00:33:29,520 custodial, how would those slashing conditions be applied 515 00:33:29,520 --> 00:33:33,920 then? It's self custodial, but the 516 00:33:33,920 --> 00:33:39,040 slashing condition is associated with the finale provider that 517 00:33:39,040 --> 00:33:44,520 you chose. OK, so maybe think of a typical 518 00:33:44,520 --> 00:33:47,840 example. In Cosmos Chain, there's a 519 00:33:47,840 --> 00:33:52,400 notion called delegation, right? You delegate your stick to a 520 00:33:52,400 --> 00:33:56,800 particular validator like you know, Cosmo station. 521 00:33:58,040 --> 00:34:02,040 So in some sense the staker is trusting Cosmo station to do the 522 00:34:02,040 --> 00:34:05,600 right thing. It would not double spend and 523 00:34:05,600 --> 00:34:08,679 get the stickers Bitcoin or not Bitcoin in that case, that may 524 00:34:08,679 --> 00:34:13,320 be Osmo staked a slash. So the same delegation is 525 00:34:13,320 --> 00:34:16,560 happening here in our design for Bitcoin sticking as well. 526 00:34:17,239 --> 00:34:20,400 And of course, you can always run your own phonetic provider 527 00:34:20,400 --> 00:34:23,280 if you don't trust anyone else to do the right job. 528 00:34:23,639 --> 00:34:26,719 And indeed, there are stickers that are running their own 529 00:34:26,719 --> 00:34:29,639 phonetic provider right now because they have so much stake. 530 00:34:30,000 --> 00:34:31,560 They don't want anyone and trust anyone else. 531 00:34:31,560 --> 00:34:34,480 They run for their provider. Right. 532 00:34:34,480 --> 00:34:37,679 OK, so basically what you're saying is that the staking 533 00:34:37,679 --> 00:34:42,480 rewards are off for slashing but not the original like collateral 534 00:34:42,480 --> 00:34:47,199 or like delegated tokens? No, no, no, no, no, no, that's 535 00:34:47,199 --> 00:34:48,080 not true. That's not true. 536 00:34:48,239 --> 00:34:53,560 So, OK, let me let me let me make sure the contract, OK, the 537 00:34:53,560 --> 00:35:00,480 sticking contract is that your stick is safe except only the 538 00:35:00,480 --> 00:35:01,760 condition. Excellent. 539 00:35:01,760 --> 00:35:07,400 In the condition that the finale providing you delegate to double 540 00:35:07,400 --> 00:35:09,320 sides. OK. 541 00:35:09,320 --> 00:35:13,200 That's the contract. You have a double size, you will 542 00:35:13,200 --> 00:35:17,440 lose a fraction of just stick and that fraction is a parameter 543 00:35:17,600 --> 00:35:21,800 also part of the contract. So that's the promise, that's 544 00:35:21,800 --> 00:35:24,320 the collateralization of your capital. 545 00:35:26,040 --> 00:35:29,440 So let's talk a little bit about the Babylon chain, right? 546 00:35:29,440 --> 00:35:36,760 Because Babylon also is launching a Cosmos chain, the 547 00:35:36,760 --> 00:35:41,760 Babylon chain, which is going to have its own staking token. 548 00:35:42,080 --> 00:35:45,360 What's the relationship between your the Bitcoin staking and the 549 00:35:45,360 --> 00:35:48,640 Babylon chain and then these Bitcoin secured networks? 550 00:35:49,920 --> 00:35:55,480 OK. So yeah, so the Babylon Chain is 551 00:35:55,480 --> 00:35:59,160 playing a multiple roles here. So first of all, Babylon Chain 552 00:35:59,160 --> 00:36:01,480 will be the first Bitcoin secure network. 553 00:36:01,960 --> 00:36:06,760 It's like our dog food Bitcoin secure network that we build 554 00:36:06,760 --> 00:36:09,520 ourselves. So that would be launched in 555 00:36:09,520 --> 00:36:12,960 phase two of the project. After phase one, the current 556 00:36:12,960 --> 00:36:16,440 Phase 1 is finished. So that's the one number one 557 00:36:16,440 --> 00:36:19,640 row. Now the second row is when all 558 00:36:19,640 --> 00:36:23,320 the BSNS come online, which is our phase 3. 559 00:36:24,360 --> 00:36:30,000 Then the Bitcoin secure, then the Babylon chain will act as a 560 00:36:30,000 --> 00:36:36,120 coordination layer, coordination layer between Bitcoin and all 561 00:36:36,120 --> 00:36:40,120 these other BSNS. Because if you think about it, 562 00:36:41,080 --> 00:36:46,880 our system is actually the whole Bradburn protocol is a 563 00:36:47,640 --> 00:36:51,680 interchange system because it involves multiple block chains. 564 00:36:52,440 --> 00:36:57,200 The stick is sitting on Bitcoin, but the finance providers are 565 00:36:57,200 --> 00:37:01,240 voting on the BSNS. So to make this whole system 566 00:37:01,240 --> 00:37:05,200 works, it requires a coordination between Bitcoin and 567 00:37:05,200 --> 00:37:12,480 each of these other chains. And so the Babylon chain serves 568 00:37:12,520 --> 00:37:15,680 as a middle layer, a coordination layer to make that 569 00:37:15,680 --> 00:37:20,640 coordination work efficiently. So to give example, you 570 00:37:20,640 --> 00:37:24,760 mentioned time stamping earlier, time stamping earlier. 571 00:37:25,760 --> 00:37:30,520 And it turns out that for this protocol to work, we need also 572 00:37:30,520 --> 00:37:35,680 time stamping between Bitcoin and each of the BSNS. 573 00:37:36,560 --> 00:37:42,760 And the role of the Babylon chain in this case is to help 574 00:37:42,840 --> 00:37:47,960 with this time stamping because Babylon itself time stamps to 575 00:37:47,960 --> 00:37:50,440 Bitcoin. And this time stamping is very 576 00:37:50,440 --> 00:37:54,440 important because you need to synchronize the timing between a 577 00:37:54,440 --> 00:37:59,240 BSN and Bitcoin so that for example, when you unlock we 578 00:37:59,240 --> 00:38:03,280 unborn a stick, then the Bitcoin, the valid, the 579 00:38:03,280 --> 00:38:09,960 financial provider voting power can be removed immediately on 580 00:38:10,040 --> 00:38:13,040 the BSN. So a time coordination is very 581 00:38:13,040 --> 00:38:16,040 important in this interchange system. 582 00:38:17,960 --> 00:38:20,080 Right. And then the nice thing is that 583 00:38:20,080 --> 00:38:23,320 because the Babylon chain is a proof of safe chain, so it can 584 00:38:23,320 --> 00:38:25,920 have very fast blocks. So you can have this time 585 00:38:25,920 --> 00:38:28,920 stamping kind of, you know In Sync with the speed of all of 586 00:38:28,920 --> 00:38:35,200 these chains for Babylon chain. And then that basically sort of, 587 00:38:35,320 --> 00:38:39,440 you know, aggregates and time stamps that to Bitcoin sort of 588 00:38:39,480 --> 00:38:45,800 on the like running a little bit behind, but you know, still 589 00:38:45,800 --> 00:38:48,920 providing like, you know, high, high degree of security. 590 00:38:49,960 --> 00:38:52,480 Exactly, the aggregation that you mentioned is the most 591 00:38:52,480 --> 00:38:55,120 important, one of the most important thing because imagine 592 00:38:55,120 --> 00:38:58,000 a world where there are hundreds of these BSNS. 593 00:38:58,360 --> 00:39:01,080 If each of these chains have the directly build their own 594 00:39:01,080 --> 00:39:04,880 infrastructure, the time stamp to Bitcoin, it's just not a 595 00:39:04,880 --> 00:39:08,360 scalable solution to have so many time stamps on the Bitcoin 596 00:39:08,360 --> 00:39:10,680 chain. And so Babylon chain serves as 597 00:39:10,680 --> 00:39:14,920 this aggregation row so that you only need one time stamp even 598 00:39:14,920 --> 00:39:16,720 though you have hundreds of BSNS. 599 00:39:18,400 --> 00:39:24,320 These liquid staking tokens, do you imagine that in the future 600 00:39:24,320 --> 00:39:30,000 they will mostly also be issued on the Babylon chain, or could 601 00:39:30,000 --> 00:39:32,520 they be issued in many different places? 602 00:39:34,720 --> 00:39:37,720 Yeah. So yes, we are hoping to 603 00:39:37,720 --> 00:39:42,080 encourage folks to issue their LSTS on the Babylon chain first 604 00:39:42,680 --> 00:39:46,360 and then move that liquidity to other chains as needed. 605 00:39:46,680 --> 00:39:49,720 So that would be good. So we would like to sort of 606 00:39:49,720 --> 00:39:53,400 build our next generation of technology would be some 607 00:39:53,400 --> 00:39:57,640 infrastructure to support to do that in a trust minimizing way. 608 00:40:00,000 --> 00:40:05,960 So like taking a step back here, there's been I, I find this like 609 00:40:06,080 --> 00:40:08,680 quite, quite surprising actually, But you know, when I 610 00:40:08,680 --> 00:40:11,640 was at. Proof of stakes second summit 611 00:40:11,640 --> 00:40:14,160 just recently. And there were there were people 612 00:40:14,160 --> 00:40:16,760 there talking about Bitcoin moving to proof of stake. 613 00:40:17,400 --> 00:40:20,120 And like for someone who's been in the space for so long, I 614 00:40:20,120 --> 00:40:22,800 think like maybe to a lot of people that just seems like a 615 00:40:22,800 --> 00:40:26,240 very, you know, unlikely sort of scenario. 616 00:40:26,600 --> 00:40:31,480 But you know, at this point, how, how do you think about that 617 00:40:31,480 --> 00:40:33,680 idea? And like, what is the likelihood 618 00:40:33,680 --> 00:40:37,480 that in some time, what would that look like, you know, 619 00:40:37,480 --> 00:40:38,680 Bitcoin moving to proof of stake? 620 00:40:40,680 --> 00:40:44,240 Yeah. So just to clarify, right, our 621 00:40:44,240 --> 00:40:49,680 research, our, our project Babylon is not advocating to 622 00:40:49,680 --> 00:40:51,720 turn Bitcoin into approval stake chain. 623 00:40:51,720 --> 00:40:57,680 Our, our, our goal right now is to take this Bitcoin asset to 624 00:40:57,680 --> 00:41:01,360 make it as useful as we can. And the use case we're focusing 625 00:41:01,360 --> 00:41:06,160 on is used as a sticking asset to bootstrap or to improve the 626 00:41:06,160 --> 00:41:08,720 liquidity and security of other block chains. 627 00:41:08,720 --> 00:41:11,520 So that's the that's the focus of the project. 628 00:41:12,360 --> 00:41:19,000 Now, in the distant future, if it happens that this idea is so, 629 00:41:19,000 --> 00:41:24,280 so, so successful, so much other block chains, so much of the 630 00:41:24,280 --> 00:41:27,720 entire crypto ecosystem is building on this Bitcoin 631 00:41:27,720 --> 00:41:31,480 sticking, then at some point Bitcoiners may say, hey, maybe 632 00:41:31,480 --> 00:41:35,680 we can also use the security to secure ourselves to improve the 633 00:41:35,680 --> 00:41:40,160 Bitcoin security. If that day happens, then it 634 00:41:40,160 --> 00:41:42,200 happens. If it doesn't happen, it doesn't 635 00:41:42,200 --> 00:41:45,360 happen. So one thing, one thing 636 00:41:45,360 --> 00:41:49,440 interesting about the evolution of crypto is that Bitcoiners 637 00:41:49,440 --> 00:41:54,960 often said that all other block chains are test Nets for 638 00:41:54,960 --> 00:41:58,280 Bitcoin. OK, So what does that mean? 639 00:41:58,280 --> 00:42:01,720 That means that hey, if you have a new concept, you want to test 640 00:42:01,720 --> 00:42:04,800 it on other block chains before you bring it back to Bitcoin. 641 00:42:05,880 --> 00:42:10,480 And in some sense, Bitcoin sticking is kind of a an example 642 00:42:10,480 --> 00:42:13,680 of that thinking, right? Because hey, sticking has been 643 00:42:13,680 --> 00:42:16,440 proved to be rather successful in these proof of stick 644 00:42:16,440 --> 00:42:20,120 blockchains. Now we're bringing part of that 645 00:42:20,120 --> 00:42:23,520 idea back to Bitcoin and say, hey, why don't we use Bitcoin 646 00:42:23,520 --> 00:42:26,520 also as a sticking asset for these other blockchains? 647 00:42:26,520 --> 00:42:28,200 So in some sense we go in that direction. 648 00:42:28,560 --> 00:42:31,400 And maybe at one point people would think, whoa, this proof of 649 00:42:31,400 --> 00:42:34,440 stick idea of using Bitcoin is so powerful that maybe we can 650 00:42:34,440 --> 00:42:38,840 use Bitcoin the asset to increase the security of Bitcoin 651 00:42:38,840 --> 00:42:41,680 chain itself. That's a long way off though, I 652 00:42:41,680 --> 00:42:45,800 think. Yeah, I, I, I feel like it's a 653 00:42:45,800 --> 00:42:48,200 long way off as well if, if it were to happen. 654 00:42:50,320 --> 00:42:54,480 But yeah, I find it like sort of interesting that people are 655 00:42:54,480 --> 00:42:57,080 actually bringing this up as like as a possibility where, you 656 00:42:57,080 --> 00:42:58,920 know, if you would have said this maybe 3-4 years ago, it 657 00:42:58,920 --> 00:43:03,960 would have been no, no one was ever considering Bitcoin to move 658 00:43:03,960 --> 00:43:05,720 to prove a stake. And now it's actually actually 659 00:43:05,720 --> 00:43:08,800 being talked about. I think like one of the things 660 00:43:08,800 --> 00:43:12,400 that's interesting here about Babylon and like generally 661 00:43:12,480 --> 00:43:16,400 Bitcoin L twos is that it, it allows Bitcoin liquidity to move 662 00:43:16,400 --> 00:43:19,000 into D5 and be better utilized in D5. 663 00:43:19,560 --> 00:43:26,640 Well, there's a whole array of chains that also would fall in 664 00:43:26,640 --> 00:43:29,160 this category. Many of the top 20 chains, 665 00:43:29,160 --> 00:43:36,800 chains like Litecoin, XRP, Cardano, Dogecoin, these these 666 00:43:36,800 --> 00:43:41,160 so-called dinosaur chains right where a lot of the liquidity is 667 00:43:41,160 --> 00:43:45,920 being held in wallets or on sexes and not really being 668 00:43:45,920 --> 00:43:48,320 utilized in D5 very much. Now over the last couple of 669 00:43:48,320 --> 00:43:52,480 months, there's been more and more conversation about allowing 670 00:43:52,480 --> 00:43:55,480 that liquidity to more easily flow into D5 protocols. 671 00:43:56,880 --> 00:44:03,320 What is your take on expanding, you know, Bitcoin liquid Bitcoin 672 00:44:03,480 --> 00:44:07,040 re staking to other chains, perhaps other proof of work 673 00:44:07,040 --> 00:44:10,560 chains, you know some script chains or or other chains like 674 00:44:10,560 --> 00:44:14,400 the ones I mentioned so that we can grow liquidity and defy 675 00:44:14,600 --> 00:44:16,400 using the liquidity that's already on chain? 676 00:44:18,880 --> 00:44:21,560 Yeah. I mean, I could see the concept 677 00:44:21,560 --> 00:44:25,600 that what it's the pro code that we came up with can be adapted 678 00:44:26,320 --> 00:44:31,400 to applied on other particular proof of work chains which use 679 00:44:31,400 --> 00:44:33,200 similar scripting language as Bitcoin. 680 00:44:33,200 --> 00:44:36,640 Yes, I'm quite sure there are projects probably working on 681 00:44:36,640 --> 00:44:39,480 that. Right now our focus is entirely 682 00:44:39,480 --> 00:44:45,200 on Bitcoin, Bitcoin. So Bitcoin is a huge enough 683 00:44:45,240 --> 00:44:49,960 asset that if we increase, if we get 1% of Bitcoin, there's 684 00:44:49,960 --> 00:44:52,640 already quite significant accomplishment. 685 00:44:52,640 --> 00:44:55,440 So we just focus laser focus on Bitcoin. 686 00:44:57,320 --> 00:45:00,600 So we talked earlier a little bit about, you know, some of the 687 00:45:00,600 --> 00:45:06,360 efforts to have, you know, some upgrades for covenants more OP 688 00:45:06,360 --> 00:45:11,560 cat, more exclusivity. Now the way you guys are 689 00:45:11,560 --> 00:45:14,800 building, right, you're not relying on that, but you you're 690 00:45:14,800 --> 00:45:17,560 building basically on Bitcoin as it is. 691 00:45:17,960 --> 00:45:22,960 But if some of those things were to happen, would this change 692 00:45:23,080 --> 00:45:28,000 Babylon or would this kind of bring, I know, some new 693 00:45:28,000 --> 00:45:30,840 features? Or is it something where you 694 00:45:30,840 --> 00:45:33,760 kind of feel like, no, we can make do of the way it is right 695 00:45:33,760 --> 00:45:35,720 now and it doesn't really matter? 696 00:45:37,360 --> 00:45:42,600 Yeah. So our technology is entirely 697 00:45:42,600 --> 00:45:45,280 independent of soft fork, right. So that was our philosophy I 698 00:45:45,280 --> 00:45:48,600 mentioned. So we do not assume soft fork 699 00:45:49,160 --> 00:45:50,920 and our technology does not assume that. 700 00:45:51,280 --> 00:45:55,560 Now if there is a soft fork like passing some kind of covenants 701 00:45:55,560 --> 00:46:02,360 or we can't or something similar, then yes, that would 702 00:46:02,360 --> 00:46:07,720 make us to be able to do more things and in a cheaper way. 703 00:46:09,480 --> 00:46:16,000 So right now a lot of the ideas around bit VM is basically to 704 00:46:16,000 --> 00:46:21,080 get around this covenants issue. The the consequence though is 705 00:46:21,080 --> 00:46:26,960 that there are some costs associated with it. 706 00:46:26,960 --> 00:46:31,160 So the transaction fees tends to be a little bit high and so that 707 00:46:31,160 --> 00:46:34,160 could be reduced. So I think to me it's mainly a 708 00:46:34,160 --> 00:46:38,000 question of efficiency that you can do it at a lower cost, you 709 00:46:38,000 --> 00:46:39,960 can do more things at a lower cost. 710 00:46:41,200 --> 00:46:44,560 But for us right now, the Bitcoin sticking core primitive 711 00:46:44,560 --> 00:46:49,160 is already very low cost and without this software. 712 00:46:51,760 --> 00:46:54,400 So the Babylon ecosystem is really, you know, grown 713 00:46:54,400 --> 00:46:57,680 tremendously I think over the past year or so. 714 00:46:57,680 --> 00:47:00,120 There's a lot of projects. You know, you mentioned liquid 715 00:47:00,120 --> 00:47:04,520 staking assets are being built on top of Babylon, a lot of 716 00:47:04,520 --> 00:47:08,120 things happening. What are the most interesting 717 00:47:08,120 --> 00:47:12,840 and exciting things being built? Yeah. 718 00:47:12,840 --> 00:47:18,240 So a lot of the innovations right now is really try to 719 00:47:18,240 --> 00:47:26,400 figure out how to sort of couple or add liquidity to the base 720 00:47:26,400 --> 00:47:30,440 layer of sticking. And I think that's sort of where 721 00:47:30,440 --> 00:47:34,200 we try to provide a lot of support as the base staking 722 00:47:34,200 --> 00:47:39,280 protocol. So what are the timelines here? 723 00:47:39,280 --> 00:47:42,920 You mentioned, you know, phase one, phase two, phase three, 724 00:47:45,040 --> 00:47:47,240 Yeah. How do you see? 725 00:47:48,000 --> 00:47:49,640 I don't know. What time frame do you see those 726 00:47:49,640 --> 00:47:54,720 rolling out? Yeah, we're shooting for right 727 00:47:54,720 --> 00:47:59,720 now we're in phase one. We have opened the cap three 728 00:47:59,720 --> 00:48:04,040 times, cap one, cap 2, cap 3 and right now it's closed. 729 00:48:04,040 --> 00:48:11,480 We have about 57,000 Bitcoin, 57,000 Bitcoin staked on the 730 00:48:11,480 --> 00:48:20,600 Babylon protocol and phase two we are shooting for roughly end 731 00:48:20,600 --> 00:48:26,440 of Q1, begin of Q2 time frame to launch the Babylon chain. 732 00:48:26,880 --> 00:48:30,560 That's our phase two. And in phase three which 733 00:48:30,640 --> 00:48:35,440 hopefully will happen maybe 1/4 after that is we will have a 734 00:48:35,440 --> 00:48:42,400 bunch of initial cohort of BSNS, Bitcoin secure networks to 735 00:48:43,760 --> 00:48:50,280 complete the entire picture. So that's the face lodge. 736 00:48:52,080 --> 00:48:54,480 Cool, well, thank you so much for coming on David. 737 00:48:54,480 --> 00:48:59,400 It's really great to you know, to hear your overview and it's 738 00:48:59,400 --> 00:49:01,720 super exciting. I think as as you know, as a 739 00:49:01,960 --> 00:49:05,840 long term Bitcoin holder who's helped Bitcoin for a long time 740 00:49:05,840 --> 00:49:08,200 and always been like, oh, it would be great to do something 741 00:49:08,200 --> 00:49:10,560 with it. I think it's super exciting and 742 00:49:10,560 --> 00:49:14,080 of course there's someone you know Sebastian as well as me, 743 00:49:14,080 --> 00:49:16,240 you know, they deep in the cosmos ecosystem. 744 00:49:16,240 --> 00:49:19,640 It's it's amazing that here are those two things come together 745 00:49:19,640 --> 00:49:23,520 and we've now seen such a vibrant ecosystem emerging 746 00:49:23,520 --> 00:49:26,160 around Babylon. So super excited to see how 747 00:49:26,160 --> 00:49:30,920 these phases roll out and yeah, how it's going to play out in 748 00:49:30,920 --> 00:49:33,280 the next years. So thank you so much for your 749 00:49:33,280 --> 00:49:35,080 work and thanks so much for joining us today. 750 00:49:36,080 --> 00:49:37,680 Great being here, great conversation. 751 00:49:37,680 --> 00:49:39,920 Brian is the best yet. Thank you very much. 752 00:49:41,160 --> 00:49:41,520 Thank you.