1 00:00:03,320 --> 00:00:06,520 My fellow clubs River is setting a new standard in 2 00:00:06,520 --> 00:00:10,240 bitcoin@river.com. You'll pay zero fees when you 3 00:00:10,240 --> 00:00:13,400 dollar cost average. Truly the best way to build your 4 00:00:13,400 --> 00:00:16,200 Bitcoin? Well, all Bitcoin at River is 5 00:00:16,200 --> 00:00:19,440 held in secure cold storage with 100% full reserves. 6 00:00:19,720 --> 00:00:22,320 There's no need to wonder what's happening behind the scenes. 7 00:00:22,600 --> 00:00:26,120 Your Bitcoin is your Bitcoin to withdraw at any time. 8 00:00:26,120 --> 00:00:28,920 Additionally, River lets you make Bitcoin payments via the 9 00:00:28,920 --> 00:00:31,680 Lightning Network, offers a Lightning integration for 10 00:00:31,680 --> 00:00:34,960 developers, and allows you to mine Bitcoin directly to your 11 00:00:34,960 --> 00:00:37,920 River account. River has a level of service 12 00:00:37,920 --> 00:00:40,760 that is unheard of in this industry, including phone 13 00:00:40,760 --> 00:00:43,800 support, private client advisors, and the ability to 14 00:00:43,800 --> 00:00:47,080 designate beneficiaries to inherit your Bitcoin wealth. 15 00:00:48,040 --> 00:00:51,000 River has become the premium name in Bitcoin that anyone can 16 00:00:51,000 --> 00:00:52,040 easily. Access. 17 00:00:52,360 --> 00:00:55,200 Sure, you have a place to buy Bitcoin, but have you tried 18 00:00:55,200 --> 00:00:57,600 River? See and feel the difference at 19 00:00:57,600 --> 00:01:02,120 river.com and the River iOS app. The preferred partner of Bitcoin 20 00:01:02,120 --> 00:01:05,360 Magazine. Over the last five years, the 21 00:01:05,360 --> 00:01:08,640 Bitcoin conference has become the world's largest gathering of 22 00:01:08,640 --> 00:01:11,280 bitcoiners. From breaking announcements and 23 00:01:11,280 --> 00:01:14,480 international media coverage to countless meaningful talks by 24 00:01:14,480 --> 00:01:17,520 thought leaders and industry innovators, we are excited to 25 00:01:17,520 --> 00:01:20,720 continue our drive for global hyper bitcoinization. 26 00:01:21,480 --> 00:01:25,760 From July 25th to 27th, 2024, we'll be taking the Bitcoin 27 00:01:25,760 --> 00:01:29,720 Conference to the City of Music and Freedom Nashville, TN. 28 00:01:30,320 --> 00:01:33,280 Join thousands of attendees for countless opportunities to 29 00:01:33,280 --> 00:01:37,680 learn, engage and network across 3 days of pure Bitcoin signal. 30 00:01:38,440 --> 00:01:42,080 Get your tickets now for the best price at B dot TC forward 31 00:01:42,080 --> 00:01:44,400 slash conference. You are not going to want to 32 00:01:44,400 --> 00:01:46,320 miss what Nashville has in store. 33 00:01:47,240 --> 00:01:48,760 How's it going, Shinobi? Doing well? 34 00:01:48,800 --> 00:01:51,520 What's up, Mark? Looking forward to this 35 00:01:51,520 --> 00:01:53,880 conversation. Talking about covenants, Yep, 36 00:01:54,120 --> 00:01:57,760 guess there is just the waiting. Buddy, how we doing? 37 00:01:57,760 --> 00:01:59,280 What's up, Chris? What's up, shinobi? 38 00:02:00,200 --> 00:02:02,720 What's up, Mark? Well, I guess we're waiting for 39 00:02:02,720 --> 00:02:05,440 the autistic. Cabinet a nice, nice lovely 40 00:02:05,760 --> 00:02:08,840 morning over here. Excited to talk covenants with 41 00:02:08,840 --> 00:02:11,680 the homies. Yeah, Mark, I think you might 42 00:02:11,680 --> 00:02:14,000 need to hop off because I don't know if you can hear Shinobi 43 00:02:14,000 --> 00:02:16,440 when he's talking. No. 44 00:02:17,360 --> 00:02:18,840 You might need to just leave and come back. 45 00:02:18,840 --> 00:02:20,480 And I'll. I'll bring you back up on stage. 46 00:02:21,520 --> 00:02:24,520 All right. The Avengers slowly assembling. 47 00:02:25,560 --> 00:02:29,320 Got two more. Yep, I'm inviting Sam. 48 00:02:29,320 --> 00:02:33,040 Super testing that up here. Hopefully Mark will be back in a 49 00:02:33,040 --> 00:02:35,520 minute too. What's up y'all? 50 00:02:36,640 --> 00:02:38,440 Hey Sam. Hey, Moon Settler. 51 00:02:38,720 --> 00:02:40,800 Nice shinobi. Aloha. 52 00:02:42,080 --> 00:02:44,640 Hello guys. How's it going everyone? 53 00:02:44,640 --> 00:02:46,720 Mark, you're back. Hopefully you can hear everyone 54 00:02:46,720 --> 00:02:48,880 now. I can, I think. 55 00:02:49,720 --> 00:02:52,720 Can you hear Moon Settler? I haven't heard Shinobi yet, but 56 00:02:53,560 --> 00:02:55,120 it's up Super Test net. What up, Sam? 57 00:02:55,120 --> 00:02:58,320 How's everybody doing? So good, thank you for asking. 58 00:02:59,280 --> 00:03:01,720 Just wonderful. What a, what a, what a group of 59 00:03:01,720 --> 00:03:03,920 people this is. This is the spaces I've been 60 00:03:03,920 --> 00:03:07,800 really, really, really excited about for a while and I am a bit 61 00:03:07,880 --> 00:03:09,480 over my head on a lot of these things. 62 00:03:09,480 --> 00:03:13,080 So I'm excited to learn from you guys about all this stuff. 63 00:03:13,080 --> 00:03:17,080 So been following you guys for a while and I think more people 64 00:03:17,080 --> 00:03:18,880 should. Pay attention to what you guys 65 00:03:18,880 --> 00:03:21,160 are talking about. So excited to have you guys. 66 00:03:22,120 --> 00:03:24,080 Yeah, I'm what you want to call it. 67 00:03:24,080 --> 00:03:28,120 Chris, if you could invite Reardon up, he he was a maybe. 68 00:03:28,160 --> 00:03:30,120 I see him working down there though. 69 00:03:30,480 --> 00:03:33,960 Yep, just tossed him an invite and looking for, I think anyone 70 00:03:33,960 --> 00:03:35,600 else that's coming in last minute here. 71 00:03:36,560 --> 00:03:39,440 All right, at this point, I think we are just waiting for 72 00:03:39,440 --> 00:03:46,120 Polly Ed, who might pop in late, and Robin to stop his autistic 73 00:03:46,200 --> 00:03:50,240 spasming in the in front of a. Shinobi, you want to take it 74 00:03:50,240 --> 00:03:51,640 away? Maybe we'll do some brief 75 00:03:51,640 --> 00:03:53,200 introductions and then we can dive into it. 76 00:03:54,240 --> 00:03:59,440 Yeah, I guess before I go on the long winded framing ramble, 77 00:04:00,440 --> 00:04:04,400 everybody kind of want to introduce themselves, tell 78 00:04:04,400 --> 00:04:06,360 everybody what they're working on, if they're working on 79 00:04:06,360 --> 00:04:08,720 anything. I guess we can start with you, 80 00:04:08,720 --> 00:04:11,480 Sam. Yo, hey guys. 81 00:04:12,880 --> 00:04:21,079 I am a fur researcher guy who among other things, that was 82 00:04:21,360 --> 00:04:25,200 part of the kind of group of people that were thinking about 83 00:04:25,200 --> 00:04:28,160 how to hack Zero knowledge prover into Bitcoin that 84 00:04:28,160 --> 00:04:31,240 eventually led to Robin's discovery of Bit VM. 85 00:04:32,280 --> 00:04:36,520 In general, my day job is inventing product specs for 86 00:04:36,520 --> 00:04:39,320 weird. Experimental type of protocols 87 00:04:39,320 --> 00:04:44,760 like bit BM but for shit coin projects but at the end of the 88 00:04:44,760 --> 00:04:49,720 day like all I want is to to scrape all the the good research 89 00:04:49,720 --> 00:04:51,240 and and bring it back to Bitcoin. 90 00:04:52,160 --> 00:04:55,600 Here here Mark. Oh, hi. 91 00:04:55,600 --> 00:05:00,720 Yeah, hello. I do writing and you know, do 92 00:05:00,720 --> 00:05:02,760 some editorial stuff for Bitcoin Magazine. 93 00:05:02,760 --> 00:05:08,360 And yeah, in general I think my like first big break from, I 94 00:05:08,360 --> 00:05:11,600 would say the echo chamber discourse of Bitcoin was 95 00:05:11,600 --> 00:05:15,760 watching. You know, the bit 119 stuff kind 96 00:05:15,760 --> 00:05:19,560 of happened and and. You know, being, you know, 97 00:05:19,720 --> 00:05:23,560 getting covenants explained to me seemingly like a really great 98 00:05:23,560 --> 00:05:26,200 idea that would be pretty much good for everybody for pretty 99 00:05:26,200 --> 00:05:29,040 much every reason. And then kind of seeing a lot of 100 00:05:29,040 --> 00:05:33,000 people push back against it was, you know, a big part of my kind 101 00:05:33,000 --> 00:05:37,080 of, you know, break to the echo chamber and yeah, I I'm 102 00:05:37,080 --> 00:05:40,440 interested in covenants greatly. I think that they're very 103 00:05:40,440 --> 00:05:44,360 important for, you know, keeping Bitcoin basically as permission 104 00:05:44,360 --> 00:05:47,480 lesson and as accessible for the next billion people as it was 105 00:05:47,480 --> 00:05:49,880 for us, you know, people the last few years. 106 00:05:49,880 --> 00:05:52,960 So yeah, excited to learn more about it and be here with you 107 00:05:53,920 --> 00:05:54,960 guys. Super Tesla. 108 00:05:55,920 --> 00:05:58,680 Hi guys I am a free and open source software developer 109 00:05:58,680 --> 00:06:02,200 focused on primarily Bitcoin, the Lightning Network, and most 110 00:06:02,200 --> 00:06:06,520 recently Noster. And some of the most of what I 111 00:06:06,520 --> 00:06:09,800 do is come up with cool new ideas and then proofs of concept 112 00:06:09,800 --> 00:06:11,840 that they are actually possible in code. 113 00:06:12,400 --> 00:06:15,600 And so that's what I do. And moon. 114 00:06:16,800 --> 00:06:22,440 Oh, do we still have you, Moon? The moon is gone or moon has 115 00:06:22,440 --> 00:06:24,320 been taken from us. That's no moon. 116 00:06:24,320 --> 00:06:29,160 Or is it a space station? When you are the moon. 117 00:06:30,160 --> 00:06:34,080 All right. Well, well, Moon diagnosis that, 118 00:06:34,160 --> 00:06:37,200 I guess. Someone go out there and lasso 119 00:06:37,200 --> 00:06:40,760 the moon for us. Sorry guys, I couldn't speak. 120 00:06:41,360 --> 00:06:44,680 There we go. So hello guys. 121 00:06:44,680 --> 00:06:50,000 I'm Moon Settler and I she was on Twitter about scaling Bitcoin 122 00:06:50,000 --> 00:06:54,960 and privacy covenant stuff and blind store and stuff like this 123 00:06:56,000 --> 00:07:00,280 already. So I guess time for the long 124 00:07:00,280 --> 00:07:03,280 winded framing rant from shinobi. 125 00:07:04,200 --> 00:07:09,360 So covenants are the the thing that bitcoiners have been 126 00:07:09,360 --> 00:07:12,320 obsessing about for the last couple years. 127 00:07:12,320 --> 00:07:17,520 At this point, I still feel like a lot of people are very 128 00:07:17,520 --> 00:07:23,160 confused when they hear that word about what that means, just 129 00:07:23,160 --> 00:07:26,360 because of how broad of a topic it is. 130 00:07:27,040 --> 00:07:32,280 So to start, I think the best place to begin would be just 131 00:07:32,280 --> 00:07:35,800 thinking about what is Bitcoin Script right now? 132 00:07:36,760 --> 00:07:41,960 And it it's essentially just a very small language where you 133 00:07:41,960 --> 00:07:48,760 can write programs to lock coins that exist right now so that the 134 00:07:48,760 --> 00:07:52,680 only way to spend those coins is fulfill the condition of that 135 00:07:52,680 --> 00:07:55,320 program. Like for instance, the simplest 136 00:07:55,320 --> 00:08:00,360 example of that is just. Here is a public key provide me 137 00:08:00,360 --> 00:08:04,240 with a signature that validates against this public key. 138 00:08:05,160 --> 00:08:10,320 And so the the entire purpose and point of Bitcoin script is 139 00:08:10,320 --> 00:08:15,800 to define what conditions you have to meet to spend coins that 140 00:08:15,800 --> 00:08:21,520 exist right now. So what covenants want to do is 141 00:08:21,800 --> 00:08:28,000 expand what script is capable of doing from just restricting 142 00:08:28,000 --> 00:08:33,600 coins that exist right now to restricting coins that don't 143 00:08:33,600 --> 00:08:37,720 exist that are yet to be actually created on chain. 144 00:08:38,640 --> 00:08:43,919 So that the conditions you put in a script for a coin that 145 00:08:43,919 --> 00:08:50,160 exists now actually have some degree of control to restrict 146 00:08:50,160 --> 00:08:53,880 coins that will be created when you spend that coin. 147 00:08:55,000 --> 00:08:59,120 Also real quick Robin, if you could request the host is having 148 00:08:59,120 --> 00:09:03,880 trouble you finding or finding you down in the listener, but so 149 00:09:03,880 --> 00:09:09,440 like that's the most general definition there is for a 150 00:09:09,440 --> 00:09:12,680 covenant. It's just some script, some 151 00:09:12,680 --> 00:09:18,400 primitive in Bitcoin that extends the ability to restrict 152 00:09:19,120 --> 00:09:24,120 coins being spent from coins that exist right now in the UTXO 153 00:09:24,120 --> 00:09:28,880 set. 2 coins that haven't been created and added to the UTXO 154 00:09:28,880 --> 00:09:34,160 set yet. And so that is a really, really 155 00:09:34,160 --> 00:09:40,280 open-ended and kind of a vague potential like that that could 156 00:09:40,280 --> 00:09:44,480 be literally almost anything like that could be these coins 157 00:09:44,480 --> 00:09:48,160 can only be spent if the government authority lets you. 158 00:09:48,320 --> 00:09:54,560 Or these coins can only be spent for the rest of eternity, once a 159 00:09:54,560 --> 00:09:58,040 month. And any coin that descends from 160 00:09:58,040 --> 00:10:00,880 it is forever encumbered by those same conditions. 161 00:10:01,600 --> 00:10:07,200 And so that's that can be a very scary thing when people just 162 00:10:07,200 --> 00:10:10,640 hear covenants and think the most general type of 163 00:10:10,640 --> 00:10:16,080 restrictions like that. But they can also be incredibly 164 00:10:16,080 --> 00:10:22,400 simple things, just like this coin has to be spent to this 165 00:10:22,400 --> 00:10:26,200 address just once. So you just have a simple 166 00:10:26,200 --> 00:10:31,720 covenant that applies to 1 UTXO that exists right now. 167 00:10:32,400 --> 00:10:38,160 And all it does is for one time, it just requires that that coin 168 00:10:38,160 --> 00:10:42,440 be spent to a specific place, and after that, that coin can be 169 00:10:42,440 --> 00:10:45,560 spent to wherever the owner wants to spend it after that. 170 00:10:46,440 --> 00:10:55,680 So you have this vast spectrum of like just super simple, not 171 00:10:55,680 --> 00:10:59,840 really dangerous or expansive restrictions that you can place 172 00:10:59,840 --> 00:11:05,160 on future coins to the open-ended like whatever, like 173 00:11:05,160 --> 00:11:09,160 your head could come up with. And that is a massive design 174 00:11:09,160 --> 00:11:12,640 space. But at the same time, everything 175 00:11:12,640 --> 00:11:17,560 that we're doing in Bitcoin in terms of solving problems like 176 00:11:18,040 --> 00:11:24,560 scalability, like privacy, all of the problems in making those 177 00:11:24,560 --> 00:11:29,240 solutions we, we're implementing work keep coming back to 178 00:11:29,240 --> 00:11:32,120 covenants. And so I think the whole 179 00:11:32,120 --> 00:11:40,360 question here is what is the bare minimum type of covenant to 180 00:11:40,360 --> 00:11:45,760 address problems in our scaling road map and what are the 181 00:11:45,760 --> 00:11:49,360 implications of that? And so I guess you know from 182 00:11:49,360 --> 00:11:53,800 here I might try to rein in the autism and ask for 183 00:11:53,800 --> 00:11:56,360 clarifications. If you guys start going in a 184 00:11:56,360 --> 00:12:01,280 direction that might be a bit too over everybody's heads. 185 00:12:02,200 --> 00:12:04,760 But I think you know the to start off like what are you, 186 00:12:04,760 --> 00:12:07,880 what are your guys thoughts? Just open question to everybody 187 00:12:07,880 --> 00:12:13,200 about like how far should we try to take the capabilities of a 188 00:12:13,200 --> 00:12:20,000 covenant just to get the first simple covenant to try to solve 189 00:12:20,000 --> 00:12:24,400 the problems of stuff like lightning or systems being built 190 00:12:24,400 --> 00:12:30,280 right now, you know, open floor? I'm a big fan of OP CTV Check 191 00:12:30,280 --> 00:12:34,480 template verify and one of the reasons why I like it is that 192 00:12:34,480 --> 00:12:37,720 there are a couple of things that I know how to build once we 193 00:12:37,720 --> 00:12:41,600 have it, and two of them are, I know that it's it seems to me 194 00:12:41,600 --> 00:12:45,720 that it's a lot easier to build arc if you if you have CTV. 195 00:12:46,680 --> 00:12:49,040 And similarly, it's a lot easier to build channel factories for 196 00:12:49,040 --> 00:12:51,440 lightning. So those are two things that I'd 197 00:12:51,440 --> 00:12:53,280 like to really I'd like to get started on. 198 00:12:53,720 --> 00:12:57,720 And CTV would make them easier. One of the reasons it does that 199 00:12:57,720 --> 00:13:01,920 is because CTV allows you to get a guarantee that if you put 200 00:13:01,920 --> 00:13:05,840 coins into address A, you'll get the same amount of coins back 201 00:13:06,560 --> 00:13:09,240 later. No one, no one can like take 202 00:13:09,240 --> 00:13:12,480 them from you. And address A can be controlled 203 00:13:12,480 --> 00:13:16,080 by a lot of people. It can be, It can be. 204 00:13:16,080 --> 00:13:18,160 It can have payouts for A for a number of people. 205 00:13:18,160 --> 00:13:20,920 It enables something called payment pools where a bunch of 206 00:13:20,920 --> 00:13:24,560 people put money into address A and they know that when they're 207 00:13:24,560 --> 00:13:26,960 done using it, they'll get the same amount back out of address 208 00:13:27,120 --> 00:13:29,360 A. So I really want that. 209 00:13:29,360 --> 00:13:31,320 And that enables a couple of cool things. 210 00:13:31,320 --> 00:13:33,880 So, yeah, that's that's one of one of the things I'm a fan of. 211 00:13:33,880 --> 00:13:36,960 All right. So real, real quick kind of a 212 00:13:36,960 --> 00:13:42,320 question to go with that just for listeners like why is that 213 00:13:42,320 --> 00:13:48,080 something that we need CTV for? Like why couldn't we do that now 214 00:13:48,120 --> 00:13:51,720 just using pre signed transactions or like the scripts 215 00:13:51,720 --> 00:13:54,760 that we have available right? Now well you can do it with pre 216 00:13:54,760 --> 00:13:57,920 signed transactions, but it limits the number of people who 217 00:13:57,920 --> 00:14:00,120 can be involved and it increases the expense. 218 00:14:00,600 --> 00:14:04,440 So when you do pre signed transactions you either have to 219 00:14:04,720 --> 00:14:08,000 add every public key who's going to be in control of this Bitcoin 220 00:14:08,000 --> 00:14:10,880 address. On into the into the address. 221 00:14:10,880 --> 00:14:13,200 And so when you want to spend it, you've got to have like 50 222 00:14:13,200 --> 00:14:16,200 public keys in there. That's pretty expensive. 223 00:14:16,360 --> 00:14:18,120 For every public key you need a signature. 224 00:14:19,080 --> 00:14:21,320 It adds up quickly. You have a lot of data that you 225 00:14:21,320 --> 00:14:23,520 have to put on the blockchain in order to do that, increasing the 226 00:14:23,520 --> 00:14:27,080 expense for everyone. And the other thing you can do 227 00:14:27,080 --> 00:14:32,800 is you can do it off chain using using MUSIC or FROST. 228 00:14:33,520 --> 00:14:36,480 But that increases the computational the amount of 229 00:14:36,480 --> 00:14:40,520 computation that you have to do, and it also increases the the 230 00:14:40,520 --> 00:14:43,400 online time of everybody. Everyone who's involved in that 231 00:14:43,400 --> 00:14:45,400 address has to be online at the same time. 232 00:14:46,440 --> 00:14:48,960 Well, not necessarily at the same time, but they have, they 233 00:14:48,960 --> 00:14:52,000 all have to get online in order to coordinate what they want to 234 00:14:52,000 --> 00:14:54,400 do with this address and any changes they make to it. 235 00:14:54,400 --> 00:14:57,160 They all have to come online to say all right, it's time to do 236 00:14:57,160 --> 00:15:01,000 everyone's payouts or whatever in order to change the payout 237 00:15:01,000 --> 00:15:03,280 structure. That kind of sucks. 238 00:15:04,040 --> 00:15:06,960 And with CTV you limit the, you limit that you you make it so 239 00:15:06,960 --> 00:15:10,360 that you only have a a normal sized address, normal sized 240 00:15:10,360 --> 00:15:15,720 transactions and the process for modifying what it does is a lot 241 00:15:15,720 --> 00:15:17,160 simpler. Not not everyone has to be 242 00:15:17,160 --> 00:15:20,720 online at the same time. So that that makes everything a 243 00:15:20,720 --> 00:15:23,480 lot easier. And and it makes it scale 244 00:15:23,480 --> 00:15:24,600 better. It makes it so you can have 245 00:15:24,920 --> 00:15:26,800 thousands of people instead of just dozens. 246 00:15:27,840 --> 00:15:29,400 Yeah, I mean, you got something to say? 247 00:15:30,480 --> 00:15:34,440 Yeah, so I wanted to add that with Music and Frost and stuff 248 00:15:34,440 --> 00:15:38,480 like that, with this easy small signature aggregations, we no 249 00:15:38,480 --> 00:15:41,800 longer really have the problem with the blockchain space 250 00:15:41,800 --> 00:15:45,320 utilization because everything could look like a single signal. 251 00:15:45,320 --> 00:15:48,880 That's pretty efficient, but the interactivity requirements are 252 00:15:48,880 --> 00:15:51,120 still there and. If you want to allow for a 253 00:15:51,120 --> 00:15:54,840 flexible fee schedule without covenants, you can't really do 254 00:15:54,840 --> 00:15:59,040 more than one hope with pre signed transactions. 255 00:15:59,040 --> 00:16:03,400 After that, if the transaction IDs are not predictable to you, 256 00:16:03,840 --> 00:16:08,840 then those signatures are basically unusable. 257 00:16:09,440 --> 00:16:14,480 So we have this problem of creating longer chains where we 258 00:16:14,480 --> 00:16:19,280 want the ability for people to odd fees according to a future, 259 00:16:19,720 --> 00:16:22,840 you know, fee market and not have to suffer with the child 260 00:16:22,840 --> 00:16:26,160 pay for parent outputs and stuff like that. 261 00:16:26,720 --> 00:16:30,840 Basically want to allow that anyone who executes from a large 262 00:16:30,840 --> 00:16:34,480 set of people, anyone who executes that contract, is 263 00:16:34,480 --> 00:16:38,560 actually paying the fee if he's opting out of cooperation. 264 00:16:39,040 --> 00:16:41,760 And he has to bear the cost you know and stuff like that. 265 00:16:41,760 --> 00:16:46,280 So so it just it just makes the whole thing more practical and 266 00:16:46,280 --> 00:16:53,480 and more implementable for a lot of cases and like you you you 267 00:16:53,480 --> 00:16:58,760 can you can better do certain relative time lock situations 268 00:16:58,760 --> 00:17:03,600 like that again with with flexible fees and and not having 269 00:17:03,600 --> 00:17:06,599 to worry about the transaction ID more liability. 270 00:17:07,280 --> 00:17:11,400 So that's that's kind of where I would put the the emphasis and I 271 00:17:11,400 --> 00:17:15,480 would like to say that I I personally think the minimum 272 00:17:15,480 --> 00:17:18,880 said that we should be thinking about these these check check 273 00:17:18,880 --> 00:17:24,720 complete verify CTV plus check seek from stack CSFS. 274 00:17:25,200 --> 00:17:33,640 So the two together enables like very, very flexible, very clever 275 00:17:33,640 --> 00:17:38,240 ways to to exit. Directly with the operator from 276 00:17:38,240 --> 00:17:44,720 payment pools, it gives us LS symmetry which is also high 277 00:17:44,720 --> 00:17:51,520 value use case to many people. And so basically basically it's 278 00:17:51,520 --> 00:17:57,080 not something where we would not be able to properly reason about 279 00:17:57,120 --> 00:18:02,560 the possibilities that it opens up and it just gives us like the 280 00:18:02,560 --> 00:18:05,520 building blocks for. You know, getting started on 281 00:18:05,520 --> 00:18:09,800 this part, yeah. So just to, you know, sum up for 282 00:18:09,800 --> 00:18:14,640 everybody listening. So CTV is essentially something 283 00:18:14,640 --> 00:18:20,040 that lets you make a bunch of pre signed transactions, except 284 00:18:20,040 --> 00:18:24,760 once the first one confirms the rest of them are not double 285 00:18:24,760 --> 00:18:28,520 spendable. So like once you start spending 286 00:18:28,960 --> 00:18:32,400 that chain of transactions, you have to follow through all the 287 00:18:32,400 --> 00:18:37,760 way to the end by consensus and then check sig from stack is 288 00:18:37,760 --> 00:18:41,440 something that the when a signature gets checked in the 289 00:18:41,480 --> 00:18:45,960 Bitcoin script system, right now it only gets checked against the 290 00:18:45,960 --> 00:18:49,920 transaction itself. Check sig from stack would allow 291 00:18:49,920 --> 00:18:55,400 you to check a signature against any random piece of data, so 292 00:18:55,400 --> 00:19:02,360 like just part of a transaction or some arbitrary value from an 293 00:19:02,360 --> 00:19:07,040 Oracle and things like that. And also Robin, I don't know if 294 00:19:07,040 --> 00:19:11,400 you missed it, but we're kind of going through like what is the 295 00:19:11,400 --> 00:19:17,360 bare minimum degree of covenant functionality that people think 296 00:19:17,360 --> 00:19:19,880 we should start with. So if you have any thoughts in 297 00:19:19,880 --> 00:19:22,120 that regard, welcome to chime in. 298 00:19:23,120 --> 00:19:24,760 Yeah. If if you wanna go for the bare 299 00:19:24,760 --> 00:19:28,040 minimum, that's I think obviously CTV because that's 300 00:19:28,040 --> 00:19:31,960 what CTV is designed for, to be the bare minimum of covenants 301 00:19:31,960 --> 00:19:36,400 that we could have. And I guess, Sam, you got any 302 00:19:36,600 --> 00:19:40,360 thoughts to chime in here? I mean, yeah, if someone is, if 303 00:19:40,360 --> 00:19:42,680 someone has an idea of how to make a more conservative 304 00:19:42,680 --> 00:19:45,200 covenant scheme than CTV, I'd love to see it. 305 00:19:45,640 --> 00:19:51,040 But yeah, I think that. That that maybe we should start 306 00:19:51,040 --> 00:19:55,920 arguing about whether we necessarily need that level of 307 00:19:56,760 --> 00:20:00,640 of conservatism. Like, how important is it to 308 00:20:02,240 --> 00:20:06,040 absolutely prevent the kind of infinitely recursive 309 00:20:06,600 --> 00:20:10,200 restrictions that, you know, we're, we're worried about at 310 00:20:10,200 --> 00:20:14,480 the protocol level, knowing full well that those kind of 311 00:20:14,480 --> 00:20:19,560 restrictions are and. That can be enforced at the 312 00:20:19,560 --> 00:20:22,560 level of, you know, physical violence, etcetera. 313 00:20:23,560 --> 00:20:27,560 All right. So I guess the next one I'll 314 00:20:27,560 --> 00:20:30,360 toss out again to the floor, open to anybody. 315 00:20:31,120 --> 00:20:36,880 I think this is kind of really where a lot of users and people 316 00:20:36,880 --> 00:20:40,600 paying attention in the space kind of just get lost on this 317 00:20:40,600 --> 00:20:45,240 whole topic. But like what are some of the 318 00:20:45,240 --> 00:20:49,640 problems? That we face right now that are 319 00:20:49,640 --> 00:20:54,920 really difficult if not impossible to solve without some 320 00:20:54,920 --> 00:20:58,240 form of covenant. You know, like shortcomings or 321 00:20:58,240 --> 00:21:02,120 issues with things like lightning or side chains or 322 00:21:02,320 --> 00:21:05,920 systems like FIT BM. Just like where where are the 323 00:21:05,920 --> 00:21:10,120 limits of all of those types of system and the problems they're 324 00:21:10,120 --> 00:21:14,320 running into that covenants would really help address where 325 00:21:14,320 --> 00:21:16,280 nothing else can really solve that. 326 00:21:16,920 --> 00:21:19,560 Yeah. Well I I was thinking about this 327 00:21:19,960 --> 00:21:25,400 a lot recently and I think that one of if not the biggest core 328 00:21:25,400 --> 00:21:30,760 problem to scale that we that we need to solve right now is is 329 00:21:30,920 --> 00:21:36,080 guaranteeing settlement of of like exit transactions, right. 330 00:21:36,440 --> 00:21:39,040 Because it it's seeming that like you look at lightning, you 331 00:21:39,040 --> 00:21:43,520 look at our, you look at bit VM, you know assuming that we're not 332 00:21:43,520 --> 00:21:47,800 ever going to have op ZK verify on Bitcoin, that kind of 333 00:21:47,800 --> 00:21:50,640 restricts us to these optimistic protocols. 334 00:21:51,520 --> 00:21:53,440 And the way the optimistic protocol works is like you're 335 00:21:53,440 --> 00:21:56,200 assuming that someone is following some rules, but if 336 00:21:56,200 --> 00:21:59,240 they don't, then you're able to exit somehow and either, you 337 00:21:59,280 --> 00:22:02,960 know, do a fraud proof or just just get out of the system in 338 00:22:02,960 --> 00:22:06,600 time for you to not, you know, be damaged by them acting 339 00:22:06,600 --> 00:22:10,680 maliciously. And and and that's great. 340 00:22:10,680 --> 00:22:13,880 These these systems are like absurdly efficient in basically 341 00:22:13,880 --> 00:22:17,720 every way. But but the problem that this 342 00:22:17,720 --> 00:22:22,120 keeps running into is like, well, you you can't, you can't 343 00:22:22,120 --> 00:22:24,520 guarantee that you're going to be able to get your day in court 344 00:22:24,520 --> 00:22:28,960 on the L1 in time before you know the expiration window for 345 00:22:28,960 --> 00:22:30,600 these kind of fraud proofs expire. 346 00:22:31,200 --> 00:22:34,600 So one of the things, one of the big things that I think we need 347 00:22:34,600 --> 00:22:39,560 like something to to enable we've argued about this before. 348 00:22:39,840 --> 00:22:42,480 I don't think you can do this with just getting with just 349 00:22:42,480 --> 00:22:46,840 clever like interactivity schemes is you just need to have 350 00:22:47,240 --> 00:22:51,360 some kind of way to guarantee that if you need to exit from an 351 00:22:51,360 --> 00:22:54,440 optimistic protocol, you need to do a fraud proof, whatever that 352 00:22:54,440 --> 00:22:57,280 that's going to get settled. Whether that means, you know, a 353 00:22:57,280 --> 00:23:00,600 side chain or whether that means some kinds of clever, you know, 354 00:23:00,600 --> 00:23:04,160 like congestion control batching scheme whereby you know, oh, I 355 00:23:04,160 --> 00:23:07,160 have a fraud proof for a very small amount you're sending a 356 00:23:07,160 --> 00:23:10,480 transaction on chain anyway, you can kind of aggregate that into 357 00:23:10,480 --> 00:23:13,600 yours without bearing, you know, much more cost for yourself. 358 00:23:13,600 --> 00:23:16,760 And now I'm getting settled. I think that that that is kind 359 00:23:16,760 --> 00:23:19,960 of a very big high level problem that that something like 360 00:23:19,960 --> 00:23:22,120 covenants is probably the only way to solve. 361 00:23:22,120 --> 00:23:24,680 But you know, I could never say never. 362 00:23:25,600 --> 00:23:28,200 OK, really, really quick before you moon settler. 363 00:23:28,200 --> 00:23:31,960 So what what you're saying Sam, is like if if multiple people. 364 00:23:32,840 --> 00:23:35,920 Have to take something like lightning closure transactions 365 00:23:35,920 --> 00:23:39,440 on chain. Like right now there's no way to 366 00:23:39,440 --> 00:23:44,280 save block space by just combining those, not without 367 00:23:44,320 --> 00:23:47,960 everybody having to be online at the same time and talk to each 368 00:23:47,960 --> 00:23:50,800 other. And if we had a way to combine 369 00:23:50,800 --> 00:23:54,320 those without everyone being online at the same time, like 370 00:23:54,360 --> 00:23:59,240 that would be a huge efficiency gain for 2nd layers that have to 371 00:23:59,240 --> 00:24:01,680 do that. Yeah, it's not even efficiency. 372 00:24:01,680 --> 00:24:04,640 It's just like allowing them to actually be secure like 373 00:24:04,840 --> 00:24:07,600 lightning. Plus like, you know, stuff that 374 00:24:07,600 --> 00:24:11,280 looks like arc, like you look at that, you can just see how that 375 00:24:11,280 --> 00:24:13,880 actually does scale to literal world scale. 376 00:24:14,240 --> 00:24:17,040 The only kind of flying the ointment there is like, well, 377 00:24:17,440 --> 00:24:20,080 you know, what if you would need to do a fraud proof for an 378 00:24:20,080 --> 00:24:22,120 amount that isn't worth the block space? 379 00:24:22,360 --> 00:24:27,120 What if, you know there's some kind of massive attack just 380 00:24:27,120 --> 00:24:30,560 within the rolling window for the being able to do a fraud, 381 00:24:30,560 --> 00:24:38,880 proof these kinds of things. Yeah, I just wanted to add that 382 00:24:39,120 --> 00:24:42,640 I know there are tricks that you can do with check sync from 383 00:24:42,640 --> 00:24:45,880 stack and maybe a lot of people don't even understand what's the 384 00:24:45,880 --> 00:24:48,880 point in signing some random data. 385 00:24:49,520 --> 00:24:53,320 Well, we checked and verified. The obvious answer is that you 386 00:24:53,320 --> 00:24:57,640 can actually. Like sign a CTV template hash 387 00:24:58,040 --> 00:25:02,080 and that means that you can sign a certain output distribution. 388 00:25:03,040 --> 00:25:07,240 And the way I think about this is basically deferred 389 00:25:07,240 --> 00:25:09,720 authorization. So you are giving someone a 390 00:25:09,920 --> 00:25:14,000 deferred authorization to spend, so that may or may not exist 391 00:25:14,000 --> 00:25:15,480 yet. So the best part of that? 392 00:25:16,160 --> 00:25:18,920 Is that you can actually give him an authorization to spend 393 00:25:19,040 --> 00:25:21,880 UTX so that does not exist yet and you don't know the 394 00:25:21,920 --> 00:25:23,720 transaction ID that it will have. 395 00:25:23,920 --> 00:25:26,280 Like this is the absolute best part about it. 396 00:25:26,280 --> 00:25:28,280 You can do that with pre signed transaction. 397 00:25:28,920 --> 00:25:30,800 Basically it's impossible to do that. 398 00:25:31,400 --> 00:25:34,720 But with checks from stack and CTV you can do these 399 00:25:35,080 --> 00:25:38,160 authorizations. By the way, hash locks are a 400 00:25:38,160 --> 00:25:43,000 certain type of these. Deferred authors that are 401 00:25:43,280 --> 00:25:47,840 technically like normal label, but you cannot actually like 402 00:25:47,840 --> 00:25:51,040 rest the outputs. That only works on the input 403 00:25:51,040 --> 00:25:53,440 part. So with the check table, verify 404 00:25:53,440 --> 00:25:57,800 and check from step, you can actually give someone a deferred 405 00:25:57,800 --> 00:26:01,280 authorization to spend a future UTX so that he knows how to 406 00:26:01,280 --> 00:26:04,640 create in a certain way, and you can keep giving him these 407 00:26:04,640 --> 00:26:08,440 authorizations and let him take the one that is the most. 408 00:26:09,160 --> 00:26:14,360 The most beneficial to him. So basically this is the basis 409 00:26:14,360 --> 00:26:17,280 of more interactive channels. You can create lightning 410 00:26:17,280 --> 00:26:20,520 channels and you can show to someone that there is nothing up 411 00:26:20,520 --> 00:26:24,880 your sleeve and you are giving him this authorization and he 412 00:26:24,880 --> 00:26:29,480 will be able to spend it and you can keep giving him like better 413 00:26:29,480 --> 00:26:35,360 versions of it and he can have like a single sig on that. 414 00:26:35,960 --> 00:26:40,320 So in case you have. Like a covenant pool operator 415 00:26:40,440 --> 00:26:43,160 and you have a lot of participants in the covenant 416 00:26:43,160 --> 00:26:48,680 pool and some of them are not responsive, then you can without 417 00:26:49,040 --> 00:26:53,360 taking these virtual Utxos on chain, you can basically just 418 00:26:53,360 --> 00:26:56,760 start giving the pool operator these deferred authorizations 419 00:26:57,600 --> 00:27:04,480 and in return he can basically I don't know how to say it, he can 420 00:27:04,480 --> 00:27:08,640 basically help you get out. Have you spend without the 421 00:27:08,640 --> 00:27:11,680 cooperation of the others? You create an all interaction, 422 00:27:11,680 --> 00:27:14,280 everything and you are able to spend over the lightning 423 00:27:14,280 --> 00:27:17,920 network. And others may come online later 424 00:27:18,080 --> 00:27:23,000 and maybe they update the state or maybe they just, you know, 425 00:27:23,000 --> 00:27:25,800 everyone exits on their own and the new pool is created. 426 00:27:26,040 --> 00:27:28,760 So it gives a lot more flexibility and a lot more the 427 00:27:28,760 --> 00:27:32,640 ability to cover on pool designs that are not. 428 00:27:33,640 --> 00:27:37,600 And don't have this compromise that ARC choose to have with the 429 00:27:37,640 --> 00:27:41,360 time lock sweep. So with the time lock sweep, we 430 00:27:41,360 --> 00:27:45,680 know that technically, as was said before, if if people cannot 431 00:27:45,680 --> 00:27:49,920 enforce their property rights on chain for whatever reason, then 432 00:27:49,920 --> 00:27:54,160 the pool operator is is able to basically steal from people. 433 00:27:54,560 --> 00:28:00,960 And that's kind of the the main downside of the design, but also 434 00:28:00,960 --> 00:28:04,800 what makes it. Sort of work from the ASP's 435 00:28:04,800 --> 00:28:08,240 perspective because he knows he will get his liquidity back in a 436 00:28:08,240 --> 00:28:13,520 certain time frame. And basically this is the 437 00:28:13,520 --> 00:28:16,120 compromise that you don't necessarily have to make if you 438 00:28:16,120 --> 00:28:18,680 have checks from stack and you can do these deferred 439 00:28:18,680 --> 00:28:23,240 authorizations for specific settlements, because then you 440 00:28:23,240 --> 00:28:25,880 can. Like I said, create lighting 441 00:28:25,880 --> 00:28:28,960 channels that never existed because once you spend them you 442 00:28:28,960 --> 00:28:32,680 can just give the give your private key the pool operator 443 00:28:32,680 --> 00:28:36,560 basically give up your private key and he can compose the the 444 00:28:37,320 --> 00:28:41,080 settlement chain at the higher level, even even maybe back to 445 00:28:41,080 --> 00:28:45,960 the route if everyone just exits the pool 1 by 1 unilaterally 446 00:28:46,080 --> 00:28:49,480 they I mean the help of the operator, they just exit. 447 00:28:50,360 --> 00:28:53,480 Then basically the pool operator, we have all the 448 00:28:53,480 --> 00:28:59,040 private keys for the large end of music, for example the keypad 449 00:28:59,120 --> 00:29:03,720 on the taproot output. And then he can just take the 450 00:29:03,720 --> 00:29:06,280 whole thing very very very efficiently. 451 00:29:06,400 --> 00:29:11,440 So this whole idea that the CTV settlementary has to be unfolded 452 00:29:11,440 --> 00:29:14,840 on chain just goes away. And I think that's a very 453 00:29:14,840 --> 00:29:18,480 powerful thing and we should definitely coincidental and talk 454 00:29:18,480 --> 00:29:23,840 about that because I don't think the downsides that are imagined 455 00:29:24,360 --> 00:29:30,240 justify being overly careful around check signal phone stick. 456 00:29:31,000 --> 00:29:37,520 OK, so I'm try my best to succinctly put that so the one 457 00:29:37,520 --> 00:29:43,440 of the problems at least is. Something like a a lightning 458 00:29:43,440 --> 00:29:48,720 channel, like you are just spending as you unfurl things 459 00:29:49,560 --> 00:29:54,120 like previous transactions. And so with SegWit, like the 460 00:29:54,120 --> 00:29:58,480 transaction malleability is not a problem in the sense that 461 00:29:58,480 --> 00:30:03,440 somebody else can just see your transaction and change it and 462 00:30:03,440 --> 00:30:07,640 then break future transaction spending from that, but the 463 00:30:07,640 --> 00:30:12,320 participants still can't. Like if if somebody involved in 464 00:30:12,320 --> 00:30:18,080 the channel adds a new input to pay fees because the fees were 465 00:30:18,080 --> 00:30:23,080 too low and it's not confirming that changes the transaction ID 466 00:30:23,400 --> 00:30:26,640 which breaks anything spending from it in future. 467 00:30:26,640 --> 00:30:31,000 So it's really difficult to have more than one or two hops 468 00:30:31,000 --> 00:30:35,000 involved there. The the other issue you kind of 469 00:30:35,000 --> 00:30:39,240 wanted to. Is the cost of actually taking 470 00:30:39,240 --> 00:30:44,000 that data and unfurling it on chain and kind of the solution 471 00:30:44,000 --> 00:30:47,520 that you were getting at is where you can apply a signature 472 00:30:47,520 --> 00:30:52,240 to any arbitrary data that allows you to change the 473 00:30:52,240 --> 00:30:57,800 spending conditions of a coin without actually spending that 474 00:30:57,800 --> 00:31:02,240 coin. So if there is a UTXOI can make 475 00:31:02,240 --> 00:31:07,440 a script that just says. Use check sig from stack and 476 00:31:07,440 --> 00:31:13,440 check against this key and then I can actually just add any 477 00:31:13,440 --> 00:31:16,600 script to that later after the fact. 478 00:31:17,200 --> 00:31:21,040 And as long as I sign that script with that key, What 479 00:31:21,040 --> 00:31:25,040 somebody can do is then put the script with the signature on it 480 00:31:25,040 --> 00:31:30,040 on the stack it will verify against the public key that's 481 00:31:30,080 --> 00:31:34,920 actually in the UTXO script. And then this whole new script 482 00:31:34,920 --> 00:31:40,640 that was never part of that UTXO that gets checked and as long as 483 00:31:40,640 --> 00:31:46,240 that pass is valid you, you can just keep adding new ways to 484 00:31:46,240 --> 00:31:49,440 spend a coin without ever actually moving that coin. 485 00:31:49,920 --> 00:31:53,160 And so that adds a lot of flexibility to what you can do 486 00:31:53,160 --> 00:31:55,720 off chain. I get that right? 487 00:31:56,760 --> 00:31:58,920 Yes. Although in my example and with 488 00:31:58,920 --> 00:32:04,760 CTV, I don't think you can just only add like new distributions, 489 00:32:05,200 --> 00:32:07,520 so you can keep updating the distributions. 490 00:32:07,520 --> 00:32:10,880 Someone can imagine that if Lightning China can only go from 491 00:32:11,520 --> 00:32:15,760 Alice to Bob and never backwards, then Alice can just 492 00:32:15,760 --> 00:32:20,520 give updated signatures to Bob with new and new templates for 493 00:32:20,520 --> 00:32:24,240 Checked Amplify that changes the distribution between them 494 00:32:24,240 --> 00:32:29,120 towards Bob. And Bob has to do nothing else 495 00:32:29,160 --> 00:32:34,480 but sign a transaction that that spends this with the one that is 496 00:32:34,480 --> 00:32:37,920 most beneficial to him. So Alice does not really have a 497 00:32:37,920 --> 00:32:43,440 way to screw Bob over in in this setup, and Bob has no way to 498 00:32:43,440 --> 00:32:47,520 steal from Alice any amount that she did not forfeit to him. 499 00:32:48,480 --> 00:32:52,280 So the whole thing is perfectly fair and secure. 500 00:32:53,040 --> 00:32:55,720 And basically, Bob only has that. 501 00:32:55,720 --> 00:32:59,480 Maybe he loses the best state that he had, but that is a 502 00:32:59,480 --> 00:33:04,120 technical problem that is solvable, and it's not something 503 00:33:04,120 --> 00:33:07,480 that Lightning does not suffer from and whatnot. 504 00:33:08,240 --> 00:33:11,520 So this is what's called non interactive channel. 505 00:33:11,520 --> 00:33:14,800 And the best way is that Alice can open this non interactive 506 00:33:14,800 --> 00:33:17,360 channel without even cooperating with Bob. 507 00:33:17,440 --> 00:33:20,920 So she can just open it and show everything to Bob and Bob can 508 00:33:20,920 --> 00:33:23,760 verify that this is indeed a proper non interactive channel. 509 00:33:24,800 --> 00:33:29,080 And this can happen like in a way where this channel is 510 00:33:29,080 --> 00:33:35,680 created at the end of a long tail of CTV transactions and. 511 00:33:36,600 --> 00:33:40,560 So that that's kind of the way to think about in in this regard 512 00:33:40,560 --> 00:33:44,240 that it just gives you a delayed authorization, A deferred 513 00:33:44,280 --> 00:33:48,560 authorization to spend otherwise and that opens up a lot of 514 00:33:48,560 --> 00:33:52,360 possibilities on how to how to proceed or how to compose these 515 00:33:52,360 --> 00:33:59,480 things. I guess Robin or super, do you 516 00:33:59,480 --> 00:34:03,680 either of you have any like concrete problem or limitation? 517 00:34:04,000 --> 00:34:07,160 With something existing now that would be solved with covenants. 518 00:34:08,320 --> 00:34:11,880 Yeah, if I should speak for bit VM, like there is that setup 519 00:34:11,880 --> 00:34:15,760 phase where you have to set up the transactions that you can 520 00:34:15,760 --> 00:34:21,679 execute in case there's fraud and yeah, or like the 521 00:34:21,679 --> 00:34:25,040 transactions that you can execute as as to perform the 522 00:34:25,040 --> 00:34:29,000 fraud proof and currently you have to set them up 523 00:34:29,000 --> 00:34:32,400 interactively. And in particular in that multi 524 00:34:32,400 --> 00:34:34,760 verifier setting where you have like a single prover 525 00:34:34,760 --> 00:34:38,080 facilitating a bridge for example and lots of verifiers 526 00:34:38,080 --> 00:34:43,120 verifying them. In that setting, every verifier 527 00:34:43,120 --> 00:34:47,320 has to verify the setup of every other verifier, and of course 528 00:34:47,320 --> 00:34:51,040 that's case pulley and if we had covenants, if we had CTV for 529 00:34:51,040 --> 00:34:55,560 example, the the prover could set it up and it could set it up 530 00:34:55,560 --> 00:35:03,360 for everyone non interactively. And OK I I'm confusing myself 531 00:35:03,360 --> 00:35:07,320 here they still everybody has to verify the setup of everybody 532 00:35:07,320 --> 00:35:10,760 else but they don't have to Co sign the setup of everybody else 533 00:35:11,080 --> 00:35:13,640 without covenants. You you have to Co you have to 534 00:35:13,640 --> 00:35:18,000 pre sign the the sequence of transactions and in the multi 535 00:35:18,000 --> 00:35:23,480 verifier setting every verifier has to Co sign the pre sign 536 00:35:23,480 --> 00:35:27,280 transactions of every other verifier and that's gates very 537 00:35:27,280 --> 00:35:30,200 poorly. They still have to verify the 538 00:35:30,200 --> 00:35:35,080 setup of each of all other verifiers, but yeah then you can 539 00:35:35,200 --> 00:35:40,680 essentially compress all of that into a ZKP and then it becomes 540 00:35:41,360 --> 00:35:44,120 no problem to verify the setup of the other verifiers. 541 00:35:44,520 --> 00:35:50,280 So the the the the essential part that you can get rid of is 542 00:35:50,280 --> 00:35:53,760 the pre signing and I think there are many protocols where 543 00:35:54,040 --> 00:35:58,760 you have like. Yeah, lots of things that could 544 00:35:58,760 --> 00:36:03,360 happen and you have to pre sign them all and if you had some 545 00:36:03,360 --> 00:36:06,600 kind of covenants, then yeah, you could get rid of this pre 546 00:36:06,600 --> 00:36:09,000 signing and just replace it with them some. 547 00:36:10,040 --> 00:36:12,240 Yeah, some template. All right. 548 00:36:12,240 --> 00:36:16,160 And the. VM real quick is is far beyond 549 00:36:16,160 --> 00:36:20,000 the scope of this, so there there's an article I claim 550 00:36:20,000 --> 00:36:23,320 magazine to read about that, but the gist of what you're saying 551 00:36:23,320 --> 00:36:27,920 is in context. Bit VM requires like potentially 552 00:36:27,920 --> 00:36:33,240 millions or billions of of pre signed transactions to be made 553 00:36:33,760 --> 00:36:38,800 and So what you can do is cut out like the back and forth part 554 00:36:38,800 --> 00:36:40,680 of that. Like you still have to make 555 00:36:40,680 --> 00:36:45,440 them, but instead of each step involving going back and forth 556 00:36:45,480 --> 00:36:48,920 between everyone involved, like somebody can just make them all 557 00:36:48,920 --> 00:36:53,440 at once, Send them all at once. And the other people can verify 558 00:36:53,440 --> 00:36:56,720 them all at once instead of all the back and forth between 559 00:36:56,720 --> 00:36:58,480 everybody. Yeah exactly. 560 00:36:59,320 --> 00:37:01,760 And that is very similar to the problem that they have at ARC. 561 00:37:02,040 --> 00:37:04,920 Like in ARC you also have that problem that yeah you have that 562 00:37:04,920 --> 00:37:08,760 non cooperative case and in that non cooperative case you have 563 00:37:08,880 --> 00:37:13,560 these exit trees and people have to pre sign them all together 564 00:37:13,560 --> 00:37:15,480 for these exit trees to be trustless. 565 00:37:16,160 --> 00:37:19,520 And yeah, you can get rid of that with CTV. 566 00:37:19,800 --> 00:37:23,080 And I wanted to say that I think in general, of all the proposals 567 00:37:23,080 --> 00:37:28,720 that are currently discussed, I would say CTV is the most simple 568 00:37:28,720 --> 00:37:33,600 proposal that enables the most powerful things next to OPCAT, 569 00:37:33,600 --> 00:37:36,640 of course, but. Yes, opcat definitely takes. 570 00:37:37,640 --> 00:37:40,480 But like of the of the of the proposals where everybody is 571 00:37:40,480 --> 00:37:42,600 like, yeah, this, this is very simple. 572 00:37:43,440 --> 00:37:45,880 And that has no side effects at all that. 573 00:37:46,280 --> 00:37:49,200 Yeah, you. Have to, you have to say that it 574 00:37:49,200 --> 00:37:52,240 is also the the least risky, right? 575 00:37:52,680 --> 00:37:55,880 So if you say, oh, you lost Robin. 576 00:37:56,160 --> 00:38:03,640 So if if if you say that CTV is basically the best risk benefit 577 00:38:04,640 --> 00:38:08,800 move that we can make at this point in Bitcoin's history, then 578 00:38:08,800 --> 00:38:12,160 I don't think anyone is able to argue with that on a technical 579 00:38:12,160 --> 00:38:15,760 level. And when we are talking about 580 00:38:15,760 --> 00:38:18,760 the simplest that's most powerful, then to my knowledge 581 00:38:18,760 --> 00:38:22,360 that is of CED because it's like 10 lines of code and it enables 582 00:38:22,440 --> 00:38:26,360 like almost everything. Oh yes, super. 583 00:38:26,440 --> 00:38:30,480 Did you have any, like, specific problems in mind we haven't gone 584 00:38:30,480 --> 00:38:33,920 over already? That would be drastically easier 585 00:38:33,920 --> 00:38:36,080 to solve if we had some form of covenant. 586 00:38:37,000 --> 00:38:40,560 Yeah, lightning, lightning, the lighting network could benefit 587 00:38:40,560 --> 00:38:43,680 from covenants as well. One of the things that you have 588 00:38:43,680 --> 00:38:47,360 to do in the Lightning Network is save a lot of state, which 589 00:38:47,360 --> 00:38:49,960 is, which has to do with the fact that you're in a 590 00:38:49,960 --> 00:38:52,080 relationship with someone on the Lightning Network. 591 00:38:52,080 --> 00:38:55,000 You you always have a channel partner, someone who you open to 592 00:38:55,000 --> 00:38:57,000 Channel 2 or who opened a channel to you. 593 00:38:57,760 --> 00:39:01,160 And every time you make a payment on Lightning, you're 594 00:39:01,160 --> 00:39:03,520 creating a new Bitcoin transaction and you're 595 00:39:03,520 --> 00:39:05,240 revealing. You're typically revealing 596 00:39:05,240 --> 00:39:07,800 something called a revocation key for the previous state. 597 00:39:08,560 --> 00:39:11,120 So every time you make one of these Lightning payment you have 598 00:39:11,120 --> 00:39:15,200 to store. The old, every old transaction 599 00:39:15,360 --> 00:39:19,560 of every old state in your in your channel as well as the 600 00:39:19,560 --> 00:39:22,560 revocation key given by your counterparty or that you gave. 601 00:39:23,560 --> 00:39:26,200 And that's a lot of data to store it, especially for routing 602 00:39:26,200 --> 00:39:28,800 nodes, it really adds up sometimes they have, you know 603 00:39:28,800 --> 00:39:31,840 gigabytes of of data that they have to store. 604 00:39:32,400 --> 00:39:35,480 But if we had covenants, we could make it a constant size. 605 00:39:35,480 --> 00:39:38,320 We could make it like, you know, you only have to store one MB of 606 00:39:38,320 --> 00:39:40,840 data. And and then ever like it 607 00:39:40,960 --> 00:39:44,600 increases after that. So that's another area where I 608 00:39:44,600 --> 00:39:48,640 think that you could make it a lot less intrusive or or less 609 00:39:48,640 --> 00:39:50,720 difficult to run a lightning node. 610 00:39:51,560 --> 00:39:54,400 You could make the software a lot simpler in the database, a 611 00:39:54,400 --> 00:39:58,520 lot smaller if we had covenants. I think, I think that's an 612 00:39:58,520 --> 00:40:01,200 interesting, an interesting point to kind of discuss like 613 00:40:01,200 --> 00:40:04,480 the difference of you know, I would say you know it's it's a, 614 00:40:04,560 --> 00:40:06,480 it's a. Basically a fact that there's 615 00:40:06,480 --> 00:40:09,720 more funding and broad support for you know, development and 616 00:40:09,720 --> 00:40:13,600 advancement with Lightning and you know even I guess at this 617 00:40:13,600 --> 00:40:16,680 point even like tokens on Bitcoin but like not necessarily 618 00:40:16,680 --> 00:40:21,680 for covenant support that's that's not as much of A of a, 619 00:40:22,400 --> 00:40:25,320 you know, mass saturated thought. 620 00:40:25,760 --> 00:40:29,560 So I'm kind of curious to you guys like what, what is kind of 621 00:40:29,560 --> 00:40:33,000 missing you know based on these you know kind of solutions that 622 00:40:33,000 --> 00:40:35,560 covenants can provide to these issues you guys just brought up 623 00:40:35,760 --> 00:40:38,400 especially with some of them like Lightning being you know 624 00:40:38,400 --> 00:40:42,960 having a big application to you know presumably the next billion 625 00:40:42,960 --> 00:40:45,000 users. You know what, what is the 626 00:40:45,000 --> 00:40:47,200 missing? What kind of element of of 627 00:40:47,200 --> 00:40:50,840 education and the communications that we can give to the masses 628 00:40:50,960 --> 00:40:55,960 like for why this is important and why they should care and and 629 00:40:55,960 --> 00:40:58,400 be supportive of, you know, whatever their iteration of 630 00:40:58,400 --> 00:41:00,720 covenant that that, that, that they want like what? 631 00:41:00,720 --> 00:41:04,440 What is kind of missing to get that sort of mass acceptance? 632 00:41:05,440 --> 00:41:08,600 Yeah, one thing that is worth noting is that the lightning 633 00:41:08,600 --> 00:41:14,200 network works like even without the lens symmetry it it just 634 00:41:14,200 --> 00:41:18,560 works. And with splicing temperatures 635 00:41:18,560 --> 00:41:23,200 and splicing you going to get a free pruning of your channel 636 00:41:23,200 --> 00:41:26,560 state anyhow. So I don't think professional 637 00:41:26,560 --> 00:41:29,560 nodes we have any problem with this whatsoever. 638 00:41:30,520 --> 00:41:36,760 So the main benefit to Allen's symmetry is US super said it is 639 00:41:36,760 --> 00:41:40,760 going to possibly make the lightning developers job a lot 640 00:41:40,760 --> 00:41:43,000 easier. They can make simpler and more 641 00:41:43,000 --> 00:41:46,720 robust nodes. So that's like the main benefit. 642 00:41:47,200 --> 00:41:50,400 That benefit to the users is going to be basically non 643 00:41:50,400 --> 00:41:54,840 existent As for a second. So LS symmetry does not actually 644 00:41:55,280 --> 00:41:57,600 deliver anything to the billions directly. 645 00:41:58,480 --> 00:42:02,400 What actually is something that covenants can help us with is 646 00:42:02,400 --> 00:42:05,880 that the Lightning network is severely limited in the number 647 00:42:05,880 --> 00:42:11,920 of participants with the Avon throughput the block space that 648 00:42:11,920 --> 00:42:17,640 is available for us. And that is the big point where 649 00:42:17,760 --> 00:42:20,560 all these covenant pools and channel factories and. 650 00:42:21,600 --> 00:42:24,640 Not even sure why we are calling them in different news because 651 00:42:25,080 --> 00:42:27,920 it pretty much looks like that any channel factory will be 652 00:42:27,920 --> 00:42:32,000 somewhat of a covenant pool and every covenant pool will be like 653 00:42:33,080 --> 00:42:36,680 a channel factory on demand or or opportunistically or 654 00:42:36,680 --> 00:42:39,840 whatever. So I I kind of think the two 655 00:42:40,000 --> 00:42:43,960 concepts are are going to. Like converge into a hybrid 656 00:42:44,640 --> 00:42:49,000 thing and and that is like where we see a very clear need of 657 00:42:49,000 --> 00:42:51,480 covenants for for for that to work. 658 00:42:52,560 --> 00:42:56,640 OK so So what you're you're saying is like just we we we 659 00:42:56,640 --> 00:43:02,400 kind of need to stay ahead of like keeping the limitations of 660 00:43:02,400 --> 00:43:06,840 lightning in mind so that like the the small changes and 661 00:43:06,840 --> 00:43:10,120 optimizations we can make right now without. 662 00:43:10,520 --> 00:43:13,920 Like forking or adding anything to Bitcoin that just give us a 663 00:43:13,920 --> 00:43:18,200 little more breathing room. Don't come across like they're 664 00:43:18,200 --> 00:43:21,520 fundamentally solving the issue to the same degree. 665 00:43:22,440 --> 00:43:28,240 Yes, and and and the like. There is another point that you 666 00:43:28,240 --> 00:43:33,920 could make about all this I guess is that you know the pay, 667 00:43:33,920 --> 00:43:38,360 Polish and and SMTP vacation of the lightning network. 668 00:43:38,760 --> 00:43:42,040 It's something that we are seeing in real time happening 669 00:43:42,960 --> 00:43:46,280 and that's not the vision that originally. 670 00:43:46,360 --> 00:43:50,360 Really quick, Can you just, like, explain what that means 671 00:43:50,360 --> 00:43:53,760 for people who maybe don't know the history of both of those 672 00:43:53,760 --> 00:43:58,760 protocols? Yeah, so lightning was 673 00:43:59,080 --> 00:44:03,760 envisioned like that anyone can run a server and connect to this 674 00:44:03,760 --> 00:44:07,720 network and it will be a lot more mesh like and less. 675 00:44:08,480 --> 00:44:14,120 Providers like Skype, PayPal, Google, whatever. 676 00:44:14,120 --> 00:44:18,280 So these giant providers operating with each other in a 677 00:44:18,400 --> 00:44:20,640 more closed, more permission network. 678 00:44:20,640 --> 00:44:24,760 How the SMPP protocol turned out and basically turned the whole 679 00:44:24,760 --> 00:44:27,720 thing into a hub and spoke model that you are. 680 00:44:28,360 --> 00:44:32,720 Completely exposed to your hub you have no privacy against your 681 00:44:32,720 --> 00:44:36,000 hub because they see everything they report to chain on all and 682 00:44:36,000 --> 00:44:40,480 things that you do anyhow and to each other and and basically we 683 00:44:40,480 --> 00:44:44,080 can we can get into this this state with the Lightning 684 00:44:44,080 --> 00:44:45,800 Network. There is a very, very strong 685 00:44:45,800 --> 00:44:49,920 much of A tendency for, for centralization, for for, you 686 00:44:49,920 --> 00:44:55,680 know, the optimization of this whole thing and so. 687 00:44:56,880 --> 00:45:02,120 That is kind of where I see like a big danger because you know 688 00:45:02,120 --> 00:45:05,840 that especially custodial lightning in this set rise form 689 00:45:05,840 --> 00:45:11,200 we are scared to billions. But that is not the network that 690 00:45:11,400 --> 00:45:14,400 one can say it's a peer-to-peer network or anything. 691 00:45:14,760 --> 00:45:18,680 So that's why I say the pay qualification and SMTP 692 00:45:18,680 --> 00:45:23,400 ification, because the SMTP protocol started out a lot more 693 00:45:23,400 --> 00:45:26,160 peer-to-peer. But eventually with the spam and 694 00:45:26,160 --> 00:45:31,000 these giant providers, you know, trying to combat it, it became 695 00:45:31,000 --> 00:45:34,720 something where you can't really have your own SMTP server 696 00:45:34,720 --> 00:45:38,440 anymore and and have people be able to send you emails or 697 00:45:38,440 --> 00:45:41,000 you'll be able to send anyone emails. 698 00:45:41,000 --> 00:45:44,120 You know you have to have an account with one of the large 699 00:45:44,120 --> 00:45:48,360 providers and it has become very permission and you are very 700 00:45:48,360 --> 00:45:53,120 easily denied access to this. This protocol, so to speak, in 701 00:45:53,120 --> 00:45:56,240 practice, even though in theory anyone could run the software 702 00:45:56,240 --> 00:45:58,800 right, but it just doesn't doesn't actually work. 703 00:45:58,800 --> 00:46:01,920 You won't be able to send an e-mail to someone else like 704 00:46:01,920 --> 00:46:07,800 that. Well, I guess I'm going to take 705 00:46:07,800 --> 00:46:11,120 the spotlight for a second and jump in with a big problem I 706 00:46:11,120 --> 00:46:13,760 see, because I think it relates to that pretty well. 707 00:46:15,560 --> 00:46:19,160 You know, the more we look at lightning as it is now, like 708 00:46:19,160 --> 00:46:24,360 Moon said, it keeps. Gravitating towards big central 709 00:46:24,360 --> 00:46:30,320 nodes like a lightning service provider, and honestly a lot of 710 00:46:30,320 --> 00:46:36,200 the most practical basic types of coin pools or channel 711 00:46:36,200 --> 00:46:40,960 factories that there are very concrete designs for that we 712 00:46:40,960 --> 00:46:47,480 could do if we had covenants actually kind of lean into that 713 00:46:47,480 --> 00:46:50,200 dependence on something like an LSP. 714 00:46:50,560 --> 00:46:54,680 Like they're explicitly designed around counting on that. 715 00:46:54,680 --> 00:46:59,440 And I think one of the big problems that that has caused 716 00:46:59,440 --> 00:47:06,040 that is the problem of how do you exit from something like an 717 00:47:06,040 --> 00:47:09,440 off chain channel that has more than two people involved. 718 00:47:09,920 --> 00:47:14,680 Because the general way that's done is just a long series of 719 00:47:14,680 --> 00:47:18,360 transactions where one UTXO breaks into two. 720 00:47:19,000 --> 00:47:22,720 And each of those break into two and each of those break into two 721 00:47:23,080 --> 00:47:27,560 until eventually the UTXO is on chain are actually somebody's 722 00:47:27,560 --> 00:47:31,600 lightning channels. And you have to go through all 723 00:47:31,600 --> 00:47:35,560 of those steps in between to get to somebody's lightning channel 724 00:47:35,600 --> 00:47:38,720 going on. Well, like there are covenant 725 00:47:38,720 --> 00:47:44,400 proposals like tap, tap, weave, update, Verify T Love building 726 00:47:44,400 --> 00:47:48,400 on top of Taproot that offer a more efficient way to do that. 727 00:47:49,160 --> 00:47:54,600 Where you actually have in like the Tap Leaf script, some script 728 00:47:54,600 --> 00:48:00,240 that enforces that in one transaction, even if there's a 729 00:48:00,240 --> 00:48:07,160 hundred people or 1000 people in in this UTXO, one transaction 730 00:48:07,160 --> 00:48:12,040 enforces that you are allowed to take whatever money you own in 731 00:48:12,040 --> 00:48:16,520 the current state and spend it wherever you want everybody 732 00:48:16,520 --> 00:48:20,560 else's money. Has to go back into a specific 733 00:48:20,560 --> 00:48:27,440 output with a specific script, which is that like taproot multi 734 00:48:27,440 --> 00:48:32,160 sig with everybody involved minus just your key. 735 00:48:32,920 --> 00:48:35,120 And it actually enforces all of that. 736 00:48:35,760 --> 00:48:39,040 It actually checks the tap leaf, it looks at the amounts in 737 00:48:39,040 --> 00:48:42,320 there, it makes sure the right amount goes back to the script 738 00:48:42,320 --> 00:48:46,520 with everybody else's money and it actually verifies that the 739 00:48:46,520 --> 00:48:52,120 public key for that output is the pre-existing like taproot 740 00:48:52,120 --> 00:48:56,080 multi sig just minus the key of the guy who left. 741 00:48:57,000 --> 00:49:02,200 And so it can take that whole chain of of a shit ton of 742 00:49:02,200 --> 00:49:05,000 transactions that has to unfurl on chain. 743 00:49:05,680 --> 00:49:11,440 And turns it into just one transaction and that capability 744 00:49:12,320 --> 00:49:18,040 is exactly what we need to build multi party channels like that 745 00:49:18,040 --> 00:49:23,440 that don't require being built around like some service 746 00:49:23,440 --> 00:49:28,760 provider and like those designs they're they're not trusted. 747 00:49:29,240 --> 00:49:32,440 You still can't enforce things without that provider 748 00:49:32,440 --> 00:49:35,520 cooperating. But the whole design is still 749 00:49:35,520 --> 00:49:38,640 built around them. Whereas if we had a covenant 750 00:49:38,640 --> 00:49:42,800 that would just let anybody in a single transaction pull their 751 00:49:42,800 --> 00:49:46,720 money out and leave everyone else to do whatever they want. 752 00:49:47,000 --> 00:49:53,040 Or the opposite allowed everybody to kick out the one 753 00:49:53,040 --> 00:49:58,040 guy who won't get online to sign stuff in one transaction and 754 00:49:58,040 --> 00:50:02,960 everyone else goes on with their day and like that type of 755 00:50:02,960 --> 00:50:07,480 functionality? Is something necessary to do 756 00:50:07,960 --> 00:50:11,840 things like coin pools or channel factories in a way that 757 00:50:11,840 --> 00:50:16,680 doesn't revolve around some like service provider that is 758 00:50:16,680 --> 00:50:21,880 necessary to make it all work? I think it's it's it's worth 759 00:50:22,120 --> 00:50:27,160 mentioning that everyone that dug into this problem space 760 00:50:27,160 --> 00:50:30,880 knows that the the denial of service. 761 00:50:32,200 --> 00:50:39,560 Potential for for any any multi sequel is going to go very hard 762 00:50:39,560 --> 00:50:43,120 up with the number of participants and not necessarily 763 00:50:43,120 --> 00:50:44,880 intentional. So like like the sheer 764 00:50:44,880 --> 00:50:49,360 possibility for an error for someone to to to suffer no error 765 00:50:49,360 --> 00:50:55,160 is just going to go up hard after a certain point, so. 766 00:50:55,920 --> 00:50:59,520 Basically kicking someone out without stealing their money, so 767 00:50:59,520 --> 00:51:03,000 enforcing that property right just putting them out of the 768 00:51:03,280 --> 00:51:07,520 pool is something pretty fundamental that should be 769 00:51:07,520 --> 00:51:10,880 taught about, and ARC is actually sidestepping this whole 770 00:51:10,880 --> 00:51:14,480 issue. So with there if if you like 771 00:51:14,480 --> 00:51:18,720 experience no other wallet failure then the mean the the 772 00:51:19,680 --> 00:51:23,040 ARC service provider we are simply sweep your virtual Utah 773 00:51:23,480 --> 00:51:26,880 and that's basically is going to turn them into IOU's. 774 00:51:26,920 --> 00:51:31,200 So either he honors your claim, then you can, can, you know, 775 00:51:31,200 --> 00:51:35,200 show your keys and prove your keys to those virtual Utah 776 00:51:35,200 --> 00:51:38,880 excessively, either under them or not that that's up to him at 777 00:51:38,880 --> 00:51:45,400 the point if they are stopped. So yes, this is a very big 778 00:51:45,400 --> 00:51:49,160 problem. And the other issue is that when 779 00:51:49,160 --> 00:51:53,200 you just imagine this scaled up to like billions of people, 780 00:51:53,200 --> 00:51:57,840 let's not say 8 billion people, because I think it would be more 781 00:51:57,840 --> 00:52:01,160 than enough if every household had an old or something like 782 00:52:01,160 --> 00:52:03,880 that. So we shouldn't go beyond like 3 783 00:52:03,880 --> 00:52:07,160 billion or something like that in our imaginings? 784 00:52:08,040 --> 00:52:11,400 So if you imagine that like 3 billion nodes are trying to do 785 00:52:11,400 --> 00:52:16,320 these this cooperative pools, the mod still does not work out 786 00:52:16,520 --> 00:52:21,800 for even very optimistic on chain settlement if if these 787 00:52:22,120 --> 00:52:24,800 these unilateral exits like keep happening. 788 00:52:25,760 --> 00:52:30,400 I just wanted to know that. So I don't think that schemes 789 00:52:30,400 --> 00:52:34,000 that are trying to enforce cooperation like they they are 790 00:52:34,000 --> 00:52:38,080 forcing people to cooperate. Are not necessarily garbage. 791 00:52:38,600 --> 00:52:44,120 I think they should be explored because that that kind of has 792 00:52:44,120 --> 00:52:47,120 this benefit that if people are are are kind of forced to 793 00:52:47,120 --> 00:52:53,080 cooperate, then then they will, you know, they will find a way 794 00:52:53,520 --> 00:52:56,160 to make it more efficient because it's actually in 795 00:52:56,160 --> 00:52:59,360 everyone's interest to to have a more efficient settlement so 796 00:52:59,360 --> 00:53:03,120 long nobody can steal from the other, you know, That's just my 797 00:53:03,120 --> 00:53:07,120 thought on this. And Sam, it looked like you had 798 00:53:07,120 --> 00:53:09,520 something to say. Yeah, well this is. 799 00:53:09,520 --> 00:53:11,160 We've talked about this before, but this is the reason why I 800 00:53:11,160 --> 00:53:18,840 love ARC is it It doesn't have the the the data availability 801 00:53:19,160 --> 00:53:25,600 problems that basically all other forms of like UTXO multi 802 00:53:25,600 --> 00:53:29,920 sig aggregation schemes have, which is like they're always 803 00:53:29,920 --> 00:53:33,320 some version of. Hey guys, I'm going to aggregate 804 00:53:33,360 --> 00:53:36,200 all of your UTXOS into some Merkel, something that looks 805 00:53:36,200 --> 00:53:41,400 like a Merkel tree on chain. I'm going to publish the route. 806 00:53:42,000 --> 00:53:46,840 But what if you give me your your UTXO and I don't give you 807 00:53:46,840 --> 00:53:49,680 your inclusion proof from your TXO to the root? 808 00:53:50,120 --> 00:53:54,680 I can't steal your coins, but I've kind of burned them if I 809 00:53:54,680 --> 00:53:56,960 don't give that to you. And I can certainly hold them 810 00:53:56,960 --> 00:53:58,760 hostage for, like, you know, some. 811 00:53:59,680 --> 00:54:03,480 You know, like 30% of their value or or something like that. 812 00:54:03,720 --> 00:54:06,960 Unless you get really clever. And the ways in which you can 813 00:54:06,960 --> 00:54:12,080 get really clever are you can have like massive interaction 814 00:54:12,080 --> 00:54:17,560 schemes that scale extremely poorly, like n ^2 in the number 815 00:54:17,560 --> 00:54:21,120 of participants, or you can have something like a side chain. 816 00:54:21,600 --> 00:54:25,520 Where you know you're posting your UTXOS on the side chain and 817 00:54:25,520 --> 00:54:28,720 they're Merkel eyes up to the root that goes on the L1 kind of 818 00:54:28,720 --> 00:54:32,000 from that side chain. And so everyone can compute 819 00:54:32,000 --> 00:54:35,160 their own inclusion proof from the data available on that side 820 00:54:35,160 --> 00:54:37,600 chain. This is kind of the main reason 821 00:54:37,600 --> 00:54:40,640 why I've slowly become a side chain apologist is I don't see a 822 00:54:40,640 --> 00:54:42,880 better solution to that particular problem than this. 823 00:54:43,480 --> 00:54:46,120 But the thing that kind of gives me pause as to whether that's 824 00:54:46,120 --> 00:54:50,760 100% necessary is ARC. The way that arc works, it 825 00:54:50,760 --> 00:54:58,360 sidesteps that because of what you just said Moon, that the the 826 00:54:58,360 --> 00:55:01,400 way the interaction there works, it's it's like eeny meeny miney 827 00:55:01,400 --> 00:55:04,280 MO. And rather than the MO landing 828 00:55:04,280 --> 00:55:07,960 on the like the authority and like now they're the one that 829 00:55:07,960 --> 00:55:12,040 gets to go to chain. The MO ends in the user and it's 830 00:55:12,040 --> 00:55:15,960 like the the thing goes through. Atomic with the user's final 831 00:55:15,960 --> 00:55:19,800 action, not with the, the service provider. 832 00:55:19,800 --> 00:55:23,440 And so you don't have this kind of, you know, OK you're you're 833 00:55:23,440 --> 00:55:26,800 the final executor now please give me my witness because 834 00:55:26,800 --> 00:55:28,480 you're the one that's kind of generating that with that 835 00:55:28,480 --> 00:55:33,760 clinical witness yourself. So yeah, if if we can figure out 836 00:55:33,760 --> 00:55:37,240 a way of kind of having a cake and eating it too in that 837 00:55:37,240 --> 00:55:40,120 regard. Even with things like like T 838 00:55:40,120 --> 00:55:42,720 love, I think still requires solving this problem. 839 00:55:43,480 --> 00:55:48,800 That would be cool. I guess what, sorry, but welcome 840 00:55:48,800 --> 00:55:54,120 Trevor, might be a little out of stuff, but I guess just to try 841 00:55:54,120 --> 00:55:58,360 and catch you up real quick, we kind of for the first bit just 842 00:55:58,360 --> 00:56:01,480 went through the nature of covenants and the difference 843 00:56:01,480 --> 00:56:06,520 between restricting the spending conditions of future coins 844 00:56:06,520 --> 00:56:10,040 versus ones that exist. And we've kind of just been 845 00:56:10,040 --> 00:56:15,160 going through like specific scalability problems with things 846 00:56:15,160 --> 00:56:18,800 like lightning or side chains and other layers that covenants 847 00:56:18,800 --> 00:56:21,640 would help. So I don't know if you if you 848 00:56:21,640 --> 00:56:24,520 have any thoughts on that matter and I guess if we've gone 849 00:56:24,520 --> 00:56:26,760 through it, I'll let you know. Yeah. 850 00:56:26,760 --> 00:56:28,200 No, I I definitely have some thoughts on it. 851 00:56:28,200 --> 00:56:34,200 I mean, I think, I think that covenants to me seem like a type 852 00:56:34,240 --> 00:56:39,760 of protocol change that. Is one that if you don't use it 853 00:56:39,760 --> 00:56:44,720 it, it won't really affect you. I think you know we always 854 00:56:44,720 --> 00:56:48,960 struggle with like these changes to Bitcoin because as opposed to 855 00:56:48,960 --> 00:56:50,640 like normal software development, like once you 856 00:56:50,640 --> 00:56:53,960 introduce a feature like you can't really take it out right? 857 00:56:53,960 --> 00:56:57,040 Like the majority of the software development world you 858 00:56:57,040 --> 00:57:01,640 know, USE has many best practices for AB testing and 859 00:57:01,640 --> 00:57:03,480 feature flags and different things to like. 860 00:57:04,080 --> 00:57:06,840 Implement a new feature and test it out on a certain percent of 861 00:57:06,840 --> 00:57:08,840 the population. Figure out if it's valuable and 862 00:57:08,840 --> 00:57:13,200 then and then implement it right or then roll it out. 863 00:57:13,200 --> 00:57:16,360 We can't, we obviously we can't really do that with Bitcoin and 864 00:57:16,360 --> 00:57:19,280 so it makes development much harder. 865 00:57:19,320 --> 00:57:24,400 And you know, This is why, you know we have to be careful of 866 00:57:24,400 --> 00:57:27,640 course because we don't want to interest bloat to the protocol. 867 00:57:27,640 --> 00:57:32,040 We don't want to mess up anyone's funds and bitcoins core 868 00:57:32,040 --> 00:57:35,880 value proposition is it's. That it changes very slowly and 869 00:57:35,880 --> 00:57:39,200 it's a it's a safe haven as opposed to the kind of Wild West 870 00:57:39,200 --> 00:57:42,960 of other blocks. And I think that you know 871 00:57:43,000 --> 00:57:47,240 covenants to me seem like the time is really right for them. 872 00:57:47,240 --> 00:57:50,840 I think that people have kind of come around to it more and it's 873 00:57:50,840 --> 00:57:54,960 really a question of various implementations and and where to 874 00:57:54,960 --> 00:57:57,840 start because you know, covenants are essentially more 875 00:57:57,840 --> 00:58:00,920 of a category than a specific feature. 876 00:58:02,120 --> 00:58:05,360 I love what of course like Robin is doing with with bid VM and I 877 00:58:05,360 --> 00:58:10,520 think that you know introduces a lot of alternative ways to 878 00:58:10,600 --> 00:58:14,880 implement potential covenants that might also you know, 879 00:58:14,880 --> 00:58:20,360 depending on Robin's development and his team's progress like can 880 00:58:20,360 --> 00:58:24,200 help show if there's value, you know, like if there's a certain 881 00:58:24,200 --> 00:58:27,520 covenant that we want you know the ideal way. 882 00:58:27,920 --> 00:58:30,680 Would be to sort of follow the path of like what ordinals did 883 00:58:30,680 --> 00:58:35,640 if it's feasible, which is like to implement it in an an 884 00:58:35,640 --> 00:58:40,240 alternative way that can show what the adoption is, you know. 885 00:58:40,240 --> 00:58:43,160 So for for covenants though, I think it's also a change as 886 00:58:43,160 --> 00:58:46,120 opposed to like you know to drive chains like there's a lot 887 00:58:46,120 --> 00:58:48,000 of, there's a lot of product discussion is like, well, if you 888 00:58:48,000 --> 00:58:52,840 don't use it then you know it's not going to affect you kind of 889 00:58:52,840 --> 00:58:54,920 a thing and I don't know that it's. 890 00:58:55,440 --> 00:58:57,640 The case with with drive chains but seems to be the case with 891 00:58:57,840 --> 00:59:00,400 with CTV. And you know I think that this 892 00:59:00,480 --> 00:59:05,640 this larger discussion about you know classification and 893 00:59:05,640 --> 00:59:11,680 categorization of potential changes and and whether or not 894 00:59:11,680 --> 00:59:15,920 they introduce or they will affect users who don't use it. 895 00:59:15,920 --> 00:59:18,120 And what the implications of that are going to be as part of 896 00:59:18,120 --> 00:59:19,920 the. The real crux of where the 897 00:59:19,920 --> 00:59:21,520 discussion should be is you know. 898 00:59:23,120 --> 00:59:26,120 If some if you know how much blow does it 'cause you know 899 00:59:26,600 --> 00:59:30,560 could could there be a scenario where there is a trial period 900 00:59:30,560 --> 00:59:35,240 for something where it's like you give it a year and if it 901 00:59:35,240 --> 00:59:37,480 doesn't reach a certain threshold you you roll it back 902 00:59:37,480 --> 00:59:39,600 and it's just agreed upon by the community in advance. 903 00:59:40,880 --> 00:59:43,600 You know we're we're definitely entering a period where I think 904 00:59:44,600 --> 00:59:47,280 in the next cycle Bitcoin is going to grow even larger. 905 00:59:47,280 --> 00:59:49,040 There's going to be even more demand for users. 906 00:59:49,600 --> 00:59:55,280 We see the. You know inflation and what's 907 00:59:55,280 --> 00:59:57,920 happening with interest rates and and in the Middle East is 908 00:59:58,400 --> 01:00:03,360 causing Bitcoin to break away from the you know being traded 909 01:00:03,360 --> 01:00:06,200 like a a bit high beta of a tech stock and sort of going the 910 01:00:06,200 --> 01:00:08,640 opposite way of the market and maybe a new narrative forming 911 01:00:09,120 --> 01:00:11,200 and that could lead to significantly more users coming 912 01:00:11,200 --> 01:00:12,760 on. And so we definitely have to 913 01:00:12,760 --> 01:00:15,720 step up our game in terms of the the nuance and and how we 914 01:00:15,720 --> 01:00:19,160 execute in introducing these features which we may need, you 915 01:00:19,160 --> 01:00:22,080 know, to add. ZK roll ups in the future or to 916 01:00:22,080 --> 01:00:26,520 add other scalability solutions. I think we need to try as many 917 01:00:26,520 --> 01:00:32,000 things as possible with while being conservative and not 918 01:00:32,320 --> 01:00:35,920 messing up what we have today. Moving You got something to say? 919 01:00:36,040 --> 01:00:39,080 Yeah, yeah. Just quickly, I wanted to say 920 01:00:39,080 --> 01:00:43,040 that it is always worth, you know, examining these claims 921 01:00:43,040 --> 01:00:47,000 that only the people who opt in to use them will be affected. 922 01:00:47,720 --> 01:00:51,320 And it is there is no way for others to be negatively 923 01:00:51,320 --> 01:00:54,960 effective. So obviously in the end after 924 01:00:55,120 --> 01:01:00,160 after like the the, the basic you know the the rudimentary 925 01:01:00,200 --> 01:01:04,680 like how do you say this like due diligence is done by the 926 01:01:04,680 --> 01:01:09,240 developer committee it is actually on the detractors the 927 01:01:09,280 --> 01:01:12,960 opponents of a software to to prove that it can you know harm 928 01:01:13,400 --> 01:01:15,920 the network and and users will be not obtained. 929 01:01:16,800 --> 01:01:20,240 But for example, recently there has been talks about 930 01:01:20,280 --> 01:01:25,600 reactivating cat or cat, and we know it is relatively harmless 931 01:01:25,920 --> 01:01:30,200 in the sense of resource consumption because stick items 932 01:01:30,200 --> 01:01:34,600 are limited in 520 bytes if I remember correctly. 933 01:01:35,280 --> 01:01:39,880 And the people realize that this also limits what opcat can be 934 01:01:39,880 --> 01:01:44,360 used for in terms of, you know, funny, fun developer things. 935 01:01:44,720 --> 01:01:49,640 And so a proposal was made that you should actually multiply 936 01:01:49,640 --> 01:01:54,040 that 520 times with the maximum number of stack items. 937 01:01:54,040 --> 01:01:59,320 So the total amount of stack memory that you can use with top 938 01:01:59,320 --> 01:02:05,920 cat would still be limited, but you could actually create like a 939 01:02:07,520 --> 01:02:15,200 520 KB size strings at maximum. And the problem with that is it 940 01:02:15,200 --> 01:02:22,200 actually it opt get you can very quickly reach that size and it 941 01:02:22,200 --> 01:02:24,480 opens up a quadratic hashing talk. 942 01:02:24,800 --> 01:02:27,600 I'm not sure if my calculations are completely correct, but I 943 01:02:27,600 --> 01:02:32,840 got something like it would take 11 hours for a Raspberry Pi 4 to 944 01:02:32,840 --> 01:02:39,400 verify a block specifically constructed to deny service to 945 01:02:39,400 --> 01:02:41,280 the Bitcoin network. So. 946 01:02:42,520 --> 01:02:47,000 We have to be kind of you know, vigilant about this and think 947 01:02:47,000 --> 01:02:49,200 these things too. I'm not trying to fought 948 01:02:49,200 --> 01:02:51,720 covenants. I think covenants are super 949 01:02:52,040 --> 01:02:56,400 important and I'm not sure on the next step for this, but 950 01:02:57,400 --> 01:03:01,720 obviously we cannot like get carried away and claim that that 951 01:03:01,720 --> 01:03:06,160 nobody will be harmed by anything unless they use it. 952 01:03:06,480 --> 01:03:10,320 We have to actually examine these claims with each and every 953 01:03:10,320 --> 01:03:13,040 proposal. And certainly the way things are 954 01:03:13,200 --> 01:03:16,320 in Bitcoin and script, you actually kind of have to take 955 01:03:16,320 --> 01:03:21,080 into account how multiple, of course multiple proposals 956 01:03:21,080 --> 01:03:23,680 interact with each other. I think she know be likes to 957 01:03:24,240 --> 01:03:28,760 rant about this a lot, that it's not enough to just look at 958 01:03:28,760 --> 01:03:33,480 something in isolation. For example, opcat can do a lot 959 01:03:33,480 --> 01:03:35,520 of very fun and interesting things. 960 01:03:36,400 --> 01:03:40,320 For example you can actually it looks like you can implement the 961 01:03:40,320 --> 01:03:44,920 finite state machines in Bitcoin script that can change state and 962 01:03:44,920 --> 01:03:47,240 stick to a contract or program if you wish. 963 01:03:47,800 --> 01:03:50,960 With these States and one transaction at the time you can 964 01:03:50,960 --> 01:03:53,000 update the state and you can do this. 965 01:03:53,440 --> 01:03:58,360 But for example with taproot you can't really do that because you 966 01:03:58,360 --> 01:04:05,720 would need optic verify. Known from liquid elements 967 01:04:06,480 --> 01:04:09,640 script. You would need optic verify to 968 01:04:09,640 --> 01:04:18,000 actually verify that assembled test script output address so to 969 01:04:18,000 --> 01:04:25,120 speak and so opcat with taproot would not really work in this 970 01:04:25,120 --> 01:04:30,360 way, but so stuff like this I think. 971 01:04:31,240 --> 01:04:35,800 We need to, like spend a lot of time collectively on exporting 972 01:04:35,800 --> 01:04:39,480 these limitations and possibilities and not be too 973 01:04:39,480 --> 01:04:43,640 fearful, but but always have in our mind that how could this be 974 01:04:43,640 --> 01:04:46,960 used as a denial of service attack on people who do not use 975 01:04:46,960 --> 01:04:49,880 it? Because that's like the first 976 01:04:49,880 --> 01:04:51,880 thing that you have to ensure that it cannot. 977 01:04:52,240 --> 01:04:55,840 That's the absolute basic your proposal cannot, cannot go 978 01:04:55,840 --> 01:04:58,720 through. If you cannot, you know, like 979 01:04:58,760 --> 01:05:02,400 reassure everyone. That that it is reasonably safe 980 01:05:03,040 --> 01:05:07,360 and the CTV has been around the block for years and then the lot 981 01:05:07,360 --> 01:05:10,440 of very small people have looked at it for a very long time and 982 01:05:10,440 --> 01:05:14,000 and so far I'm not aware of anyone being able to find 983 01:05:14,000 --> 01:05:17,800 anything any such thing. If anything, if CTV was heavily 984 01:05:17,800 --> 01:05:22,520 used it would actually speed up block validation significantly 985 01:05:23,120 --> 01:05:26,320 because it's a much cheaper operation than like a signature 986 01:05:26,320 --> 01:05:28,400 check. So please sign transactions that 987 01:05:28,400 --> 01:05:32,640 actually actually much more computational heavy and and take 988 01:05:32,640 --> 01:05:35,000 up more space on the blockchain as well. 989 01:05:35,680 --> 01:05:40,440 So that's one thing. All right, just just real quick. 990 01:05:40,440 --> 01:05:44,440 I wanted to let everyone know we're going to have to wind up 991 01:05:44,440 --> 01:05:46,880 in 8 minutes. But also real quick. 992 01:05:46,880 --> 01:05:49,760 Robin, I saw super tried to get a word in. 993 01:05:50,760 --> 01:05:55,480 Yeah, I just wanted to add that. Of course, Shinobi is not that 994 01:05:55,480 --> 01:05:58,280 big of a fan of side chains, but I'm a big fan of side chains. 995 01:05:58,320 --> 01:06:01,560 And in general, to have trust the side chain, you need two 996 01:06:01,560 --> 01:06:03,520 things. You need a consensus mechanism 997 01:06:03,520 --> 01:06:05,080 and you need some kind of bridge. 998 01:06:05,760 --> 01:06:12,200 And for the consensus mechanism part, CTV also helps us because 999 01:06:13,640 --> 01:06:17,680 CTV enables. Yeah, essentially. 1000 01:06:17,720 --> 01:06:20,000 Space chains. Space chains. 1001 01:06:20,880 --> 01:06:23,680 Space chains. Space chains as well, but, but 1002 01:06:23,760 --> 01:06:26,440 I'm talking about stake chains and I think they are superior 1003 01:06:26,760 --> 01:06:30,720 because yeah, they enable a Bitcoin backed proof of stake. 1004 01:06:30,800 --> 01:06:34,320 So you can have a proof of stake algorithm and essentially you 1005 01:06:34,320 --> 01:06:36,640 get the best of both worlds because you get the proof of 1006 01:06:36,640 --> 01:06:39,720 work security because you get bitcoins that are anchored into 1007 01:06:39,720 --> 01:06:42,760 bitcoins, proof of work. But you can stake them in such a 1008 01:06:42,760 --> 01:06:47,440 way that, yeah, you get the benefits of proof of stake, 1009 01:06:47,440 --> 01:06:51,600 which is essentially, yeah, instant finality. 1010 01:06:52,000 --> 01:06:54,920 Because once the stakers have signed, once the majority of the 1011 01:06:54,920 --> 01:06:59,480 stakers have signed, you cannot change their voting without them 1012 01:07:00,680 --> 01:07:02,560 revealing their keys and getting stashed for it. 1013 01:07:02,560 --> 01:07:05,640 So. If you try the 51%, your A6 1014 01:07:05,640 --> 01:07:07,680 explode. It's the only way in which Proof 1015 01:07:07,680 --> 01:07:10,480 of Stake is superior. And that's. 1016 01:07:11,480 --> 01:07:14,000 That is, I mean not not the only way, but yes. 1017 01:07:14,320 --> 01:07:18,040 Real quick though guys. Because there is no social 1018 01:07:18,040 --> 01:07:20,560 consensus or something. Because it's it's really about, 1019 01:07:21,280 --> 01:07:25,800 you know, reusing you you you're using pre committed analysis and 1020 01:07:26,320 --> 01:07:30,280 you can sign block 5 only with your announce 5, and if you ever 1021 01:07:30,280 --> 01:07:33,480 sign 2 conflicting block fives, then you have to reuse your 1022 01:07:33,480 --> 01:07:35,560 announce 5. And if you reuse your announce 1023 01:07:35,560 --> 01:07:37,680 5, you will leak your key immediately and then you get 1024 01:07:37,680 --> 01:07:40,320 slashed. And Long story short, that is a 1025 01:07:40,320 --> 01:07:43,120 very interesting side chain consensus mechanism that is that 1026 01:07:43,120 --> 01:07:44,600 has all kinds of nice properties. 1027 01:07:45,120 --> 01:07:46,960 It is way more on chain efficient. 1028 01:07:46,960 --> 01:07:49,880 It is way faster, like you can have way faster block times, you 1029 01:07:49,880 --> 01:07:53,680 have way faster finality And yeah, you have all kinds of nice 1030 01:07:53,680 --> 01:07:57,600 features and I think that's a cool thing about CTV that it 1031 01:07:57,600 --> 01:08:01,280 enables such a powerful side chain consensus mechanism. 1032 01:08:03,720 --> 01:08:06,640 Super. You were trying to say something 1033 01:08:06,640 --> 01:08:10,920 a bit ago, though. I just like to mention that one 1034 01:08:10,920 --> 01:08:13,600 difference between space chains and stake chains is that space 1035 01:08:13,600 --> 01:08:17,120 chains work right now and they work very well, whereas stake 1036 01:08:17,120 --> 01:08:18,319 chains don't. So. 1037 01:08:18,319 --> 01:08:24,200 So I think that's an advantage that is worth $1,000,000. 1038 01:08:24,200 --> 01:08:27,840 So there you go. State chains work as well, like 1039 01:08:27,880 --> 01:08:31,920 you just have to emulate CTV like you, you have to pre sign 1040 01:08:31,920 --> 01:08:35,520 the burning contract and yeah, you can emulate CTV. 1041 01:08:36,560 --> 01:08:40,880 By yeah. Using an N of N music and you 1042 01:08:40,880 --> 01:08:45,240 can make everybody participate in that N of N music by yeah. 1043 01:08:45,240 --> 01:08:48,279 Inscribing the the the protocol into the chain so that everybody 1044 01:08:48,279 --> 01:08:51,479 can participate or like sign up for it to participate and then 1045 01:08:51,800 --> 01:08:55,479 when they refuse to sign they get removed removed from the 1046 01:08:55,560 --> 01:08:58,560 cosigner set and. At some point you will end up 1047 01:08:58,560 --> 01:09:01,479 with a valid signature and then this is the signature that 1048 01:09:01,600 --> 01:09:05,560 allows you to emulate CTV and then it would work like. 1049 01:09:05,600 --> 01:09:07,800 Then you can run state chains without CTV. 1050 01:09:08,640 --> 01:09:14,000 All right, sounds. Like a lot on that proclamation 1051 01:09:14,000 --> 01:09:16,200 from the wise Wizards of Bitcoin. 1052 01:09:17,800 --> 01:09:22,000 We're 5 minutes from the the end time, I guess Everybody. 1053 01:09:23,040 --> 01:09:26,000 Want to go through like any last comments they have on covenants. 1054 01:09:26,000 --> 01:09:29,279 I guess we can start with you, Moon and go reverse. 1055 01:09:30,279 --> 01:09:33,920 All right. So the reason I I changed my 1056 01:09:33,920 --> 01:09:40,479 name to get Moxie is because I'm I'm kind of personally a bit fed 1057 01:09:40,479 --> 01:09:45,960 up with the current culture that developed on Bitcoin and and 1058 01:09:45,960 --> 01:09:49,640 everyone is trying to tell everyone else what they can can 1059 01:09:49,640 --> 01:09:53,399 do on on Bitcoin. And it's kind of like me opting 1060 01:09:53,399 --> 01:09:58,000 out like a teenager, you know, and saying that, you know, fuck 1061 01:09:58,000 --> 01:10:00,000 that. Let's enable everything and then 1062 01:10:00,000 --> 01:10:04,280 only talk about what use cases are actually valuable enough to 1063 01:10:04,280 --> 01:10:07,560 make them more efficient. Because doing it with Top cat is 1064 01:10:07,560 --> 01:10:12,040 going to be like messy and limited and inefficient for a 1065 01:10:12,040 --> 01:10:16,760 lot of things, but as soon as like the possibility of. 1066 01:10:17,560 --> 01:10:22,800 Of like not having people, not having a say in embargoes and 1067 01:10:22,800 --> 01:10:26,040 whatnot goes. And also like opcat was a part 1068 01:10:26,040 --> 01:10:29,800 of Bitcoin. I would like to, you know, move 1069 01:10:29,800 --> 01:10:34,120 us like to see us move past this, this phase of what we want 1070 01:10:34,120 --> 01:10:38,560 and what not want and just just go into the what we should make 1071 01:10:38,560 --> 01:10:41,880 more efficient and what is really valuable to Bitcoin 1072 01:10:42,120 --> 01:10:46,440 phase. Just let's let's do it. 1073 01:10:46,720 --> 01:10:50,320 I think I I want to build this. I want to build a meme that is 1074 01:10:50,320 --> 01:10:52,240 currently not true, but maybe someday will be. 1075 01:10:53,240 --> 01:10:55,600 Everyone agrees that we need CTV. 1076 01:10:55,840 --> 01:10:58,120 The only question is what comes with it. 1077 01:10:59,120 --> 01:11:03,920 Do we bring it, bring along with it's C cash, any priv out or do 1078 01:11:03,920 --> 01:11:06,240 we bring along with it? Check from stack or what? 1079 01:11:06,600 --> 01:11:09,160 But everyone agrees or not currently, but pretty. 1080 01:11:09,160 --> 01:11:10,720 If we say this enough, maybe it'll happen. 1081 01:11:11,120 --> 01:11:12,880 Everyone agrees CTV is the minimum. 1082 01:11:12,960 --> 01:11:14,520 And then after that you know, who knows. 1083 01:11:14,800 --> 01:11:19,320 So let's let's start there. Yeah, I, I, I, I generally agree 1084 01:11:19,320 --> 01:11:23,200 with super right there. I think, you know, I'm really 1085 01:11:23,200 --> 01:11:28,240 curious to see where kind of public support falls, you know, 1086 01:11:28,240 --> 01:11:32,280 amongst these different iterations and you know how we 1087 01:11:32,280 --> 01:11:35,120 balance that with. Things like simplicity and some 1088 01:11:35,120 --> 01:11:37,480 other things. So yeah, I'm just very curious 1089 01:11:37,480 --> 01:11:40,880 to see how it develops. I do think we could benefit 1090 01:11:40,880 --> 01:11:43,120 greatly from them. I think they were will really 1091 01:11:43,120 --> 01:11:46,920 benefit, you know, Bitcoin users in the future. 1092 01:11:47,200 --> 01:11:52,920 And I think it is sort of a duty of the current Bitcoin users to, 1093 01:11:53,240 --> 01:11:57,920 you know, keep it as trustless. And as accessible as it was when 1094 01:11:57,920 --> 01:12:00,600 we found it, So I'm, I'm interested in seeing what 1095 01:12:00,600 --> 01:12:04,320 happens and yeah, appreciate all you guys coming here and 1096 01:12:04,320 --> 01:12:09,960 teaching and speedy trial. Now I guess right Robin, Europe. 1097 01:12:11,200 --> 01:12:14,280 Yeah, I totally agree with with what Moon Settler said. 1098 01:12:15,320 --> 01:12:19,000 I think opcat is by far the best government proposal. 1099 01:12:19,000 --> 01:12:22,040 Even though it's kind of inefficient, I think it's the 1100 01:12:22,040 --> 01:12:27,560 most flexible opcode that's. Is currently in discussion and 1101 01:12:28,280 --> 01:12:30,800 it would enable all kinds of great things and it would allow 1102 01:12:30,800 --> 01:12:34,520 us to scale Bitcoin to global scale to billions of users, I 1103 01:12:34,520 --> 01:12:37,600 think. And that's why I think Opcad is 1104 01:12:37,640 --> 01:12:40,480 the right proposal. And from there we can see what's 1105 01:12:40,600 --> 01:12:44,480 worth optimizing. Sam shower us with Autism. 1106 01:12:45,440 --> 01:12:49,920 In order of preference cat, CTV, APO. 1107 01:12:50,400 --> 01:12:53,680 CSFSI would be happy enough with all four of them, but if I had 1108 01:12:53,680 --> 01:12:55,840 to pick just one gun to that, it's got to be Cat. 1109 01:12:56,920 --> 01:12:59,320 Yeah, I agree fully with what Sam just said. 1110 01:13:00,120 --> 01:13:02,120 Yes. Trevor, you got any last 1111 01:13:02,120 --> 01:13:04,760 thoughts for us. Yeah I mean I think the the 1112 01:13:04,760 --> 01:13:09,040 panels here are are more expert than me on the the the specific 1113 01:13:09,040 --> 01:13:11,960 alternatives here and it's it's you know great to be on the 1114 01:13:11,960 --> 01:13:13,160 stage. Thank you for having me. 1115 01:13:13,520 --> 01:13:18,400 I think that you know taking more broader look like we're in 1116 01:13:18,440 --> 01:13:22,240 a very uncharted domain for software development when it 1117 01:13:22,240 --> 01:13:25,160 comes to how Bitcoin works. Most of the software best 1118 01:13:25,160 --> 01:13:28,800 practices used are you know, come from Silicon Valley, come 1119 01:13:28,800 --> 01:13:31,040 from web too. And I'm just wondering if 1120 01:13:31,040 --> 01:13:34,120 there's you know lessons we can learn maybe from other 1121 01:13:34,120 --> 01:13:38,280 industries where they need to adapt and move quickly, but if 1122 01:13:38,280 --> 01:13:40,840 they move too fast there could be catastrophic consequences. 1123 01:13:41,320 --> 01:13:43,600 You know industries like the Pharmaceutical industry, 1124 01:13:43,600 --> 01:13:47,200 aerospace etcetera, things that we can kind of adapt to software 1125 01:13:47,200 --> 01:13:51,080 development model to more closely match the environment 1126 01:13:51,080 --> 01:13:54,200 that we're in. And I think that a lot of the 1127 01:13:54,200 --> 01:13:58,320 things that prevent what we need from happening just come from 1128 01:13:58,320 --> 01:14:04,400 the the lacking the right tools for for deciding how to proceed 1129 01:14:04,400 --> 01:14:06,160 here. All right. 1130 01:14:06,280 --> 01:14:09,320 Thanks so much everyone. Shinobi, is there anything else 1131 01:14:09,320 --> 01:14:10,960 you want to add or should we just wrap up here? 1132 01:14:12,280 --> 01:14:15,720 I think hopefully this was what people needed to hear. 1133 01:14:15,760 --> 01:14:19,200 Just thanks everybody who came and participated for coming and 1134 01:14:19,200 --> 01:14:22,240 give us your time. Thanks so much everyone. 1135 01:14:22,440 --> 01:14:24,800 Really appreciate all the speakers up on stage and 1136 01:14:24,800 --> 01:14:26,200 everyone that came to listen in can. 1137 01:14:26,680 --> 01:14:29,120 I just one more thing please. Yeah, sure. 1138 01:14:30,400 --> 01:14:36,720 We are inscribing now the first Blake 3 hash function call into 1139 01:14:36,720 --> 01:14:40,480 Bitcoin script. We implemented Blake 3 and it 1140 01:14:40,480 --> 01:14:43,320 will. Execute right now, like we will 1141 01:14:43,320 --> 01:14:48,000 add it to the men pool within the next few seconds and then we 1142 01:14:48,520 --> 01:14:52,080 yeah, we prove that Bitcoin script is capable of much more 1143 01:14:52,080 --> 01:14:55,200 than people thought. Bow, chicka, bow, bow. 1144 01:14:56,240 --> 01:14:59,280 Wizard shit. Wizard shit, Really. 1145 01:14:59,600 --> 01:15:02,120 For those who don't get it all. Right. 1146 01:15:02,120 --> 01:15:05,280 Thanks so much, everyone. We'll catch you next week. 1147 01:15:05,280 --> 01:15:07,080 Thank you for tuning in. And I want to say thank you to 1148 01:15:07,080 --> 01:15:09,240 all the speakers and everyone that joined us today. 1149 01:15:09,600 --> 01:15:11,040 Have a good one, everyone. Peace. 1150 01:15:11,920 --> 01:15:13,760 Take it easy. Toodles. 1151 01:15:15,120 --> 01:15:18,320 Thank you Miami, for the last three years in this amazing 1152 01:15:18,320 --> 01:15:21,000 city. The whole world shut. 1153 01:15:21,000 --> 01:15:24,600 Down, but Miami welcomed us with open arms. 1154 01:15:25,240 --> 01:15:28,200 We want to show Bitcoin to the whole world. 1155 01:15:29,640 --> 01:15:31,960 We are taking the conference on the road. 1156 01:15:32,000 --> 01:15:35,240 To set the stage. For Bitcoin in a New City, 1157 01:15:36,560 --> 01:15:41,120 Nashville. Bitcoin 2024 is coming to 1158 01:15:41,120 --> 01:15:45,360 Nashville in Tennessee, a city that is known as a Music and 1159 01:15:45,360 --> 01:15:48,920 Freedom City. Bitcoin 2024 in Nashville from 1160 01:15:48,920 --> 01:15:51,160 July 25th to 27th.