1 00:00:00,000 --> 00:00:23,160 Hello, good morning, guys. How are you guys doing? So yeah, many of you guys might be 2 00:00:23,160 --> 00:00:30,920 familiar with what I do. I work mainly on a software project called U3XO. It's by Tad 3 00:00:30,920 --> 00:00:36,200 Stryza, who's right there. But today I won't be talking about that. Today I'll be talking 4 00:00:36,200 --> 00:00:43,720 about the hardships and the things that we go through when we work on an implementation 5 00:00:43,720 --> 00:00:49,640 of Bitcoin that is not Bitcoin Core. So these are my slides. If you scan the QR code or 6 00:00:49,640 --> 00:00:56,320 go to the link, there'll be a bunch of links. There'll be a bunch of evidence of my complaints 7 00:00:56,320 --> 00:01:01,160 about Bitcoin Core on the presentation. So if you would like to follow along, do scan, 8 00:01:01,160 --> 00:01:08,360 and then you could take a look at it together. Yeah, so for me, you could take pictures of 9 00:01:08,360 --> 00:01:14,400 me on the stage. The only thing that I ask of you is that the picture you post on Twitter 10 00:01:14,720 --> 00:01:22,400 look nice. That's the only thing that I ask. And so, okay, let's get started then. So BTCD, 11 00:01:23,040 --> 00:01:33,760 this is the software projects that I stumbled upon being a maintainer of now. And so BTCD is 12 00:01:34,560 --> 00:01:40,800 essentially just a alternative implementation of Bitcoin Core. Bitcoin Core, as you guys might know, 13 00:01:40,800 --> 00:01:46,800 is a reference implementation of the Bitcoin protocol, of the Bitcoin spec. So if you run 14 00:01:46,800 --> 00:01:53,360 Bitcoin Core, that is essentially Bitcoin. But then if you take those rules and just implement 15 00:01:53,360 --> 00:02:00,080 a different software project, it's like, yeah, you could theoretically do that, right? And if you do 16 00:02:00,080 --> 00:02:08,240 that in the Go language, well, you get BTCD. So that's what BTCD is in a nutshell. Not many people 17 00:02:08,320 --> 00:02:18,320 really know about BTCD, or if such a project exists. So today, can I get a show of hands on, 18 00:02:18,320 --> 00:02:25,040 like, if you've heard of BTCD before? Oh, quite a decent amount of people. Okay, cool. 19 00:02:25,920 --> 00:02:32,320 But I wanted to sort of share, if I go to a conference like Bitcoin Magazine conference, 20 00:02:32,320 --> 00:02:39,520 and I introduce myself as, hey, I work on BTCD. Usually, they'll be like, oh, what is that? But 21 00:02:39,520 --> 00:02:43,760 then they'll be like, yeah, I know what you do. You work on the Bitcoin dominance, right? 22 00:02:44,400 --> 00:02:51,280 It's like, yeah. Or in Hong Kong, there was a guy that I was talking to. I was like, yeah, 23 00:02:51,280 --> 00:02:55,120 I work on BTCD. And like, you probably don't know about it. But then it's like, yeah. Oh, 24 00:02:55,120 --> 00:03:01,360 like, how do you know about BTCD? Oh, it's that stablecoin, right? It's the BTC dollar. So there's 25 00:03:01,360 --> 00:03:08,720 a bunch of other projects like this that I had issues with, I don't know, like little miscommunications 26 00:03:08,720 --> 00:03:14,400 with. It's like, oh, you work on Bitcoin Dark, you work on Bitcoin Diamond. And then I was Googling 27 00:03:14,400 --> 00:03:20,480 and I found this thing called BTCD. I think it's like a crypto credit card or something. 28 00:03:20,480 --> 00:03:27,040 But anyway, no one really knows about BTCD. And in this presentation today, I would like to sort 29 00:03:27,040 --> 00:03:35,280 of go through why I work on BTCD and why I work on BTCD is like really simple. I just, I hate C++. 30 00:03:36,000 --> 00:03:41,760 That's the only reason. That's the only reason that I work on BTCD. No, it's not the only reason. 31 00:03:41,760 --> 00:03:51,120 But I really, really don't like C++. And so that's my personal reason. But there are other sort of 32 00:03:51,120 --> 00:03:59,440 philosophical reasons as well. And I want to quote someone of a higher reputation than me, 33 00:03:59,440 --> 00:04:07,360 which is Roastbeef, the CTO of Lightning Labs. And how Roastbeef, or Lalu, views BTCD or Bitcoin 34 00:04:07,360 --> 00:04:13,360 is that, you know, Bitcoin is an idea. It's not a software implementation. So Bitcoin Core is a 35 00:04:13,360 --> 00:04:18,720 reference implementation, but Bitcoin Core shouldn't be Bitcoin. So that's how he feels about it. 36 00:04:19,520 --> 00:04:26,880 And this is what a lot of others feel. This is what the people that work on BTCD sort of feel 37 00:04:26,880 --> 00:04:33,440 about Bitcoin. It's like, hey, like, Bitcoin should be a thing that we could implement, 38 00:04:33,440 --> 00:04:38,400 and we could have multiple implementations. It's just an idea. It's not C++ code that is Bitcoin. 39 00:04:39,200 --> 00:04:46,640 So yeah, so not many of you guys know about BTCD. But this is one of the things that I want to point 40 00:04:46,640 --> 00:04:55,840 out today. BTCD is a weird software project, because you don't know about it. Not many people 41 00:04:55,840 --> 00:05:03,520 really use it. But it's very, very influential in terms of the entire Bitcoin ecosystem, because 42 00:05:03,520 --> 00:05:10,800 a lot of the Lightning Network depends on code from BTCD. How many of you guys remember the 43 00:05:11,360 --> 00:05:20,480 the unfortunate segwit bug that happened a few years back that crashed the Lightning Network? 44 00:05:20,480 --> 00:05:26,640 And so, yeah, so it's very influential. If we screw up with BTCD, then we screw up with a lot 45 00:05:26,640 --> 00:05:35,840 of things in the Bitcoin ecosystem. But so yeah, I'm going to get into the main meat of my talk. 46 00:05:35,920 --> 00:05:41,440 I want you guys to take two things away. First thing that I want you to take away is why 47 00:05:42,240 --> 00:05:46,240 alt implementations are difficult. Who else works on alt implementations here? 48 00:05:47,360 --> 00:05:54,880 Oh, yeah, I got some people, yeah. And I do want to also sell you on BTCD itself. Like, 49 00:05:54,880 --> 00:06:01,440 why should you give it a try? Or why should you look into it? Why is it worth your attention? 50 00:06:02,400 --> 00:06:06,080 So first things first, why are alt implementations hard? 51 00:06:07,680 --> 00:06:14,000 More or less, yeah, Bitcoin Core's development process treats Bitcoin Core as the only 52 00:06:14,000 --> 00:06:20,400 implementation. I quoted myself. You can take a picture. It's okay. You can post it on Twitter 53 00:06:20,400 --> 00:06:28,880 for fiery memes. We could have a fight on Twitter online. But yeah, so Bitcoin Core, 54 00:06:29,840 --> 00:06:36,880 when I don't think the devs are malicious in this, it's just that it's not on your mind. 55 00:06:36,880 --> 00:06:42,080 It's like when you're working on a protocol change, or when you're working on something 56 00:06:42,080 --> 00:06:48,080 even like minor, whatever, like, it's just not on your mind. And that's, I think that's totally 57 00:06:48,080 --> 00:06:52,960 understandable. If I worked on Bitcoin Core, I would probably do the same thing. But this is 58 00:06:52,960 --> 00:06:59,040 the reality of things in that, hey, like, the development process doesn't really pay attention 59 00:06:59,920 --> 00:07:10,240 to these other implementations or doesn't sort of, I don't know, like, care for them. So 60 00:07:11,440 --> 00:07:18,400 I want to give you guys two examples of these things. The first example happened a few years 61 00:07:18,400 --> 00:07:25,760 back. It's by Nicholas Goiga. And the disclosure, BTCD consensus bugs due to the usage of signed 62 00:07:25,760 --> 00:07:33,920 transaction version. So this is one of the bugs where to validate some rules on Bitcoin, you had 63 00:07:33,920 --> 00:07:45,120 to typecast from signed integers to unsigned integers. And Nicholas, in this Bitcoin Delving 64 00:07:45,120 --> 00:07:50,960 Post, sort of points out that, hey, like, it's BTCD's fault for not doing this typecast. Like, 65 00:07:50,960 --> 00:07:58,640 you should have done this typecast. It's written in the BIP specification. So you should have done 66 00:07:58,640 --> 00:08:04,560 that. But in reality, you know, it's like, no one really knew about this rule. So I want to point 67 00:08:04,560 --> 00:08:10,320 out, it's like, hey, like, prominent Bitcoin developer, Gregory Sanders, said, hey, what? I 68 00:08:10,320 --> 00:08:18,240 have no idea that we should treat it as unsigned. Like, we have to, like, cast it. So this rule 69 00:08:18,800 --> 00:08:28,880 that supposedly BTCD couldn't bother implementing is a rule that is not known to prominent Bitcoin 70 00:08:28,880 --> 00:08:37,920 core developers. So there's two BIPs for this. There's BIP 68, and then there's BIP 112. So in 71 00:08:38,000 --> 00:08:49,760 the BIP 68 specification, there is no mention of the typecast that you have to do. So this is a 72 00:08:49,760 --> 00:08:59,520 screenshot of BIP 68. And nowhere in the specification is there any mention of this 73 00:08:59,520 --> 00:09:06,960 typecast being done. So how can you say that, hey, this is a BTCD bug? It's not a BTCD bug. 74 00:09:07,280 --> 00:09:14,160 It's a BIP bug. So there's this section for specification, and it mentions nothing about 75 00:09:14,160 --> 00:09:20,240 this typecast. You have this other section. It's very small. But you have this other section called 76 00:09:20,240 --> 00:09:27,520 implementation. And in this implementation, if you look there in the very bottom, oh, okay. 77 00:09:28,080 --> 00:09:34,000 Well, anyway, if you look at the implementation, we're back. Yeah, nice. But if we look at the 78 00:09:34,000 --> 00:09:41,360 implementation here, it's like, yeah, we should cast it. So it's not in the spec. It's in the 79 00:09:41,360 --> 00:09:48,240 implementation. It's just C++ code on the BIP itself, and you have to go through and read these 80 00:09:48,240 --> 00:09:55,920 tiny implementation details to know that there is a typecasting to be done. So this is BIP 68. 81 00:09:55,920 --> 00:10:03,440 What about BIP 112? And BIP 112 situation is basically this. It's like, hey, like, we should 82 00:10:03,440 --> 00:10:09,760 totally write a specification about typecast. This is very important stuff. We should probably have 83 00:10:09,760 --> 00:10:20,240 it, right? So BIP 112, I'll give them credit. They just sort of skipped the writing up a 84 00:10:20,240 --> 00:10:26,000 specification and just slapped the code on there and called it a specification. And if you look 85 00:10:26,000 --> 00:10:34,720 there, yeah, there's a cast. There's no comment on that you should cast. But there is a cast. 86 00:10:34,720 --> 00:10:42,800 And this is very frustrating. Because, hey, like, these are important consensus rules that alternate 87 00:10:42,800 --> 00:10:48,800 between the two. And, like, these are rules that implementations have to obey. And if you document 88 00:10:48,800 --> 00:10:55,360 it like this, then how are you going to obey these rules, right? And, like, other prominent Bitcoin 89 00:10:55,360 --> 00:11:03,760 developers share this frustration with me, right? This is HL. This is HL looking at the CTV BIP and 90 00:11:03,760 --> 00:11:10,560 saying, hey, like, this is just C++ code pasted on to the BIP document. It's like, we shouldn't do 91 00:11:10,560 --> 00:11:15,120 this. It's like, if you don't know C++ code, how are you going to implement it? I totally agree. 92 00:11:15,760 --> 00:11:22,080 We shouldn't. We really shouldn't, right? But in, like, these BIFs, in these older BIFs, it's like, 93 00:11:22,080 --> 00:11:28,560 yeah, like, we just slap on C++ code and call it a day. And if something goes wrong, it's a 94 00:11:28,560 --> 00:11:36,880 BTC debug. And that has been frustrating. It's not like BTC is perfect. Like, there's the lightning 95 00:11:36,880 --> 00:11:44,800 bug. And that one just, like, it's just screw-ups by the BTC people. But, like, stuff like this, 96 00:11:44,800 --> 00:11:50,240 it's very annoying. How are you, like, I don't know. Like, Greg Sanders doesn't even know about 97 00:11:50,240 --> 00:11:58,320 the rule. So, it's like, yeah, what are we doing here? So, this is the first example. The second 98 00:11:58,320 --> 00:12:06,640 example is much more recent. This is a recent PR that I had on BTCD. And the, if I were to 99 00:12:06,640 --> 00:12:15,040 summarize it, the Go library, it wraps IPv4 and IPv6 addresses. And this is so that for if you 100 00:12:15,040 --> 00:12:21,680 have a computer that's dual stack and if you want your IPv4 addresses to be read, it's just in the 101 00:12:21,680 --> 00:12:32,480 IPv6 form. The top, I think, is just filled with Fs. So, this is how the Go library by default 102 00:12:32,480 --> 00:12:39,440 deals with it. And so, that's how addresses are just parsed in the Go standard library. But it 103 00:12:39,440 --> 00:12:45,840 turned out that Bitcoin Core doesn't do this. This is, oh, I'm sorry. This is specifically for 104 00:12:46,800 --> 00:12:57,360 a the P2Pv2 protocol. You guys, show of hands if you're familiar with P2Pv2. Okay. So, P2Pv2 is 105 00:12:57,360 --> 00:13:02,560 just the new encryption protocol for the Bitcoin network. So, when you're sending and receiving 106 00:13:02,560 --> 00:13:07,600 messages instead of being unencrypted and showing your ISP everything that you're doing, we 107 00:13:07,680 --> 00:13:16,240 encrypt it so that they can't see what you're doing. But in this P2Pv2, how we share addresses, 108 00:13:18,320 --> 00:13:24,560 it's just you can't wrap, you can't do this IPv4 wrapping and IPv6. So, was this written in the 109 00:13:24,560 --> 00:13:33,200 BIP? So, P2Pv2 is BIP 155. It's very recent BIP. Is this in the specification? No. It is not in 110 00:13:33,280 --> 00:13:40,480 the specification. I did this, like, search thing. Is IPv4 embed not? No. It's, like, nothing. It's 111 00:13:40,480 --> 00:13:45,040 not in the spec. It's not in the BIP anywhere. So, how are you going to find it? It's just in 112 00:13:45,040 --> 00:13:51,760 Bitcoin Core code. You go in, I forget what file this was. But you go in, look there, and it's, 113 00:13:51,760 --> 00:13:58,720 like, oh, we shouldn't wrap IPv4 addresses. Or we shouldn't embed them in IPv6. So, 114 00:13:59,680 --> 00:14:07,680 that, so you have to go look through all this code to find this very, very important detail 115 00:14:07,680 --> 00:14:14,320 about, like, being able to synchronize and work together. And it turned out that because of this, 116 00:14:16,160 --> 00:14:21,520 Bitcoin seeders were dropping BTCD nodes. So, if you had a Bitcoin seeder running, 117 00:14:22,080 --> 00:14:27,920 even if the BTCD node was good, it would just drop it. Because we were wrapping it. 118 00:14:28,960 --> 00:14:35,360 We were embedding IPv4 and IPv6. So, this is, I will not take credit for this. This was from 119 00:14:35,360 --> 00:14:43,040 a coworker. And this is the chat that I had with the coworker. I was, like, is it implemented? No, 120 00:14:43,040 --> 00:14:49,200 I hate Bitcoin. It's, like, of course it's not. Naturally, like, very important specification 121 00:14:49,200 --> 00:14:56,720 details are not documented. You have to go look in the code. And this is the most frustrating 122 00:14:56,720 --> 00:15:01,600 thing when you're working on an alternative implementation. It's, like, oh, you can't take 123 00:15:01,600 --> 00:15:06,880 a look at the BIP and be okay with it. You can't trust the specifications. You have to go look at 124 00:15:06,880 --> 00:15:13,280 the code. You have to test things against Bitcoin core. And we talk about, like, Bitcoin core as, 125 00:15:13,280 --> 00:15:19,120 hey, like, we have these things. And the consensus rules are very complicated. So, 126 00:15:19,760 --> 00:15:26,880 we can't specify things. But for stuff like BIP 155, you could. It's just lack of effort. 127 00:15:27,920 --> 00:15:31,440 So, if you're working on an alternative implementation, what you always have in mind 128 00:15:31,440 --> 00:15:36,480 is are we in consensus with Bitcoin core? This is not what Bitcoin core devs have in their mind. 129 00:15:37,920 --> 00:15:43,200 When you make a new change to Bitcoin core code, do you think about, hey, are we in consensus with 130 00:15:43,200 --> 00:15:50,160 BTC? Are we in consensus with Bitcoin? That's not something they have in mind. And you can say, 131 00:15:50,160 --> 00:15:56,480 hey, like, why should the devs have that in mind, right? So, this is a chart that I took 132 00:15:57,760 --> 00:16:08,800 off of coin.dance. And 99% is Bitcoin core code. So, it's like, yeah, like, why should you care 133 00:16:08,800 --> 00:16:14,080 about that sliver of minority? And that's true. If I was a Bitcoin core developer, I would not 134 00:16:14,080 --> 00:16:20,640 care either. So, I'm not saying that these other developers are evil. I wouldn't do that either. 135 00:16:20,640 --> 00:16:24,720 I'd be like, yeah, screw you. Work on Bitcoin core. Why are you working on some other implementation? 136 00:16:24,720 --> 00:16:30,960 But, you know, like, come back to it. For whatever reason, it may be, Bitcoin core 137 00:16:30,960 --> 00:16:37,440 treats itself as the only existing implementation. And that makes it really difficult. I have this 138 00:16:37,440 --> 00:16:43,280 one other reason. Like, this is a side reason that I do want to mention. Bitcoin core is also 139 00:16:43,280 --> 00:16:49,520 much more prestigious. So, like, people will share on Twitter, like, hey, like, hi, I contributed to 140 00:16:49,520 --> 00:16:55,680 Bitcoin core, right? And it's like, and we want people to feel that way. Because this will bring 141 00:16:55,680 --> 00:17:01,920 more contributors in, right? This is something that's important to have. And Bitcoin core does 142 00:17:01,920 --> 00:17:06,960 have this. And this is, I think this is good for Bitcoin in general. But, you know, of course, 143 00:17:06,960 --> 00:17:12,560 BTCD doesn't have this. The kind of tweets you'll get about BTCD is like, yeah, I broke BTCD. 144 00:17:12,560 --> 00:17:20,640 I hope the devs notice, you know? So, these are the things, these are the reasons why 145 00:17:22,800 --> 00:17:27,840 having a, like, developing an alternative implementation is difficult. But now, let's get 146 00:17:27,840 --> 00:17:34,720 into, like, why should you try BTCD? I want to sell you guys on, like, trying BTCD. And I want to 147 00:17:34,720 --> 00:17:39,840 talk about, like, these five different things about BTCD that I think are good. And that I 148 00:17:39,840 --> 00:17:44,400 do believe that they are better than Bitcoin core and other alt implementations as well. 149 00:17:45,440 --> 00:17:54,400 First of all, code that's much, much, much easier to understand. And Bitcoin D has also onboarded 150 00:17:54,400 --> 00:18:00,560 very important prominent figures to the Bitcoin ecosystem as well. So, again, I'm going to quote 151 00:18:00,560 --> 00:18:05,920 Roast Beef. So, this is what he said to me in a call a few years back. He said, yeah, BTCD code 152 00:18:05,920 --> 00:18:12,400 is much better than Bitcoin cores. And at the time, I was very confused. Because when we did the 153 00:18:12,400 --> 00:18:18,000 IBD benchmarking, BTCD code was much worse than Bitcoin cores. So, I was like, oh, are you sure 154 00:18:18,000 --> 00:18:27,200 about that? But now that I think of it, I think he meant in that, hey, like, Bitcoin cores code 155 00:18:27,200 --> 00:18:35,760 wasn't written to be read. BTCD code was written to be read. This is another quote from Tad Schreijer, 156 00:18:35,760 --> 00:18:40,960 who was in the audience. Yeah, I could kind of read BTCD code. But Bitcoin core is kind of 157 00:18:40,960 --> 00:18:49,040 difficult, because it's C++. So, that is two very prominent people in Bitcoin that BTCD has 158 00:18:49,040 --> 00:18:55,200 onboarded onto Bitcoin. If BTCD didn't exist, these people wouldn't have been working on Bitcoin. And 159 00:18:55,200 --> 00:19:02,720 I think that speaks for itself. Okay. He's like saying, okay, but fine, fair enough. Moving on. 160 00:19:04,000 --> 00:19:09,760 I want to do a case study. I wanted to sort of point out, it's like, I wanted to give an example 161 00:19:09,760 --> 00:19:18,320 of BTCD code that is written in a much easier to understand way. And so, block index traversals. So, 162 00:19:18,320 --> 00:19:24,000 in Bitcoin core, or in Bitcoin consensus, you would have the, if you, there are times where 163 00:19:24,000 --> 00:19:30,240 you need to just go back a couple blocks. And so, what each block node has is it has a parent 164 00:19:30,240 --> 00:19:35,440 pointer. So, this is just a linked list. And so, it has a parent pointer, so you can move back. 165 00:19:36,000 --> 00:19:43,920 So, one of the requests could be given block 10, fetch block 2. So, when you're at block 10, 166 00:19:43,920 --> 00:19:50,560 you would just go back. Like, right? 9, 8, 7, 6, 5, 4, 2. And then you get at 2. So, that's how you 167 00:19:50,560 --> 00:20:00,560 would do things. But let's say at block 900,000, fetch height 6. This is a much more expensive 168 00:20:00,560 --> 00:20:06,160 operation. And this would be way too slow to just go back one block at a time. So, we're not going 169 00:20:06,160 --> 00:20:13,120 to do that. So, each block index entry has a parent pointer and it also has a skip pointer, 170 00:20:13,120 --> 00:20:21,280 which is which allows you to skip many, many blocks back. So, like, for this specific example, 171 00:20:21,280 --> 00:20:27,920 let's just define many blocks as a floor of divided by 2. So, if we do the same example again 172 00:20:28,560 --> 00:20:35,040 with block 10 and then fetch heights 2, you have block 10, you go back to block 5 because 173 00:20:35,040 --> 00:20:40,560 block 10 divided by 2 is 5, right? So, you have that skip. So, you skip once. And then at 5, 174 00:20:40,560 --> 00:20:46,800 you divide it by 2 and you take the floor, which is 2. And then now, you have block 2. So, that 175 00:20:46,800 --> 00:20:54,320 is a lot of reduction in the traversals that you have to do. So, yeah. How was this implemented 176 00:20:54,320 --> 00:21:02,640 in both BTCD and Bitcoin Core? This is BTCD, right? You could sort of look at it and like you 177 00:21:02,640 --> 00:21:07,360 could sort of like read through and be like, yeah, this is like pretty easy code, right? 178 00:21:08,160 --> 00:21:11,120 I think it's pretty. I wrote that code. So, I think it's pretty easy code. 179 00:21:12,800 --> 00:21:19,760 But then let's look at Bitcoin Cores, right? It's a mess. It's hard to see the mess. I zoomed into 180 00:21:19,760 --> 00:21:27,200 the mess. Can any of you who works on Bitcoin Core here? Yeah, yeah, yeah, yeah. Do you know, 181 00:21:27,200 --> 00:21:33,680 have you seen that code? Do you know what that code does? Exactly. What is the minus 2 for, 182 00:21:34,480 --> 00:21:43,280 right? Like, what is this? Sipa wrote that code, by the way. So, we have these brilliant engineers 183 00:21:43,840 --> 00:21:48,400 that write code in brilliant ways that only their brilliant minds understand. 184 00:21:49,440 --> 00:21:58,320 It's a normal pleb like me, I don't know what that code does. And so, like, this code that I wrote, 185 00:22:00,160 --> 00:22:07,040 other plebs can also read it. It's easier to validate. And it's easier to get a grasp on what 186 00:22:07,040 --> 00:22:14,560 the actual code is doing. So, anyway, sorry for calling you guys out on that. But, yeah, like, 187 00:22:14,560 --> 00:22:22,320 BTCD code is much, much easier to read. Second reason is that BTCD has, like, these static builds 188 00:22:22,320 --> 00:22:30,880 and we have good distribution across numerous operating systems. So, static builds, you smoosh 189 00:22:30,880 --> 00:22:36,240 everything together. There's no dynamic loading of libraries in the operating system. So, if you 190 00:22:36,240 --> 00:22:43,440 have the binary, it will run anywhere. So, because of this and because of how Go supports so many 191 00:22:43,440 --> 00:22:52,400 different platforms, BTCD for each release has 31 different targets that we support. And we support 192 00:22:52,960 --> 00:23:01,680 weird operating systems such as Dragonfly. That's the first time I've seen that. And we also support 193 00:23:01,680 --> 00:23:08,400 weird architectures such as MIPS. And, yeah, so, like, lots of different platforms. So, 194 00:23:10,160 --> 00:23:15,280 if you're a nerd and you run LoomOS because it has Dtrace and it has lots of tracing 195 00:23:15,920 --> 00:23:20,000 capabilities in the operating system, then, yeah, you can run it. For Bitcoin Core, it doesn't 196 00:23:20,000 --> 00:23:29,040 support BSDs that well. So, your only other option would be BTCD. Third reason why I think BTCD does 197 00:23:29,040 --> 00:23:35,600 better or where I think BTCD does better is openness towards features. So, this is, again, 198 00:23:37,360 --> 00:23:42,320 so, if I were to quote him, he said, I want BTCD to be a node implementation where new features 199 00:23:42,320 --> 00:23:49,760 arrive first. And we have been doing this. So, this is one of the PRs that are open and that I 200 00:23:49,760 --> 00:23:55,600 need to get back to for merging. And so, we implemented this new thing called Swift Sync 201 00:23:55,600 --> 00:24:03,280 and the reception has been very positive. And barring any delays, I think we'll have this in 202 00:24:03,280 --> 00:24:08,960 the next few months. Other things is, like, yeah, Electrum server. It's, like, yeah, like, 203 00:24:09,920 --> 00:24:13,200 Electrum server is not the best thing in the world, but, yeah, we can have it because it's 204 00:24:13,200 --> 00:24:19,120 an optional thing that we can have in BTCD. In Bitcoin Core, if you wanted to do this, 205 00:24:19,120 --> 00:24:24,320 it's, like, hey, we take a look at the address space index. We don't want address index. It's, 206 00:24:24,320 --> 00:24:31,200 like, Greg Maxwell, we don't want this address index. And one of the things that points out is 207 00:24:31,200 --> 00:24:37,520 that Bitcoin Core's code is not very modular enough to separate these things out and it'll 208 00:24:37,520 --> 00:24:45,440 be difficult to support for where, you know, this address index has only a few users and it becomes 209 00:24:45,440 --> 00:24:52,400 a maintenance burden. But for BTCD, the way the indexes are implemented, it's very clean. It's 210 00:24:52,400 --> 00:25:00,880 very modular. And so, this was back in 2014 and this is how Roastbeef got into BTCD by implementing 211 00:25:00,880 --> 00:25:02,080 the address indexer. 212 00:25:02,265 --> 00:25:14,265 So, this is, yeah, now, in January of 2015, Roastbeef implemented the address index and now we have address index and because of how the things were implemented in a very modular way, we're able to support these features. 213 00:25:14,265 --> 00:25:24,265 So, with this address index, we have these now new websites. This is called BTCD.watch. You can go on there right now and check it out. 214 00:25:24,265 --> 00:25:36,265 This is a block explorer and a mempool based on BTCD. And it's just the only node back end that you need is just BTCD. 215 00:25:36,265 --> 00:25:49,265 I could sell you guys on the fact that it's Canadian made. It's by Suheb from Lightning Labs. And so, it's Canadian made and operated. So, if you guys want to check that out. 216 00:25:50,265 --> 00:26:00,265 So, yeah. So, we're able to have these features like the address index because it's very modular. 217 00:26:00,265 --> 00:26:09,265 So, this is a diagram of the different dependencies of how different packages are imported within BTCD. 218 00:26:10,265 --> 00:26:21,265 These are the main packages that are able to be reused across different systems. And these packages that you see here are used everywhere. 219 00:26:21,265 --> 00:26:33,265 If you write Bitcoin code in Go, you are using one of these packages. And because of this modularity that we have, we have code that's impactful across the ecosystem. 220 00:26:34,265 --> 00:26:42,265 So, this is not an exhaustive list of things that use BTCD or things that depend on BTCD. 221 00:26:42,265 --> 00:26:50,265 Of course, you have a lot of Lightning Labs on there. But you have things like the Bitbox app, like the Bitbox Wallet app. 222 00:26:50,265 --> 00:27:01,265 You have things like ArcD. The proto-fleets is the mining software by Block. And that is also importing BTCD code. 223 00:27:01,265 --> 00:27:05,265 So, BTCD code is pretty influential across the ecosystem. 224 00:27:08,265 --> 00:27:15,265 Now, I do want to point out, if things are so great about BTCD, why wouldn't you want to use them? 225 00:27:15,265 --> 00:27:21,265 There are two historical cons about BTCD that I think are getting better. 226 00:27:21,265 --> 00:27:28,265 One is performance. I think some of you guys know about these blog posts from Jameson Knopp. 227 00:27:28,265 --> 00:27:31,265 He goes through and tests different Bitcoin implementations. 228 00:27:31,265 --> 00:27:39,265 And this was his latest one, which Bitcoin Core on his machine took 12 hours to sync the entire chain with checking signatures. 229 00:27:39,265 --> 00:27:44,265 And BTCD took 3 days, 11 hours, and 28 minutes. 230 00:27:44,265 --> 00:27:52,265 And I do want to point out that we have gotten a lot, lot better about performance on BTCD. 231 00:27:53,265 --> 00:27:59,265 So, there's three things. You have the block download logic. So, how fast are you able to download blocks? 232 00:27:59,265 --> 00:28:04,265 Two, you have the signature validation efficiency. How fast are you able to validate the signatures? 233 00:28:04,265 --> 00:28:09,265 And then, finally, it's like the TX read and write, which is the UTXO. 234 00:28:09,265 --> 00:28:15,265 Hey, I need to write this UTXO and I need to fetch this UTXO to be able to validate a transaction. 235 00:28:15,265 --> 00:28:22,265 So, that is really slow. We're working on it. That is really slow. We're working on it. 236 00:28:22,265 --> 00:28:26,265 But that is actually fast on BTCD. 237 00:28:26,265 --> 00:28:31,265 And this has been work that's spanned over multiple years. 238 00:28:31,265 --> 00:28:34,265 Stephen Roos in the back started this off. 239 00:28:34,265 --> 00:28:38,265 And we've been implementing, we've been getting a lot better. 240 00:28:38,265 --> 00:28:45,265 So, I don't have a lot of time, but this is validation, or benchmarks that I did against Bitcoin Core. 241 00:28:45,265 --> 00:28:49,265 And BTCD is actually faster if you're not validating signatures. 242 00:28:49,265 --> 00:28:53,265 And if you give a lot of hardware. 243 00:28:53,265 --> 00:28:56,265 And this is even better. This is with the SwiftSync PR. 244 00:28:56,265 --> 00:28:58,265 And we're, like, way faster. 245 00:28:58,265 --> 00:29:02,265 But, you know, if we're validating signatures, we are way slower than Bitcoin Core. 246 00:29:02,265 --> 00:29:04,265 So, that is something that we need to work on. 247 00:29:04,265 --> 00:29:09,265 So, that is the commands I use. If you want to validate my work, you can do that. 248 00:29:09,265 --> 00:29:11,265 That's the computer that I had to validate. 249 00:29:11,265 --> 00:29:15,265 Finally, for the cons of BTCD was that there's not enough reviewers. 250 00:29:15,265 --> 00:29:17,265 And there's been a lot of bugs. 251 00:29:17,265 --> 00:29:19,265 And I do admit that. 252 00:29:19,265 --> 00:29:23,265 Like, the quality of the code is not as high. 253 00:29:23,265 --> 00:29:26,265 It's not as good as Bitcoin Core's. 254 00:29:26,265 --> 00:29:28,265 But that's where you guys come in. 255 00:29:28,265 --> 00:29:34,265 And you should review PRs on BTCD, so that we get better code across the Bitcoin ecosystem. 256 00:29:34,265 --> 00:29:38,265 That's my slides. That's it. Thank you, guys, for attending. 257 00:29:38,265 --> 00:29:41,265 Do we have time for questions? 258 00:29:45,265 --> 00:29:46,265 Okay, one question. 259 00:29:46,265 --> 00:29:48,265 One question from the audience? 260 00:29:49,265 --> 00:29:52,265 These are my slides. If you want them, you can scan. 261 00:29:54,265 --> 00:29:56,265 Thank you. 262 00:29:57,265 --> 00:30:00,265 And you partly said it a bit as well. 263 00:30:00,265 --> 00:30:06,265 I think the examples where you pointed out that you blame Bitcoin Core or core developers, 264 00:30:06,265 --> 00:30:10,265 they were mostly issues with VIPs, I would rather say, right? 265 00:30:10,265 --> 00:30:13,265 So, it seemed like there were things that were under-specified in VIPs. 266 00:30:13,265 --> 00:30:18,265 And then it was implemented differently in BTCD than in Bitcoin Core. 267 00:30:18,265 --> 00:30:24,265 And it felt like it wasn't really right or wrong, clearly, to make out. 268 00:30:24,265 --> 00:30:29,265 So, wouldn't you say rather that there's an issue with VIPs than with Bitcoin Core in these cases? 269 00:30:29,265 --> 00:30:34,265 And then that the VIPs should just be fixed up and it's like a broader conversation 270 00:30:34,265 --> 00:30:39,265 rather than just blaming core for doing things differently? 271 00:30:39,265 --> 00:30:42,265 Fair enough, yeah. We could say that. 272 00:30:42,265 --> 00:30:45,265 It's under the same organization, right? 273 00:30:47,265 --> 00:30:49,265 Right. Well, thank you, guys. 274 00:30:50,265 --> 00:30:51,265 Thank you. 275 00:30:55,265 --> 00:30:56,265 Thank you. 276 00:31:07,265 --> 00:31:12,265 Thank you. I'm Andrew Toth. I'm a Bitcoin Core developer. 277 00:31:12,265 --> 00:31:15,265 And I'm here to talk about parallel input fetching. 278 00:31:15,265 --> 00:31:20,265 So, this talk is about PR35295 if you follow Bitcoin Core development. 279 00:31:21,265 --> 00:31:24,265 And it took over two years to get merged, over a thousand review comments. 280 00:31:24,265 --> 00:31:27,265 So, it was a really big effort from a lot of people to get this in. 281 00:31:27,265 --> 00:31:30,265 But we can say happily that it's been merged. 282 00:31:30,265 --> 00:31:38,265 So, we'll see this improvement in Bitcoin Core version 32 that is coming out this fall. 283 00:31:39,265 --> 00:31:41,265 So, what is this change exactly? 284 00:31:41,265 --> 00:31:46,265 It's a low-level plumbing change to Bitcoin Core specifically, the specific implementation. 285 00:31:46,265 --> 00:31:49,265 So, it doesn't have any changes to the Bitcoin protocol. 286 00:31:49,265 --> 00:31:52,265 So, it's not really relevant to any implementation. 287 00:31:53,265 --> 00:32:00,265 We can't take this implementation and use it on implementations that don't have a UTXO set. 288 00:32:00,265 --> 00:32:04,265 So, it doesn't apply to things like UTREXO or LibBitcoin. 289 00:32:04,265 --> 00:32:08,265 But it speeds up IBD as well as steady-state block validation. 290 00:32:08,265 --> 00:32:13,265 So, if you get a new block at tip from a miner, we can validate it a lot faster now as well. 291 00:32:13,265 --> 00:32:20,265 For any user running Bitcoin Core and likely nodes that are based on Bitcoin Core, 292 00:32:20,265 --> 00:32:23,265 like forks of Bitcoin Core, if they pull in this change in the future. 293 00:32:25,265 --> 00:32:29,265 So, it's kind of a confusing name, parallel input fetching. 294 00:32:29,265 --> 00:32:31,265 We're not actually fetching inputs. 295 00:32:31,265 --> 00:32:33,265 We're fetching input prevouts. 296 00:32:33,265 --> 00:32:37,265 So, I'm sure a lot of you are familiar with some of this stuff already. 297 00:32:37,265 --> 00:32:41,265 But I'm going to go over it to build up to how we make this efficiency change. 298 00:32:41,265 --> 00:32:44,265 So, every transaction has inputs and outputs. 299 00:32:44,265 --> 00:32:49,265 Valid inputs, they must point to a previous out point, which we shorten to prevout. 300 00:32:49,265 --> 00:32:51,265 Inputs are references, right? 301 00:32:51,265 --> 00:32:56,265 So, the prevouts that are being spent are not included with the transaction. 302 00:32:56,265 --> 00:33:02,265 It's up to the node's implementation to go look up this data from however it's being stored. 303 00:33:02,265 --> 00:33:06,265 And so, in Bitcoin Core, we have what's called the UTXO set. 304 00:33:07,265 --> 00:33:14,265 So, it stores all unspent prevouts or unspent transaction out points, the UTXOs, in a set. 305 00:33:14,265 --> 00:33:17,265 And so, they're also referred to as coins. 306 00:33:17,265 --> 00:33:20,265 So, you can say you're spending a UTXO or you're spending a coin. 307 00:33:20,265 --> 00:33:27,265 And this is an optimization that Bitcoin Core does primarily for this optimization called pruning, right? 308 00:33:27,265 --> 00:33:31,265 So, what we can do here when we connect a block and we get these UTXOs, 309 00:33:31,265 --> 00:33:35,265 if we just store the UTXOs, we can discard the rest of that block data. 310 00:33:35,265 --> 00:33:41,265 And that has all the information we need to then continue validating future blocks. 311 00:33:41,265 --> 00:33:45,265 I mean, you might want that block data for other information to look up things, 312 00:33:45,265 --> 00:33:48,265 but you don't actually need it to continue being a validating node. 313 00:33:48,265 --> 00:33:53,265 So, that lets you run Bitcoin Core with a much smaller disk footprint. 314 00:33:53,265 --> 00:33:56,265 So, it's easier to use it on smaller devices. 315 00:33:56,265 --> 00:33:58,265 And even, like, big devices. 316 00:33:58,265 --> 00:34:06,265 So, today, if you're not running pruned, you will probably not be able to run Bitcoin Core on a 1TB disk drive anymore. 317 00:34:06,265 --> 00:34:08,265 So, pruning lets you do that. 318 00:34:08,265 --> 00:34:12,265 So, this is kind of what it looks like at a very, very high level, right? 319 00:34:12,265 --> 00:34:15,265 So, we have the chain state that is represented by the UTXO set. 320 00:34:15,265 --> 00:34:18,265 So, we have in the chain state UTXO A. 321 00:34:18,265 --> 00:34:24,265 And if we're going to connect this new transaction, spending input A and creating output B, 322 00:34:24,265 --> 00:34:27,265 when we connect this, it does an atomic operation on the chain state. 323 00:34:27,265 --> 00:34:31,265 So, it'll delete UTXO A because it's no longer unspent. 324 00:34:31,265 --> 00:34:33,265 Now, it's just a TXO. 325 00:34:33,265 --> 00:34:36,265 And it will create UTXO B. 326 00:34:36,265 --> 00:34:41,265 And that's the new state of the chain state after this transaction has been connected. 327 00:34:41,265 --> 00:34:44,265 And so, there's lots of these UTXOs, right? 328 00:34:44,265 --> 00:34:46,265 There's billions, I think. 329 00:34:46,265 --> 00:34:48,265 And we can expect lots more in the future, right? 330 00:34:48,265 --> 00:34:55,265 Because anytime you receive a payment on chain, someone's created a UTXO, right? 331 00:34:55,265 --> 00:34:56,265 And so, we expect more users. 332 00:34:56,265 --> 00:34:58,265 We're going to get more UTXOs. 333 00:34:58,265 --> 00:35:01,265 And so, there's way too many to store in memory. 334 00:35:01,265 --> 00:35:11,265 So, like every block, like we can store the block index in memory because every block that comes in just has a small entry for where the block is stored. 335 00:35:11,265 --> 00:35:13,265 And that's less than a million today. 336 00:35:13,265 --> 00:35:17,265 But every block can also create tens of thousands of UTXOs potentially. 337 00:35:17,265 --> 00:35:19,265 So, we have to store these in a database. 338 00:35:19,265 --> 00:35:27,265 And then, if we're connecting a block, though, that's a lot of reading of those UTXOs, writing new UTXOs, and deleting UTXOs. 339 00:35:27,265 --> 00:35:30,265 And we can't just do all that directly into the database. 340 00:35:30,265 --> 00:35:31,265 That would be very slow. 341 00:35:31,265 --> 00:35:38,265 It's like orders of magnitude, several orders of magnitude slower to write to disk than it would be to just do this all in memory. 342 00:35:38,265 --> 00:35:42,265 So, we have this optimization called the UTXO cache. 343 00:35:42,265 --> 00:35:47,265 So, when a new block is connected, we read through the cache first. 344 00:35:47,265 --> 00:35:51,265 So, if this UTXO is in the cache, we don't have to go to disk. 345 00:35:51,265 --> 00:35:54,265 And if new UTXOs are created by this block, they stay in the cache. 346 00:35:54,265 --> 00:35:56,265 We don't have to write them yet. 347 00:35:56,265 --> 00:35:59,265 And new UTXOs are marked fresh. 348 00:35:59,265 --> 00:36:03,265 And that allows us to have another optimization. 349 00:36:03,265 --> 00:36:05,265 So, this is kind of how it looks like. 350 00:36:05,265 --> 00:36:09,265 If you just start up your node, you have this empty cache, and it's pointing to the database. 351 00:36:09,265 --> 00:36:14,265 So, now, when we want to validate this new transaction, we don't actually read the database. 352 00:36:14,265 --> 00:36:16,265 We read into the cache first. 353 00:36:16,265 --> 00:36:19,265 So, we're like, do we have input A, UTXO A? 354 00:36:19,265 --> 00:36:21,265 So, the cache will check that it doesn't have it. 355 00:36:21,265 --> 00:36:30,265 So, it goes to the database, reads the UTXO into the cache, and then we can spend it and then create UTXO B in the cache. 356 00:36:30,265 --> 00:36:32,265 But we don't do any writes here. 357 00:36:32,265 --> 00:36:36,265 And so, this allows us another optimization that I like to call UTXO cut-through. 358 00:36:36,265 --> 00:36:43,265 So, when the next block spends a fresh UTXO that doesn't exist in the database, we can just delete it from the cache. 359 00:36:43,265 --> 00:36:46,265 We never have to write it to the database. 360 00:36:46,265 --> 00:36:50,265 And this is a really big performance improvement here, right? 361 00:36:50,265 --> 00:36:52,265 So, we have UTXO B as fresh. 362 00:36:52,265 --> 00:36:54,265 It doesn't exist in the database. 363 00:36:54,265 --> 00:37:05,265 And then when another transaction comes in that's spending UTXO B, we can just delete UTXO B from the cache and write UTXO C. 364 00:37:05,265 --> 00:37:07,265 And so, we never have to touch the database here. 365 00:37:07,265 --> 00:37:15,265 This makes connecting blocks a lot faster already before this new efficiency change we're going to talk about. 366 00:37:15,265 --> 00:37:21,265 So, we do have to actually sync this stuff to disk at some point, right, to store all the UTXOs. 367 00:37:21,265 --> 00:37:23,265 And so, when do we do this? 368 00:37:23,265 --> 00:37:25,265 There's two times we do this. 369 00:37:25,265 --> 00:37:30,265 Well, two main events where we will write to the disk, right, is when the DB cache fills up. 370 00:37:30,265 --> 00:37:32,265 So, right now it's bounded by memory. 371 00:37:32,265 --> 00:37:34,265 It's a gigabyte in size. 372 00:37:34,265 --> 00:37:39,265 So, as we add more UTXOs to the cache, eventually we're going to get to a size limit. 373 00:37:39,265 --> 00:37:41,265 And then we'll have to write everything to disk. 374 00:37:41,265 --> 00:37:44,265 And then we wipe that cache. 375 00:37:44,265 --> 00:37:54,265 And then if we haven't flushed the cache in a long time, we also sync all this data to the database every hour. 376 00:37:54,265 --> 00:37:57,265 So, in that case, though, we don't clear the cache. 377 00:37:57,265 --> 00:38:01,265 We just keep the unspent UTXOs in memory. 378 00:38:01,265 --> 00:38:02,265 And that will look like this. 379 00:38:02,265 --> 00:38:03,265 So, say we have this cache here. 380 00:38:03,265 --> 00:38:06,265 We have a spent UTXO A and a fresh UTXO C. 381 00:38:06,265 --> 00:38:09,265 And now we want to sync this to the database. 382 00:38:09,265 --> 00:38:16,265 So, in order, from top to bottom, we'll have to go and we first delete that UTXO A from the database. 383 00:38:16,265 --> 00:38:20,265 And then we can remove that from the cache so our cache gets lighter. 384 00:38:20,265 --> 00:38:23,265 And then we write UTXO C to the database. 385 00:38:23,265 --> 00:38:28,265 And then we have to remove that fresh flag from our entry C there. 386 00:38:28,265 --> 00:38:33,265 And now our database and our cache are perfectly in sync. 387 00:38:33,265 --> 00:38:34,265 And we still have UTXO C in memory. 388 00:38:34,265 --> 00:38:38,265 So, next time we want to read it, it's going to be a lot cheaper. 389 00:38:38,265 --> 00:38:42,265 And if you're interested in the code, this is in the coins header file. 390 00:38:42,265 --> 00:38:44,265 This is the coins cache entry here. 391 00:38:44,265 --> 00:38:47,265 So, it has the coin struct and the flags. 392 00:38:47,265 --> 00:38:51,265 So, dirty flag means it's different from the database. 393 00:38:51,265 --> 00:38:52,265 So, we have to write it. 394 00:38:52,265 --> 00:38:55,265 And then a fresh flag means it's also new. 395 00:38:55,265 --> 00:38:57,265 So, we can just delete it if we spend it. 396 00:38:57,265 --> 00:39:05,265 And so, the validation code actually has an abstract interface to this UTXO set, this coins view. 397 00:39:05,265 --> 00:39:07,265 We just call this the coins view, right? 398 00:39:07,265 --> 00:39:10,265 So, the validation code doesn't know anything about this caching. 399 00:39:10,265 --> 00:39:14,265 And this is all just a very low-level implementation of what we're doing here. 400 00:39:14,265 --> 00:39:18,265 And so, it can just call to get a coin, see if we have a coin, 401 00:39:18,265 --> 00:39:22,265 write the flush to disk if we need to. 402 00:39:22,265 --> 00:39:26,265 But validation code, this is outside the scope of that. 403 00:39:26,265 --> 00:39:28,265 This is just low-level plumbing stuff. 404 00:39:28,265 --> 00:39:35,265 And so, this is some more C++ code where we have the coins view cache and the coins view DB 405 00:39:35,265 --> 00:39:38,265 that are extending from the coins view. 406 00:39:38,265 --> 00:39:43,265 And so, we have the coins view cache backed by the database. 407 00:39:43,265 --> 00:39:47,265 And so, now, that's basically how our caching works. 408 00:39:47,265 --> 00:39:51,265 So, how do we use this when we want to validate this block, right? 409 00:39:51,265 --> 00:39:53,265 And this is where we're going to see these speedups. 410 00:39:53,265 --> 00:39:59,265 So, first, when we get a new block from a peer, we have to do a context list check. 411 00:39:59,265 --> 00:40:06,265 So, we check things that don't depend on UTXO set, like the size limit, the proof of works, and the Merkle trees. 412 00:40:06,265 --> 00:40:10,265 And once we have that all done, then we have to move on to actually checking the context. 413 00:40:10,265 --> 00:40:13,265 Like, do all these UTXOs exist? 414 00:40:13,265 --> 00:40:16,265 And are they being validly spent? 415 00:40:16,265 --> 00:40:19,265 And so, that's where we have this ephemeral cache. 416 00:40:19,265 --> 00:40:21,265 So, now, we have a stack of caches. 417 00:40:21,265 --> 00:40:27,265 We put this extra cache on top of the main cache before we call connect block. 418 00:40:27,265 --> 00:40:32,265 And we do this because we don't know yet if this block is going to be valid or not, right? 419 00:40:32,265 --> 00:40:37,265 So, as we're creating new inputs and spending inputs, 420 00:40:37,265 --> 00:40:40,265 if we just did that right in the main cache for every block we got 421 00:40:40,265 --> 00:40:43,265 and we found out this block was invalid right in the middle, 422 00:40:43,265 --> 00:40:48,265 then we'd have to walk back every output that we created 423 00:40:48,265 --> 00:40:51,265 and, like, find those spent coins and re-add them. 424 00:40:51,265 --> 00:40:52,265 And that gets really messy. 425 00:40:52,265 --> 00:40:54,265 So, we just have this, like, scratch space on top. 426 00:40:54,265 --> 00:40:56,265 And it looks like this, right? 427 00:40:56,265 --> 00:40:59,265 So, we have this new block coming in that we're going to validate. 428 00:40:59,265 --> 00:41:03,265 And so, we have our empty overlay scratch space that backs to the cache, 429 00:41:03,265 --> 00:41:05,265 and then that backs into the database. 430 00:41:05,265 --> 00:41:11,265 So, if we're going to validate this block, we'll go through each transaction in order. 431 00:41:11,265 --> 00:41:13,265 And we'll have to validate each one, right? 432 00:41:13,265 --> 00:41:17,265 So, the first transaction is spending UTXO A. 433 00:41:17,265 --> 00:41:19,265 So, we read that from the cache. 434 00:41:19,265 --> 00:41:22,265 Then we spend it, and we create UTXO B. 435 00:41:22,265 --> 00:41:28,265 The next transaction, we read UTXO C into the overlay, spend it, and create UTXO D. 436 00:41:28,265 --> 00:41:32,265 Then this third one, we're spending UTXO D, but we already have that in the overlay. 437 00:41:32,265 --> 00:41:35,265 So, we can just delete that and cut through. 438 00:41:35,265 --> 00:41:39,265 So, we can cut through on the overlay too, and these will never even hit the cache. 439 00:41:39,265 --> 00:41:44,265 Then we create UTXO E, and then this last one, the cache doesn't have UTXO F. 440 00:41:44,265 --> 00:41:46,265 So, we have to do this really long lookup. 441 00:41:46,265 --> 00:41:48,265 And this is what takes a lot of time, right? 442 00:41:48,265 --> 00:41:52,265 Because we have to go all the way to disk, the database, read that into the cache, 443 00:41:52,265 --> 00:41:57,265 allocate space in the cache for this, and then read it into the overlay. 444 00:41:57,265 --> 00:41:59,265 And now, finally, we can spend it. 445 00:41:59,265 --> 00:42:05,265 And so, that takes a lot of time, but now we have all this block validated into our overlay. 446 00:42:06,265 --> 00:42:10,265 If this block was invalid, we could just discard this overlay. 447 00:42:10,265 --> 00:42:14,265 And so, that makes it a lot cleaner because nothing in the cache was changed. 448 00:42:14,265 --> 00:42:16,265 So, now, say it's valid. 449 00:42:16,265 --> 00:42:20,265 Now, we want to write this new block data to our cache. 450 00:42:20,265 --> 00:42:24,265 So, we'll have to go again through the block here. 451 00:42:24,265 --> 00:42:26,265 We write that to the cache. 452 00:42:26,265 --> 00:42:28,265 We write the new UTXOs. 453 00:42:28,265 --> 00:42:32,265 We delete any fresh entries. 454 00:42:32,265 --> 00:42:38,265 And then, now, we have all this written to the cache, and we can just get rid of the overlay. 455 00:42:38,265 --> 00:42:40,265 So, that's how we do it today. 456 00:42:40,265 --> 00:42:47,265 And we go through every entry in order, and we read them all from the disk or the cache. 457 00:42:47,265 --> 00:42:50,265 And so, let's say our cache was empty. 458 00:42:50,265 --> 00:42:52,265 This is where it gets really, really slow, right? 459 00:42:52,265 --> 00:42:54,265 We have everything on database. 460 00:42:54,265 --> 00:43:00,265 So, for every entry you want to get, you have to go all the way to the database. 461 00:43:00,265 --> 00:43:04,265 And so, this read takes a long time, this one read from the database. 462 00:43:04,265 --> 00:43:06,265 And we have to do that in sequence. 463 00:43:06,265 --> 00:43:10,265 So, as we're waiting for that read, nothing can be validating at the same time. 464 00:43:10,265 --> 00:43:19,265 So, this takes a long time, and this really slows down the block validation and IVD speed. 465 00:43:19,265 --> 00:43:25,265 And so, that's a big problem, especially for high latency disks. 466 00:43:25,265 --> 00:43:31,265 If you're running on AWS and you're running an EC2 instance, it takes a millisecond for each of those reads. 467 00:43:31,265 --> 00:43:35,265 So, if you have 10,000 inputs, that's like 10 seconds just to validate a block. 468 00:43:35,265 --> 00:43:39,265 And this is causing a lot of problems for users, right? 469 00:43:39,265 --> 00:43:43,265 They're complaining about very slow IVD time, very slow block connections. 470 00:43:43,265 --> 00:43:46,265 So, what we want to do is have something like this. 471 00:43:46,265 --> 00:43:51,265 So, if we already know what the block is, and we know what inputs we're going to want to read, 472 00:43:51,265 --> 00:43:55,265 we just want to do a full read of everything into our overlay at once, 473 00:43:55,265 --> 00:43:58,265 and then we don't have to worry about all that round tripping, right? 474 00:43:58,265 --> 00:44:00,265 And that's going to speed up things a lot. 475 00:44:00,265 --> 00:44:04,265 So, then we can just put everything into the overlay at once, and then we have everything there, we can validate much faster. 476 00:44:04,265 --> 00:44:13,265 So, say we have everything in the database, we can just pull everything in from the database into the overlay and go faster. 477 00:44:13,265 --> 00:44:16,265 So, that's where this idea comes from, right? 478 00:44:16,265 --> 00:44:20,265 So, before we enter the connect block, that's where we do the validation. 479 00:44:20,265 --> 00:44:22,265 So, we already know all the inputs of the block. 480 00:44:22,265 --> 00:44:26,265 So, we don't know if this block is valid or not, but we know all the inputs that it's going to be asking for. 481 00:44:26,265 --> 00:44:29,265 So, we can flatten all those inputs into a list, 482 00:44:29,265 --> 00:44:35,265 and then we have parallel worker threads going to the disk or the cache to get these UTXOs 483 00:44:35,265 --> 00:44:40,265 and insert them into the order that the overlay is going to want them. 484 00:44:40,265 --> 00:44:43,265 So, we have eight worker threads by default, configurable up to 16. 485 00:44:43,265 --> 00:44:49,265 So, if you have a slower disk, you might want to configure even more worker threads. 486 00:44:49,265 --> 00:44:53,265 So, they atomically each just fetch these inputs as we're doing the validation. 487 00:44:53,265 --> 00:44:59,265 And they don't insert to the cache, they insert into the top-level overlays list. 488 00:44:59,265 --> 00:45:04,265 And so, the validation code doesn't have to wait on any of these reads. 489 00:45:04,265 --> 00:45:12,265 It can just keep validating and then just grab the next UTXO from the list and increment the tail. 490 00:45:12,265 --> 00:45:15,265 So, it will go to the list on the main thread. 491 00:45:15,265 --> 00:45:20,265 So, this is a lock-free, multi-producer, single-consumer queue. 492 00:45:20,265 --> 00:45:25,265 Each entry has an atomic flag that gets set by the workers, 493 00:45:25,265 --> 00:45:33,265 and then the validation code waits on that flag so that there's no data racing. 494 00:45:33,265 --> 00:45:36,265 And so, it looks like this. 495 00:45:36,265 --> 00:45:40,265 So, we have this block coming in, the overlay now has these worker threads and this input list. 496 00:45:40,265 --> 00:45:46,265 And so, the first input it wants to get is input A, and that will be in the first entry of this list. 497 00:45:46,265 --> 00:45:50,265 So, at first, it initially has to wait like it did before, 498 00:45:50,265 --> 00:45:53,265 but all these workers are now fetching the inputs in parallel. 499 00:45:53,265 --> 00:45:58,265 So, as soon as the first worker gets the first UTXO, it writes it into the first slot. 500 00:45:58,265 --> 00:46:01,265 The overlay can just take that and start validating the code. 501 00:46:01,265 --> 00:46:05,265 Meanwhile, as the overlay is working, the other workers are also still fetching this stuff 502 00:46:05,265 --> 00:46:08,265 and putting it into the list here. 503 00:46:08,265 --> 00:46:12,265 And so, as the overlay keeps validating and going through, 504 00:46:12,265 --> 00:46:15,265 all the workers are done now putting all these UTXOs in the list, 505 00:46:15,265 --> 00:46:19,265 and the overlay never even has to go to the cache or the database. 506 00:46:19,265 --> 00:46:24,265 And this is a big performance improvement. 507 00:46:24,265 --> 00:46:28,265 And so, this is all done in CoinsViewOverlay, also in the coins header file. 508 00:46:28,265 --> 00:46:31,265 So, here we have this, if you want to check out the code, 509 00:46:31,265 --> 00:46:35,265 input to fetch is each entry in that inputs list, 510 00:46:35,265 --> 00:46:38,265 and then we have the head of the list and the tail, 511 00:46:38,265 --> 00:46:42,265 which is how the workers and the main thread synchronize. 512 00:46:42,265 --> 00:46:45,265 Process input is how we atomically fetch these, 513 00:46:45,265 --> 00:46:48,265 so each worker is just calling process input over and over and over 514 00:46:48,265 --> 00:46:50,265 until all the inputs are fetched, 515 00:46:50,265 --> 00:46:53,265 and then the validation code is calling fetch coin from base 516 00:46:53,265 --> 00:46:58,265 to fetch these instead of going and reading them from the cache. 517 00:46:58,265 --> 00:47:01,265 And this is what we call when we get the block, 518 00:47:01,265 --> 00:47:04,265 to kick off the workers to just call process input. 519 00:47:04,265 --> 00:47:10,265 We flatten all the inputs of the block into the list and kick them off. 520 00:47:10,265 --> 00:47:13,265 And so, this is a graph by Lawrence, 521 00:47:13,265 --> 00:47:16,265 who was benchmarking this on all kinds of different platforms. 522 00:47:16,265 --> 00:47:24,265 So, the three different quadrants here are different configurations. 523 00:47:24,265 --> 00:47:26,265 The default one is on the left, though, 524 00:47:26,265 --> 00:47:29,265 so if you're running, say, an M4 Max, 525 00:47:29,265 --> 00:47:32,265 he measures it as over three times faster than a laptop, 526 00:47:32,265 --> 00:47:34,265 which is a huge performance improvement. 527 00:47:34,265 --> 00:47:36,265 It was like 100 minutes. 528 00:47:36,265 --> 00:47:41,265 It's like an hour and 40 minutes to sync the entire blockchain. 529 00:47:41,265 --> 00:47:45,265 Raspberry Pi 5 was 46% faster, 530 00:47:45,265 --> 00:47:48,265 so big performance improvements there. 531 00:47:48,265 --> 00:47:50,265 And then on network-attached storage, 532 00:47:50,265 --> 00:47:52,265 so if you're running on AWS, 533 00:47:52,265 --> 00:47:56,265 so a lot of nodes on the network are all running on AWS today. 534 00:47:56,265 --> 00:48:00,265 You can see it from AS map charts, right? 535 00:48:00,265 --> 00:48:02,265 And when you run a node on AWS, 536 00:48:02,265 --> 00:48:04,265 you have network-connected storage, 537 00:48:04,265 --> 00:48:06,265 which is very slow, very low latency. 538 00:48:06,265 --> 00:48:09,265 It's like single-digit milliseconds per read. 539 00:48:09,265 --> 00:48:12,265 And so, this is where we see a huge improvement. 540 00:48:12,265 --> 00:48:18,265 So, the blue line is the read throughput of the previous version, 541 00:48:18,265 --> 00:48:20,265 where we're doing it single-threaded. 542 00:48:20,265 --> 00:48:22,265 You can see it never actually gets to read much, 543 00:48:22,265 --> 00:48:24,265 and it takes forever. 544 00:48:25,265 --> 00:48:30,265 And the first green line is running with four worker threads, 545 00:48:30,265 --> 00:48:33,265 and so it finishes much quicker. 546 00:48:33,265 --> 00:48:37,265 I noticed when I was benchmarking this that it finished so quickly, 547 00:48:37,265 --> 00:48:39,265 and so I ran it again with eight threads, 548 00:48:39,265 --> 00:48:41,265 which is the next one, 549 00:48:41,265 --> 00:48:44,265 and that one finished at about the same time the original one did. 550 00:48:44,265 --> 00:48:48,265 So, it was about five times faster running it on AWS, 551 00:48:48,265 --> 00:48:50,265 which is a huge speed-up. 552 00:48:50,265 --> 00:48:53,265 And what else is interesting about this graph 553 00:48:53,265 --> 00:48:57,265 is that where you see this huge spike in read throughput, 554 00:48:57,265 --> 00:48:59,265 that's where a lot of... 555 00:48:59,265 --> 00:49:01,265 That starts at around block 800,000. 556 00:49:01,265 --> 00:49:05,265 So, the first 800,000 blocks were already pretty efficient, 557 00:49:05,265 --> 00:49:07,265 but what happened around block 800,000, 558 00:49:07,265 --> 00:49:10,265 there was a lot more UTXOs being created on the network, 559 00:49:10,265 --> 00:49:14,265 which really slowed down a lot of users running nodes. 560 00:49:14,265 --> 00:49:17,265 Like, a lot of users were really complaining 561 00:49:17,265 --> 00:49:21,265 about all the spam causing IBD to get really slow. 562 00:49:21,265 --> 00:49:23,265 And you can see that from the chart, right? 563 00:49:23,265 --> 00:49:28,265 Because 90% of the syncing time was just the last 100,000 blocks. 564 00:49:28,265 --> 00:49:31,265 So, this change fixes that, right? 565 00:49:31,265 --> 00:49:33,265 So, now we can write lots of UTXOs, 566 00:49:33,265 --> 00:49:38,265 and spam is no longer really a problem for syncing your node. 567 00:49:38,265 --> 00:49:43,265 And so, this will be going, hopefully, live in sometime this fall, 568 00:49:43,265 --> 00:49:46,265 when we release version 32. 569 00:49:46,265 --> 00:49:48,265 Yeah, thank you. 570 00:49:48,265 --> 00:49:50,265 Thank you. 571 00:49:53,265 --> 00:49:55,265 Any questions? 572 00:49:58,265 --> 00:50:00,265 No? So, thank you so much. 573 00:50:09,407 --> 00:50:10,407 We have a question. 574 00:50:18,407 --> 00:50:22,407 I just wanted to ask you, I think you're not working on Bitcoin Core full-time, is that correct? 575 00:50:23,407 --> 00:50:26,407 Yeah, I have a part-time grant from OpenSats. 576 00:50:27,407 --> 00:50:28,407 Cool. 577 00:50:28,407 --> 00:50:30,407 Thanks for doing that work. 578 00:50:30,407 --> 00:50:36,407 I'm wondering what was your experience with that as a sort of like a part-timer coming into this gigantic codebase? 579 00:50:36,407 --> 00:50:39,407 I noticed it was a two-year effort. 580 00:50:39,407 --> 00:50:42,407 How did that go? 581 00:50:42,407 --> 00:50:45,407 And are you working on multiple PRs in parallel? 582 00:50:45,407 --> 00:50:49,407 Or was this like your core thing, your main thing you were trying to do? 583 00:50:49,407 --> 00:50:52,407 Or do you, yeah, how did that go? 584 00:50:52,407 --> 00:50:58,407 So, well, I disconnected, but I had a... 585 00:50:58,407 --> 00:51:01,407 And how did you get roped into two years worth of work? 586 00:51:01,407 --> 00:51:04,407 Well, so I've been working on Bitcoin Core for a long time. 587 00:51:04,407 --> 00:51:06,407 I was always passionate and interested about it. 588 00:51:06,407 --> 00:51:10,407 So, I've been, this is not my first change. 589 00:51:10,407 --> 00:51:12,407 I've worked on performance improvements and caching. 590 00:51:12,407 --> 00:51:17,407 So, a lot of the caching talk I was doing, I was built based on experience. 591 00:51:17,407 --> 00:51:22,407 I have had, you know, improving that over the years. 592 00:51:22,407 --> 00:51:26,407 So, this is just something that I noticed was a problem for a long time. 593 00:51:26,407 --> 00:51:38,407 And it took a lot of convincing people to take it seriously and try and get it in, which was a lot of work. 594 00:51:38,407 --> 00:51:44,407 But, yeah, I'm definitely very passionate about continuing working on Bitcoin Core. 595 00:51:44,407 --> 00:51:52,407 We have more performance improvements in the pipeline as well, specifically around indexing. 596 00:51:52,407 --> 00:51:58,407 So, right now, the transaction index is a very large database, and it doesn't let you use it in prune. 597 00:51:58,407 --> 00:52:03,407 So, hopefully, in version 32, we'll also be able to shrink that considerably. 598 00:52:03,407 --> 00:52:08,407 And then in future versions, we'll be able to run all the indexes in prune mode. 599 00:52:08,407 --> 00:52:15,407 So, those are some of the things I'm working on as well. 600 00:52:15,407 --> 00:52:35,407 Okay. Thank you. 601 00:52:35,407 --> 00:52:36,407 Good morning, everyone. 602 00:52:36,407 --> 00:52:40,407 Today, I will be presenting the ARK Round Signing Ceremony. 603 00:52:40,407 --> 00:52:47,407 The ARK Round Signing Ceremony is the fundamental building block of ARK. 604 00:52:47,407 --> 00:52:58,407 It's what makes the protocol what it is, and it is the source of the VTXOs, which you use to transact in the ARK. 605 00:52:58,407 --> 00:53:03,407 It is the ARK Round Signing Ceremony, which builds the timeout tree. 606 00:53:03,407 --> 00:53:10,407 And it is the ARK timeout tree, which grants you absolute self-custody of your VTXOs. 607 00:53:10,407 --> 00:53:14,407 So, the system is not trustodial, it's not custodial. 608 00:53:14,407 --> 00:53:17,407 You can always exit the system unilaterally. 609 00:53:17,407 --> 00:53:25,407 And it is the first cause of your VTXOs, meaning this is where your VTXOs come from. 610 00:53:25,407 --> 00:53:26,407 Almost everyone. 611 00:53:27,407 --> 00:53:30,407 You can board directly into the ARK, which will get you a VTXO. 612 00:53:30,407 --> 00:53:38,407 But most of the VTXOs which you will interact with come from a previous round. 613 00:53:38,407 --> 00:53:44,407 The round is a three-phase process driven by the round state machine. 614 00:53:44,407 --> 00:53:48,407 First, you collect payments of everybody who will be participating in the round. 615 00:53:48,407 --> 00:53:52,407 Then, there is the signing ceremony of the VTXO tree. 616 00:53:52,407 --> 00:53:55,407 And then, finally, the round is finished. 617 00:53:56,407 --> 00:54:00,407 So, now we have three ARK implementations in the ecosystem. 618 00:54:00,407 --> 00:54:05,407 We have Bark, Arcade, and Wavelength now by Lightning Labs. 619 00:54:05,407 --> 00:54:09,407 And you'll notice that all of them use VTXOs. 620 00:54:09,407 --> 00:54:15,407 So, this same shape, this same fundamental structure is present across all of these protocols. 621 00:54:15,407 --> 00:54:21,407 They may use different language, but there is intermittent timeout trees which happen on-chain, 622 00:54:21,407 --> 00:54:27,407 which require refreshes, and they all follow the same similar structure. 623 00:54:28,407 --> 00:54:30,407 ARK rounds are powered by Taproot. 624 00:54:30,407 --> 00:54:36,407 So, Taproot was activated in Bitcoin on Mainnet in November 2021. 625 00:54:36,407 --> 00:54:42,407 It consists of BIP-340, BIP-341, and BIP-342. 626 00:54:42,407 --> 00:54:47,407 And all three of these BIPs are used in ARK in these rounds. 627 00:54:48,407 --> 00:54:52,407 This is a great monetary use case of Taproot. 628 00:54:52,407 --> 00:54:57,407 So, you have a tree that happens for these off-chain outputs, and they look like Taproot spends. 629 00:54:57,407 --> 00:55:03,407 So, this is a really good monetary use case of the Taproot update. 630 00:55:04,407 --> 00:55:14,407 Now, we mentioned that the Taproot rounds happen intermittently, or periodically, better to say. 631 00:55:14,407 --> 00:55:20,407 So, the tree has a limited lifespan, and you will participate in them periodically. 632 00:55:20,407 --> 00:55:27,407 For example, an ARK round could happen once every hour, so you could have 24 rounds per day. 633 00:55:28,407 --> 00:55:35,407 And you enter into a round in order to perform a refresh, because your VTXOs will expire. 634 00:55:36,407 --> 00:55:41,407 Each round's tree has a finite lifespan, so when you construct a tree, 635 00:55:41,407 --> 00:55:46,407 all of the VTXOs on that tree are all going to expire together on the same date. 636 00:55:46,407 --> 00:55:50,407 But the VTXOs do not all have to refresh together. 637 00:55:50,407 --> 00:55:57,407 The VTXOs from one tree, they can be refreshed in various different trees later on. 638 00:55:58,407 --> 00:56:03,407 You re-enter the future rounds before expiry, and participating in a round is a good thing. 639 00:56:03,407 --> 00:56:08,407 You want to participate in a round. It's what keeps your self-custody alive. 640 00:56:10,407 --> 00:56:14,407 To walk you through this, I'm using the canonical ARK round from the Bark test suite. 641 00:56:15,407 --> 00:56:20,407 The demonstration I'm going to show you today comes from a real file in the Bark library. 642 00:56:20,407 --> 00:56:25,407 You can find it in testing, testbarkround.rs, so you can try this at home. 643 00:56:26,407 --> 00:56:31,407 And it uses the Rust Bitcoin kernel project, which is Bitcoin Core's consensus engine, 644 00:56:31,407 --> 00:56:35,407 to prove the tree is consensus valid in the test. 645 00:56:36,407 --> 00:56:40,407 This version I'm showing you today is pinned to Bark 0.4.0. 646 00:56:40,407 --> 00:56:43,407 That's the round we're going to showcase today. 647 00:56:43,407 --> 00:56:48,407 There's three phases. Phase 1, Phase 2, and Phase 3. 648 00:56:48,407 --> 00:56:51,407 In Phase 1, you're collecting participants. 649 00:56:51,407 --> 00:56:59,407 The coordinator, or the ARK server, gathers everybody who is going to participate in the round in Step 1. 650 00:56:59,407 --> 00:57:03,407 Then they all co-sign the tree together in Step 2. 651 00:57:03,407 --> 00:57:09,407 Once the round is finished, this will broadcast into an on-chain transaction. 652 00:57:13,407 --> 00:57:19,407 Hello? 653 00:57:19,407 --> 00:57:47,407 Oh, we're back on the screen. 654 00:57:47,407 --> 00:57:48,407 Very good. 655 00:57:48,407 --> 00:57:52,407 I put these four dots between all of the three different phases 656 00:57:52,407 --> 00:57:55,407 to show that each of these phases is transforming. 657 00:57:55,407 --> 00:57:59,407 It has an input and it has an output for each of the phases. 658 00:57:59,407 --> 00:58:03,407 I gave them four different images. 659 00:58:03,407 --> 00:58:09,407 At the beginning, collecting payments, you take the round participant registration, 660 00:58:09,407 --> 00:58:11,407 so all the old VTXOs. 661 00:58:11,407 --> 00:58:14,407 These are VTXOs that came from various different trees. 662 00:58:14,407 --> 00:58:15,407 They might have different weights. 663 00:58:15,407 --> 00:58:16,407 They have different histories. 664 00:58:16,407 --> 00:58:22,407 Some of them may have been transacted with many times, some not at all. 665 00:58:22,407 --> 00:58:23,407 They're inconsistent. 666 00:58:23,407 --> 00:58:25,407 They're irregular. 667 00:58:25,407 --> 00:58:28,407 Phase 1 will transform them. 668 00:58:28,407 --> 00:58:36,407 It takes that, receives all those old VTXOs, and creates an unsigned proposed tree. 669 00:58:36,407 --> 00:58:39,407 Then Phase 2, the signing of the tree, it takes as an input, 670 00:58:39,407 --> 00:58:44,407 it takes the unsigned tree, and then you get a signed timeout tree. 671 00:58:44,407 --> 00:58:50,407 Once the round is complete, that gets broadcast as an on-chain transaction. 672 00:58:50,407 --> 00:58:51,407 There it goes. 673 00:58:51,407 --> 00:58:54,407 Phase 1 is bringing you from there to there. 674 00:58:54,407 --> 00:58:58,407 Phase 2 and Phase 3. 675 00:58:58,407 --> 00:59:03,407 Now, I'm going to use the three phases to construct a diagram of the round. 676 00:59:03,407 --> 00:59:06,407 We have Steps 1, 2, and 3 at the bottom. 677 00:59:06,407 --> 00:59:10,407 You have this pivotal point at the intersection of Steps 1 and 2. 678 00:59:10,407 --> 00:59:13,407 After you've done collecting the payments and the registrants, 679 00:59:13,407 --> 00:59:19,407 but before the tree is signed, this is arguably the most pivotal point in the round 680 00:59:19,407 --> 00:59:23,407 because this is where the unsigned tree is proposed. 681 00:59:23,407 --> 00:59:32,407 Everything that comes after this point is bringing this proposed tree into completion. 682 00:59:32,407 --> 00:59:37,407 I use the analogy of consolidation up to this point and expansion afterwards. 683 00:59:37,407 --> 00:59:44,407 It's like you're inhaling in all the inputs, and then you exhale out, and there's an expansion. 684 00:59:44,407 --> 00:59:48,407 Periodically, breathing is a good thing. 685 00:59:48,407 --> 00:59:50,407 You take a new breath, it's something that you want to do. 686 00:59:50,407 --> 00:59:56,407 It's not bad to have rounds and intermittent refreshes. 687 00:59:56,407 --> 00:59:59,407 This is beneficial for the system. 688 00:59:59,407 --> 01:00:01,407 Here's one more diagram I show. 689 01:00:01,407 --> 01:00:06,407 Step 1 is the inhale process, bringing together all of the previous participants, 690 01:00:06,407 --> 01:00:13,407 gathering everyone, and then Steps 2 and 3 is exhale. 691 01:00:13,407 --> 01:00:19,407 At the far left of this diagram, you see I have the old VTXOs coming in. 692 01:00:19,407 --> 01:00:22,407 They're not coming in in a nice tree structure. 693 01:00:22,407 --> 01:00:25,407 They come in irregularly, like you're getting this VTXO from here. 694 01:00:25,407 --> 01:00:27,407 There, it's a little bit messy. 695 01:00:27,407 --> 01:00:33,407 Then the signing of the tree happens, and then there's a proposed tree that comes out. 696 01:00:33,407 --> 01:00:37,407 You have a root transaction at the bottom, which comes into a node, 697 01:00:37,407 --> 01:00:40,407 and then you have the new VTXOs at the end. 698 01:00:40,407 --> 01:00:45,407 At the end of the expansion, you have a fully signed tree that's ready to broadcast. 699 01:00:45,407 --> 01:00:51,407 I'll remove the actual helpers of the three steps. 700 01:00:51,407 --> 01:00:53,407 You can see here's the image. 701 01:00:53,407 --> 01:00:56,407 You have old VTXOs coming in from different sources. 702 01:00:56,407 --> 01:00:59,407 They may have come from previous different trees. 703 01:00:59,407 --> 01:01:01,407 They come participate in the round together. 704 01:01:01,407 --> 01:01:08,407 Then you have this new rigid structure of the timeout tree, which you can use. 705 01:01:08,407 --> 01:01:10,407 Visually, here's a diagram that you would see. 706 01:01:10,407 --> 01:01:17,407 That new VTXO, it goes, it lives its life, and then there is another tree waiting for it. 707 01:01:17,407 --> 01:01:23,407 The destiny, the final cause of one of those VTXOs that's from the previous tree, 708 01:01:23,407 --> 01:01:29,407 it will come to be an input of another future round. 709 01:01:29,407 --> 01:01:33,407 You'll notice that the arc rounds is not a chain. 710 01:01:33,407 --> 01:01:35,407 Arc is not a side chain. 711 01:01:35,407 --> 01:01:39,407 You'll notice that there's not a linear sequence of rounds, 712 01:01:39,407 --> 01:01:42,407 but rather they're scattered irregularly. 713 01:01:42,407 --> 01:01:45,407 I really made sure to show that they're not all aligned vertically either, 714 01:01:45,407 --> 01:01:50,407 to show these different rounds, they can happen in different orders. 715 01:01:53,407 --> 01:01:57,407 For example, here at the bottom, in the third round from the top, 716 01:01:57,407 --> 01:02:01,407 we have two VTXOs coming into this round from that one, 717 01:02:01,407 --> 01:02:04,407 and then one from the top one, one from the middle one. 718 01:02:04,407 --> 01:02:08,407 They can be arranged in many different configurations. 719 01:02:08,407 --> 01:02:11,407 They can get a little bit messy if you start to map it out. 720 01:02:11,407 --> 01:02:13,407 You can see this starts to become more complex. 721 01:02:13,407 --> 01:02:17,407 But if I can trace a line, I can trace a green line, 722 01:02:17,407 --> 01:02:21,407 and you can follow money through the system. 723 01:02:21,407 --> 01:02:25,407 The VTXOs themselves are ephemeral. 724 01:02:25,407 --> 01:02:27,407 They come and go. You know you forfeit them. 725 01:02:27,407 --> 01:02:31,407 They get refreshed. You get a new, different VTXO in exchange. 726 01:02:31,407 --> 01:02:34,407 But the money lives on through the rounds. 727 01:02:34,407 --> 01:02:38,407 Here at the end, we have a new VTXO at the far right, highlighted in green. 728 01:02:38,407 --> 01:02:43,407 If you follow that path all the way through one, two, three, four previous rounds, 729 01:02:43,407 --> 01:02:49,407 you can see which VTXO you started off with in the very beginning. 730 01:02:49,407 --> 01:02:54,407 Now there are sub-steps of these three phases of the rounds, 731 01:02:54,407 --> 01:02:56,407 which I will be walking you through today. 732 01:02:56,407 --> 01:02:59,407 I'm also going to highlight how these are all specific to Taproot, 733 01:02:59,407 --> 01:03:04,407 and this was made possible through Bitcoin's latest consensus change. 734 01:03:04,407 --> 01:03:09,407 In phase one of collecting the payments, the server opens up in a tent. 735 01:03:09,407 --> 01:03:15,407 It mints a one-time co-sign key, and the round begins, 736 01:03:15,407 --> 01:03:18,407 and it starts to gather all of the participants. 737 01:03:18,407 --> 01:03:22,407 The participants submit their payments, and the server collects them. 738 01:03:22,407 --> 01:03:25,407 This is all happening off-chain. This is the layer two part. 739 01:03:25,407 --> 01:03:30,407 These are not on-chain transactions that the VTXO holders are making. 740 01:03:30,407 --> 01:03:33,407 This is all happening off-chain. 741 01:03:33,407 --> 01:03:38,407 They participate. They give their old VTXOs. 742 01:03:38,407 --> 01:03:40,407 They submit. They get their place in the round. 743 01:03:40,407 --> 01:03:44,407 Then phase one ends with the unsigned proposed tree, 744 01:03:44,407 --> 01:03:48,407 which is proposed by the coordinator, or the ARC server, 745 01:03:48,407 --> 01:03:51,407 or the captain that is putting this all together. 746 01:03:51,407 --> 01:03:54,407 What are the parameters of the round? 747 01:03:54,407 --> 01:03:57,407 At the beginning of the round, the expiry height is set. 748 01:03:57,407 --> 01:04:02,407 All the different VTXOs gathered in that round, they all have a shared lifespan. 749 01:04:02,407 --> 01:04:06,407 For example, 4,032 blocks. 750 01:04:06,407 --> 01:04:12,407 Every VTXO in that tree, they will all expire on the same date, 751 01:04:12,407 --> 01:04:15,407 approximately 28 days from now. 752 01:04:16,407 --> 01:04:20,407 The exit delta is also set, and then also the server's pub key is there, 753 01:04:20,407 --> 01:04:23,407 because when you're using ARC, you're using a particular ARC. 754 01:04:23,407 --> 01:04:28,407 You cannot reuse the same VTXOs across different implementations, 755 01:04:28,407 --> 01:04:31,407 but even within the same implementation, 756 01:04:31,407 --> 01:04:36,407 if you have two different ARC servers, you're associated with a particular one. 757 01:04:36,407 --> 01:04:40,407 What do the participants give the coordinator? 758 01:04:41,407 --> 01:04:43,407 They're giving their input VTXOs, 759 01:04:43,407 --> 01:04:48,407 the requests of which VTXO they will receive in the refresh, 760 01:04:48,407 --> 01:04:52,407 their music to public nonces, and their participation mode. 761 01:04:52,407 --> 01:04:57,407 Either they're participating in the round interactively, or this is delegated. 762 01:04:57,407 --> 01:05:01,407 They can delegate their refresh to another party, 763 01:05:01,407 --> 01:05:06,407 so that they do not have to be online at the specific time of the round. 764 01:05:07,407 --> 01:05:11,407 I've created a little video demonstration. 765 01:05:11,407 --> 01:05:13,407 It should appear here. 766 01:05:28,407 --> 01:05:30,407 Here are 16 old VTXOs. 767 01:05:30,407 --> 01:05:33,407 You notice I structured them in a way that's staggered, 768 01:05:33,407 --> 01:05:35,407 so they all have different sources. 769 01:05:35,407 --> 01:05:37,407 They may have come from different trees. 770 01:05:49,407 --> 01:05:52,407 The payments are registered, 771 01:05:52,407 --> 01:05:55,407 and they all come together, 772 01:05:55,407 --> 01:05:59,407 and a tree is proposed. 773 01:05:59,407 --> 01:06:02,407 There's an unsigned tree now. 774 01:06:03,407 --> 01:06:08,407 All the participants at this level can see where they will be, 775 01:06:08,407 --> 01:06:12,407 but none of the signatures have been applied yet. 776 01:06:12,407 --> 01:06:15,407 How is Taproot used here? 777 01:06:15,407 --> 01:06:19,407 The tree spec contains the nodes paid to Taproot output. 778 01:06:19,407 --> 01:06:24,407 What's very important about this is that you have the key path and the script path. 779 01:06:24,407 --> 01:06:27,407 Before Taproot, you had two different transaction types 780 01:06:27,407 --> 01:06:29,407 for key spends and script spends, 781 01:06:29,407 --> 01:06:33,407 and Taproot brought them together into a single transaction type. 782 01:06:33,407 --> 01:06:35,407 That's how this is used. 783 01:06:35,407 --> 01:06:37,407 You're constructing one transaction, 784 01:06:37,407 --> 01:06:41,407 where you can do cooperative key spends together with the coordinator, 785 01:06:41,407 --> 01:06:43,407 or you can also go uncooperatively. 786 01:06:43,407 --> 01:06:45,407 You can broadcast an exit. 787 01:06:45,407 --> 01:06:48,407 You can do a script spend to get your money out of the system. 788 01:06:48,407 --> 01:06:52,407 The music, too, comes from BIP 340. 789 01:06:52,407 --> 01:06:55,407 Phase 2 begins now. 790 01:06:55,407 --> 01:06:57,407 We have the signing of the tree. 791 01:06:57,407 --> 01:07:01,407 Each participant returns their partial signatures for their branch of the tree. 792 01:07:01,407 --> 01:07:05,407 We're going to do another visualization of this for you to see as well. 793 01:07:05,407 --> 01:07:10,407 They're forfeiting their old VTXOs in exchange for what they will receive, 794 01:07:10,407 --> 01:07:13,407 and the server will then co-sign with them, 795 01:07:13,407 --> 01:07:15,407 and a signed tree is created. 796 01:07:15,407 --> 01:07:18,407 I'll load the next video. 797 01:07:18,407 --> 01:07:29,407 I'm going to pause right here at the beginning. 798 01:07:29,407 --> 01:07:36,407 You'll notice that each of these are the VTXOs at the top. 799 01:07:36,407 --> 01:07:40,407 Everyone applies their individual signature to those VTXOs, 800 01:07:40,407 --> 01:07:44,407 and then this node transaction of the tree has four signatures. 801 01:07:44,407 --> 01:07:47,407 It has four keys because all of the participants, 802 01:07:47,407 --> 01:07:50,407 they are signing their way all the way up the tree. 803 01:07:50,407 --> 01:07:54,407 Down here, the root transaction has 16 signatures from the participants, 804 01:07:54,407 --> 01:07:56,407 four on each of the nodes, 805 01:07:56,407 --> 01:08:01,407 and then one on each of their individual VTXOs. 806 01:08:01,407 --> 01:08:06,407 They're forfeiting their old VTXOs together as they're signing the new ones, 807 01:08:06,407 --> 01:08:13,407 and you have in blue, this is the signature of the coordinator, 808 01:08:13,407 --> 01:08:15,407 the ARC server or the captain. 809 01:08:15,407 --> 01:08:19,407 ARC server comes and is the second one here. 810 01:08:19,407 --> 01:08:24,407 It's the fifth and the 17th signature on all of them. 811 01:08:24,407 --> 01:08:26,407 Now you have the signature aggregation, 812 01:08:26,407 --> 01:08:29,407 so all of those different co-signatures come together, 813 01:08:29,407 --> 01:08:35,407 and you complete this step with an unbroadcast but fully signed tree. 814 01:08:35,407 --> 01:08:37,407 Now, how is taproot used here? 815 01:08:37,407 --> 01:08:40,407 You can see the whole thing is BIP 340 Schnorr signatures. 816 01:08:40,407 --> 01:08:42,407 We have the signature aggregation, 817 01:08:43,407 --> 01:08:45,407 and these signatures authorize the key path, 818 01:08:45,407 --> 01:08:48,407 so if I want to do cooperative things in the ARC, 819 01:08:48,407 --> 01:08:51,407 like, for example, make a payment, an ARC payment, 820 01:08:51,407 --> 01:08:54,407 if I want to do a swap and make a Lightning payment, 821 01:08:54,407 --> 01:08:57,407 this all happens cooperatively through the key spend, 822 01:08:57,407 --> 01:08:59,407 and if I want to leave the system, 823 01:08:59,407 --> 01:09:01,407 I want to broadcast a unilateral exit, 824 01:09:01,407 --> 01:09:05,407 that's coming from the script spend. 825 01:09:05,407 --> 01:09:07,407 And finally, we have phase three. 826 01:09:07,407 --> 01:09:10,407 The round is finished. Time to broadcast. 827 01:09:10,407 --> 01:09:13,407 So first thing that happens is it persists, 828 01:09:13,407 --> 01:09:16,407 so the rounds and the signed transactions 829 01:09:16,407 --> 01:09:18,407 are written to the database before it's broadcast. 830 01:09:18,407 --> 01:09:22,407 The VTXOs are formally created, so to speak, 831 01:09:22,407 --> 01:09:28,407 and the transaction is signed by the ARC server and broadcast. 832 01:09:30,407 --> 01:09:32,407 Play this video. 833 01:09:41,407 --> 01:09:47,407 Here's it persisting. Individual VTXOs are finalized. 834 01:09:49,407 --> 01:09:52,407 The on-chain transaction is signed, 835 01:09:52,407 --> 01:09:55,407 and you'll notice it's only the signature of the ARC server here. 836 01:09:55,407 --> 01:09:58,407 The individual participants are just signing their exit paths. 837 01:09:58,407 --> 01:10:02,407 They're signing the tree itself, and the round is now complete. 838 01:10:02,407 --> 01:10:07,407 It's broadcast on-chain, and users will receive their VTXOs, 839 01:10:08,407 --> 01:10:10,407 and they can start transacting with them. 840 01:10:10,407 --> 01:10:12,407 So how is Taproot used here? 841 01:10:12,407 --> 01:10:16,407 BIP-341, we have the pay-to-Taproot output, 842 01:10:16,407 --> 01:10:20,407 we have the Tapscript exit paths, 843 01:10:20,407 --> 01:10:23,407 and here's a final image of what that looks like. 844 01:10:23,407 --> 01:10:25,407 You'll notice that in the round transaction, 845 01:10:25,407 --> 01:10:28,407 you have the zeroth output there. 846 01:10:28,407 --> 01:10:33,407 That is the Taproot output from which the root of the tree is coming, 847 01:10:33,407 --> 01:10:36,407 and the input, it's the CaptainD wallet. 848 01:10:36,407 --> 01:10:37,407 This is the round's wallet. 849 01:10:37,407 --> 01:10:42,407 This is the ARC server funding the round on-chain. 850 01:10:42,407 --> 01:10:45,407 And then you have change, which could come from that as well. 851 01:10:45,407 --> 01:10:49,407 And this is the final image of what's broadcast on-chain. 852 01:10:51,407 --> 01:10:54,407 The round asserts your absolute self-custody. 853 01:10:54,407 --> 01:10:57,407 Participating in a round is a good thing. 854 01:10:57,407 --> 01:10:59,407 It's the act of claiming that self-custody. 855 01:10:59,407 --> 01:11:01,407 It's not a custodial model. 856 01:11:01,407 --> 01:11:03,407 That timeout tree, it has an expiry, 857 01:11:03,407 --> 01:11:07,407 so you'll have to keep refreshing your funds through future trees. 858 01:11:07,407 --> 01:11:10,407 And just like breathing, inhale, exhale, 859 01:11:10,407 --> 01:11:13,407 each round is like one breath. 860 01:11:13,407 --> 01:11:16,407 And this is evidence of a proof 861 01:11:16,407 --> 01:11:19,407 of a true monetary use case for Taproot, 862 01:11:19,407 --> 01:11:23,407 which is Bitcoin's most racist consensus soft fork. 863 01:11:23,407 --> 01:11:24,407 Thank you. 864 01:11:25,407 --> 01:11:27,407 APPLAUSE 865 01:11:30,407 --> 01:11:32,407 So we have some time for questions. 866 01:11:42,407 --> 01:11:43,407 Me again. 867 01:11:43,407 --> 01:11:45,407 I'm wondering in practice right now, 868 01:11:45,407 --> 01:11:47,407 these trees, are they limited by... 869 01:11:47,407 --> 01:11:48,407 What size are they? 870 01:11:48,407 --> 01:11:51,407 Are they limited by the number of participants you have? 871 01:11:51,407 --> 01:11:55,407 Is there an upper bound to what the implementations are, 872 01:11:55,407 --> 01:11:56,407 like the number of people? 873 01:11:56,407 --> 01:12:00,407 You also mentioned sort of like a threshold 874 01:12:00,407 --> 01:12:03,407 at which the round would automatically trigger. 875 01:12:03,407 --> 01:12:07,407 Is that for a number of participants or for other things? 876 01:12:07,407 --> 01:12:10,407 So the number of participants, this is implementation-specific. 877 01:12:10,407 --> 01:12:14,407 And it's also a parameter which can be configured. 878 01:12:14,407 --> 01:12:16,407 So the ARC server can set, 879 01:12:16,407 --> 01:12:18,407 here's the max participants of a round. 880 01:12:18,407 --> 01:12:20,407 They have control over that. 881 01:12:21,407 --> 01:12:24,407 And for a round to automatically happen... 882 01:12:24,407 --> 01:12:28,407 No, the opportunity for a round comes every hour. 883 01:12:28,407 --> 01:12:33,407 So if there's no participants who want to come to the ARC server, 884 01:12:33,407 --> 01:12:36,407 then the round could be passed on. 885 01:12:36,407 --> 01:12:38,407 So let's say, OK, no round will happen now. 886 01:12:38,407 --> 01:12:40,407 Let's try again in an hour and see how many participants. 887 01:12:40,407 --> 01:12:43,407 OK, now the next hour comes and seven people are there 888 01:12:43,407 --> 01:12:47,407 and they're ready to submit to participate, 889 01:12:47,407 --> 01:12:49,407 then that round will happen. 890 01:12:49,407 --> 01:12:52,407 But they're not forced into a round, per se. 891 01:12:52,407 --> 01:12:55,407 If users come on early, they can delegate their refresh 892 01:12:55,407 --> 01:12:57,407 and then somebody else is going to come on their behalf 893 01:12:57,407 --> 01:12:59,407 and force them... 894 01:12:59,407 --> 01:13:01,407 I don't know if it's right to say, 895 01:13:01,407 --> 01:13:03,407 force them into a round, a particular one. 896 01:13:03,407 --> 01:13:06,407 But they can walk away and they will be entered into one 897 01:13:06,407 --> 01:13:08,407 that they're not actively in. 898 01:13:08,407 --> 01:13:11,407 That's a non-interactive. 899 01:13:11,407 --> 01:13:15,407 But I hope that answers your question. 900 01:13:15,407 --> 01:13:17,407 And how big are those trees at the moment? 901 01:13:18,407 --> 01:13:20,407 How many participants can you have? 902 01:13:20,407 --> 01:13:25,407 I guess the expiry and the exit gets pricier and pricier 903 01:13:25,407 --> 01:13:27,407 the bigger the tree. 904 01:13:27,407 --> 01:13:29,407 In practice, what does that look like right now? 905 01:13:29,407 --> 01:13:32,407 I'll get some empirical data to share with you. 906 01:13:35,407 --> 01:13:37,407 Any questions? 907 01:13:41,407 --> 01:13:44,407 The main limitation is that before we start the round, 908 01:13:44,407 --> 01:13:47,407 we kind of need to ask nonsense from the users. 909 01:13:47,407 --> 01:13:49,407 And depending on how many users will eventually show up, 910 01:13:49,407 --> 01:13:51,407 we need a different amount of nonsense. 911 01:13:51,407 --> 01:13:54,407 So we kind of limit it currently at 65,000 leaves, 912 01:13:54,407 --> 01:13:57,407 just so that we know that we only have to ask for 913 01:13:57,407 --> 01:14:00,407 four or eight whatever math nonsense from the users. 914 01:14:00,407 --> 01:14:03,407 But we could just ask more, but it's like a trade-off. 915 01:14:03,407 --> 01:14:05,407 Because the more data users have to submit, 916 01:14:05,407 --> 01:14:08,407 the more likely they are to have bandwidth problems. 917 01:14:08,407 --> 01:14:10,407 So we think currently 64,000 is fine. 918 01:14:10,407 --> 01:14:12,407 But yeah, we can easily grow it. 919 01:14:12,407 --> 01:14:14,407 It's not really... 920 01:14:14,407 --> 01:14:16,407 The protocol doesn't bound it. 921 01:14:21,407 --> 01:14:24,407 Can you talk a little about consensus proposals 922 01:14:24,407 --> 01:14:26,407 that will be useful for Arc? 923 01:14:26,407 --> 01:14:29,407 I understand that something like template hash could be useful. 924 01:14:29,407 --> 01:14:33,407 Would other proposals or other capabilities also be useful 925 01:14:33,407 --> 01:14:35,407 related to expiry or anything else? 926 01:14:36,407 --> 01:14:38,407 Yeah. 927 01:14:39,407 --> 01:14:43,407 One usability concern that people have with Arc is they say 928 01:14:43,407 --> 01:14:45,407 it's inconvenient for me to come online 929 01:14:45,407 --> 01:14:47,407 in order to participate in a round. 930 01:14:47,407 --> 01:14:50,407 They don't like that they have this liveness requirement. 931 01:14:50,615 --> 01:14:54,615 That they have to come participate either to delegate the refresh to somebody else on a monthly basis or themselves interactively participate in the round. 932 01:14:54,615 --> 01:15:02,615 So template hash or CTV, what these covenant proposals would do is they would remove the need for the user to come online. 933 01:15:02,615 --> 01:15:14,615 So a user would be able to put money into an Arc, participate into a round, and then they would be able to walk away and turn off their device for several months. 934 01:15:15,615 --> 01:15:21,615 And then they would be able to come back later and find that they're still within the Arc. 935 01:15:21,615 --> 01:15:25,615 That they have not been removed, their money has not been swept away from them. 936 01:15:25,615 --> 01:15:29,615 So covenant proposals would eliminate the liveness requirements from Arc. 937 01:15:29,615 --> 01:15:49,615 Hey, so just to understand from the server side, when you have those VTXOs and the round has been initiated with the tree, how do you deal with continuity issues if something happens to the server? 938 01:15:50,615 --> 01:15:55,615 Continuity issues. So the server is doing live, real-time backups. 939 01:15:55,615 --> 01:16:04,615 So if the server goes down, it has a database that exists off-chain which has backups. 940 01:16:04,615 --> 01:16:08,615 So we can bring the server back online and it can continue where it left off. 941 01:16:08,615 --> 01:16:15,615 So the file crashing would be able to, assuming there is a backup presence, you can pick up where you left off. 942 01:16:16,615 --> 01:16:17,615 Thank you. 943 01:16:23,615 --> 01:16:28,615 Just to be sure I got it, when you say participant, I guess you're speaking of Arc clients? 944 01:16:29,615 --> 01:16:30,615 Yes. 945 01:16:30,615 --> 01:16:31,615 Okay. 946 01:16:31,615 --> 01:16:34,615 So an Arc participant, that could be you with your mobile wallet. 947 01:16:34,615 --> 01:16:38,615 It could be a cashument, which is using an Arc client in order to power it. 948 01:16:38,615 --> 01:16:40,615 It could be a mobile money gateway. 949 01:16:40,615 --> 01:16:55,615 So the Arc server doesn't have conception of what are the different types of applications which are plugged into the clients, but be it an exchange doing payouts over Lightning, that's one example of a client, or an individual wallet. 950 01:16:55,615 --> 01:16:59,615 The person who is driving that client would be the participant. 951 01:16:59,615 --> 01:17:00,615 Yes. 952 01:17:03,615 --> 01:17:04,615 Thank you. 953 01:17:11,615 --> 01:17:23,615 Hey, how many transactions does it take to unwind the timeout tree, and then what are the timeouts of those transactions? 954 01:17:23,615 --> 01:17:28,615 So how long does it take to actually fully exit from a large Arc? 955 01:17:32,615 --> 01:17:37,615 So the amount of time it takes depends on how deep you are in the tree. 956 01:17:37,615 --> 01:17:41,615 So refreshing in a round brings you back to this reset state. 957 01:17:41,615 --> 01:17:44,615 You know, it minimizes your depth inside of the tree. 958 01:17:44,615 --> 01:17:55,615 If after a round you go and you start to make out-of-round transactions, you start to interact within the system, that can increase your depth in the tree because the tree is actually extending. 959 01:17:55,615 --> 01:17:59,615 And the deeper you are, the longer it'll take. 960 01:17:59,615 --> 01:18:03,615 I did mention a timeout, which is set for the round. 961 01:18:04,615 --> 01:18:12,615 I'm happy to refer you to some empirical exits which we've done that have some exact durations and costs. 962 01:18:17,615 --> 01:18:18,615 Any other questions? 963 01:18:21,615 --> 01:18:23,615 Okay, so thank you, Matthew. 964 01:18:33,615 --> 01:18:34,615 Thank you. 965 01:18:39,615 --> 01:18:40,615 Hi. 966 01:18:42,615 --> 01:18:49,615 Yeah, so I'm going to talk today about a Covenant BIP proposal that I've made with two of my colleagues. 967 01:18:49,615 --> 01:18:52,615 My name is Stephen Ruse, I'm at the bottom there. 968 01:18:52,615 --> 01:18:56,615 Antoine Poinsot and Greg Sanders are co-authors of this BIP. 969 01:18:56,615 --> 01:18:59,615 It's a Covenant BIP proposal. 970 01:18:59,615 --> 01:19:02,615 We're at the consensus edition of Bitcoin++, I think. 971 01:19:02,615 --> 01:19:09,615 You don't have to ask who knows what a Covenant is or who has heard of a Covenant, but who knows how Covenants work, has thought about them technically. 972 01:19:09,615 --> 01:19:11,615 Someone, you can raise your hand. 973 01:19:11,615 --> 01:19:12,615 Okay, very few people. 974 01:19:14,615 --> 01:19:22,615 So I'm going to very briefly explain a little bit what are Covenants, why we want them, and then a bit of some history of some earlier proposals that have been made, 975 01:19:22,615 --> 01:19:33,615 and then some motivation of why we decided to propose BIP448, which includes a few different opcodes that weren't proposed before. 976 01:19:33,615 --> 01:19:35,615 So what are Covenants? 977 01:19:35,615 --> 01:19:38,615 I like to think of Covenants in the following way. 978 01:19:38,615 --> 01:19:49,615 When we define the coins or the spending conditions in our Bitcoin wallets, we currently have a few options of how we can constrain these coins, how we can protect them. 979 01:19:49,615 --> 01:19:55,615 But there are always conditions that we put on the coins on what you need to fulfill to be able to spend these coins. 980 01:19:55,615 --> 01:19:59,615 For example, you can say, I need a signature from this specific pubkey. 981 01:19:59,615 --> 01:20:01,615 You can put time constraints. 982 01:20:01,615 --> 01:20:03,615 Closer to my mouth? Okay. 983 01:20:03,615 --> 01:20:10,615 You can put time constraints on your coins, like saying it can only be spent after this time, or you need to wait for a few months before you can spend them, stuff like that. 984 01:20:10,615 --> 01:20:14,615 We have opcodes to enforce these constraints. 985 01:20:15,615 --> 01:20:26,615 The model in which this works is usually that the inputs of the transaction always have witnesses that fulfill the policy of the output that they are spending. 986 01:20:26,615 --> 01:20:30,615 So each input needs to make sure that they fulfill the output that they are spending. 987 01:20:30,615 --> 01:20:39,615 But once this output is fulfilled, they can basically just take the money and do whatever they want with the money because they are the rightful owners of the money. 988 01:20:39,615 --> 01:20:43,615 With Covenants, you can basically do a different type of check. 989 01:20:43,615 --> 01:20:52,615 So instead of just expressing who or how you need to fulfill the coins, you can also limit in what way the coins can actually be spent. 990 01:20:52,615 --> 01:20:55,615 So not just, like, you need to do the signature and then you can do whatever you want. 991 01:20:55,615 --> 01:20:57,615 Also, like, well, you cannot just do whatever you want. 992 01:20:57,615 --> 01:20:59,615 You can only do specific things. 993 01:20:59,615 --> 01:21:05,615 So, for example, you can limit what new outputs can be created using the money that you are spending. 994 01:21:06,615 --> 01:21:15,615 And in this model, the policies of the inputs of the transaction can actually encumber and limit all of the outputs of the new transaction that you are making. 995 01:21:15,615 --> 01:21:19,615 Now, this might sound a little bit, like, abstract or a bit vague. 996 01:21:19,615 --> 01:21:22,615 So I'm going to try and give an example. 997 01:21:22,615 --> 01:21:24,615 At first, maybe, like, why is this useful? 998 01:21:24,615 --> 01:21:27,615 So, like, primarily, obviously, Bitcoin is programmable money. 999 01:21:27,615 --> 01:21:34,615 So if you can have more expressivity of what you can do with the money, obviously, you can be more programmable. 1000 01:21:34,615 --> 01:21:41,615 And this usually translates in better security, more, like, wallet policies that you can have. 1001 01:21:41,615 --> 01:21:46,615 Stuff like vaults are often discussed in the context of covenants. 1002 01:21:46,615 --> 01:21:48,615 Also, inheritance policies. 1003 01:21:48,615 --> 01:21:51,615 Basically, different ways to protect your wallet. 1004 01:21:51,615 --> 01:21:55,615 And then, obviously, also second-layer protocols. 1005 01:21:55,615 --> 01:22:02,615 So Lightning, ARC, BitVM, all these protocols kind of use the programmability that Bitcoin has to make them actually work. 1006 01:22:02,615 --> 01:22:06,615 And then have stuff that you can do off-chain without having to touch the block chain. 1007 01:22:06,615 --> 01:22:11,615 But using the primitives that the block chain has to make sure that these protocols are secure. 1008 01:22:11,615 --> 01:22:17,615 So with covenants, we can have better expressibility and better functionality in these layer 2 protocols as well. 1009 01:22:17,615 --> 01:22:20,615 So this might be a bit abstract. 1010 01:22:20,615 --> 01:22:28,615 So I'm going to use an example throughout my talk of a very specific covenant use case. 1011 01:22:29,615 --> 01:22:32,615 So imagine, like, you're a regular Bitcoin wallet user. 1012 01:22:32,615 --> 01:22:33,615 You have two kids. 1013 01:22:33,615 --> 01:22:34,615 They're named Alice and Bob. 1014 01:22:34,615 --> 01:22:36,615 Obviously, we will all name our kids Alice and Bob. 1015 01:22:36,615 --> 01:22:40,615 And you want to be able to use your wallet as a regular wallet. 1016 01:22:40,615 --> 01:22:43,615 You want to be able to just sign a transaction, send it to anyone you want. 1017 01:22:43,615 --> 01:22:48,615 But you also want to make sure that if you would die, that somehow your money would go to your kids. 1018 01:22:48,615 --> 01:22:56,615 Well, what you could do currently is you could have an additional key or a multisig of two keys, for example, that is activated after five years. 1019 01:22:56,615 --> 01:22:59,615 And then you put the keys of your two children there. 1020 01:22:59,615 --> 01:23:03,615 But for them to be able to spend this money, they would have to come together and agree on spending it. 1021 01:23:03,615 --> 01:23:06,615 Imagine your kids don't get along very well. 1022 01:23:06,615 --> 01:23:13,615 If you use the current strategy with a multisig key, then, for example, one of the two could say, well, I'm not signing. 1023 01:23:13,615 --> 01:23:15,615 So you cannot get your half of the money. 1024 01:23:15,615 --> 01:23:23,615 So with a covenant, what you can actually say, well, after five years, someone can just take this money and spread it into two outputs. 1025 01:23:23,615 --> 01:23:26,615 One for my one kid, one for my other kid, and no one can stop them. 1026 01:23:26,615 --> 01:23:29,615 So neither of them can stop the other one from doing this. 1027 01:23:29,615 --> 01:23:33,615 So specifically, what this means is, for example, you have a 10 Bitcoin UTXO. 1028 01:23:33,615 --> 01:23:35,615 You can just spend it by signing. 1029 01:23:35,615 --> 01:23:44,615 But also after five years, a transaction can be made that just takes this 10 Bitcoin UTXO, makes two new UTXOs, one for Alice, one for Bob with five Bitcoin each. 1030 01:23:45,615 --> 01:23:53,615 And anyone can do that because it's encoded in the output that the money needs to be spent into these two outputs. 1031 01:23:53,615 --> 01:23:56,615 So that's what a covenant could enable. 1032 01:23:56,615 --> 01:24:04,615 This is obviously a very simple use case, but it's a useful one to think about when we're trying to construct these kind of policies. 1033 01:24:05,615 --> 01:24:19,615 So OPCTV, or Object Template Verify, was a proposal made around the same time as Taproot, which is actually an opcode that would do exactly the thing that I just explained. 1034 01:24:19,615 --> 01:24:31,615 It's basically an opcode that allows you to encode inside your spend policy a template, quote-unquote, which is kind of a hash that summarizes the outputs of your transaction. 1035 01:24:31,615 --> 01:24:33,615 And then you encode it into the policy. 1036 01:24:33,615 --> 01:24:38,615 And then at spending time, this template is kind of compared against the actual transaction. 1037 01:24:38,615 --> 01:24:41,615 And then if it doesn't match the transaction, it's invalid. 1038 01:24:41,615 --> 01:24:47,615 So you can basically make a hash of the transaction that says five Bitcoin to Alice, five Bitcoin to Bob. 1039 01:24:47,615 --> 01:24:49,615 And then you put this in your output. 1040 01:24:49,615 --> 01:24:53,615 And then anyone that spends needs to actually fulfill this in order to be valid. 1041 01:24:53,615 --> 01:24:57,615 The way you do that is you hash this, you put it in your script, and then you use the opcode OPCTV. 1042 01:24:57,615 --> 01:25:00,615 And then this will compare the template with the actual transaction. 1043 01:25:00,615 --> 01:25:04,615 So how would we implement our example that way? 1044 01:25:04,615 --> 01:25:05,615 Very simple. 1045 01:25:05,615 --> 01:25:08,615 You would hash the template, like I said, five Bitcoin to Alice, five Bitcoin to Bob. 1046 01:25:08,615 --> 01:25:13,615 You put it in your output script, like in your tap script spend policy. 1047 01:25:13,615 --> 01:25:15,615 You put OPCTV so that it checks it. 1048 01:25:15,615 --> 01:25:21,615 And then you also check, additionally, that five years have passed since the UTXO was created. 1049 01:25:21,615 --> 01:25:24,615 But this is something that already exists today. 1050 01:25:25,615 --> 01:25:29,615 So I want to take a small detour. 1051 01:25:29,615 --> 01:25:35,615 Because I said right now in Bitcoin we don't have a way to encumber the outputs of the transaction. 1052 01:25:35,615 --> 01:25:39,615 But obviously if you sign a transaction and you want to send one Bitcoin to someone and get all your other Bitcoin in change, 1053 01:25:39,615 --> 01:25:43,615 obviously that somehow does encumber the outputs of the transaction. 1054 01:25:43,615 --> 01:25:47,615 Because you kind of don't want anyone to use your signature to do some other stuff. 1055 01:25:47,615 --> 01:25:53,615 So we actually do have an opcode or a mechanism to look into the outputs of the transaction 1056 01:25:53,615 --> 01:25:55,615 and make sure that they fulfill some conditions. 1057 01:25:55,615 --> 01:25:57,615 It's called the TREXIC opcode. 1058 01:25:57,615 --> 01:26:03,615 So if you sign a transaction, the signature actually is not a signature of any arbitrary message. 1059 01:26:03,615 --> 01:26:08,615 It's a signature of a specific hash that is calculated from the transaction that also looks into the outputs. 1060 01:26:08,615 --> 01:26:12,615 And then make sure that that signature matches what the transaction is actually doing. 1061 01:26:12,615 --> 01:26:17,615 So this is a visualization of all the fields that go into the signature hash. 1062 01:26:17,615 --> 01:26:22,615 This is the SIGHASHALL, which basically hashes all the stuff that you could possibly hash. 1063 01:26:23,615 --> 01:26:26,615 So most importantly, all the outputs are like here. 1064 01:26:26,615 --> 01:26:28,615 This is just a random data example. 1065 01:26:28,615 --> 01:26:31,615 And it also hashes a bunch of other transaction fields. 1066 01:26:31,615 --> 01:26:35,615 Now, what you could try to do, you could think, 1067 01:26:35,615 --> 01:26:37,615 OK, let's say I want my money to go to Alice and Bob. 1068 01:26:37,615 --> 01:26:41,615 Can I not already sign a transaction that goes to Alice and Bob 1069 01:26:41,615 --> 01:26:45,615 and then put the signature inside the spend policy, right? 1070 01:26:45,615 --> 01:26:50,615 Where you say, OK, the signature that I already defined needs to be valid for this transaction and this pubkey. 1071 01:26:50,615 --> 01:26:53,615 And because I signed it for the two outputs for Alice and Bob, 1072 01:26:53,615 --> 01:26:59,615 if I put it in there, I can actually enforce that the transaction needs to go to Alice and Bob. 1073 01:26:59,615 --> 01:27:05,615 Now, this obviously doesn't work because part of the signature hash is the TXID of the transaction that you're spending. 1074 01:27:05,615 --> 01:27:11,615 So you cannot put a signature that commits to something that you don't know yet inside the output that will create a transaction, right? 1075 01:27:11,615 --> 01:27:13,615 So this is kind of a dependency loop. 1076 01:27:13,615 --> 01:27:17,615 Because you need to know the transaction up front, you cannot create a transaction that commits to this. 1077 01:27:18,615 --> 01:27:22,615 So in this slide, this doesn't work because of that. 1078 01:27:22,615 --> 01:27:29,615 So in this slide, there's another relevant technical proposal that's been made even way before taproot. 1079 01:27:29,615 --> 01:27:34,615 Originally called SIGHASH no input, but currently called SIGNASH anyprevout or APO. 1080 01:27:34,615 --> 01:27:36,615 It's not a covenant proposal. 1081 01:27:36,615 --> 01:27:41,615 It's a proposal to introduce a different signature hash algorithm. 1082 01:27:41,615 --> 01:27:47,615 Originally, it was introduced or proposed part of the Lightning white paper. 1083 01:27:47,615 --> 01:27:54,615 So because people were trying to build these payment channels that eventually will have turned into Lightning, 1084 01:27:54,615 --> 01:28:01,615 they kind of want what you do in Lightning is use two parties that don't trust each other kind of create a joint UTXO. 1085 01:28:01,615 --> 01:28:08,615 And then they'll make sure that they can always in some way exit from this UTXO so that they get their fair share of the money back. 1086 01:28:08,615 --> 01:28:14,615 So if two people each want to put one Bitcoin in a UTXO, they then first sign an exit transaction, so to speak, 1087 01:28:14,615 --> 01:28:18,615 that gives them the money back in case their channel partner goes away. 1088 01:28:18,615 --> 01:28:23,615 But because you don't know the transaction ID of that transaction, 1089 01:28:23,615 --> 01:28:32,615 because back in the days before SegWit, Bitcoin had this property that was called transaction malleability that was an issue. 1090 01:28:32,615 --> 01:28:39,615 Because if I sign a transaction and broadcast it, someone could actually change my signature in some way that it's still valid, 1091 01:28:39,615 --> 01:28:41,615 but the transaction ID would change. 1092 01:28:41,615 --> 01:28:46,615 But it means that if we sign a transaction, like I said before, using the SIGHASH all, it commits to the TXID. 1093 01:28:46,615 --> 01:28:53,615 But if I'm not sure that the TXID will actually work, then this transaction could become invalid. 1094 01:28:53,615 --> 01:28:59,615 So the Lightning paper proposed to introduce the SIGHASH flag, which does not commit to the inputs. 1095 01:28:59,615 --> 01:29:05,615 That's why it was called no input, so that you could build this type of Lightning channels. 1096 01:29:05,615 --> 01:29:11,615 Now, we all know that APO was not activated, and instead the Bitcoin developer community said, 1097 01:29:11,615 --> 01:29:14,615 okay, this transaction malleability problem is not just an issue for Lightning. 1098 01:29:14,615 --> 01:29:17,615 It's actually a broad issue that we should kind of fix more generally. 1099 01:29:17,615 --> 01:29:25,615 So then SegWit was proposed, which alongside other technical benefits introduced transaction ID stability, 1100 01:29:25,615 --> 01:29:28,615 which kind of fixed the malleability problem. 1101 01:29:28,615 --> 01:29:32,615 And because then we had SegWit, we kind of didn't need APO anymore for Lightning to work. 1102 01:29:32,615 --> 01:29:38,615 So people started building Lightning using the stability, the TXID stability that SegWit gave. 1103 01:29:38,615 --> 01:29:43,615 And then APO kind of was still talked about, but kind of put on the long run. 1104 01:29:43,615 --> 01:29:49,615 Now, you might have heard of Lightning Symmetry, which is kind of a version 2 or an improved version of the Lightning protocol 1105 01:29:49,615 --> 01:29:53,615 that would reduce a lot the state that you need to manage. 1106 01:29:53,615 --> 01:29:57,615 It also improves the safety of your unilateral exit and stuff like that. 1107 01:29:57,615 --> 01:30:02,615 But Lightning Symmetry still requires what we call rebindable signatures, 1108 01:30:02,615 --> 01:30:12,615 which are like signatures that you can put, that you can replug even if another transaction actually creates your UTXO. 1109 01:30:12,615 --> 01:30:15,615 So how does APO, using APO work? It's the same. 1110 01:30:15,615 --> 01:30:18,615 You have the same check stick with a pub key, but here inside the signature, 1111 01:30:18,615 --> 01:30:25,615 you basically add a small flag that says, okay, I'm using an APO sig, and I'm not committing to the inputs. 1112 01:30:25,615 --> 01:30:30,615 And this would then obviously get new consensus meaning. 1113 01:30:30,615 --> 01:30:32,615 So this is the same diagram. 1114 01:30:32,615 --> 01:30:36,615 Just the only difference here is that this prev outs in APO are not committed. 1115 01:30:36,615 --> 01:30:42,615 You do commit some other stuff about the inputs, for example, the amount and the output scripts, 1116 01:30:42,615 --> 01:30:51,615 so that you make sure that only a UTXO that was created between you and your counterparty could actually use the signature. 1117 01:30:51,615 --> 01:30:59,615 So going back to my small covenant example, what we could actually use this APO trick for is we could actually, 1118 01:30:59,615 --> 01:31:06,615 like I suggested before, pre-create a signature that actually signs a transaction, 1119 01:31:06,615 --> 01:31:09,615 that takes the money and gives five Bitcoin to Alice, five Bitcoin to Bob. 1120 01:31:09,615 --> 01:31:14,615 We put it into our output policy using the APO flag so it doesn't commit to the prev outs, 1121 01:31:14,615 --> 01:31:19,615 and then together with the pub key, the check stick op code, and the same five-year relative time lock check, 1122 01:31:19,615 --> 01:31:25,615 put it into our wallet policy, and actually we can achieve the same goal. 1123 01:31:25,615 --> 01:31:31,615 So even though APO is not a covenant proposal or a covenant op code, 1124 01:31:31,615 --> 01:31:41,615 we noticed that we could actually use it to emulate or to achieve the same functionality that covenant op codes are actually doing. 1125 01:31:41,615 --> 01:31:44,615 So there is some kind of technical equivalence, 1126 01:31:44,615 --> 01:31:50,615 because it's possible, like we just showed, to implement CTV-like behavior using APO. 1127 01:31:50,615 --> 01:31:54,615 Now I'm going to show that there's also a reverse technical equivalence, 1128 01:31:54,615 --> 01:31:59,615 but before I do that, I'm going to introduce another really small op code that many of you might have heard of. 1129 01:31:59,615 --> 01:32:01,615 It's called check stick from stack. 1130 01:32:01,615 --> 01:32:07,615 Like I just said earlier, the check stick op codes or any other signature check in Bitcoin 1131 01:32:07,615 --> 01:32:12,615 doesn't really check any arbitrary message that you can specify. 1132 01:32:12,615 --> 01:32:16,615 It always looks at the transaction, creates a message from the transaction, 1133 01:32:16,615 --> 01:32:18,615 and then checks the signature against that message. 1134 01:32:18,615 --> 01:32:22,615 With check stick from stack, you can actually do arbitrary signature validation. 1135 01:32:22,615 --> 01:32:26,615 So instead of just giving a pub key, you give the pub key and the message, 1136 01:32:26,615 --> 01:32:29,615 and then the signature is checked against that message for that pub key. 1137 01:32:29,615 --> 01:32:33,615 So how you would do that in practice is you put the message and the pub key in your policy, 1138 01:32:33,615 --> 01:32:39,615 and then the user that spends provides a signature, and this signature needs to be valid for this specific message. 1139 01:32:39,615 --> 01:32:41,615 It's a very simple op code. 1140 01:32:41,615 --> 01:32:47,615 It's been live on the liquid network since it's on mainnets, which is definitely more than six years ago. 1141 01:32:47,615 --> 01:32:50,615 So it's a useful building block. 1142 01:32:50,615 --> 01:32:57,615 It's been discussed for a long time, but it's never been a priority to be discussed for consensus upgrades. 1143 01:32:57,615 --> 01:33:02,615 But using this additional op code, we can actually also emulate APO, 1144 01:33:02,615 --> 01:33:07,615 so rebindable signatures, using the CTV op code, so the reverse of what we did earlier. 1145 01:33:07,615 --> 01:33:08,615 How does that work? 1146 01:33:08,615 --> 01:33:14,615 Well, because the CTV is actually a hash of the transaction that commits to the outputs but not the inputs, 1147 01:33:14,615 --> 01:33:19,615 it's kind of similar to the SIG hash that any prep out specifies. 1148 01:33:19,615 --> 01:33:23,615 So what you can do is you can actually let the user provide a template, 1149 01:33:23,615 --> 01:33:25,615 which is the hash of the transaction without the inputs, 1150 01:33:25,615 --> 01:33:30,615 then use the op code CTV to make sure that what the user provided is actually the correct template hash, 1151 01:33:30,615 --> 01:33:35,615 and then use this op code check stick from stack to make sure that the signature that the user also provides 1152 01:33:35,615 --> 01:33:39,615 is the correct signature for the template of the transaction. 1153 01:33:39,615 --> 01:33:42,615 So this is basically, like I said there, checking the signature of the template, 1154 01:33:42,615 --> 01:33:49,615 but the template is kind of similar to a SIG hash value without the inputs. 1155 01:33:49,615 --> 01:33:55,615 So we have this situation where there's this covenant proposal CTV, 1156 01:33:55,615 --> 01:34:01,615 there's this old SIG hash proposal APO, and both have use cases, right? 1157 01:34:01,615 --> 01:34:03,615 CTV is an explicit covenant proposal. 1158 01:34:03,615 --> 01:34:08,615 APO is like rebindable signature, so it's useful in the lightning sense. 1159 01:34:08,615 --> 01:34:12,615 And you can kind of emulate one with the other and other with one. 1160 01:34:12,615 --> 01:34:16,615 So in the community, there has been a lot of discussion about, 1161 01:34:16,615 --> 01:34:18,615 okay, should we want to upgrade both? 1162 01:34:18,615 --> 01:34:22,615 Should we want to include both in Bitcoin? 1163 01:34:22,615 --> 01:34:30,615 Should we just pick one and then have the people that want to do the other just emulate using this roundabout way? 1164 01:34:30,615 --> 01:34:33,615 And it's not really clear which one is the best one to do, 1165 01:34:33,615 --> 01:34:35,615 which are the use cases that people most want to do. 1166 01:34:35,615 --> 01:34:39,615 Those are really hard things to estimate or predict. 1167 01:34:39,615 --> 01:34:44,615 If you look at the cost to use this, it's also not really clear. 1168 01:34:44,615 --> 01:34:49,615 I mean, CTV obviously is very efficient for doing CTV, right? 1169 01:34:49,615 --> 01:34:54,615 But then it's quite expensive to use it for rebindable signatures, 1170 01:34:54,615 --> 01:34:57,615 and then APO is kind of in the middle of that for both. 1171 01:34:58,615 --> 01:35:03,615 Also here, we don't really have a clear winner, quote-unquote. 1172 01:35:03,615 --> 01:35:07,615 So this is where the BIP that I want to propose or I want to talk about comes in. 1173 01:35:07,615 --> 01:35:09,615 It's an explicit BIP. 1174 01:35:09,615 --> 01:35:13,615 It's a BIP that explicitly wants to enable both rebindable signatures 1175 01:35:13,615 --> 01:35:19,615 and this commitment to a next transaction, like templating, in an optimal way. 1176 01:35:19,615 --> 01:35:24,615 And we're trying to do that by introducing three opcodes. 1177 01:35:24,615 --> 01:35:28,615 They're only introduced in the TabScript context, 1178 01:35:28,615 --> 01:35:31,615 which is relevant, we'll see, in the future. 1179 01:35:31,615 --> 01:35:38,615 But obviously APO was defined or specified even before SegWit existed 1180 01:35:38,615 --> 01:35:40,615 and CTV kind of before TabRoot existed, 1181 01:35:40,615 --> 01:35:42,615 so they are like slightly older protocols. 1182 01:35:42,615 --> 01:35:48,615 So we're also trying to kind of make use of the latest protocol system 1183 01:35:48,615 --> 01:35:52,615 that we have for TabScript and kind of make them a little bit more modern. 1184 01:35:52,615 --> 01:35:57,615 So the first, like the major new opcode that we're proposing, 1185 01:35:57,615 --> 01:36:01,615 it's also specified in BIP446, is called TemplateHash. 1186 01:36:01,615 --> 01:36:05,615 And TemplateHash is actually a very straightforward opcode. 1187 01:36:05,615 --> 01:36:09,615 Similar to CTV, which checks your transaction against the template, 1188 01:36:09,615 --> 01:36:12,615 TemplateHash will just calculate the template and give it to you on the stack 1189 01:36:12,615 --> 01:36:14,615 so that you can do with it what you want. 1190 01:36:14,615 --> 01:36:18,615 We can do this in TabScript because in TabScript we have Opsuccess. 1191 01:36:19,615 --> 01:36:22,615 You might be aware or have already heard people talk about it 1192 01:36:22,615 --> 01:36:26,615 that before TabScript, when we did soft forks, 1193 01:36:26,615 --> 01:36:29,615 we always have these opcodes that end with verify. 1194 01:36:29,615 --> 01:36:34,615 And that is because we cannot change the stack with upgrades for opcodes 1195 01:36:34,615 --> 01:36:37,615 because if you change the stack, it's actually often a hard fork. 1196 01:36:37,615 --> 01:36:41,615 So the only upgrades that we could do before TabScript 1197 01:36:41,615 --> 01:36:44,615 was create opcodes that would check something 1198 01:36:44,615 --> 01:36:46,615 and then fail the transaction if it's incorrect 1199 01:36:46,615 --> 01:36:49,615 and then do nothing if it's correct so that they don't change the stack. 1200 01:36:49,615 --> 01:36:51,615 That's why it's called CTV, CheckTemplateVerify. 1201 01:36:51,615 --> 01:36:53,615 It just looks at the template, checks it. 1202 01:36:53,615 --> 01:36:55,615 If it's okay, it will do nothing. 1203 01:36:55,615 --> 01:36:57,615 And if it's not okay, it will abort. 1204 01:36:57,615 --> 01:36:59,615 In TabScript, we can actually do more stuff. 1205 01:36:59,615 --> 01:37:01,615 So we can actually change the stack. 1206 01:37:01,615 --> 01:37:04,615 So we can have an opcode that calculates the template, 1207 01:37:04,615 --> 01:37:07,615 calculates the hash, puts it on the stack, 1208 01:37:07,615 --> 01:37:10,615 and then lets the user do something with it. 1209 01:37:10,615 --> 01:37:13,615 So how do you do next transaction commitment with this? 1210 01:37:13,615 --> 01:37:14,615 Very simple. 1211 01:37:14,615 --> 01:37:16,615 The user provides a template. 1212 01:37:16,615 --> 01:37:18,615 It uses the opcode to calculate the template again, 1213 01:37:18,615 --> 01:37:20,615 and then you check that they're actually the same. 1214 01:37:20,615 --> 01:37:23,615 So this is basically CTV using template hash. 1215 01:37:23,615 --> 01:37:27,615 But if you're doing rebindable signatures 1216 01:37:27,615 --> 01:37:29,615 the way we would emulate them using CTV, 1217 01:37:29,615 --> 01:37:33,615 you no longer have to have the user provide the template here. 1218 01:37:33,615 --> 01:37:35,615 You can just calculate the template 1219 01:37:35,615 --> 01:37:38,615 and then make sure that the signature matches the template 1220 01:37:38,615 --> 01:37:41,615 that is now on the stack using CheckStickFromStack, 1221 01:37:41,615 --> 01:37:43,615 which brings us to the second opcode 1222 01:37:43,615 --> 01:37:47,615 that we included in our BIP448 package, CheckStickFromStack, 1223 01:37:47,615 --> 01:37:50,615 an existing opcode that's been defined for a long time. 1224 01:37:54,615 --> 01:37:55,615 So, yeah. 1225 01:37:55,615 --> 01:37:59,615 Now, I say that template hash just brings the template, 1226 01:37:59,615 --> 01:38:00,615 quote-unquote, on stack, 1227 01:38:00,615 --> 01:38:03,615 similar to how CTV checks, quote-unquote, the template. 1228 01:38:03,615 --> 01:38:04,615 But the templates that we're talking about 1229 01:38:04,615 --> 01:38:06,615 are not exactly byte-for-byte the same. 1230 01:38:06,615 --> 01:38:07,615 Conceptually, they're the same. 1231 01:38:07,615 --> 01:38:10,615 They're trying to commit to the outputs of the transaction mostly. 1232 01:38:11,615 --> 01:38:14,615 But we also commit to some additional stuff, 1233 01:38:14,615 --> 01:38:19,615 mostly because one of the goals for this templating construction 1234 01:38:19,615 --> 01:38:21,615 is that we can somehow fix the TXID 1235 01:38:21,615 --> 01:38:25,615 given the prevout that is spent in this transaction. 1236 01:38:25,615 --> 01:38:27,615 So if you have a transaction with one input, 1237 01:38:27,615 --> 01:38:31,615 and the input is the one that contains the covenant policy, 1238 01:38:31,615 --> 01:38:35,615 then any transaction that passes the policy 1239 01:38:35,615 --> 01:38:37,615 should have the same TXID. 1240 01:38:38,615 --> 01:38:40,615 That's useful for various off-chain constructions. 1241 01:38:40,615 --> 01:38:44,615 So that's just the goalpost that CTV had 1242 01:38:44,615 --> 01:38:46,615 and that we also want to have. 1243 01:38:47,615 --> 01:38:49,615 So for that, we can make a few changes from CTV. 1244 01:38:49,615 --> 01:38:50,615 So one is that in taproot, 1245 01:38:50,615 --> 01:38:52,615 scriptseqs are no longer allowed. 1246 01:38:52,615 --> 01:38:53,615 Scriptseqs is kind of an old legacy field 1247 01:38:53,615 --> 01:38:55,615 that we used to put signatures, 1248 01:38:55,615 --> 01:38:57,615 and currently we use the witness for that. 1249 01:38:57,615 --> 01:38:59,615 So we don't have to commit to the scriptseq 1250 01:38:59,615 --> 01:39:01,615 because in taproot you simply cannot have a scriptseq 1251 01:39:01,615 --> 01:39:03,615 that's already invalid. 1252 01:39:03,615 --> 01:39:06,615 So that's one of the changes from CTV. 1253 01:39:06,615 --> 01:39:09,615 And then, because I explained to you 1254 01:39:09,615 --> 01:39:12,615 that the template hash is actually very similar to a SIG hash 1255 01:39:12,615 --> 01:39:15,615 and we already have a lot of machinery inside BitConcord 1256 01:39:15,615 --> 01:39:16,615 to calculate the SIG hashes 1257 01:39:16,615 --> 01:39:18,615 for all the signature checks that we're doing, 1258 01:39:18,615 --> 01:39:21,615 we thought, okay, let's see if we could reuse 1259 01:39:21,615 --> 01:39:23,615 some of that machinery that taproot introduced 1260 01:39:23,615 --> 01:39:25,615 to calculate the SIG hashes. 1261 01:39:25,615 --> 01:39:27,615 And what we did is we actually looked at SIG hash all, 1262 01:39:27,615 --> 01:39:30,615 which is the default to sign everything, 1263 01:39:30,615 --> 01:39:32,615 and then we took out some things, 1264 01:39:32,615 --> 01:39:34,615 but then we could reuse most of the calculations 1265 01:39:34,615 --> 01:39:36,615 for SIG hash all. 1266 01:39:36,615 --> 01:39:38,615 So one thing that we don't have that SIG hash all has 1267 01:39:38,615 --> 01:39:40,615 is the hash type and the spend type 1268 01:39:40,615 --> 01:39:42,615 because they're basically irrelevant. 1269 01:39:42,615 --> 01:39:44,615 They have to do with something with signatures, 1270 01:39:44,615 --> 01:39:46,615 so we don't really have this. 1271 01:39:46,615 --> 01:39:48,327 It's irrelevant in this context. 1272 01:39:48,327 --> 01:39:52,327 Obviously, we don't commit to the PrevAs, right, which SIG hash all does. That's kind of the whole point of this. 1273 01:39:52,327 --> 01:39:59,327 And then a last one that SIG hash all commits that we decided to not commit is the amounts. 1274 01:39:59,327 --> 01:40:06,327 This was a bit of a trickier decision because there's good arguments to be made to include them, and there's arguments to be made to not include them. 1275 01:40:07,327 --> 01:40:15,327 Eventually, we settled on not including them, mostly because if you include the amounts and then somehow accidentally send a different amount to your policy, 1276 01:40:15,327 --> 01:40:30,327 you would black hole all your funds, basically, and to avoid that foot gun, we kind of thought that any of the other more, like, fringe benefits that on the other side you would get would kind of, yeah, that this one was more important, basically. 1277 01:40:31,327 --> 01:40:39,327 And then, lastly, the last difference is that template hash also commits to the Annex. This was another one where we went a lot of back and forth. 1278 01:40:39,327 --> 01:40:44,327 CTV obviously was defined before the Annex, so it didn't touch the Annex at all. 1279 01:40:44,327 --> 01:40:57,327 We'd eventually, I mean, it's relevant to point out that no formal, no use of the Annex has been formally proposed so far, so it's very abstract and hypothetical to talk about the Annex. 1280 01:40:58,327 --> 01:41:11,327 But because the SIG hashes currently commit to the Annex, we decided to just also do it so that any proposal that might be proposed in the future to use the Annex that is compatible with SIG hashes is also compatible with template hash. 1281 01:41:11,327 --> 01:41:19,327 Again, there were some arguments to be made to not do that, but eventually we decided to stay as close as possible to the SIG hash calculation of taproot. 1282 01:41:20,327 --> 01:41:28,327 So this is basically the calculation of the template in template hash in a nutshell and how it differs from CTV. 1283 01:41:32,327 --> 01:41:43,327 Well, I hear a lot of talks about spam and all that, so it seems that people care a lot about block space, so I kind of made a comparing table about how much block space you would use to use all of these constructions. 1284 01:41:44,327 --> 01:41:55,327 So these ones, these four we saw before, the template hash plus check SIG from stack construction uses one byte more to do the next transaction commitment, but then it's equally efficient as APO to do the rebindable signature. 1285 01:41:55,327 --> 01:41:58,327 So it kind of finds a good middle ground here. 1286 01:42:00,327 --> 01:42:04,327 Now, I said that there was three upcodes, and we've only seen two so far. 1287 01:42:05,327 --> 01:42:14,327 So when we go back at the constructions we saw before, we looked at this, and you look at this 32-byte pubkey here, right? 1288 01:42:14,327 --> 01:42:29,327 And like I said, we only proposed the introduction of these primitives in tapscript context, and for those of you who understand tapscript, you know that when you do a tapscript spend, your witness already contains your internal key. 1289 01:42:30,327 --> 01:42:38,327 Like the way taproot works is that you have an internal key and then a commitment to some scripts, and if you want to use the scripts, you need to show the internal key, and then you can use the scripts. 1290 01:42:38,327 --> 01:42:49,327 So that means that every time you spend a tapscript, there's already in your transaction like a pubkey there that you need to show, and then with this construction, you would have to use another pubkey that you would also have to put there that is for this policy. 1291 01:42:49,327 --> 01:42:52,327 So we thought, why can we not just use the same pubkey, right? 1292 01:42:53,327 --> 01:43:06,327 So we introduced another really simple opcode, another push opcode, and it's called internal key, and all it does, it just looks at the control block, the taproot control block, it takes the internal key, and it just puts it on the stack. 1293 01:43:06,327 --> 01:43:12,327 This means that you don't have to specify a different key for your rebindable signature. 1294 01:43:12,327 --> 01:43:21,327 You could do that, obviously, if you want a different key than the root key, but then if you want the same key as the root key, you can just use one opcode and get the key on the stack. 1295 01:43:21,327 --> 01:43:38,327 So that means that to do a rebindable signature using our construction, we can basically use our three opcodes in a row, the template hash to create the message, the internal key to get the pubkey, and then check from stack to basically check the user signature in a very elegant three opcodes script. 1296 01:43:38,327 --> 01:44:07,327 This turns out to be just 68 bytes, so it kind of, for fairness, I also gave the other proposals the internal key benefit, but still, we're as efficient as APO for doing rebindable signatures, and we're just one weight unit, which is a quarter of a virtual byte less efficient than CTV for doing the next transaction commitment, so we feel that this strikes a really good balance for doing both constructions and functionalities in a single proposal. 1297 01:44:08,327 --> 01:44:12,327 So, yeah, that kind of sums up BIP448. 1298 01:44:12,327 --> 01:44:17,327 It's trying to do rebindable signatures, next transaction commitments, both in a single proposal with three opcodes. 1299 01:44:17,327 --> 01:44:19,327 The opcodes are specified in individual BIPs. 1300 01:44:19,327 --> 01:44:29,327 We have a website which brings you to GitHub where there's a list of different projects of people working on proof of concepts, also the BIPs you can find there. 1301 01:44:32,327 --> 01:44:34,327 So what's next for this proposal? 1302 01:44:34,327 --> 01:44:37,327 Obviously, people need to learn about it, so I'll go to these websites. 1303 01:44:38,327 --> 01:44:43,327 I might have accidentally broken the redirect, so I might fix that right after this talk, but it might also work. 1304 01:44:43,327 --> 01:44:44,327 I'm not sure. 1305 01:44:45,327 --> 01:44:46,327 Yeah, it works? 1306 01:44:46,327 --> 01:44:47,327 Nice. 1307 01:44:48,327 --> 01:44:50,327 And obviously, we need to build proof of concepts. 1308 01:44:50,327 --> 01:44:56,327 We need to show that this is a useful proposal, that Bitcoin gets better if it would adopt this BIP, right? 1309 01:44:56,327 --> 01:44:59,327 That's how BIPs always work. 1310 01:44:59,327 --> 01:45:01,327 So that's what we're doing. 1311 01:45:01,327 --> 01:45:14,327 And one proposal that would benefit a lot from this BIP is the protocol that I myself work on, that Matthew also talked about in the previous talk. 1312 01:45:14,327 --> 01:45:23,327 ARK actually was originally designed based on the idea of CTV, but because it seemed unlikely at the time that CTV would activate, 1313 01:45:23,327 --> 01:45:36,327 the companies that were building implementations of ARK kind of built a different version that kind of emulates some of the CTV properties using signed rounds, 1314 01:45:36,327 --> 01:45:45,327 which Matthew discussed to you earlier, which is a very interactive process where all the users kind of need to pass messages with the server at the same time, 1315 01:45:45,327 --> 01:45:48,327 sign a bunch of things, and basically be online for an extended period of time. 1316 01:45:48,327 --> 01:45:50,327 And this is really hard for mobile wallets. 1317 01:45:50,327 --> 01:45:56,327 So we have built-in different trade-offs where you can kind of be less secure to have less interactivity. 1318 01:45:56,327 --> 01:46:06,327 But with a covenant opcode like CTV or TemplateHash, ARK could have full security without having any interactivity between its users. 1319 01:46:06,327 --> 01:46:12,327 So as a proof of concept, I kind of implemented TemplateHash support in Bark. 1320 01:46:12,327 --> 01:46:14,327 It's live today. 1321 01:46:14,327 --> 01:46:16,327 So you can go to this website, templatehash.com. 1322 01:46:16,327 --> 01:46:19,327 You will find the URL of a server and a branch that you can check out. 1323 01:46:19,327 --> 01:46:22,327 So you can build Bark with TemplateHash support. 1324 01:46:22,327 --> 01:46:24,327 You can connect to a server. 1325 01:46:24,327 --> 01:46:33,327 And then because the server has a Lightning channel with our second Signet faucet, you can actually go to our faucet, request with Lightning a payment, 1326 01:46:33,327 --> 01:46:42,327 and you can actually get Lightning coins in with a TemplateHash ARK on the Inquisition Signet right now. 1327 01:46:42,327 --> 01:46:44,327 Then I have a few colored slides. 1328 01:46:44,327 --> 01:46:46,327 Most of my slides were black and white. 1329 01:46:46,327 --> 01:46:53,327 These are borrowed from a talk that unfortunately we will not see today because Greg Sanders, my colleague, was going to talk about some other work that he's been doing, 1330 01:46:53,327 --> 01:46:56,327 but his flight got canceled and he unfortunately cannot make it. 1331 01:46:56,327 --> 01:47:07,327 So I kind of took two slides that I really liked from his presentation where he's basically plotting many of the off-chain Layer 2 constructions in some kind of spectrum 1332 01:47:07,327 --> 01:47:10,327 from someone can take your coins to no one can take your coins. 1333 01:47:10,327 --> 01:47:14,327 Basically a custodial to fully on-chain trustless. 1334 01:47:14,327 --> 01:47:21,327 And ARK has kind of the different modes, like I said, because we felt like the interactivity was kind of impeding mobile usage. 1335 01:47:21,327 --> 01:47:24,327 The interactivity was impeding mobile usage. 1336 01:47:24,327 --> 01:47:31,327 We kind of introduced different modes where people can choose to be either fully trustless but need to do interactive work regularly, 1337 01:47:31,327 --> 01:47:40,327 or people can kind of have a slightly less trustless trade-off, but then have the ease of being able to do it on mobile. 1338 01:47:40,327 --> 01:47:49,327 So there's a few different modes in ARK that go from more or less, well, you kind of trust the server to do right stuff, 1339 01:47:49,327 --> 01:47:54,327 to like, I'm totally safe, but I need to come online and co-sign stuff. 1340 01:47:54,327 --> 01:48:06,327 And with TemplateHash or another covenant opcode, we can kind of be fully trustless in all the modes with the full UX that is mobile-friendly. 1341 01:48:06,327 --> 01:48:08,327 So, yeah, thanks, Greg, for the slides. 1342 01:48:08,327 --> 01:48:16,327 Hopefully you guys will be able to see his full presentation at some other point, because it's also really, really nice. 1343 01:48:16,327 --> 01:48:21,327 So, yeah, you can visit this to try it out, and this kind of sums up my talk. 1344 01:48:21,327 --> 01:48:23,327 BIP448, definitely check it out. 1345 01:48:23,327 --> 01:48:24,327 We have a website. 1346 01:48:24,327 --> 01:48:25,327 We have some proof of concepts. 1347 01:48:25,327 --> 01:48:27,327 The BIPs are there. 1348 01:48:27,327 --> 01:48:28,327 Thank you all. 1349 01:48:28,327 --> 01:48:30,327 I hope you have some questions. 1350 01:48:30,327 --> 01:48:38,327 APPLAUSE 1351 01:48:38,327 --> 01:48:40,327 Okay, we have some questions. 1352 01:48:40,327 --> 01:48:42,327 I'll start from here. 1353 01:48:42,327 --> 01:48:45,327 Come back. 1354 01:48:45,327 --> 01:48:46,327 Just a quick question. 1355 01:48:46,327 --> 01:48:57,327 So, every single time when you have one of these introspection to match up for CheckSig from Stack and CTV or any of that stuff, right, 1356 01:48:57,327 --> 01:49:04,327 are you feeding in that same transaction hash or DX hash or whatnot every single time? 1357 01:49:04,327 --> 01:49:12,327 Because on BCH, on Bitcoin Cash, I think it's the same CTV kind of mechanisms, right? 1358 01:49:12,327 --> 01:49:19,327 We have something called CheckDataSig, which is essentially the same thing as CheckSig from Stack, if I'm not mistaken. 1359 01:49:19,327 --> 01:49:27,327 And what we've seen is that with some of these covenants that we've made, the more of the introspection that we need to do, 1360 01:49:27,327 --> 01:49:33,327 the more times we need to feed in that entire signature and whatnot and do that data check, right? 1361 01:49:33,327 --> 01:49:39,327 So, I was just wondering, because later on on Bitcoin Cash, we developed native introspection, 1362 01:49:39,327 --> 01:49:48,327 which is very similar to the idea of the internal key, right, where we're able to pick out all the inputs, all the outputs, amounts, so on and so forth. 1363 01:49:48,327 --> 01:49:50,327 So, yeah, I was just kind of curious. 1364 01:49:50,327 --> 01:49:53,327 Is it the same kind of data? 1365 01:49:53,327 --> 01:50:00,327 Like, how big would it be if you have a lot more of these introspections to match up? 1366 01:50:00,327 --> 01:50:06,327 I'm not sure how to answer, but yes, the CheckDataSig, I think, is the same as CheckSig from Stack. 1367 01:50:06,327 --> 01:50:14,327 I'm not sure if you had CTV on Bitcoin Cash early on, but if you have CAT and you have CheckSig from Stack, 1368 01:50:14,327 --> 01:50:21,327 you can also do really complex constructions to somehow look into the different pieces of the transaction 1369 01:50:21,327 --> 01:50:26,327 by basically deconstructing the SIG hash and then reconstructing it and then checking the signature. 1370 01:50:26,327 --> 01:50:31,327 And that's, like you said, it takes a lot of data in your transactions, but it's kind of a roundabout way, 1371 01:50:31,327 --> 01:50:38,327 and this is not the type of constructions that I'm talking about, because that's exactly what template hash or CTV kind of gives you. 1372 01:50:38,327 --> 01:50:42,327 It gives you, like, one opcode that can look at a bunch of relevant information condensed together, 1373 01:50:42,327 --> 01:50:47,327 and you don't have to do, like, CheckSig from Stack CAT shenanigans to be able to do that. 1374 01:50:47,327 --> 01:50:50,327 So, yeah, obviously, direct introspection opcodes, like this one. 1375 01:50:50,327 --> 01:50:53,327 This one is a very simple one that gives you only a summary. 1376 01:50:53,327 --> 01:50:56,327 Liquid, for example, has, like, give me output one, give me output two. 1377 01:50:56,327 --> 01:50:59,327 It is, like, very fine-grained introspection opcodes. 1378 01:50:59,327 --> 01:51:01,327 They're obviously also useful. 1379 01:51:01,327 --> 01:51:03,327 There's a lot more bike-shedding to be done, though. 1380 01:51:03,327 --> 01:51:06,327 So this is a very simple proposal. 1381 01:51:06,327 --> 01:51:09,327 The primitives are very easy to reason about. 1382 01:51:09,327 --> 01:51:10,327 They're very safe. 1383 01:51:10,327 --> 01:51:17,327 So, like, we feel that this is a good first step, and then hopefully in the future maybe enable more fine-grained introspection, 1384 01:51:17,327 --> 01:51:23,327 like either the direct introspection opcodes or something like TxHash or something like Optx, 1385 01:51:23,327 --> 01:51:27,327 where you can actually say, I want to know this about my transaction and give it to me. 1386 01:51:27,327 --> 01:51:31,327 But, yeah, that's definitely future work. 1387 01:51:34,327 --> 01:51:36,327 More questions? 1388 01:51:36,327 --> 01:51:38,327 I have a question. 1389 01:51:38,327 --> 01:51:40,327 Kind of a small question, I suppose. 1390 01:51:40,327 --> 01:51:43,327 How did you decide on the name TemplateHash? 1391 01:51:43,327 --> 01:51:45,327 It's a very canonical name. 1392 01:51:45,327 --> 01:51:49,327 I can imagine in the future we might have other opcodes for other templates. 1393 01:51:49,327 --> 01:51:52,327 Well, that's a good point, that there could be multiple templates. 1394 01:51:52,327 --> 01:51:54,327 I mean, we borrowed the name from CTV, right? 1395 01:51:54,327 --> 01:51:57,327 The word template kind of got introduced using CTV. 1396 01:51:57,327 --> 01:52:00,327 You do check template verify, so, like, you have a template, you check it. 1397 01:52:00,327 --> 01:52:03,327 We just calculate the template. 1398 01:52:03,327 --> 01:52:09,327 We think just a summary of all outputs plus a version, the log time, it's kind of you could see of it as a transaction template. 1399 01:52:09,327 --> 01:52:12,327 You just don't know how you're going to fund it yet, right? 1400 01:52:12,327 --> 01:52:14,327 It's definitely just a random name. 1401 01:52:14,327 --> 01:52:22,327 I know that CTV was earlier called Secure the Bag, and then earlier version was called Check Output Hash Verifier, 1402 01:52:22,327 --> 01:52:26,327 something like that, so, like, there's definitely been backshedding over the name. 1403 01:52:26,327 --> 01:52:31,327 We just settled on this because the word template was kind of already used, so. 1404 01:52:32,327 --> 01:52:34,327 Thanks. 1405 01:52:34,327 --> 01:52:46,327 You mentioned that one of the main differences between CTV and template hash was that CTV commits to output amounts, whereas template hash doesn't. 1406 01:52:46,327 --> 01:52:47,327 Is that right? 1407 01:52:47,327 --> 01:52:48,327 No. 1408 01:52:48,327 --> 01:52:50,327 CTV doesn't commit to the amounts. 1409 01:52:50,327 --> 01:52:53,327 Sorry, yeah, that was maybe a confusion. 1410 01:52:54,327 --> 01:53:05,327 So, here I said that we looked at the Cache All machinery, and then these were the differences from the Cache All machinery, but not necessarily from CTV. 1411 01:53:05,327 --> 01:53:06,327 Okay, thank you. 1412 01:53:06,327 --> 01:53:10,327 This is a difference from CTV, though, so we commit to Annex, and CTV doesn't. 1413 01:53:10,327 --> 01:53:16,327 Mostly because I think at the time the CTV was specified, the Annex didn't exist, so, like, they couldn't have made that decision, 1414 01:53:16,327 --> 01:53:20,327 so then we were like, okay, should we do it, should we not, and eventually we decided to do it. 1415 01:53:21,327 --> 01:53:22,327 Yeah. 1416 01:53:24,327 --> 01:53:26,327 Any other questions? Matthew? 1417 01:53:29,327 --> 01:53:37,327 I understand that one of the differences between template hash and Tx hash is that you're not selecting individual transaction fields. 1418 01:53:37,327 --> 01:53:47,327 I was wondering why return to taking a template, taking a hash of the entire transaction rather than just selecting the fields that you want. 1419 01:53:48,327 --> 01:53:50,327 Good question. 1420 01:53:50,327 --> 01:53:54,327 I think the answer is twofold. 1421 01:53:54,327 --> 01:53:56,327 Mostly bike-shitting. 1422 01:53:56,327 --> 01:54:00,327 Like, if you want, like, so maybe some introduction. 1423 01:54:00,327 --> 01:54:08,327 So, Tx hash is another proposal that was originally coined by Russell O'Connor, who I saw here yesterday, but then authored by myself as a bib, 1424 01:54:08,327 --> 01:54:11,327 which is similar to template hash. 1425 01:54:11,327 --> 01:54:15,327 Like, it hashes some stuff from the transaction and puts it on the stack, 1426 01:54:15,327 --> 01:54:18,327 but instead of template hash, which gives you only one option, 1427 01:54:18,327 --> 01:54:25,327 Tx hash basically gives you a variety of methods on how to specify which exact fields of all the stuff that you can see here, 1428 01:54:25,327 --> 01:54:31,327 plus some other ones that you want to get hashed into your hash. 1429 01:54:31,327 --> 01:54:36,327 And obviously, with all the things that gives you options and choice, there's a lot of bike-shitting. 1430 01:54:36,327 --> 01:54:44,327 So, like, well, which ones should we allow, which ones should we allow to be hashed more efficiently than others, right? 1431 01:54:45,327 --> 01:54:52,327 And then the second argument was mostly, like, code simplicity and code review. 1432 01:54:52,327 --> 01:54:59,327 The template hash, because we're reusing the SIG hash machinery, it's actually a very small amount of lines of codes, 1433 01:54:59,327 --> 01:55:02,327 because all of these hashes are already pre-prepared for the SIG hash. 1434 01:55:02,327 --> 01:55:06,327 We just take a few of them from the SIG hash and then hash them together, and it's, like, that simple. 1435 01:55:06,327 --> 01:55:11,327 So, it's, like, very simple, very easy to check for bugs. 1436 01:55:12,327 --> 01:55:19,327 But the code that I wrote for Tx hash is definitely, like, maybe one or two orders of magnitude more complex. 1437 01:55:19,327 --> 01:55:25,327 It has, like, bit fields that allow you to, like, specify and select different fields. 1438 01:55:25,327 --> 01:55:33,327 And it's also because one concern with this kind of construction is denial of service. 1439 01:55:33,327 --> 01:55:40,327 Like, if someone would put a whole bunch of these different Tx hashes, it could cause you to hash, like, a lot and a lot of data. 1440 01:55:40,327 --> 01:55:44,327 So, it's important that the implementation has proper caching strategies. 1441 01:55:44,327 --> 01:55:48,327 So, the caching strategy that I implemented for Tx hash was also a little bit complex. 1442 01:55:48,327 --> 01:55:54,327 More complex, definitely, than the SIG hash cache strategies that we have in BigConcord already, 1443 01:55:54,327 --> 01:55:58,327 because there's only a handful of different options, so it's easy to just pre-prepare them. 1444 01:55:58,327 --> 01:56:04,327 But for Tx hash, the options are kind of infinite, so you need to have some kind of at-runtime caching 1445 01:56:04,327 --> 01:56:10,327 to make sure that when a user is just smashing you with the same hash, you don't go do the work all over again. 1446 01:56:10,327 --> 01:56:15,327 So, yeah, it's definitely a combination of backshooting, and just, it needs more time and more review. 1447 01:56:15,327 --> 01:56:20,327 It seems that this is something that is very safe and very straightforward that we can get consensus on, 1448 01:56:20,327 --> 01:56:24,327 while Tx hash might take a lot more time to get, like, right. 1449 01:56:24,327 --> 01:56:34,327 Yeah, I was also wondering about, like, Tx hash versus template hash. 1450 01:56:34,327 --> 01:56:43,327 And you mentioned backshooting is, like, the main difference, and also the implementation or the review difference. 1451 01:56:43,327 --> 01:56:52,327 But I feel like if you have a very specific template, you mentioned multiple times that it's not clear which template is the correct one, 1452 01:56:52,327 --> 01:57:00,327 or you might have someone who wants to build something else, which is not ARC, but they would need a slightly different template. 1453 01:57:00,327 --> 01:57:08,327 So I feel like when you think about it like this, it's much more complicated to come to consensus on one specific template 1454 01:57:08,327 --> 01:57:18,327 instead of having this general option to just choose which fields you're interested in. 1455 01:57:18,327 --> 01:57:24,327 Yes, that's true. I mean, there's not much I can say about that. 1456 01:57:24,327 --> 01:57:28,327 Tx hash is another proposal that does exist. 1457 01:57:28,327 --> 01:57:32,327 It doesn't have as much momentum because it needs a lot of work to be done, 1458 01:57:32,327 --> 01:57:35,327 and it doesn't seem that people are very interested in doing that work. 1459 01:57:35,327 --> 01:57:42,327 I myself am building ARC, so I don't have time to dedicate time to implementing and refining Tx hash. 1460 01:57:42,327 --> 01:57:47,327 So these are opcodes like these two kind of already existed as ideas. 1461 01:57:47,327 --> 01:57:49,327 This one existed as an implementation for a very long time. 1462 01:57:49,327 --> 01:57:52,327 Internal key, the implementation is also that simple. 1463 01:57:52,327 --> 01:57:54,327 And then template hash is actually also very simple. 1464 01:57:54,327 --> 01:57:56,327 So this is something that, like, the code has been there. 1465 01:57:56,327 --> 01:57:58,327 It's been merged in Inquisition. 1466 01:57:58,327 --> 01:58:06,327 There's a PR ready for core or already published or not yet, but definitely in the pipeline. 1467 01:58:06,327 --> 01:58:11,327 And it just happens so that it can do almost everything that we want. 1468 01:58:11,327 --> 01:58:17,327 I mean, the only, like, real use case that people are looking at today that is hard to do with template hash, 1469 01:58:17,327 --> 01:58:20,327 I'm not sure if it's still impossible because people always find ways, 1470 01:58:20,327 --> 01:58:24,327 is the BitVM bridge design for the latest version of BitVM. 1471 01:58:24,327 --> 01:58:32,327 They kind of wanted a slightly different template that is kind of just really specific for BitVM. 1472 01:58:32,327 --> 01:58:34,327 Unfortunately, you can't do everything. 1473 01:58:34,327 --> 01:58:36,327 This is just a template that makes sense. 1474 01:58:36,327 --> 01:58:41,327 It's kind of everything that you need to keep your TXID stable plus the annex. 1475 01:58:41,327 --> 01:58:45,327 And, yeah. 1476 01:58:45,327 --> 01:58:48,327 Thank you. 1477 01:58:48,327 --> 01:58:52,327 I definitely feel encouraged to look at TX hash, look at the codes, 1478 01:58:52,327 --> 01:58:56,327 replace the branch because it's a few years old, review the codes, 1479 01:58:56,327 --> 01:59:00,327 propose potential changes, and maybe, like, it can happen, 1480 01:59:00,327 --> 01:59:05,327 and it can be either a next soft fork or it can replace this one. 1481 01:59:05,327 --> 01:59:10,327 I mean, we never know, but it seems that this one has a path towards consensus 1482 01:59:10,327 --> 01:59:15,327 way earlier than something that includes TX hash. 1483 01:59:15,327 --> 01:59:18,327 Any other questions? 1484 01:59:18,327 --> 01:59:20,327 No, so thank you, Stephen. 1485 01:59:20,327 --> 01:59:22,327 Thank you. 1486 01:59:22,327 --> 01:59:25,327 Thank you. 1487 01:59:52,327 --> 02:00:20,327 Thank you. 1488 02:00:20,327 --> 02:00:22,327 My name is Calvin. 1489 02:00:22,327 --> 02:00:27,327 I work on—well, I'm prominently known for working on the UTREXO project. 1490 02:00:27,327 --> 02:00:32,327 Nowadays, I also do a lot of work on BTCD as well. 1491 02:00:32,327 --> 02:00:38,327 These are both Bitcoin node implementations that are not Bitcoin core. 1492 02:00:38,327 --> 02:00:41,327 If somebody is already running a Bitcoin core node at home, 1493 02:00:41,327 --> 02:00:45,327 they usually think, like, it's either, you know, I run a core or I run not. 1494 02:00:45,327 --> 02:00:51,327 In what scenario would somebody end up running BTCD or even UTREXO? 1495 02:00:51,327 --> 02:00:55,327 Okay, so with BTCD, it actually used to be pretty performance, 1496 02:00:55,327 --> 02:00:57,327 and it had all these features. 1497 02:00:57,327 --> 02:01:02,327 It was very well-maintained back in 2014, 2015. 1498 02:01:02,327 --> 02:01:05,327 It sort of went a little bit unmaintained, a little downhill, 1499 02:01:05,327 --> 02:01:07,327 but then now it's starting to pick up again. 1500 02:01:07,327 --> 02:01:11,327 And so, like, in 2017, why would you use BTCD? 1501 02:01:12,327 --> 02:01:15,327 If you like Go, if you like developing on it, you would. 1502 02:01:15,327 --> 02:01:21,327 But nowadays, I guess with BTCD, there's going to be features that Bitcoin D doesn't have. 1503 02:01:21,327 --> 02:01:23,327 Namely, well, address index has been there forever. 1504 02:01:23,327 --> 02:01:25,327 We're working on Electrum servers. 1505 02:01:25,327 --> 02:01:29,327 We're working on a bunch of performance improvements 1506 02:01:29,327 --> 02:01:33,327 that are going to land before Bitcoin core, and so I'm excited about that. 1507 02:01:33,327 --> 02:01:40,327 And so, like, we're hoping to make it more cutting edge, more feature. 1508 02:01:41,327 --> 02:01:44,327 I guess lots of more features, 1509 02:01:44,327 --> 02:01:49,327 and those are probably the reasons why you would probably want to run BTCD. 1510 02:01:49,327 --> 02:01:52,327 Well, I associate BTCD with LND. 1511 02:01:52,327 --> 02:01:57,327 If I was to be running an LND node at home, would there be any benefit? 1512 02:01:57,327 --> 02:02:00,327 Like, it works better if I have it with BTCD? 1513 02:02:00,327 --> 02:02:03,327 So it used to be that LND only supported BTCD, 1514 02:02:03,327 --> 02:02:06,327 but now it supports Bitcoin core as well, and so now there's no difference. 1515 02:02:06,327 --> 02:02:09,327 Like, that used to be one of the reasons why you would run BTCD, 1516 02:02:09,327 --> 02:02:13,327 because you want to run LND, but that's no longer the case. 1517 02:02:13,327 --> 02:02:18,327 So, if you do run an LND node, right now I don't think it matters, 1518 02:02:18,327 --> 02:02:24,327 but the code that is used by LND is part of BTCD. 1519 02:02:24,327 --> 02:02:28,327 Like, BTCD is very modular, and you can take different packages from it 1520 02:02:28,327 --> 02:02:31,327 and use it in other projects as well, 1521 02:02:31,327 --> 02:02:35,327 and so LND uses a lot of the same code from BTCD. 1522 02:02:35,327 --> 02:02:39,327 So, if you're using LND, you're using a lot of the BTCD code. 1523 02:02:39,327 --> 02:02:41,327 Correct me if I'm wrong, 1524 02:02:41,327 --> 02:02:44,327 but I believe that when Barack took down the Lightning Core, 1525 02:02:44,327 --> 02:02:47,327 it was related to BTCD. 1526 02:02:47,327 --> 02:02:49,327 That was entirely BTCD, yeah. 1527 02:02:49,327 --> 02:02:51,327 Tell me the story. Who is Barack and what happened? 1528 02:02:51,327 --> 02:02:58,327 Oh, Barack, well, he's most known now for being the creator of the ARK protocol, right? 1529 02:02:58,327 --> 02:03:02,327 But before, he used to be more into... 1530 02:03:02,327 --> 02:03:05,327 I guess, at the time, he was working on... 1531 02:03:06,327 --> 02:03:09,327 Shoot, what's the... like, liquid stuff? 1532 02:03:10,327 --> 02:03:13,327 Covenant stuff, I believe, at the time, 1533 02:03:13,327 --> 02:03:15,327 and then he was looking into all of these things, 1534 02:03:15,327 --> 02:03:19,327 and I think he just found this bug on BTCD, 1535 02:03:19,327 --> 02:03:22,327 because maybe he was working in Go at the time, 1536 02:03:22,327 --> 02:03:24,327 and so he found it, and he was like, 1537 02:03:24,327 --> 02:03:26,327 well, let me just crash everything. 1538 02:03:26,327 --> 02:03:29,327 So, yeah, that's how it happened. 1539 02:03:29,327 --> 02:03:31,327 And that took down the LND node? 1540 02:03:31,327 --> 02:03:33,327 That took down all the LND nodes, yep. 1541 02:03:33,327 --> 02:03:37,327 And now, Lightning Labs launched their own ARK? 1542 02:03:37,327 --> 02:03:42,327 Yep, they just announced it like three days ago, right? 1543 02:03:42,327 --> 02:03:47,327 What's the difference between BTCD, Utrex-OD, and Floresta? 1544 02:03:47,327 --> 02:03:49,327 Okay, so all these node implementations. 1545 02:03:49,327 --> 02:03:52,327 So, yeah, Utrex-OD is... 1546 02:03:52,327 --> 02:03:54,327 Well, let me explain BTCD first. 1547 02:03:54,327 --> 02:04:00,327 So, BTCD is just a completely alternate implementation of the Bitcoin protocol written in Go, 1548 02:04:00,327 --> 02:04:02,327 and that's BTCD. 1549 02:04:02,327 --> 02:04:05,327 Utrex-OD is a fork of BTCD. 1550 02:04:05,327 --> 02:04:07,327 We were using... 1551 02:04:07,327 --> 02:04:10,327 So, we just took BTCD, forked it, 1552 02:04:10,327 --> 02:04:12,327 and put the Utrex-OD accumulator in there, 1553 02:04:12,327 --> 02:04:14,327 and that is Utrex-OD. 1554 02:04:14,327 --> 02:04:18,327 Floresta is a completely alternate implementation, 1555 02:04:18,327 --> 02:04:23,327 and while the library itself was something that I was heavily involved in, 1556 02:04:23,327 --> 02:04:26,327 the node itself, like the Floresta, the node, 1557 02:04:26,327 --> 02:04:31,327 is completely done from the scratch 1558 02:04:31,327 --> 02:04:36,327 by Davidson, Sousa, and a lot of the guys from Vintium. 1559 02:04:36,327 --> 02:04:40,327 So, there are these three alternate implementations, 1560 02:04:40,327 --> 02:04:44,327 and I guess that's how they relate. 1561 02:04:44,327 --> 02:04:48,327 Floresta and Utrex-OD relate because they both implement the Utrex-O protocol, 1562 02:04:48,327 --> 02:04:50,327 so they can talk to each other, 1563 02:04:50,327 --> 02:04:53,327 but there's no code sharing in between them. 1564 02:04:54,499 --> 02:04:55,459 Cool. Thank you. 1565 02:05:07,939 --> 02:05:13,859 All right. We are at the center of Bitcoin. Bitcoin is governed by consensus, not authority. 1566 02:05:13,859 --> 02:05:18,899 So, that much you already know because you're here today. So, node runners collectively 1567 02:05:18,899 --> 02:05:24,579 steer the future of Bitcoin. Node runners are human, but how do we know what's good for Bitcoin? 1568 02:05:26,739 --> 02:05:31,939 And what if the main attack vector is actually education, meaning access to information? 1569 02:05:32,979 --> 02:05:40,179 Because most Bitcoiners want what's best for Bitcoin, but decisions are made with often, 1570 02:05:40,179 --> 02:05:46,579 or sometimes incomplete, emotional, or biased information. So, how do we know what's actually 1571 02:05:46,579 --> 02:05:51,059 best and good for Bitcoin when a new consensus change arrives, when a new soft fork arrives? 1572 02:05:52,019 --> 02:05:58,659 How do we know? How do we have access to relevant information? When information is scattered 1573 02:05:58,659 --> 02:06:06,339 on GitHub, mailing lists, podcasts, YouTube, we can listen to big voices that cite the technical 1574 02:06:06,339 --> 02:06:15,219 information and mix it with emotional things, we can say. Here we can see education is the bridge, 1575 02:06:15,219 --> 02:06:22,979 or a bridge, between users and consensus. That's why we built JustAskBips to help 1576 02:06:22,979 --> 02:06:29,939 non-technical node runners understand consensus proposals and their second order of implications 1577 02:06:29,939 --> 02:06:36,659 that are often technical. And here, today, we're going to demo you our two main features, 1578 02:06:36,659 --> 02:06:42,899 which is how we let non-technical users talk directly to the Bips through an ILM interface, 1579 02:06:43,459 --> 02:06:51,859 and our sentiment analysis market on each Bip built on Nuster, thanks to Shakespeare AI. 1580 02:06:51,859 --> 02:06:54,099 I'm going to let you give the demo. 1581 02:06:57,299 --> 02:07:05,939 So, as Hugo said, we built an educational tool whose main goal is to explain to non-technical 1582 02:07:05,939 --> 02:07:13,459 people what is a Bip, how a specific Bip works to make a very informed decision. So, we took 1583 02:07:13,459 --> 02:07:20,339 the whole Bip repository, we filtered for those changes that are consensus-related, so any soft 1584 02:07:20,339 --> 02:07:25,779 fork that we could had, we had during our history, and that we are going to have probably in the 1585 02:07:25,779 --> 02:07:34,659 future. And we put them here in this very nice view where you can see all the Bip that we have, 1586 02:07:34,659 --> 02:07:40,499 all are divided by whether they were closed, deployed, whether they are complete or still in 1587 02:07:40,499 --> 02:07:45,859 draft, and you can see for yourself, and you can decide that you want to know more about a Bip. 1588 02:07:45,859 --> 02:07:54,339 For example, you want to know more about Bip 54 consensus cleanup. You ask the Bip, and we are 1589 02:07:54,339 --> 02:08:02,179 linked to an LLM that will give you a very plain explanation of what the Bip does, what the Bip is, 1590 02:08:02,179 --> 02:08:07,299 and what is it all about, what actually changes, so that you can actually understand from the main 1591 02:08:07,299 --> 02:08:13,699 source what it's all about. In this case, the answer was cached for simplicity and speed. 1592 02:08:15,299 --> 02:08:21,539 Here you have the whole Bip, so you can actually read the whole Bip itself, so you don't have to 1593 02:08:21,539 --> 02:08:27,859 really trust the LLM to do a real summary, but you also have the whole thing here. And now I'll leave 1594 02:08:27,859 --> 02:08:34,659 the floor to Miguel for the last part. Oh yeah, we also have another feature, sorry, where you can 1595 02:08:34,659 --> 02:08:41,379 actually ask more questions about the Bip, so you can ask him, for example, who are the authors. 1596 02:08:45,299 --> 02:08:53,299 I hope it goes fast. And it will give you, yeah, here we tell you, yeah, Antoine Ponceau and Matt 1597 02:08:53,299 --> 02:09:00,339 Corallo are the authors, so you can chat with the AI. And final step, Miguel. 1598 02:09:01,939 --> 02:09:07,459 So the purpose here is for non-technical people like myself, once I understand what is this 1599 02:09:07,459 --> 02:09:12,819 proposal, what is the change, is this good for Bitcoin, then I would like to go and say like, okay, 1600 02:09:12,819 --> 02:09:17,939 how is the network feeling about this change? And what it's doing right now is going to Noster 1601 02:09:17,939 --> 02:09:23,219 and assessing all of the different posts to understand who is for, against, or neutral, 1602 02:09:23,219 --> 02:09:28,739 and that will help me also make my informed decision. And I can even vote myself as well, 1603 02:09:28,739 --> 02:09:36,339 so that it can help me share more about my point of view. The other thing too is that 1604 02:09:38,259 --> 02:09:45,779 in these last 30 seconds, the goal of all of this is we are democratizing access of 1605 02:09:45,779 --> 02:09:52,419 technical information for everybody, so that everybody can be part of consensus. Thank you. 1606 02:09:57,939 --> 02:10:01,859 So if there is any question, we will be very glad to answer. 1607 02:10:02,499 --> 02:10:10,179 Given that you're using AI to go summarize Nostra sentiment, if I understand correctly, 1608 02:10:11,619 --> 02:10:17,219 have you put any further thought into how you could go and prevent civil tax on Nostra? 1609 02:10:19,459 --> 02:10:25,699 Not yet. Honestly, the idea is to have an LLM scrape the relays for Nostra, 1610 02:10:26,339 --> 02:10:33,779 not yet. Honestly, the idea is to have an LLM scrape the relays for actual sentiment of a 1611 02:10:33,779 --> 02:10:40,019 note, for example, and see what the note really says about the BIP if it's positive 1612 02:10:40,019 --> 02:10:44,019 or negative sentiment. But we had no further thought than this. 1613 02:10:44,579 --> 02:10:47,379 So not to relay only on the Zaps, which can be faked. 1614 02:10:48,979 --> 02:10:51,859 Great job, team. Just ask BIPs. 1615 02:10:52,979 --> 02:10:53,779 Thank you, everyone. 1616 02:10:56,579 --> 02:11:05,779 Now I'm going to talk about Bitcoin Kernel, MCP. If you've ever asked an AI agent to reason about 1617 02:11:05,779 --> 02:11:10,579 consensus validity for you, then you probably have seen that it takes quite a long time. 1618 02:11:10,819 --> 02:11:17,539 It's slow. It burns a lot of tokens. It also likes to hallucinate often. And that's because it's, 1619 02:11:17,539 --> 02:11:22,259 of course, not a very straightforward answer, because it basically needs to build its own 1620 02:11:22,259 --> 02:11:29,379 tools in the background and pull in a lot of information to give you an answer. And, of course, 1621 02:11:29,379 --> 02:11:36,579 in order to improve what agents can do, we give them tools. One of these standards for these tools 1622 02:11:36,659 --> 02:11:43,779 are MCP servers. And we really already have the tool that we need for giving these answers 1623 02:11:43,779 --> 02:11:49,859 correctly. And that's, of course, the Bitcoin Kernel library. So what I did is I wrapped the 1624 02:11:49,859 --> 02:11:57,219 kernel in an MCP server that agents can use, install, that makes them fast, cost efficient, 1625 02:11:58,019 --> 02:12:04,419 and gives the correct answers. So the capabilities of this MCP server are very simple. 1626 02:12:04,899 --> 02:12:10,739 So the capabilities of this MCP server are 17 tool calls that are reaching directly into 1627 02:12:10,739 --> 02:12:16,499 the kernel library. What is provided for the context-free answers, it can give them almost 1628 02:12:16,499 --> 02:12:23,779 instantly. Then it has a sandbox mode where it allows it to mine a local chain in rec test and 1629 02:12:23,779 --> 02:12:29,779 then reason about changes across blocks with that. And it can also access the local data there if 1630 02:12:29,779 --> 02:12:38,099 you give it to that to pull in context. So we'll jump straight to the demo. I have a couple of 1631 02:12:38,819 --> 02:12:45,379 prompts prepared here. So we're playing in hard mode. This is Heiko 4.5, the cheapest and stupidest 1632 02:12:45,379 --> 02:12:51,779 model that you can get access to in code. And at least it can do the ASCII art it told it to do. 1633 02:12:51,779 --> 02:13:00,099 So now we will ask it to tell us if a block header is valid. This is a block header from a 1634 02:13:00,099 --> 02:13:06,739 recent block. It's calling the tool here, the kernel, and it should give us an answer 1635 02:13:07,539 --> 02:13:13,059 that this is a valid block and it extracts some information. So this is almost the same prompt, 1636 02:13:13,059 --> 02:13:20,899 but it has one bit flipped. And that makes the proof of work invalid. And we ask it again, 1637 02:13:20,899 --> 02:13:27,219 and it's going to call the tool again. Hopefully it will tell us that this is not valid. No. 1638 02:13:28,899 --> 02:13:33,939 So the proof of work is invalid. It's information that otherwise it would have probably taken quite 1639 02:13:33,939 --> 02:13:42,899 a long time to collect that. Now I'll show a transaction. And for additional, making it a bit 1640 02:13:42,899 --> 02:13:48,659 more challenging, this is a coin-based transaction. So if an agent would just build some kind of 1641 02:13:51,219 --> 02:13:55,699 basic transaction parser, it would probably stumble over this, that this is a coin-based 1642 02:13:55,699 --> 02:14:03,379 transaction. And so this, of course, should get it correct. You can see the tool calls here because 1643 02:14:04,579 --> 02:14:11,859 I've configured it to confirm that. So yeah, this is correct. And it should tell somewhere 1644 02:14:11,859 --> 02:14:16,339 that it's a consensus valid transaction, et cetera. 1645 02:14:17,539 --> 02:14:24,659 So here I have a raw block. This is block 170. The block famously where 1646 02:14:26,579 --> 02:14:33,299 Satoshi sent the first transaction to Hal Finney. And this should also tell you that it's a valid 1647 02:14:33,299 --> 02:14:38,579 block. What is funny there is this model is so stupid, it still manages sometimes to hallucinate 1648 02:14:38,579 --> 02:14:43,699 some stuff. So actually, like yesterday, it told me this was actually block 100. And when I asked 1649 02:14:43,699 --> 02:14:49,779 it why, it said, like, I don't know. Yeah, but it can tell us this is a correct block. 1650 02:14:50,499 --> 02:14:55,699 And then I'm not sure if this is going to finish in time, but I wanted to show the sandbox mode. 1651 02:14:55,699 --> 02:15:02,739 So I'm going to ask it to use sandbox mode, mine a couple of blocks, and then tell us what the 1652 02:15:03,299 --> 02:15:11,779 heights, what the coinbase amounts are between heights 149 and 150. So because it's reg test, 1653 02:15:11,779 --> 02:15:19,539 there's going to be a halving between these blocks. And so this just shows how it can use this local 1654 02:15:20,419 --> 02:15:27,539 reg test chain to reason about certain changes and give answers to certain questions that are not 1655 02:15:27,539 --> 02:15:33,779 with these completely context-free calls answerable for the kernel library. So this is 1656 02:15:33,779 --> 02:15:40,259 going to take a little bit of time. Maybe it will finish now or when I answer the questions. 1657 02:15:41,299 --> 02:15:45,139 But yeah, I don't really have anything else to say. I can already start answering questions, 1658 02:15:45,139 --> 02:15:50,739 and maybe we'll see the answer while I answer the questions. Oh, there it is. 1659 02:15:58,499 --> 02:16:01,219 What's next for the project? 1660 02:16:03,619 --> 02:16:13,939 I really don't have that much more to add right now. It can make it a little bit more efficient 1661 02:16:13,939 --> 02:16:20,499 and convenient, of course, to get things right all the time. You can always add more better 1662 02:16:20,499 --> 02:16:24,899 instruction, better documentation, of course, for the agent to use it more effectively. 1663 02:16:25,699 --> 02:16:31,779 But especially what I saw there is that the kernel library still could use a few more things, 1664 02:16:31,779 --> 02:16:39,699 a few more features. There's new PRs open there all the time for new calls. But some of them have 1665 02:16:39,699 --> 02:16:45,379 been kind of like, OK, maybe let's see if they actually need it for the community. But with this 1666 02:16:46,099 --> 02:16:53,539 more versatile usage of the kernel library, I think I, for the first time, felt like, OK, 1667 02:16:53,539 --> 02:16:57,859 there's this thing that I would want the library to do and this other thing that I would like it to 1668 02:16:57,859 --> 02:17:04,899 do. So yeah, I think the most excited I'm for this tool is when the kernel itself adds more 1669 02:17:04,899 --> 02:17:10,979 capabilities as well. Great job, Bitcoin Kernel MCP. Thank you. 1670 02:17:14,419 --> 02:17:18,579 Hey, everyone. I'm Connor. For people who don't know me, I am researching the Corverse 1671 02:17:18,659 --> 02:17:24,339 Nods debate. And my number one complaint when trying to translate that into a properly academic 1672 02:17:25,219 --> 02:17:32,019 paper was that, man, I really wish there was a nice, organized way to discuss consensus with 1673 02:17:32,019 --> 02:17:38,979 other verified node operators. And so it got me thinking. And also, when I started Node, 1674 02:17:38,979 --> 02:17:43,299 I always got so excited when I found out our peer connection. So I wish there was a way to, like, 1675 02:17:43,299 --> 02:17:48,339 say hi to these guys and, like, hear about them and, like, especially, like, hear about, like, 1676 02:17:48,339 --> 02:17:52,579 what they're signaling for or what their beliefs are, like, what that got them into Bitcoin, 1677 02:17:52,579 --> 02:17:56,259 just socializing with them. And there's simply just no way to do it right now on the Bitcoin 1678 02:17:56,259 --> 02:18:04,179 blockchain. So welcome to Node Signal. So here is a demo of what it's supposed to look like. It's 1679 02:18:04,179 --> 02:18:11,059 pretty much just I wish it scaled better to the screen here, but it is a node map where you can 1680 02:18:11,059 --> 02:18:14,899 see all your connections, what their implementations are. If you hover your mouse over, 1681 02:18:14,899 --> 02:18:18,739 it'll show you what they're signaling for. So, like, this example node is signaling for 1682 02:18:18,739 --> 02:18:27,619 bit 110, for example. This one's not signaling for anything. This one's at bit 324. And you can go to 1683 02:18:27,619 --> 02:18:33,459 the messages tab, go through, and, like, it's all encrypted. I use that term lightly, of course. It's 1684 02:18:33,459 --> 02:18:39,219 just a four-digit pin. But you can see, like, just fake messages. You can text back and forth and say 1685 02:18:39,219 --> 02:18:45,619 hi, and you'll get, like, random messages back. What was really cool, though, was figuring out 1686 02:18:45,619 --> 02:18:52,739 how to actually connect it. So this blinking one down here is actually my Bitcoin node connected 1687 02:18:52,739 --> 02:19:01,059 to this program. So I can click on this and send a message back and forth. And when I presented 1688 02:19:01,059 --> 02:19:08,579 this yesterday, there was a big problem. There was simply no way to actually do this over the 1689 02:19:08,579 --> 02:19:14,499 Bitcoin blockchain, right? Like, Bitcoin does not allow for this. So the big solution was pretty 1690 02:19:14,499 --> 02:19:20,339 much redesigning the entire program and installing it directly using a tail scale onto my Bitcoin 1691 02:19:20,339 --> 02:19:25,939 node all the way in Tuscaloosa, Alabama. And that is what I managed to do last night at about 1692 02:19:25,939 --> 02:19:34,579 3 a.m. This is my actual node and my actual peers. And that green line you're seeing with the 1693 02:19:34,579 --> 02:19:41,219 blinking live is the demo program that I was just showing before. So I can now go here, text on this, 1694 02:19:41,219 --> 02:19:49,459 and it shows our entire chat thread, including when history was made at 2.39 a.m. And I was really 1695 02:19:49,459 --> 02:19:54,259 happy, as you can see. And even shows when things aren't delivered. So it confirms it goes to sent, 1696 02:19:54,259 --> 02:20:01,379 delivered, not delivered when it was simply just off earlier. And, yeah, and it still allows you 1697 02:20:01,379 --> 02:20:07,619 to send it back and forth. And I know it says my internet's not connected. I can assure you it is. 1698 02:20:07,619 --> 02:20:12,659 It's just a weird gray hall of Wi-Fi here. So I wanted to explain this a little bit more. 1699 02:20:13,699 --> 02:20:20,019 And so I had this little quick slide show for the last two minutes here, where this is essentially 1700 02:20:20,019 --> 02:20:25,219 what it is. It's got a nice pretty AI-generated logo and everything. A peer-to-peer social 1701 02:20:25,219 --> 02:20:29,459 networking that essentially piggybacks off the connections that you already have on the Bitcoin 1702 02:20:29,459 --> 02:20:35,059 blockchain through your peers, and uses that information to then send messages and have its 1703 02:20:35,059 --> 02:20:41,139 own WebSocket on top of it. So here's how it actually works. So the hello, where you get the 1704 02:20:41,139 --> 02:20:48,419 signaling from and everything else, is still normally just port 8333. On top of that, though, 1705 02:20:48,419 --> 02:20:55,699 is the peer-to-peer messaging through port 8788. And then the WebSocket UI is port 8789 on your 1706 02:20:55,699 --> 02:21:01,939 server with your Bitcoin node on it. So it all just is on top of it. It doesn't really mess with 1707 02:21:01,939 --> 02:21:06,499 Bitcoin blockchain, all besides from just saying hello, which your node does anyway. So here's what 1708 02:21:06,499 --> 02:21:11,059 was actually happening in that messaging that I showed you there. So it goes from here in Toronto, 1709 02:21:11,699 --> 02:21:16,339 encrypted, again, use that term lightly, then it's through my TailScale VPN. That's how I 1710 02:21:16,339 --> 02:21:21,059 managed to install everything, get it to work. It receives and decrypts, and then you can see it on 1711 02:21:21,059 --> 02:21:25,299 the WebUI again through TailScale on either side, and then it just goes back the other way. 1712 02:21:27,139 --> 02:21:34,179 So obviously, there's some still big things to address here. Some big disclaimers. It obviously 1713 02:21:34,179 --> 02:21:39,379 opens up a huge attack surface in its current form. You can just IPv6 bomb them, essentially, 1714 02:21:39,379 --> 02:21:43,059 and crash the entire node. So I would not recommend installing this yet until we figure that out. 1715 02:21:43,539 --> 02:21:51,379 And obviously, as I represented earlier, the identity can be faked if you just set it up so 1716 02:21:51,379 --> 02:21:55,379 that can happen. That was intentional because I wanted to be able to test this because this 1717 02:21:55,379 --> 02:22:00,179 laptop does not have a node on it. Encryption is definitely not secure at all in its current form. 1718 02:22:00,179 --> 02:22:05,139 Take a CPU like nine minutes, I think, to crack a four-digit PIN code. And obviously, as proof of 1719 02:22:05,139 --> 02:22:10,019 this conference, they're a way better way to make friends through Bitcoin than texting random nodes 1720 02:22:10,019 --> 02:22:13,779 that you don't know. But yeah, that was my presentation. Thank you guys so much for listening. 1721 02:22:13,779 --> 02:22:26,419 I have a question. What was the hardest part about making this project? 1722 02:22:26,979 --> 02:22:33,139 Definitely getting it to actually be a messaging system and not just a cool proof of concept. 1723 02:22:33,139 --> 02:22:37,299 Getting the proof of function was a major challenge, but once it finally worked, 1724 02:22:37,299 --> 02:22:42,739 it was extremely satisfying. The hardest part now that I think is going to be the most difficult 1725 02:22:42,739 --> 02:22:48,179 part is going to be seeing if I can even make this truly secure for not only just the node itself, 1726 02:22:48,179 --> 02:22:54,259 but for the messaging system, and just in general, just safe, which on a trustless network is pretty 1727 02:22:54,259 --> 02:22:57,219 difficult to do. Great job, NodeSignal. 1728 02:22:57,219 --> 02:23:14,739 Hi, everyone. I'm presenting compact block filters in Bool. Basically, Bool is a wallet that is available 1729 02:23:14,739 --> 02:23:25,219 on mobile and is dedicated to privacy, self-custody, and we are working on it in coordination with the 1730 02:23:25,219 --> 02:23:31,379 Bool Exchange. I'm one of the maintainers, and this is my profile when I had hairs. 1731 02:23:33,139 --> 02:23:37,219 This is an open-source repo, because obviously a wallet should be open-source. 1732 02:23:41,539 --> 02:23:49,779 We are a Flutter, Dart-written wallet, so we are available on mobile mainly for now, 1733 02:23:49,779 --> 02:23:56,019 so iOS and Android, and we are using the BDK bindings that were presented on the first day 1734 02:23:56,019 --> 02:24:02,339 of the conference. On the second day of the conference, they presented the compact block 1735 02:24:02,339 --> 02:24:07,859 filters, so I wanted to give it a try, because as of today, I don't know if you are aware, 1736 02:24:07,859 --> 02:24:13,939 but if you use a wallet and that relies on Electrum, and it's not your Electrum server, 1737 02:24:13,939 --> 02:24:21,059 when you sync your wallet, you take the risk of revealing your address to this third-party Electrum. 1738 02:24:21,859 --> 02:24:26,179 Obviously, in Bool, you can already set your own Electrum server. You can also use Tor, 1739 02:24:26,179 --> 02:24:32,819 but it doesn't mitigate that much the problem, because your IP is switching only every 10 minutes, 1740 02:24:32,819 --> 02:24:40,419 so you can still be clustered by the third-party Electrum server. It was interesting to me to 1741 02:24:41,059 --> 02:24:47,379 learn about compact block filters and to experiment to integrate it in Bool. 1742 02:24:48,179 --> 02:24:56,019 Unfortunately, I don't have an emulator on my laptop, because RAM is expensive, so I have a video 1743 02:24:56,659 --> 02:25:03,619 that I showed yesterday. This is basically the flow that I presented in the first APK yesterday 1744 02:25:03,619 --> 02:25:08,739 to the jury. So, this is a wizard of BoolBitcoin. Sorry, it went a bit fast, but 1745 02:25:10,339 --> 02:25:19,459 you can customize some stuff. You can customize the theme, language, and currency, but 1746 02:25:19,459 --> 02:25:23,859 it's not why we are here. You can decide to participate in the report program, and I encourage 1747 02:25:23,859 --> 02:25:30,579 you to do so, because it helps us to prioritize the issue. Here, we have the new screen that I 1748 02:25:30,579 --> 02:25:36,099 added to the wizard, which basically allows the user to enable the compact block filters. 1749 02:25:48,099 --> 02:25:52,899 And here, we can recover the wallet, and here the screen will go dark, because we have a screen 1750 02:25:52,899 --> 02:25:58,259 protection that is enabled by default to avoid people taking screenshots and stuff like this. 1751 02:25:58,819 --> 02:26:06,579 So, I have to fast forward. So, here is the start of the synchronization through 1752 02:26:06,579 --> 02:26:11,859 the block filters. So, we are querying in the peer-to-peer network. We are trying to find 1753 02:26:11,859 --> 02:26:19,379 peers to request to first sync the block heights, and then collect the block filters. 1754 02:26:20,419 --> 02:26:25,939 Because it was yesterday, and my Wi-Fi is not so good, and we are syncing from the Genesis block, 1755 02:26:25,939 --> 02:26:31,219 it will be super long. So, here we are connected to the peers, and now we see the chain height 1756 02:26:31,219 --> 02:26:40,259 starting to increase. So, what I changed between yesterday and today is to improve the user 1757 02:26:40,259 --> 02:26:47,859 experience. I let the user add a wallet birthday, and we sync only from this period of time. So, 1758 02:26:47,859 --> 02:26:51,139 if you know at what date you create your wallet, we will not sync from the Genesis. 1759 02:26:51,699 --> 02:26:56,659 Unfortunately, the UI is a bit broken on the latest APK, but I can show it to you if you want 1760 02:26:56,659 --> 02:27:06,339 to try. And for new wallet, obviously we shouldn't sync, because we are setting the wallet birthday 1761 02:27:06,339 --> 02:27:14,259 ourselves. So, the trick was a bit... So, the wallet birthday is a date, and we need to find 1762 02:27:14,259 --> 02:27:23,299 which block is close to that date, because the API of Kyoto is taking the block 8 and the block 1763 02:27:23,299 --> 02:27:32,899 hash. So, to find a solution to this problem, I'm using the mempool API that we used to propose to 1764 02:27:32,899 --> 02:27:40,819 the user the fee estimation. So, that's the way I found to properly sync from the wallet birthday 1765 02:27:40,819 --> 02:27:43,939 date, basically. And that's it for me, I think. 1766 02:27:50,659 --> 02:27:55,379 Do you have a rough idea how long it takes, and maybe more importantly, how much data it consumes? 1767 02:27:56,339 --> 02:28:03,539 So, I guess it was told during the speak of the compact block filters, but I think it's 1768 02:28:03,539 --> 02:28:09,939 something like 12 gigabytes. I didn't try to fully sync, because I don't have that much 1769 02:28:09,939 --> 02:28:17,699 data on my contract, on my prepaid SIM, but it should be something like 12 gigabytes in the 1770 02:28:17,699 --> 02:28:26,499 worst case. But with the wallet birthday thing, we can reduce this problematic. Also, we can imagine 1771 02:28:26,499 --> 02:28:34,979 that in the future, we would sync in the background to let the user navigate in the wallet before, 1772 02:28:35,059 --> 02:28:40,179 like, instead of making him stuck on the UI, because it's very frustrating. 1773 02:28:44,979 --> 02:28:47,219 Great job. BDK compact block filters in bold. 1774 02:28:51,219 --> 02:29:00,739 So, can you hack Bitcoin? Can you? Anyone? No? Yeah, it's unhackable right now. We won't go into 1775 02:29:00,739 --> 02:29:06,339 the whole quantum computing stuff. That was yesterday's question. Today is, in this current 1776 02:29:06,339 --> 02:29:13,699 state, can we hack Bitcoin? And the question is, no. But why? Try to find someone and explain it 1777 02:29:13,699 --> 02:29:18,979 to them. Why can't you hack Bitcoin? It's hard to explain. It's a bunch of math, a bunch of 1778 02:29:18,979 --> 02:29:24,659 encryption, a bunch of cryptography. It's complicated. No one's going to understand it. 1779 02:29:24,659 --> 02:29:29,779 But what if there was a fun little game that made it really easy to understand 1780 02:29:29,779 --> 02:29:33,859 why you can't hack Bitcoin? And that's exactly what I'm going to be demoing today. 1781 02:29:34,979 --> 02:29:40,419 So, let's see if together we can hack Bitcoin. We're going to start with the easy level, 1782 02:29:40,419 --> 02:29:46,259 shrimp. And what we're going to do is we are going to get a number, for example, 93, 1783 02:29:47,219 --> 02:29:51,859 and we have to figure out what two prime numbers multiply to make 93. 1784 02:29:52,261 --> 02:29:56,261 I'll give you a little hint, it's divisible by three, so you know one of the prime numbers already. 1785 02:29:56,261 --> 02:30:04,261 Let's figure out the other one. Let's say math is foggy, let's say it's 12. Let's see, is it right? 1786 02:30:04,261 --> 02:30:10,261 Now, 3 times 12 is 36. Really nice, they tell you how far off you are. 1787 02:30:10,261 --> 02:30:16,261 Let's try again. Fundamental math trick, 9 divided by 3 is 3, 3 divided by 3 is 1. 1788 02:30:16,261 --> 02:30:24,261 31, let's see if we crack it. And look at that, access granted. Turns out we can hack Bitcoin. 1789 02:30:24,261 --> 02:30:30,261 Now you can claim your SATs. So I have my wallet here, wallet of Satoshi. 1790 02:30:30,261 --> 02:30:37,261 Put it on the QR code, receive, and as you can see, SATs are live. 1791 02:30:37,261 --> 02:30:43,261 This is in production. I just won one SAT. I'll try not to spend it all in one place. 1792 02:30:44,261 --> 02:30:50,261 And it's also integrated with Wavelength, so it is on Cygnet, not real money, 1793 02:30:50,261 --> 02:30:56,261 and it's 1,000 SATs instead since they don't allow dust, but it generates. 1794 02:30:56,261 --> 02:31:02,261 So this is the easy version. You can get a bit harder. Now it's three digit numbers, 1795 02:31:02,261 --> 02:31:08,261 definitely increase in complexity, but let's try the hard one, the Satoshi one. 1796 02:31:09,261 --> 02:31:13,261 Let's see what we get here. Wow, that's a big number. 1797 02:31:13,261 --> 02:31:19,261 If you can shout out the answer right now without using a device, I will personally send you a Bitcoin. 1798 02:31:19,261 --> 02:31:27,261 But if you can't do that, we can cheat. What is cheating? Well, you can buy the answer. 1799 02:31:27,261 --> 02:31:33,261 So it will cost you double the reward, not the most profitable, but you can do it. 1800 02:31:33,261 --> 02:31:39,261 I'll do it. I've got my wallet ready. Let's see. Scan it. There we go. 1801 02:31:39,261 --> 02:31:45,261 I'll pay the six SATs. Great demo on Lightning Network 2 at the same time. 1802 02:31:45,261 --> 02:31:50,261 There we go. We bought it. Both primes are now filled in. Look at that. 1803 02:31:50,261 --> 02:31:55,261 We figured it out. Let's double check it's right. It is. 1804 02:31:56,261 --> 02:32:03,261 Now the most exciting thing is that this also is on the real blockchain with open timestamps. 1805 02:32:03,261 --> 02:32:10,261 So now everyone here saw that I was able to hack Bitcoin even with such a big number 1806 02:32:10,261 --> 02:32:15,261 because the blockchain doesn't lie. So it's obviously true. 1807 02:32:15,261 --> 02:32:21,261 Now a little bit of disclosure on this. This is sort of the basics of RSA encryption 1808 02:32:21,261 --> 02:32:26,261 rather than elliptic curve cryptography. So not exactly Bitcoin. 1809 02:32:26,261 --> 02:32:30,261 But a game for Bitcoin and ECC was a little bit more complex. 1810 02:32:30,261 --> 02:32:34,261 So I thought I'd keep it simple because the idea is the same. 1811 02:32:34,261 --> 02:32:39,261 The reason we can't hack Bitcoin or any encryption based on cryptography 1812 02:32:39,261 --> 02:32:44,261 is that the math is really easy going forwards. And once you know it and you have the answer, 1813 02:32:44,261 --> 02:32:50,261 but going backwards is practically impossible at the level of computation that we have today. 1814 02:32:50,261 --> 02:32:53,261 So that's my presentation. 1815 02:32:59,261 --> 02:33:03,261 What was the most difficult part about shipping this project? 1816 02:33:03,261 --> 02:33:07,261 I really wanted to make it based on Bitcoin and ECC. 1817 02:33:07,261 --> 02:33:12,261 So I spent quite a bit of time trying to think about a nice game with proper progression. 1818 02:33:12,261 --> 02:33:17,261 Didn't find that in the right time frame. So stuck to the good old fashioned RSA. 1819 02:33:18,261 --> 02:33:21,261 Great job, team. Can you hack BTC? 1820 02:33:21,261 --> 02:33:23,261 Thank you. 1821 02:33:23,261 --> 02:33:28,261 All right. Hello, everyone. I'm Curtis with Template Watcher. 1822 02:33:28,261 --> 02:33:34,261 So in 2,000 blocks or so, BIP 110 is going to activate. 1823 02:33:34,261 --> 02:33:41,261 And the thing everybody is watching is the signaling percentage from miners. 1824 02:33:42,261 --> 02:33:48,261 And there's resources where you can look at this, such as this open source one from Kilombino. 1825 02:33:49,261 --> 02:33:55,261 But I believe that the signaling percentage is not the right thing to be watching 1826 02:33:55,261 --> 02:33:57,261 in the lead up to the activation. 1827 02:33:57,261 --> 02:34:06,261 The right thing to be watching is the number of miners or the number of blocks 1828 02:34:06,261 --> 02:34:12,261 on a per miner basis that are compliant with BIP 110 but not signaling. 1829 02:34:12,261 --> 02:34:14,261 So I created Template Watcher. 1830 02:34:14,261 --> 02:34:21,261 And yesterday, the data was based on Kilombino's website, pulling from his API. 1831 02:34:21,261 --> 02:34:28,261 But I have ported it over to my own node, so it's pulling the data from my own node now. 1832 02:34:29,261 --> 02:34:34,261 And when you go to the website, you will see a watch feed, 1833 02:34:34,261 --> 02:34:39,261 which currently says no positioning detected because no miners are positioning, 1834 02:34:39,261 --> 02:34:45,261 no mining pools are positioning for BIP 110 yet, if they ever do. 1835 02:34:45,261 --> 02:34:51,261 But when any blocks come out that are positioned for it, they will show up here. 1836 02:34:52,261 --> 02:35:00,261 And then I have the pool matrix, which you can sort by pool, blocks, block number, 1837 02:35:01,261 --> 02:35:09,261 block signaling percentage, compliance percentage, and then compliant but not signaling. 1838 02:35:10,261 --> 02:35:15,261 And I believe that this is a good indicator because it's harder to become compliant 1839 02:35:15,261 --> 02:35:20,261 than it is to signal for compliance, and no miner is incentivized to do that. 1840 02:35:21,261 --> 02:35:30,261 But they will start becoming compliant on the lead up to the activation date if they're going to flip. 1841 02:35:32,261 --> 02:35:40,261 And then down here, I have some charts, which show on a pool by pool basis. 1842 02:35:40,261 --> 02:35:45,261 And there's some block ranges here. 1843 02:35:45,261 --> 02:35:50,261 So these are difficulty adjustment periods, and you can sort it by that. 1844 02:35:50,261 --> 02:35:55,261 And so on the far right, you'll see the mandatory signaling deadline. 1845 02:35:55,261 --> 02:36:04,261 And so I would expect if any mining pools are thinking of switching or are planning to switch, 1846 02:36:04,261 --> 02:36:09,261 you'll see these lines that are flatlining at the bottom, or there's very little variability, 1847 02:36:09,261 --> 02:36:14,261 you'll see those start to climb very close to that line. 1848 02:36:15,261 --> 02:36:20,261 You can also see which ones are signaling, and as you can see, there's none except for ocean right now. 1849 02:36:24,261 --> 02:36:27,261 And then, of course, I have some information about the compliance rules. 1850 02:36:27,261 --> 02:36:38,261 So this is a neutral, non-opinionated data source, fully on my own stack, and it's live right now. 1851 02:36:38,261 --> 02:36:44,261 So you can go to templatewatcher.curtisheinen.com and you'll see exactly what I'm presenting here. 1852 02:36:46,261 --> 02:36:56,261 On the back end, there's an indexer and an API, and the indexer just pulls from my own node, 1853 02:36:56,261 --> 02:37:05,261 and the front end just pulls from the API and displays the data. 1854 02:37:05,261 --> 02:37:10,261 The front end is doing all of the analysis here. 1855 02:37:11,261 --> 02:37:19,261 Yesterday, everything had been fully vibed with Shakespeare, which is by Soapbox, 1856 02:37:19,261 --> 02:37:26,261 but since yesterday, as I ported it over to my own stack, I used a lot of Cloud Code as well. 1857 02:37:26,261 --> 02:37:29,261 So this is fully vibe-coded. 1858 02:37:29,261 --> 02:37:37,261 And yeah, this will be up until after activation day, so if anyone wants to follow along, 1859 02:37:37,261 --> 02:37:41,261 they can just go to this website and it'll stay up. 1860 02:37:41,261 --> 02:37:43,261 That's good. Thank you. 1861 02:37:43,261 --> 02:37:49,261 APPLAUSE 1862 02:37:49,261 --> 02:37:59,261 Have you considered making test transactions to validate if the compliance rate actually reflects transactions 1863 02:37:59,261 --> 02:38:02,261 in the mempool that could be mined, rather than just random luck? 1864 02:38:03,261 --> 02:38:05,261 I've considered it, but I haven't done it. 1865 02:38:10,261 --> 02:38:12,261 Great job, team TemplateWatcher. 1866 02:38:12,261 --> 02:38:15,261 APPLAUSE 1867 02:38:15,261 --> 02:38:17,261 Thank you. 1868 02:38:17,261 --> 02:38:20,261 All right, that concludes our finalist presentations. 1869 02:38:20,261 --> 02:38:23,261 Can we get another big round of applause for all of our finalists? 1870 02:38:23,261 --> 02:38:26,261 APPLAUSE 1871 02:38:26,261 --> 02:38:27,261 Thank you. 1872 02:38:56,261 --> 02:39:19,261 MUSIC 1873 02:39:19,261 --> 02:39:25,261 Hi, my name is Jerry. 1874 02:39:25,261 --> 02:39:31,261 I'm the founder of OptinLabs, and we're building out a lot of the user interfaces 1875 02:39:31,261 --> 02:39:36,261 to help users control covenants, introspection, and just better guardrails for their funds. 1876 02:39:36,261 --> 02:39:39,261 Right now it's on Bitcoin Cash, but hopefully Bitcoin soon. 1877 02:39:39,261 --> 02:39:43,261 Yeah, I noticed you have a Bitcoin Cash shirt on. 1878 02:39:43,261 --> 02:39:46,261 Can you tell me a little bit about why you like Bitcoin Cash? 1879 02:39:47,261 --> 02:39:52,261 Yeah, I mean, I won't go into too much detail, but for the context of this conference, 1880 02:39:52,261 --> 02:39:58,261 a lot of it, quite honestly, is just down to the covenants and the introspection capabilities. 1881 02:39:58,261 --> 02:40:05,261 There's something that's very similar to, I would say, CTV and CSFS on BCH, 1882 02:40:05,261 --> 02:40:09,261 and a lot of issues with that implementation, I guess. 1883 02:40:09,261 --> 02:40:12,261 But yeah, I just wanted to share some of the insights with people 1884 02:40:12,261 --> 02:40:18,261 and see how exactly we can incorporate covenants and introspections on BTC later on. 1885 02:40:18,261 --> 02:40:22,261 I heard this line that Ethereum is like the Bitcoin testnet. 1886 02:40:22,261 --> 02:40:27,261 Do you think that Bitcoin Cash has been like a Bitcoin testnet for trying out different stuff? 1887 02:40:27,261 --> 02:40:29,261 I mean, same underlying tech? 1888 02:40:29,261 --> 02:40:34,261 I think right now a lot of the companies are really just defaulting to Ethereum 1889 02:40:34,261 --> 02:40:38,261 because they're looking for the smart contract capabilities to better control their funds. 1890 02:40:39,261 --> 02:40:42,261 We were just at the Blockchain Futures conference earlier this week. 1891 02:40:42,261 --> 02:40:46,261 There was a Bitcoin Cash booth, and most people didn't even know that 1892 02:40:46,261 --> 02:40:51,261 there's all this programming capabilities, tokens, all this kind of stuff. 1893 02:40:51,261 --> 02:40:54,261 We have DEXs, stable coins, and whatnot. 1894 02:40:54,261 --> 02:40:59,261 So I think it's a good stepping stone into getting more of that programmability 1895 02:40:59,261 --> 02:41:03,261 into something like Bitcoin itself, just because the architecture is way more efficient 1896 02:41:03,261 --> 02:41:06,261 than anything like EVM or Solana or whatnot. 1897 02:41:06,261 --> 02:41:09,261 And just to say, Jerry, you're a true Toronto Bitcoin OG. 1898 02:41:09,261 --> 02:41:12,261 You've been part of the Bitcoin community since I first met you many years ago. 1899 02:41:12,261 --> 02:41:15,261 Tell me about your origins of Bitcoin in Toronto. 1900 02:41:15,261 --> 02:41:21,261 Yeah, so I started out with organizing Bitcoin meetups, Bitcoin Bay meetups. 1901 02:41:21,261 --> 02:41:25,261 Unfortunately, in Toronto, it's a birthplace of Ethereum, 1902 02:41:25,261 --> 02:41:28,261 so very, very quickly exploring other things. 1903 02:41:28,261 --> 02:41:34,261 But yeah, no, it's a lot of meetups that we were doing. 1904 02:41:35,261 --> 02:41:39,261 We try to get people to come out, show up, do their demos, 1905 02:41:39,261 --> 02:41:42,261 talk about some of the new emerging things that are coming out, 1906 02:41:42,261 --> 02:41:45,261 and really just try to keep the community spirit alive. 1907 02:41:45,261 --> 02:41:48,261 So yeah, that's basically the main thing. 1908 02:41:48,261 --> 02:41:52,261 And I'm glad that a decade afterwards, when I started in 2014, 1909 02:41:52,261 --> 02:41:55,261 there's you guys doing all these meetups. 1910 02:41:55,261 --> 02:41:57,261 There's everyone else doing all their meetups. 1911 02:41:57,261 --> 02:42:00,261 So it's good to see that. 1912 02:42:00,261 --> 02:42:03,261 Excellent. So you're not, despite being a B-cashier, 1913 02:42:03,261 --> 02:42:05,261 you're not actually against Bitcoin. 1914 02:42:05,261 --> 02:42:08,261 And if Bitcoin had the functionality that you wanted, 1915 02:42:08,261 --> 02:42:11,261 you would come over to Bitcoin and build your projects here. 1916 02:42:11,261 --> 02:42:14,261 It would make bridging a lot easier, right? 1917 02:42:14,261 --> 02:42:18,261 So we can do things like, but yeah, like at the end of the day, 1918 02:42:18,261 --> 02:42:21,261 like all this covenant introspection and whatnot. 1919 02:42:21,261 --> 02:42:26,261 Like I was in OpNext in 2024, and the energy was great, right? 1920 02:42:26,261 --> 02:42:29,261 It was a lot of talks about all these covenants and whatnot. 1921 02:42:29,261 --> 02:42:31,261 And then one month later, everything got derailed. 1922 02:42:31,261 --> 02:42:36,261 So yeah, we're hoping that maybe by 2027, 2028, 1923 02:42:36,261 --> 02:42:38,261 some of these capabilities can come in. 1924 02:42:38,261 --> 02:42:42,261 Because as I said, there's a lot more of these interoperability. 1925 02:42:42,261 --> 02:42:46,261 I describe covenants as kind of like programmable checks, 1926 02:42:46,261 --> 02:42:50,261 whereas right now everyone is essentially just signing blank checks. 1927 02:42:50,261 --> 02:42:52,261 So a little bit more guardrail would be nice. 1928 02:42:52,261 --> 02:42:54,261 Thank you so much, Jerry. 1929 02:42:54,261 --> 02:42:55,261 Awesome. Thanks so much. 1930 02:43:00,261 --> 02:43:08,261 Hey, everyone. 1931 02:43:08,261 --> 02:43:11,261 We are starting again after the hackathon finalists. 1932 02:43:11,261 --> 02:43:14,261 Right now, our next guest is Paul Sztorc, 1933 02:43:14,261 --> 02:43:18,261 and he's going to talk about stuff he's working about. 1934 02:43:18,261 --> 02:43:22,261 So please give him a huge welcome. Thank you. 1935 02:43:22,261 --> 02:43:25,261 Thank you, guys. Thank you very much. 1936 02:43:25,261 --> 02:43:27,261 That's the actual title. 1937 02:43:27,261 --> 02:43:29,261 That's the stuff we're working on. 1938 02:43:29,261 --> 02:43:31,261 But I think you guys will get a lot out of it, 1939 02:43:31,261 --> 02:43:33,261 because I have a lot of unconventional views, 1940 02:43:33,261 --> 02:43:36,261 and I'm working on a lot of stuff that's actually pretty cool, I think. 1941 02:43:36,261 --> 02:43:39,261 So I thought it would be like 15 minutes to just sprint through. 1942 02:43:39,261 --> 02:43:44,261 This has barely been enough time to touch on a few of the things that we're doing. 1943 02:43:44,261 --> 02:43:46,261 And then I thought we could do Q&A. 1944 02:43:46,261 --> 02:43:48,261 But, you know, we'll see. 1945 02:43:48,261 --> 02:43:50,261 I normally rehearse the talk to death, but I didn't really time it. 1946 02:43:50,261 --> 02:43:53,261 So we'll see how these times end up going. 1947 02:43:54,261 --> 02:43:57,261 The first thing is this idea of drive chain that you probably have heard of, 1948 02:43:57,261 --> 02:43:59,261 which is BIPS 300-301. 1949 02:43:59,261 --> 02:44:04,261 And it creates this layer 2 side chain that was coined by Blockstream. 1950 02:44:04,261 --> 02:44:07,261 And the idea is it's a separate blockchain, 1951 02:44:07,261 --> 02:44:09,261 and it's merge-mined, and this is key. 1952 02:44:09,261 --> 02:44:12,261 When you withdraw the funds back, 1953 02:44:12,261 --> 02:44:15,261 it's a slow withdrawal that is acted by miners. 1954 02:44:15,261 --> 02:44:20,261 So the idea is that the miners farm up the chain with merge-mining for money, 1955 02:44:20,261 --> 02:44:23,261 and this encourages them to keep the withdrawals honest, 1956 02:44:23,261 --> 02:44:26,261 because the net present value, the fees they earn, 1957 02:44:26,261 --> 02:44:29,261 is always higher than the total amount of coins on the chain 1958 02:44:29,261 --> 02:44:31,261 at any time that you could withdraw. 1959 02:44:31,261 --> 02:44:35,261 So if you're interested in this idea, this is the drivechain.info is the site. 1960 02:44:35,261 --> 02:44:39,261 But really, this idea, even though it's from 2015, 1961 02:44:39,261 --> 02:44:41,261 it's much better than the state-of-the-art. 1962 02:44:41,261 --> 02:44:43,261 It's much better than many other ideas. 1963 02:44:43,261 --> 02:44:47,261 So, for example, Lightning, if you use it as a scaling solution, 1964 02:44:47,261 --> 02:44:50,261 it has this onboarding problem that's unfixable. 1965 02:44:50,261 --> 02:44:53,261 It has this liquidity channel rebalancing problem. 1966 02:44:53,261 --> 02:44:57,261 It has a problem where the HTLCs cannot be enforced if the L1 fee rates are too high. 1967 02:44:57,261 --> 02:44:59,261 And it has this routing problem. 1968 02:44:59,261 --> 02:45:01,261 But none of these things happen in drivechain. 1969 02:45:01,261 --> 02:45:03,261 You can onboard people directly to the L2, 1970 02:45:03,261 --> 02:45:06,261 and you can do as many transactions as you want over there 1971 02:45:06,261 --> 02:45:08,261 without requiring any more L1 bytes. 1972 02:45:08,261 --> 02:45:09,261 So it's better than that. 1973 02:45:09,261 --> 02:45:12,261 ARK, it seems like ARK has been changing a lot, 1974 02:45:12,261 --> 02:45:16,261 but when I look into it, usually there's this idea that ARK has to be over-collateralized, 1975 02:45:16,261 --> 02:45:19,261 where there's a lot of transactions changing hands, 1976 02:45:19,261 --> 02:45:25,261 and you need transactions for every open payment. 1977 02:45:25,261 --> 02:45:30,261 That is far in excess of the coins that have actually been in use at any one time, 1978 02:45:30,261 --> 02:45:33,261 but we don't have that problem in drivechain. 1979 02:45:33,261 --> 02:45:36,261 There's no merge mining in ARK. 1980 02:45:36,261 --> 02:45:38,261 I suppose you could try to add it some way, 1981 02:45:38,261 --> 02:45:42,261 but the merge mining is key for a reason I presented up next, 1982 02:45:42,261 --> 02:45:50,261 which is that you don't want there to be a conflict of interest between the L1 miners and the L2. 1983 02:45:50,261 --> 02:45:53,261 So it's also much simpler. 1984 02:45:53,261 --> 02:45:56,261 And even stuff like snarks, which are kind of like they have these magical properties, 1985 02:45:56,261 --> 02:46:01,261 like super compression, but because of the data availability problem, it doesn't even matter. 1986 02:46:01,261 --> 02:46:07,261 And even snarks have this idea where maybe miners could theoretically steal from the drivechain, 1987 02:46:07,261 --> 02:46:09,261 but in the snark they could not. 1988 02:46:10,261 --> 02:46:13,261 It ends up not mattering because the miners don't want to steal. 1989 02:46:13,261 --> 02:46:16,261 They make more money by not stealing than they make from stealing. 1990 02:46:16,261 --> 02:46:20,261 So even if there was some kind of glitch where they accidentally stole, they'd get the money back. 1991 02:46:20,261 --> 02:46:22,261 So that's just a tiny thing for that. 1992 02:46:22,261 --> 02:46:24,261 And drivechain doesn't just do scaling, it does all this other stuff. 1993 02:46:24,261 --> 02:46:25,261 You can do whatever you like. 1994 02:46:25,261 --> 02:46:27,261 You have EVM chain. 1995 02:46:27,261 --> 02:46:29,261 We have a chain based on Namecoin. 1996 02:46:29,261 --> 02:46:32,261 We have a z-side privacy chain based on the Orchard Rust crate. 1997 02:46:32,261 --> 02:46:34,261 We have a prediction markets thing. 1998 02:46:34,261 --> 02:46:35,261 So you can do anything. 1999 02:46:35,261 --> 02:46:37,261 We've got the Elements Plus. 2000 02:46:37,261 --> 02:46:38,261 We have a bunch of stuff. 2001 02:46:38,261 --> 02:46:40,261 So it's actually a pretty cool idea. 2002 02:46:40,261 --> 02:46:45,261 The other thing is this Qsift, the core untouched soft fork. 2003 02:46:45,261 --> 02:46:49,261 The soft fork is this really great idea, but we can't do it anymore. 2004 02:46:49,261 --> 02:46:53,261 And so the question is how can we get the soft fork back? 2005 02:46:53,261 --> 02:46:57,261 And the answer is use soft fork Bitcoin without changing any lines of code in Bitcoin Core. 2006 02:46:57,261 --> 02:47:01,261 So this requires a second piece of software, which is the soft fork activator. 2007 02:47:01,261 --> 02:47:06,261 But it does basically what the lines of code would do. 2008 02:47:06,261 --> 02:47:08,261 Oh, I think maybe this got cut off a little bit. 2009 02:47:08,261 --> 02:47:10,261 But I think at the top, the left one. 2010 02:47:10,261 --> 02:47:11,261 Okay, no, I did it like this. 2011 02:47:11,261 --> 02:47:13,261 So Qsift is the left part. 2012 02:47:13,261 --> 02:47:16,261 You have a separate blue square. 2013 02:47:16,261 --> 02:47:23,261 And then in Bitcoin Core pull request, you'd have like some lines of code that throw invalidate block in the Bitcoin Core. 2014 02:47:23,261 --> 02:47:28,261 But in this, you have a second piece of software that checks the soft fork rules. 2015 02:47:28,261 --> 02:47:30,261 And then it calls invalidate block. 2016 02:47:30,261 --> 02:47:32,261 So it requires a second piece of software. 2017 02:47:32,261 --> 02:47:34,261 It requires 51% hash rate. 2018 02:47:34,261 --> 02:47:39,261 There is a little site, BIP300Qsift.com, although it's not limited to BIP300Qsift. 2019 02:47:39,261 --> 02:47:47,261 And, in fact, we have a new one made by Hunter Beast in part that has quantum resistant signatures to the L1 of Bitcoin. 2020 02:47:47,261 --> 02:47:51,261 And we're also going to add like OpVault and like OpCat to that one. 2021 02:47:51,261 --> 02:47:53,261 That will be like an experimental one. 2022 02:47:53,261 --> 02:47:57,261 But this has lots and lots of benefits over the core pull requests. 2023 02:47:57,261 --> 02:48:01,261 So you can just – one is that you can have competing benevolent dictators. 2024 02:48:01,261 --> 02:48:03,261 You just have different people just make one. 2025 02:48:03,261 --> 02:48:07,261 And now they don't have to go through the Bitcoin Core review process. 2026 02:48:07,261 --> 02:48:09,261 You don't have this kind of monopoly process. 2027 02:48:09,261 --> 02:48:13,261 So you have just one benevolent dictator on the right there. 2028 02:48:13,261 --> 02:48:18,261 Another weird thing is that the activator could be in any programming language. 2029 02:48:18,261 --> 02:48:22,261 It could be in Rust or it could just be in whatever you like. 2030 02:48:22,261 --> 02:48:28,261 Whereas if you do the Bitcoin Core pull request, not only do you have to go through the gatekeepers at Bitcoin Core, 2031 02:48:28,261 --> 02:48:34,261 but it has to be like C++, it has to be whatever the style guides are, CamelCase, whatever, et cetera. 2032 02:48:34,261 --> 02:48:41,261 So the idea is that we could reclaim the Qsift thing like this. 2033 02:48:41,261 --> 02:48:44,261 And then this other thing we have is called BitWindow. 2034 02:48:45,261 --> 02:48:53,261 This is pretty cool because this is very similar to Qsift really where it's like a different front end to Bitcoin Core. 2035 02:48:53,261 --> 02:48:58,261 Bitcoin Core right now, it has this Qt front end. 2036 02:48:58,261 --> 02:49:02,261 And I know there's some other – people have been talking about having a different front end for a really long time. 2037 02:49:02,261 --> 02:49:08,261 I have no idea what the status is of that, but I assume that it's taking forever and it doesn't quite exist. 2038 02:49:08,261 --> 02:49:11,261 So no one really likes the Qt front end. 2039 02:49:11,261 --> 02:49:18,261 And even it's a mainstream view that it should be ignored or not paid very much attention to. 2040 02:49:18,261 --> 02:49:22,261 So the cool thing is you have a different front end to Bitcoin Core. 2041 02:49:22,261 --> 02:49:24,261 You can put in whatever you want in there. 2042 02:49:24,261 --> 02:49:29,261 And it just pilots Bitcoin D and Bitcoin CLI under the hood. 2043 02:49:29,261 --> 02:49:32,261 And so we put a lot of cool stuff in there. 2044 02:49:32,261 --> 02:49:35,261 We have this thing, Multisig Lounge, user-friendly Multisig. 2045 02:49:35,261 --> 02:49:37,261 You have different wallets of different types. 2046 02:49:37,261 --> 02:49:42,261 You have like a BDK wallet, Electrum wallet, custom wallet. 2047 02:49:42,261 --> 02:49:44,261 You can put like a block explorer in there. 2048 02:49:44,261 --> 02:49:49,261 So I actually have a picture on the next page, which is that this is an example. 2049 02:49:49,261 --> 02:49:50,261 This is actually an old example. 2050 02:49:50,261 --> 02:49:53,261 We've added many, many things since this version. 2051 02:49:53,261 --> 02:49:58,261 But if you just see just from this alone, you have lots of different things. 2052 02:49:58,261 --> 02:50:01,261 So deniability is like a thing that sends your own coins to you a bunch of times. 2053 02:50:01,261 --> 02:50:06,261 So this is kind of like a move fast and break things type of idea where it's like you can just do whatever you want with this. 2054 02:50:06,261 --> 02:50:11,261 This is a cosmetic optional front end to Bitcoin Core. 2055 02:50:11,261 --> 02:50:13,261 So you can do whatever you like. 2056 02:50:13,261 --> 02:50:20,261 And if you want to do new things, this is the perfect place because it doesn't touch like actual Bitcoin D. 2057 02:50:20,261 --> 02:50:23,261 It doesn't touch consensus. 2058 02:50:23,261 --> 02:50:27,261 So, yeah, a lot of these things were in like Satoshi's original client or like old clients. 2059 02:50:27,261 --> 02:50:31,261 And then I think that the Bitcoin Core front end has gotten worse over time. 2060 02:50:31,261 --> 02:50:36,261 A lot of the stuff we did was just undoing what people did. 2061 02:50:36,261 --> 02:50:39,261 This is a very simple one, literally. 2062 02:50:39,261 --> 02:50:40,261 Simple pool. 2063 02:50:40,261 --> 02:50:46,261 So we were kind of asking, you know, why isn't there any open source mining pool software? 2064 02:50:46,261 --> 02:50:49,261 And we looked for some, but we didn't find any. 2065 02:50:49,261 --> 02:50:50,261 So we made some. 2066 02:50:50,261 --> 02:50:58,261 And we also have this idea, this pool hopper system where if you have SHA256D hash rate, 2067 02:50:58,261 --> 02:51:03,261 you just go to the pool hopper and it will just give you whatever gives you the highest PPS. 2068 02:51:03,261 --> 02:51:05,261 It will just do it for you. 2069 02:51:05,261 --> 02:51:08,261 It will just connect you to whichever pool is paying you the most. 2070 02:51:08,261 --> 02:51:14,261 So I'm a huge supporter of PPS, and I can explain why people are interested. 2071 02:51:14,261 --> 02:51:20,261 But if – and also the pool hopper will theoretically do something where if every – it doesn't really work yet. 2072 02:51:20,261 --> 02:51:25,261 But if it's like if every pool is bad, it will automatically create a new pool. 2073 02:51:25,261 --> 02:51:30,261 The reason why no one – because most of the pools today do a very good job, 2074 02:51:30,261 --> 02:51:37,261 and they don't do anything really bad, so it hasn't really been a priority to work on that part. 2075 02:51:37,261 --> 02:51:39,261 But the idea is that there would be this common project. 2076 02:51:39,261 --> 02:51:44,261 We have some people from Stratenvy 2 originally who are working on this. 2077 02:51:44,261 --> 02:51:48,261 And actually, if you use BIP300, it will pay people out on the L2, 2078 02:51:48,261 --> 02:51:54,261 which means that you could have 8 billion different miners, in fact, in theory. 2079 02:51:54,261 --> 02:52:00,261 Because they'd be paying out on L2, and so there's no actual bottleneck there. 2080 02:52:00,261 --> 02:52:05,261 And that's at this URL. 2081 02:52:05,261 --> 02:52:07,261 I'm a huge skeptic of Stratenvy 2. 2082 02:52:07,261 --> 02:52:13,261 I don't know if anyone wants to ask why, but I think the idea of the job selection is a huge mistake 2083 02:52:13,261 --> 02:52:16,261 and is a pointless and counterproductive objective. 2084 02:52:16,261 --> 02:52:19,261 And I also think of the pools as brands. 2085 02:52:19,261 --> 02:52:24,261 So I think it's very desirable that there be a small number of pools where everyone knows the name. 2086 02:52:24,261 --> 02:52:29,261 Because a brand is like a hostage that you can execute if the pool does something wrong, 2087 02:52:29,261 --> 02:52:33,261 whereas if instead you have the giant pie chart with lots of slivers, 2088 02:52:33,261 --> 02:52:36,261 then there's not as much accountability. 2089 02:52:36,261 --> 02:52:39,261 So that's – okay, this is good. It's going pretty well. 2090 02:52:39,261 --> 02:52:45,261 Yeah, I've been a huge shill for prediction markets on Bitcoin since the year 2012. 2091 02:52:45,261 --> 02:52:48,261 That's when I first started yelling about this. 2092 02:52:48,261 --> 02:52:51,261 And I have this site, bitcoinhivemind.com. 2093 02:52:51,261 --> 02:52:54,261 People can check out. There's lots and lots and lots of stuff there. 2094 02:52:54,261 --> 02:52:57,261 And, in fact, my name on Twitter is Truthcoin. 2095 02:52:57,261 --> 02:53:04,261 That originally comes from this paper I wrote in 2014 about a peer-to-peer oracle for Bitcoin. 2096 02:53:04,261 --> 02:53:07,261 Because there really weren't that many altcoins at the time. 2097 02:53:07,261 --> 02:53:13,261 And so this is a huge interest of mine, and I especially favor what are called these multidimensional prediction markets. 2098 02:53:14,261 --> 02:53:15,261 These are very cool. 2099 02:53:15,261 --> 02:53:19,261 You ask a question like which CEO would most increase the stock price, 2100 02:53:19,261 --> 02:53:26,261 or maybe which hard fork to BTC would most increase the exchange rate or something like that. 2101 02:53:26,261 --> 02:53:30,261 I have a lot of thoughts on this, and I think I have some. 2102 02:53:30,261 --> 02:53:32,261 These are old screenshots. 2103 02:53:32,261 --> 02:53:35,261 On the left is Bitwindow. It has its own sidechains tab. 2104 02:53:35,261 --> 02:53:37,261 You can add a new tab whenever you want. 2105 02:53:37,261 --> 02:53:41,261 And then this is downloading the L2 software and starting it up. 2106 02:53:41,261 --> 02:53:47,261 This is an old screenshot, so it doesn't even have the prediction markets software in the list over there. 2107 02:53:47,261 --> 02:53:50,261 And then even this is an old screenshot of the old. 2108 02:53:50,261 --> 02:53:53,261 This was from 2015 or something. 2109 02:53:53,261 --> 02:53:56,261 This is the old test prediction market software. 2110 02:53:56,261 --> 02:54:01,261 But we have new software, and it's not a great screenshot of it now, but you can download. 2111 02:54:01,261 --> 02:54:05,261 If you go to layer2labs.com download and you click all the buttons, 2112 02:54:05,261 --> 02:54:09,261 you can find your way into the new prediction market software. 2113 02:54:10,261 --> 02:54:12,261 I'm very interested in that. 2114 02:54:15,261 --> 02:54:21,261 Now, of course, I'm doing this infamous hard fork of Bitcoin next month, 2115 02:54:21,261 --> 02:54:29,261 but what I wanted to emphasize about this is that there's no real technical change to the software. 2116 02:54:29,261 --> 02:54:36,261 My proposal at the top here is this is the drive chain soft fork that has nothing to do with hard forking Bitcoin, 2117 02:54:36,261 --> 02:54:43,261 it's very collaborative and very conformist. 2118 02:54:43,261 --> 02:54:50,261 So that's just saying let's take Bitcoin Core and we'll add this Q-SYS activator for BIP-300-301. 2119 02:54:50,261 --> 02:54:53,261 So not changing any lines of code in Bitcoin Core. 2120 02:54:53,261 --> 02:54:59,086 We have BIP-300-301, and then these green boxes are the L2s. 2121 02:54:59,086 --> 02:55:14,446 So these are the L2s, you know, Thunder is the scaling, it's a high throughput scaling sidechain, then Bitnames is like the Namecoin style sidechain, and then you got Truthcoin DC is the prediction market sidechain, and there's a bunch of more. 2122 02:55:14,446 --> 02:55:35,806 So up top is the actual proposal that has nothing to do with hard forking Bitcoin at all. But beneath, the hard fork is just basically changing the name, dropping the difficulty artificially, which is what triggers the hard fork, and reassigning 500,000 of Satoshi's coins. But other than that, it's near identical. 2123 02:55:36,526 --> 02:56:01,246 And so there's no like technical reason to hard fork, it is really just intentionally to split off the community and get a little more competition injected into the community. My view is that competition, you know, which is a reward for error correction, that cures all ills, so that the idea is that we have been very complacent in BTC for a long time. 2124 02:56:01,246 --> 02:56:30,606 I wrote this article in July of 2025. So a whole year ago, called the derangements of Bitcoin, which is a long list of like weird things that the whole community is wrong about, and has been wrong about consistently for months or years. And we just cannot, we can't break out of, even though we're all wrong about everything, we can't break out of it. So the question is, are we doomed is a dramatic, dramatic question. 2125 02:56:31,246 --> 02:57:00,526 And okay, so I basically got it in basically 14, 13, 14 minutes. So that was the plan was to do 15, and then do Q&A. And then I'll be on this panel at 345 also. So thanks very much. I know that was kind of bizarre, but I really have my, I'm doing a lot of different things. So I thought that would be a cool thing to just briefly go over a few of them. So there you go. So I look forward to anyone's questions. But thanks a lot. Thanks for paying attention for that part. 2126 02:57:01,246 --> 02:57:07,406 Thanks very much. 2127 02:57:07,406 --> 02:57:15,006 Well, thank you so much for that. That was great, Paul. I wanted to hear more about what you don't like about Stratum V2, if that's not... 2128 02:57:15,006 --> 02:57:34,206 Sure, yeah, we can go back. So Stratum V2, I did write an article about this, but I think the main problem with Stratum V2 is, okay, it bundles a lot of things that are not controversial at all, such as you should have a lot of basic improvements and you should have more authentication and stuff. So all those things are fine. 2129 02:57:34,206 --> 02:57:55,166 But the main selling point of Stratum V2 is this job selection thing, which is that instead of the pool being able to choose what's in a block, the individual miner should be able to choose. And my question is, how could this possibly ever be desirable in any way? And also, it's not actually enforceable, because the pool is the one telling everyone else what to do. 2130 02:57:55,166 --> 02:58:17,886 So to me, the only thing it adds is the ability to actually sabotage the pool and get away with it, because you could join the pool with a tiny amount of hash rate, submit some terrible job where no one is earning any money, and then the pool says, well, listen, because of some guy, we have to do it. And then instead of being able to blame the pool, the pool can just push responsibility onto the... 2131 02:58:18,046 --> 02:58:37,326 So it's really this job selection thing that I have a problem with. I think it's actually fine for the pools to be... since we already need them to aggregate for the variance problem, I think it's perfectly fine to give... and if you have PPS, the pool is just saying, we'll pay you... they're bidding up the hash amount. 2132 02:58:37,326 --> 02:58:56,366 They're saying, we'll pay you this much for the hash price. So you kind of just leave it to them. You say, you pay me as much as you possibly can, and I'm not going to ask too many questions about what you're putting in the block. And I think that's actually best for everyone, because the individual hasher can just pick. So I don't know, does that make sense? 2133 02:58:56,366 --> 02:59:19,726 The job selection thing, I don't think... but this is a very controversial point for some reason, among some people. But I don't know if you agree or disagree. I think this job selection thing is a misconceived idea, especially because if you talk to real miners, they have no idea. A lot of them have no idea. Many of them are not even Bitcoiners, and they just have cheap power. 2134 02:59:19,726 --> 02:59:45,326 They just plug the thing in, and they just set it off, and they're trying to make money. So I don't know if you or anyone else feels very strongly that this job selection thing is... it's the only thing standing between us and transaction censorship or something, which has basically never happened, because there is very, very, very little... miners really don't misbehave. So they don't re-org blocks, they don't censor transactions. So I don't know if you think that. 2135 02:59:45,566 --> 03:00:03,166 I thought a while ago there was one of the miners in the United States was starting to do OFAC address filtering for transactions they were putting in their block templates. That seems like something that you would want to have at least a protocol that can route around. 2136 03:00:03,166 --> 03:00:33,086 Absolutely, 100%. But the thing is, it wasn't like we had this problem, and then Stratum V2 solved it. It's just already there's an incentive. If you pass on picking up the transaction fees, someone else will pick them up. And so I think it's another example of the problem having already solved itself, and that it's not that we need Stratum V2 to manipulate the pie graph and shard it into all these tiny little slices. 2137 03:00:33,486 --> 03:00:35,486 Which I actually think would be bad. 2138 03:00:37,486 --> 03:00:39,486 I don't know if anyone... yes? Great. 2139 03:00:47,486 --> 03:00:55,486 Thanks. I had a question. When you were talking about you have a soft fork and you have a hard fork on that slide. 2140 03:00:56,046 --> 03:01:16,046 So from the way you were talking, it sounded like the soft fork is somehow a lesser big deal or something than the hard fork, but I'm a bit confused because wouldn't they both cause chain splits? What's the difference here? 2141 03:01:16,446 --> 03:01:39,406 The up one is my proposal, which people have declined to accept or not even wrap their head around. So that's like the status quo today is the top. So it's kind of like I offer this for free, and it's like take it or leave it. So does that make sense? Whereas the lower one is different. The lower one is trains leaving the station. 2142 03:01:39,566 --> 03:01:44,046 You're not doing both of them, like activating both of them. They're just one proposal. 2143 03:01:44,046 --> 03:01:54,046 Yes, that's better. That's more clear. Yeah, they're kind of just like two, I guess, philosophies or something. So that's right. Yes. 2144 03:01:55,006 --> 03:01:57,006 Hey, Paul. 2145 03:01:57,006 --> 03:01:59,006 Yes. 2146 03:01:59,006 --> 03:02:21,006 So maybe there's a selection bias with the podcast that I listen to or so, but when I listen to interviews of you on eCash, I felt like you mostly talking about kind of the friction points with the crowd that is here, for example, and there's less information on the kind of different drive chains that you built. 2147 03:02:21,566 --> 03:02:33,566 So you mentioned a couple of times that there's a long list of drive chains and they enable all of these capabilities, but I never really heard or saw you actually like talk about them in detail and what it would enable. 2148 03:02:33,566 --> 03:02:44,046 So it felt like there's not so much like focus on the features in kind of your presentation of what you're doing, but more like focus on the potential stuff that will be controversial. 2149 03:02:45,006 --> 03:03:03,086 Well, that's an interesting thought. I would almost flip it around and say, like, it doesn't actually matter if there's this long list of really good stuff. It kind of doesn't matter if that's true or not, because if it actually is good, then obviously everyone would just adopt it. 2150 03:03:03,086 --> 03:03:11,886 So the actual story is about why are good things not being adopted, I think. So that's almost what I would think that has to be more relevant. You know what I mean? 2151 03:03:11,966 --> 03:03:24,286 Like, imagine if we tried to switch it to a different context and say, like, some corporation is doing something wrong and they're losing a bunch of money and another one wants to start a different company. 2152 03:03:24,286 --> 03:03:32,766 You know, like, I don't know what would be the most relatable example, like Amazon replacing Walmart or something. I'm not sure how to make this analogy work. 2153 03:03:32,766 --> 03:03:45,646 But the story would be more about, like, oh, the CEO is giving all the good jobs to, like, his cousin or his friends or something. Like, that's the real story is what went wrong before. 2154 03:03:46,446 --> 03:04:05,246 In my opinion, this is what went wrong. We have this bad culture in BTC, which, because we've been number one for so long, there's a culture of complacency and overconfidence, and it has just kind of settled into everyone kind of just it's becoming a bureaucratic. 2155 03:04:05,326 --> 03:04:16,926 So that's why I think that's more interesting, because, you know what I mean? Like, if I was right about all this stuff being much better, then it would just automatically, like, everyone would just take all these ideas. 2156 03:04:18,366 --> 03:04:32,046 So I think the real question is why, and it's not, I hate to make it all about myself, like, we can't even get something like Opcat, which is basically harmless and was in the original client and has all these people from 2157 03:04:32,686 --> 03:04:49,166 the Stark people all wanted it, and all these op-nop, op-success, op-cos are opt-in, reversible, and ignorable. So I think that's the bigger story is why is everything so deranged. Does that make sense, or no? I don't know. 2158 03:04:49,486 --> 03:05:05,726 I guess, like, an example would be, like, if people want, like, something like Namecoin or so, like, they have the need for this, they want this, then it would make sense for you to get these people on board that you talk more about something like, we have this Namecoin thing. 2159 03:05:06,206 --> 03:05:22,286 And, like, maybe it's fine for these people that you're stealing Satoshi's coins, like you say in the article there, but, like, since you, it feels to me like you're more talking about, in the front, about, like, stealing Satoshi's coins, and, like, it's more of an afterthought that this enables Namecoin. 2160 03:05:22,926 --> 03:05:48,206 Well, you know, I really don't think so, because I didn't think that this was actually a very relevant point, and actually I think it's quite a clever and ingenious idea, but that was, like, something that people got a lot, got a big reaction out of people, so that's kind of why I wrote the, I see it as mostly as me reacting to other people's, but I think if people actually download the software and whatever, they'll just see what it does for themselves, and so then I think that part will eventually take care of itself. 2161 03:05:48,366 --> 03:06:13,886 I'm not sure if, here's the thing, I've been talking about, you know, the idea of sidechains for even long before I had, even long before DriveChain existed, so even back when the Prediction Markets project was going, that I was interested in sidechains in this way of getting prediction markets on Bitcoin, so I've been talking about cool sidechains on Bitcoin for a long time. 2162 03:06:14,606 --> 03:06:28,766 And I don't think, you know, that got a certain distance, but now, and it's not just that we don't have sidechains, it's that we can't do anything right, I think, I don't think we do almost anything right in BTC. 2163 03:06:28,766 --> 03:06:53,086 I mean, right? I mean, who's, I don't know, I guess it's obviously an outrageous thing to say, but a lightning arc is always a waste of time, the treasury companies is always a waste of time, even, like, a lot of this stuff has become very academic, very convoluted, pretentious, nerd, this is all nerd sniping, you know, a lot of what people do. 2164 03:06:53,086 --> 03:06:54,206 Okay, here we go. 2165 03:06:54,286 --> 03:06:55,406 I have two questions. 2166 03:06:55,406 --> 03:06:58,686 One, I think, would be a follow-on to this comment. 2167 03:06:58,686 --> 03:07:01,886 If we're doing everything wrong, how can we do it better? 2168 03:07:01,886 --> 03:07:03,966 Competition is better. 2169 03:07:03,966 --> 03:07:05,166 More competition. 2170 03:07:05,166 --> 03:07:10,606 Oh, more competition being, like, from the merge mining stuff that you're proposing? 2171 03:07:10,606 --> 03:07:23,886 Things are just a little too much, like, a little too much 100% consensus kumbaya, we need, like, factions, and we need, like, one person to cheer and the other person to cry tears of sadness, we need, like, turnover, you know? 2172 03:07:23,886 --> 03:07:35,806 You know what I mean? Like, we haven't had a lot of, we need more, we need, like, something a little bit like that, where sidechains would help with that, because you have different L2s, you can escape the L1 onto an L2, but even if all the L2s suck, you can make a different L2. 2173 03:07:35,966 --> 03:07:43,726 So we have some competition, but, you know, it's hard with Bitcoin Core, because, so anyway, you were going to ask other things. 2174 03:07:43,726 --> 03:07:44,286 Oh, yeah. 2175 03:07:44,286 --> 03:07:48,766 So it sounds like you're championing the Coliseum, so to speak? 2176 03:07:48,766 --> 03:07:50,446 Yes, yes. 2177 03:07:50,446 --> 03:07:54,446 And then the second question was kind of just going back to your comment about Stratov2 stuff. 2178 03:07:54,446 --> 03:07:56,046 Sorry to keep digging into this. 2179 03:07:56,046 --> 03:08:08,766 But, like, see, one of the comments that you made is that you think that Stratov2 giving miners more choice about what goes into blocks isn't necessarily, like, a useful exercise. 2180 03:08:08,766 --> 03:08:10,206 Yeah, and possibly counterproductive. 2181 03:08:10,206 --> 03:08:11,486 And counterproductive. 2182 03:08:11,486 --> 03:08:18,766 Then maybe I don't have a great concept of how BIP300 with drivechains works, but isn't that giving more choice to miners? 2183 03:08:19,806 --> 03:08:24,206 To some extent, but only if it's pre-designated to them by the users. 2184 03:08:24,766 --> 03:08:35,246 And because of the way Bitcoin is already designed on L1, you have, like, to some extent, your transactions can already be reorg'd out of the blockchain. 2185 03:08:35,246 --> 03:08:39,166 So there's a certain amount of trust we all place in miners, even on L1. 2186 03:08:39,166 --> 03:08:48,846 And it's really, you can transpose it exactly into the L2, the drivechain withdrawal idea, because it's really a very similar thing. 2187 03:08:48,846 --> 03:08:51,966 It's like you're trusting them to pursue the most amount of money for themselves. 2188 03:08:52,926 --> 03:08:55,726 And if that's the case, they will process the withdrawals. 2189 03:08:55,726 --> 03:09:06,206 So, in this case, the alternative is almost nothing, because we don't have these other L2s that can do similar things. 2190 03:09:06,206 --> 03:09:14,766 And in the case of the Stratov2, the alternative is to just keep it with PPS, like we already have, which works just fine. 2191 03:09:14,766 --> 03:09:20,046 Because if the pool, the pool can't pay out any more money than it brings in. 2192 03:09:20,126 --> 03:09:23,166 So the pool already wants to fee-maximize. 2193 03:09:23,166 --> 03:09:25,166 So they're already fee-maximizing, then they pay out. 2194 03:09:25,166 --> 03:09:34,846 So that's why I think it's bizarre for Stratov2 to distract everyone by focusing on the job selection, which I think is a mistake. 2195 03:09:34,846 --> 03:09:37,006 And I don't even think it makes, you know, it doesn't even make any sense. 2196 03:09:37,006 --> 03:09:43,806 If the pool really disagreed with someone, the pool would win, because the pool could just ignore them. 2197 03:09:43,806 --> 03:09:46,926 So I don't even know, you know, it's a very strange thing. 2198 03:09:46,926 --> 03:09:49,646 Of course, if you talk to people, that's what they will talk about all the time. 2199 03:09:49,646 --> 03:09:55,566 They'll talk about how great it is that we've removed power from pools, and it returns control to the little guy. 2200 03:09:55,566 --> 03:10:00,526 So it may even be the case that people working on Stratov2 agree with me, 2201 03:10:00,526 --> 03:10:03,886 and that the whole thing is just a weird meme or something that has spread. 2202 03:10:03,886 --> 03:10:04,686 But I don't know. 2203 03:10:04,686 --> 03:10:08,526 But yeah, I don't think very highly of Stratov2. 2204 03:10:13,566 --> 03:10:14,526 Any other questions? 2205 03:10:15,486 --> 03:10:20,286 We have like two or so minutes, or if there are no questions. 2206 03:10:20,286 --> 03:10:22,286 Is that Thunder? 2207 03:10:22,286 --> 03:10:23,246 Sure. 2208 03:10:23,246 --> 03:10:29,886 It's basically, Thunder is just a BIP300 chain, but the performance has been optimized. 2209 03:10:29,886 --> 03:10:36,606 So we just, we tested it with, like, you can go online, you can go on GitHub and see the tests on GitHub. 2210 03:10:36,606 --> 03:10:39,166 And you just test it with larger and larger and larger blocks. 2211 03:10:39,166 --> 03:10:42,606 We have a big script that makes, like, tons and tons of transactions. 2212 03:10:42,606 --> 03:10:48,686 So it will just make a ton of transactions, and then attach, you know, connect all the blocks and time that. 2213 03:10:48,686 --> 03:10:50,446 And then we optimize that. 2214 03:10:50,446 --> 03:10:55,486 We did a hackathon last summer to see who could improve the performance the most. 2215 03:10:55,486 --> 03:10:58,046 And at the end, it became very optimized. 2216 03:10:58,046 --> 03:11:06,366 So it's, I have a, it's much easier to just understand how BIP300 works than Thunder specifically. 2217 03:11:06,366 --> 03:11:15,326 Because the way drive chain works is the, when you deposit coins from L1 to L2, that's the transaction on L1. 2218 03:11:15,326 --> 03:11:20,686 But then on L2, you can onboard new people there without touching L1. 2219 03:11:20,686 --> 03:11:23,726 Of course, you have to merge mine, the block. 2220 03:11:23,726 --> 03:11:28,846 But that is a constant number of bytes in the coinbase transaction. 2221 03:11:28,846 --> 03:11:35,486 So on L2, it's just how many transactions can the L2 process without collapsing. 2222 03:11:35,566 --> 03:11:44,046 And I have a, I have an article about this, which is about, if you go to, like, truthcoin.info slash blog slash thunder or something like that. 2223 03:11:44,046 --> 03:12:01,566 It's, I go through some of the math of this, where in the real world, many economies, you know, the world would be, like, partitioned into, like, you have, like, North America, Southeast Asia, Europe, continental Europe, and then, like, maybe, like, Africa and the rest of the world. 2224 03:12:01,566 --> 03:12:05,006 So you do have to split it about 14 ways. 2225 03:12:05,006 --> 03:12:07,966 So you have four, it would be, like, Thunder 1, Thunder 2, Thunder 3. 2226 03:12:07,966 --> 03:12:15,166 They wouldn't all come online at the same time, because you'd just have one, and you'd wait for it to fill up, and then it would kind of split, and it would be, like, West Hemisphere, East Hemisphere. 2227 03:12:15,166 --> 03:12:18,526 But it would kind of end up, so you can split it a little bit. 2228 03:12:18,526 --> 03:12:28,686 And the point of bringing up the regions of the world is that there are many splits that would really not interfere with the, what you might call the liquidity at that point, I suppose. 2229 03:12:28,686 --> 03:12:44,846 So you say, oh, I only have coins on the Europe one, because, so then you get a free partitioning into 14 pieces or so, and then from there, you just test, and it just has, like, giant, you know, has large and exponentially growing block size. 2230 03:12:44,846 --> 03:12:55,566 But there's a night and day difference between having large blocks on an optional L2 that everyone can ignore and having it on the mandatory L1, where everyone has the same data availability problem forever. 2231 03:12:55,806 --> 03:13:05,166 So there's a completely night and day, because this is often misunderstood as being just merely a large block project, which is absolutely not the case. 2232 03:13:05,166 --> 03:13:14,846 And in fact, the large block project has this exact same problem where Bitcoin SV and these other people have to, Bitcoin Cash had to wonder, like, okay, it shouldn't be one megabyte, but it should be, like, some other magic number. 2233 03:13:14,846 --> 03:13:19,886 And then they'll just hard fork again, and they, so that's obviously a huge downside. 2234 03:13:19,886 --> 03:13:29,246 And then for Bitcoin SV, it's kind of like it's just unlimited right off the bat, and then that has its own enormous problem, because you have this endless growing data availability problem. 2235 03:13:29,246 --> 03:13:39,406 So when you have competing different L2s, that's very good, because you can push the envelope on some of them, and maybe one or two will actually fail and die off, and that is actually healthy. 2236 03:13:39,406 --> 03:13:55,006 So, but yeah, if you had, the point is with the software that we have, if it was deployed the way I suggest, it's currently up to, like, 50% of 8 billion people using it every day, but the point is by the time it was realistically adopted, it would be up to 100%. 2237 03:13:55,006 --> 03:13:57,726 So you can check all that out on GitHub. 2238 03:13:57,726 --> 03:14:04,206 You can find, you can look up the hackathon last year, and a lot of very cool people entered to optimize the software. 2239 03:14:04,206 --> 03:14:08,766 Thank you. 2240 03:14:08,766 --> 03:14:09,566 Anyone else? 2241 03:14:09,566 --> 03:14:13,006 Okay. 2242 03:14:13,006 --> 03:14:14,366 No? 2243 03:14:14,366 --> 03:14:16,926 Okay, so thank you so much. 2244 03:14:16,926 --> 03:14:33,246 A huge applause for Paul. 2245 03:14:33,246 --> 03:14:37,086 Okay, welcome back from coffee break. 2246 03:14:37,086 --> 03:14:46,686 Our next guest is one of the most vocal proponents of BIP110, so please welcome Chris Guida. 2247 03:14:46,686 --> 03:14:48,286 Hey, guys. 2248 03:14:48,286 --> 03:14:51,326 Welcome to my talk, BIP110, How Bitcoin Wins. 2249 03:14:51,326 --> 03:14:52,766 My name is Chris Guida. 2250 03:14:52,766 --> 03:15:02,446 I am a Bitcoin medium of exchange researcher and BIP110 reviewer and cheerleader, and here's where we are and when we are. 2251 03:15:02,446 --> 03:15:04,206 Okay, so a little background on BIP110. 2252 03:15:04,366 --> 03:15:09,646 It was a proposal introduced by a developer named Dathan Om in October of 2025. 2253 03:15:09,646 --> 03:15:14,846 It is now a wildly popular UASF with about 15% of the network running it. 2254 03:15:14,846 --> 03:15:21,966 It's about to activate its first stage on August 8th in a couple of weeks, and the second stage will be later in September. 2255 03:15:21,966 --> 03:15:31,966 I've helped with reviewing, testing, and promoting it, and I'm extremely bullish on its activation, and that's why I'm here today to kind of explain to you guys why I'm excited. 2256 03:15:31,966 --> 03:15:35,086 Okay, so BIP110 is how Bitcoin wins. 2257 03:15:35,086 --> 03:15:39,006 So what does it mean for Bitcoin to win? 2258 03:15:39,006 --> 03:15:41,086 NGU? 2259 03:15:41,086 --> 03:15:41,966 ETFs? 2260 03:15:41,966 --> 03:15:42,686 Bank custody? 2261 03:15:42,686 --> 03:15:45,646 Government reserves? 2262 03:15:45,646 --> 03:15:55,566 Well, in my opinion, when Bitcoin wins, what that means is it's the end of the infinite money printer, also known as the separation of money and state. 2263 03:15:55,566 --> 03:15:59,246 People like to say the separation of money and state commonly in the Bitcoin community. 2264 03:15:59,246 --> 03:16:05,486 I think this is an admirable goal, but I think we need to be more specific about what we mean when we say that. 2265 03:16:05,486 --> 03:16:10,366 What it means is the global reserve asset can no longer be created at will by connected elites. 2266 03:16:10,366 --> 03:16:12,846 The problem is not that central bank money exists. 2267 03:16:12,846 --> 03:16:17,086 The problem is that central bank money exists, and it's the world reserve asset. 2268 03:16:17,086 --> 03:16:23,326 It's the thing that everybody has their savings in, so this is an especially pernicious form of central bank money. 2269 03:16:23,726 --> 03:16:30,286 Bitcoin wins when people voluntarily choose it over fiat. 2270 03:16:30,286 --> 03:16:32,606 Basically, we need to out-compete the dollar. 2271 03:16:32,606 --> 03:16:37,486 That's the goal, so that people choose to use Bitcoin instead of the dollar. 2272 03:16:37,486 --> 03:16:40,846 And it does this by maximizing along three axes. 2273 03:16:40,846 --> 03:16:46,846 Universal, decentralized, money. 2274 03:16:46,846 --> 03:16:49,966 Okay, so a little background on the infinite money printer. 2275 03:16:49,966 --> 03:16:53,806 It robs from the poor to feed the rich. 2276 03:16:53,806 --> 03:16:57,646 It causes a lot of systemic injustice, and most people understand that there's systemic injustice, 2277 03:16:57,646 --> 03:17:01,566 but a lot of people don't identify the source, and I think Bitcoiners are way ahead of the curve on this. 2278 03:17:01,566 --> 03:17:04,846 We understand that it's this infinite money printer. 2279 03:17:04,846 --> 03:17:09,166 How does this cause bad things to happen in the world? 2280 03:17:09,166 --> 03:17:11,646 It rewards bad behavior while punishing good behavior. 2281 03:17:11,646 --> 03:17:14,126 It finances war destruction and injustice. 2282 03:17:14,126 --> 03:17:17,806 It protects banks and corporations from the consequences of reckless behavior. 2283 03:17:17,806 --> 03:17:20,366 It causes all sorts of malinvestment. 2284 03:17:20,366 --> 03:17:24,686 It lets connected elites to create the global reserve asset at will. 2285 03:17:24,686 --> 03:17:27,086 So this is what we said before. 2286 03:17:27,086 --> 03:17:33,006 And humanity is really headed over a cliff unless we fix the money. 2287 03:17:33,006 --> 03:17:38,206 So just a little background on me, I got kind of excited about Bitcoin once I saw the failures 2288 03:17:38,206 --> 03:17:43,166 of some of these early attempts to, these were all right after the 2008 financial crisis. 2289 03:17:43,166 --> 03:17:46,846 Actually, Bitcoin sort of came out of the same financial crisis. 2290 03:17:46,846 --> 03:17:50,926 There's a famous thing in the Genesis block that says a chance are on the brink of bailout, 2291 03:17:50,926 --> 03:17:53,086 second bailout for banks. 2292 03:17:53,086 --> 03:17:58,926 So it points to Bitcoin's purpose and also does a proof of no pre-mine. 2293 03:17:58,926 --> 03:18:03,966 Anyway, so all of these other movements came out of that financial crisis, and I was really 2294 03:18:03,966 --> 03:18:08,686 excited about that and got caught up in that energy that sort of like, let's have a revolution 2295 03:18:08,686 --> 03:18:13,086 against Wall Street, against the big banks, against the money printer. 2296 03:18:13,086 --> 03:18:16,686 Everybody can see that the system is corrupt and the mask has really come off. 2297 03:18:16,686 --> 03:18:18,846 So we're going to win. 2298 03:18:18,846 --> 03:18:21,166 But what happened? 2299 03:18:21,166 --> 03:18:23,806 They depended on the goodwill of the fiat money system. 2300 03:18:23,806 --> 03:18:27,646 They depended on having a lot of funding. 2301 03:18:27,646 --> 03:18:32,046 And so when you depend on having a lot of funding and your opponent can print money, 2302 03:18:32,046 --> 03:18:33,646 you're at a disadvantage. 2303 03:18:33,646 --> 03:18:39,246 And so the money printer can fund institutions, hire their leaders, redirect their anger. 2304 03:18:39,246 --> 03:18:40,686 It can smear them in the media. 2305 03:18:40,686 --> 03:18:42,846 It can make them look like they have no purpose. 2306 03:18:42,846 --> 03:18:44,446 They have no principles. 2307 03:18:44,446 --> 03:18:49,566 I would read interviews of people from Occupy Wall Street, and they're like, what's your 2308 03:18:49,566 --> 03:18:50,606 movement about? 2309 03:18:50,606 --> 03:18:52,686 And they're like, we kind of don't know. 2310 03:18:52,686 --> 03:18:55,486 And it's just like, I'm sure if you really talked to the Occupy Wall Street people, they 2311 03:18:55,486 --> 03:19:02,526 would be like, yeah, we think this system is corrupt and we're trying to reform it. 2312 03:19:02,526 --> 03:19:03,566 But it didn't even need to do that. 2313 03:19:03,566 --> 03:19:07,726 All it needed to do is print money and buy it, basically. 2314 03:19:07,726 --> 03:19:09,166 So Bitcoin is different. 2315 03:19:09,166 --> 03:19:11,366 It does not ask the system to reform itself. 2316 03:19:11,366 --> 03:19:13,086 It creates an exit from the system. 2317 03:19:13,166 --> 03:19:15,486 It operates without permission from the elites. 2318 03:19:15,486 --> 03:19:20,766 It can finance the people and infrastructure replacing fiat because Bitcoin itself is money. 2319 03:19:20,766 --> 03:19:22,286 We are not reforming the system. 2320 03:19:22,286 --> 03:19:23,966 We are replacing it. 2321 03:19:23,966 --> 03:19:28,766 And so that's why I would consider Bitcoin a true revolution, and it will succeed where 2322 03:19:28,766 --> 03:19:31,886 these other movements failed. 2323 03:19:31,886 --> 03:19:34,526 And the UASF mechanism is Bitcoin's teeth. 2324 03:19:34,526 --> 03:19:39,006 In 2017, when Bitcoin 48 happened, I got really excited about Bitcoin because I was like, 2325 03:19:39,486 --> 03:19:44,206 Bitcoin actually can ward off attacks from the money printer in a decentralized way. 2326 03:19:44,206 --> 03:19:45,006 This is really cool. 2327 03:19:45,006 --> 03:19:48,846 A lot of sort of decentralized or anarchic systems struggle with collective defense. 2328 03:19:48,846 --> 03:19:53,806 And the UASF is how Bitcoin does collective defense without a central authority. 2329 03:19:53,806 --> 03:19:54,926 And this was successful. 2330 03:19:54,926 --> 03:19:59,886 And in my opinion, that's actually why Bitcoin went up a lot in price in 2017. 2331 03:20:00,060 --> 03:20:06,300 So, yeah, basically you have some developers propose it, businesses choose what to accept, 2332 03:20:06,300 --> 03:20:14,300 the users validate, it forms into a movement, and then it's really, really hard to stop. 2333 03:20:14,300 --> 03:20:18,780 These are the blocks that we will recognize as Bitcoin. Other blocks get rejected. And 2334 03:20:18,780 --> 03:20:21,980 it limits the danger even from a centralized mining industry. That's why it's still important 2335 03:20:21,980 --> 03:20:26,660 even today. And it shows that the nodes are in charge, not the miners. And this is just 2336 03:20:26,660 --> 03:20:31,140 an objective fact of the system of Bitcoin and how it works. And also, we really don't 2337 03:20:31,140 --> 03:20:34,420 want a centralized mining industry to be in control of Bitcoin's rules. That would be 2338 03:20:34,420 --> 03:20:41,020 really bad. And just a side note, filters and temporary UASFs are kind of like elements 2339 03:20:41,020 --> 03:20:46,380 of an immune system. And actually, I really like Brandon Quittam talking about how Bitcoin 2340 03:20:46,380 --> 03:20:49,580 is sort of like a mycelium, and it has a little bit of an immune system. And there's these 2341 03:20:49,580 --> 03:20:54,940 things called mushroom scientists, which are sort of like the filter or the UASF developers 2342 03:20:54,940 --> 03:21:04,020 who manufacture these novel molecules in response to novel attacks. And then the instructions 2343 03:21:04,020 --> 03:21:06,540 for how to build those molecules propagate throughout the network, and then the network 2344 03:21:06,540 --> 03:21:14,540 defends itself against a new attack. So mycelium operates chemically, and Bitcoin operates 2345 03:21:14,540 --> 03:21:17,660 with software. So it's pretty much the same mechanism. 2346 03:21:17,660 --> 03:21:23,740 Okay, so as we already said, Bitcoin must be preserved and improved in three ways. Universal 2347 03:21:23,740 --> 03:21:28,900 decentralized money. So Bitcoin has three sort of principles that define its identity. 2348 03:21:28,900 --> 03:21:33,500 We must preserve and improve universality. We must preserve and improve decentralization. 2349 03:21:33,500 --> 03:21:37,420 We must preserve and improve Bitcoin's monetary quality, or moneyness is another word that 2350 03:21:37,420 --> 03:21:43,860 people like to use for that. Anything that improves these qualities helps Bitcoin win. 2351 03:21:43,860 --> 03:21:48,260 Anything that harms one or more of them can be considered an attack on Bitcoin. And if 2352 03:21:48,260 --> 03:21:54,780 Bitcoin loses, humanity loses. So this is a very important subject, I think, I hope, 2353 03:21:54,780 --> 03:21:59,460 to most Bitcoiners. Bitcoin must work for every human being, not 2354 03:21:59,460 --> 03:22:03,300 just banks, governments, funds, and wealthy investors. Ordinary people must be able to 2355 03:22:03,300 --> 03:22:10,540 spend, earn, withdraw, self-custody, and verify. This is something that we have to continue 2356 03:22:10,540 --> 03:22:14,820 working towards because it's something that Bitcoin does not scale to a global user base 2357 03:22:14,820 --> 03:22:19,940 and remain decentralized as it is now. But with improvements in technology and Moore's 2358 03:22:19,940 --> 03:22:24,460 Law, we should expect this to happen in the next few decades, probably. But all we have 2359 03:22:24,460 --> 03:22:32,100 to do is keep our eye on the goal, right? We can't forget the goal. The goal is universality. 2360 03:22:32,100 --> 03:22:34,780 Custodial exposure and payment processing is not enough. These are choke points where 2361 03:22:34,780 --> 03:22:40,420 authorities can come in and take control of the system. And the old financial system must 2362 03:22:40,420 --> 03:22:44,580 not be rebuilt on top of Bitcoin. Otherwise, we've failed. 2363 03:22:44,580 --> 03:22:49,700 Bitcoin must remain decentralized. No developer group, miner, custodian, or government can 2364 03:22:49,700 --> 03:22:54,380 become Bitcoin's ruler. Influence is not authority. It's much harder to control hundreds of thousands 2365 03:22:54,380 --> 03:23:00,380 of small node runners and pleb merchants than to control a handful of large nodes. 2366 03:23:00,380 --> 03:23:04,340 Decentralization is what makes Bitcoin neutral. A lot of people say BIP110 is anti-neutrality 2367 03:23:04,340 --> 03:23:09,260 or something like that. And our response is no, it's pro-neutrality because we're trying 2368 03:23:09,260 --> 03:23:14,220 to make sure that Bitcoin stays decentralized. Decentralization is what makes Bitcoin neutral. 2369 03:23:14,220 --> 03:23:18,780 Bitcoin's particular consensus rules are actually not neutral. They are geared towards Bitcoin 2370 03:23:18,780 --> 03:23:24,580 being better money. Decentralization prevents the money printer from returning in another 2371 03:23:24,580 --> 03:23:30,620 form. And as we've just said, we want Bitcoin to be better money over time also. 2372 03:23:30,620 --> 03:23:36,100 Bitcoin has not yet out-competed the dollar. So we know that generally speaking, the U.S. 2373 03:23:36,100 --> 03:23:39,340 dollar is considered to be better money than Bitcoin. As Bitcoiners, we know that this 2374 03:23:39,340 --> 03:23:43,060 is not true, but the rest of the world does not believe us yet. So we have to continue 2375 03:23:43,060 --> 03:23:47,500 improving Bitcoin's moneyness. That's its unique purpose. 2376 03:23:47,500 --> 03:23:51,500 Universal decentralized money. It's not a good database, image host, token platform, 2377 03:23:51,500 --> 03:23:55,460 or permanent file server. Other systems can perform those functions better. Bitcoin's 2378 03:23:55,460 --> 03:24:00,180 consensus and policy rules should serve its monetary mission. This is what I was saying. 2379 03:24:00,180 --> 03:24:06,980 Bitcoin's rules are actually not neutral. The enforcement of the rules is neutral because 2380 03:24:06,980 --> 03:24:11,900 of Bitcoin's centralization. But the rules of Bitcoin themselves are not neutral. They're 2381 03:24:11,900 --> 03:24:18,900 pro-Bitcoin. They're pro-money. They're pro-decentralization. They help Bitcoin improve and fulfill its function. 2382 03:24:18,900 --> 03:24:23,500 Again, Bitcoin defeats fiat by becoming better money. 2383 03:24:24,500 --> 03:24:30,380 Bitcoin's principles should not be for sale. The only way we win is if these three principles 2384 03:24:30,380 --> 03:24:37,100 are not for sale. Not for short-term fees, speculative demand, institutional approval. 2385 03:24:37,100 --> 03:24:42,660 Not even for a much higher Bitcoin price. Of course we know if we succeed, eventually 2386 03:24:42,660 --> 03:24:48,580 in the long term, Bitcoin's price will be higher than it ever could be if we sell out 2387 03:24:48,580 --> 03:24:58,940 our principles. As I said earlier, NGU is great, but come for the NGU, stay for the 2388 03:24:58,940 --> 03:25:08,340 actual monetary revolution. As a thought experiment, imagine you're an infinite money printer, 2389 03:25:08,340 --> 03:25:11,660 you have an infinite money printer, and Bitcoin is coming after you and trying to out-compete 2390 03:25:11,660 --> 03:25:16,700 you. How much you try to stop Bitcoin from doing that, or to kill Bitcoin, or stop it 2391 03:25:16,700 --> 03:25:20,380 in its tracks. Well, you can print a bunch of money. You could print Bitcoin's entire 2392 03:25:20,380 --> 03:25:25,940 market cap. You could say, hey, Bitcoiners, I have $1 trillion, or $10 trillion. And I'll 2393 03:25:25,940 --> 03:25:31,060 give this to you if you make Bitcoin small and unscalable. So what would your response 2394 03:25:31,060 --> 03:25:38,460 be if somebody offered you $10 trillion to make Bitcoin small and unscalable? This guy. 2395 03:25:38,460 --> 03:25:42,780 This guy says no. Yeah, I agree with that guy. Yeah. No. We should say no. We should 2396 03:25:42,780 --> 03:25:48,460 not sell out our principles. We want Bitcoin to overtake the money printer and replace 2397 03:25:48,460 --> 03:25:56,380 it. If they offer us $1 trillion to make Bitcoin centralised, should we do that? No. If they 2398 03:25:56,380 --> 03:26:05,620 offer us $1 trillion to make Bitcoin something that isn't money, should we do that? No. Exactly. 2399 03:26:05,620 --> 03:26:09,860 If we compromise any one of these principles because someone offers us enough money, we 2400 03:26:09,860 --> 03:26:16,180 have sold out. We have sold out our principles, we have sold out Bitcoin, and we have sold 2401 03:26:16,180 --> 03:26:21,540 out the future of humanity. We must not sell out. 2402 03:26:21,540 --> 03:26:27,780 Bitcoin does not fix itself. Consensus rules do not interpret, enforce, or repair themselves. 2403 03:26:27,780 --> 03:26:31,580 Bitcoin survives because people understand its purpose. Its principles are not protected 2404 03:26:31,580 --> 03:26:37,540 by mathematics alone. They survive because node owners value them and enforce them. Culture 2405 03:26:37,540 --> 03:26:42,260 is therefore part of Bitcoin's security model. 2406 03:26:42,260 --> 03:26:48,140 So another thought experiment. Imagine there's an inflation bug in the software that somebody 2407 03:26:48,140 --> 03:26:55,500 accidentally introduces. Would we say that inflation is legitimate now because consensus 2408 03:26:55,500 --> 03:27:05,580 allows it? Would we call fixing the bug censorship? No. I think the answer to those questions 2409 03:27:05,580 --> 03:27:10,580 is obviously no. We would just fix it. We would consider it a bug and we would say let's 2410 03:27:10,580 --> 03:27:17,680 fix it. And if Core refused to fix it, node owners would route around Core with a UASF. 2411 03:27:17,680 --> 03:27:23,840 The rules exist because we enforce them. The $21 million limit is protected by node owners. 2412 03:27:23,840 --> 03:27:28,320 If the culture stops caring, the rules can decay with it. So again, if there's an inflation 2413 03:27:28,320 --> 03:27:33,820 bug and the culture says, oh, that looks fine, then what happens? The bug doesn't get fixed 2414 03:27:33,820 --> 03:27:38,960 and now Bitcoin has arbitrary inflation and now Bitcoin is terrible money. So again, culture 2415 03:27:38,960 --> 03:27:44,900 is part of the security model. We have to make sure that our cultural values are solid. 2416 03:27:44,900 --> 03:27:48,620 If the culture stops caring, the rules can decay with it. If Bitcoiners forget that Bitcoin 2417 03:27:48,620 --> 03:27:51,380 is money, inflation and double spends can eventually become acceptable. Bitcoin does 2418 03:27:51,380 --> 03:27:57,020 not protect itself. When Bitcoin breaks, it is up to us to fix it. 2419 03:27:57,020 --> 03:28:01,020 Many developers understandably treat Bitcoin as a profession. But for many node runners, 2420 03:28:01,020 --> 03:28:09,860 Bitcoin is a way of life. Running a node is closer to censorship than consuming a product. 2421 03:28:09,860 --> 03:28:15,700 For many of us, preserving Bitcoin is a duty to humanity. There's this notion that, oh, 2422 03:28:15,700 --> 03:28:19,340 you just run a node because you're selfishly running a node. And that's kind of true, but 2423 03:28:19,340 --> 03:28:23,620 that isn't everything there is in life. We want to feel like we're part of something 2424 03:28:23,620 --> 03:28:30,420 bigger than us. Bitcoin is not about us. Bitcoin is about, you know, our descendants and the 2425 03:28:30,420 --> 03:28:34,940 rest of the world and the future of humanity. We are providing a valuable service for humanity 2426 03:28:34,940 --> 03:28:39,620 by running a node and making Bitcoin function properly. 2427 03:28:39,620 --> 03:28:47,700 So how did core 30 threaten us? It changed what Bitcoin officially treats as legitimate. 2428 03:28:47,700 --> 03:28:53,020 It moved large file data storage toward normal supported use. Policy defaults send a cultural 2429 03:28:53,020 --> 03:28:58,300 signal which has a real effect on Bitcoin's actual purpose. Core developers may say otherwise, 2430 03:28:58,300 --> 03:29:04,860 but actions speak louder than words. There's three categories of transactions. There's 2431 03:29:04,860 --> 03:29:09,620 invalid transactions, there's valid but abusive or unsupported transactions, and there's valid 2432 03:29:09,620 --> 03:29:14,700 and legitimate or supported transaction types. Invalid just means the consensus rules say 2433 03:29:14,700 --> 03:29:19,700 your block is invalid if it includes a transaction like that. So you literally cannot include 2434 03:29:19,700 --> 03:29:23,620 that transaction in a block. Otherwise you're not participating in Bitcoin. 2435 03:29:23,620 --> 03:29:33,060 The second category is the domain of standardness or default policy. Satoshi deliberately left 2436 03:29:33,060 --> 03:29:39,500 category one very, very broad because if it's too narrow, then we have to hard fork to loosen 2437 03:29:39,500 --> 03:29:44,060 the rules and add more functionality. So he left it very broad, and then within that very, 2438 03:29:44,060 --> 03:29:51,260 very broad scope of consensus, he disabled pretty much everything. And that was his standard. 2439 03:29:51,260 --> 03:29:58,260 That became the standard rules. So that's category two is where relay policy works. 2440 03:29:58,260 --> 03:30:02,260 And that dictates what things are valid but we don't support, or we consider to be an 2441 03:30:02,260 --> 03:30:07,460 attack or an abuse. And then category three is just valid and legitimate or supported. 2442 03:30:07,460 --> 03:30:10,340 These are payments, right? Because Bitcoin is money, it's supposed to be used for payments. 2443 03:30:10,340 --> 03:30:16,340 So payments go in category three. Before core 30, data spam was valid but abusive. So it 2444 03:30:16,340 --> 03:30:23,340 was in category two. It was considered nonstandard. Core 30 reclassified it to valid and legitimate. 2445 03:30:23,340 --> 03:30:29,260 So it reclassified it from category two to category three. Core 30 says Bitcoin now officially 2446 03:30:29,260 --> 03:30:35,180 supports storage of large arbitrary files. There are two officially supported formats. 2447 03:30:35,180 --> 03:30:38,940 We're still quoting core 30 here. There are two officially supported formats, operaturns 2448 03:30:38,940 --> 03:30:43,460 of up to 100 kilobytes and inscriptions of up to 400 kilobytes. And there may be other 2449 03:30:43,460 --> 03:30:47,460 formats that are implicitly supported. So this is sort of the statement that core 30 2450 03:30:47,460 --> 03:30:53,740 as a software, as a piece of software was making. Again, core developers themselves 2451 03:30:53,740 --> 03:30:59,220 may have said, well, you know, we don't think that data storage is a legitimate usage of 2452 03:30:59,220 --> 03:31:03,260 Bitcoin or we don't think that data storage is recommended. But there's nothing we can 2453 03:31:03,260 --> 03:31:09,080 do about it. And so although their words said yes, their software, sorry, although their 2454 03:31:09,080 --> 03:31:15,800 words said no, their software said yes. And so the software of core 30 said yes to large 2455 03:31:15,800 --> 03:31:21,900 file data storage. And so as core 30 started becoming broadly adopted, this caused a redefinition 2456 03:31:21,900 --> 03:31:29,600 of Bitcoin from money into a database. Data storage would not remain a harmless side feature 2457 03:31:29,600 --> 03:31:37,840 or an abusive feature that is not supported and kind of difficult to get confirmed. It 2458 03:31:37,840 --> 03:31:42,640 would compete directly at an unfair advantage with Bitcoin's monetary use. 2459 03:31:42,640 --> 03:31:52,440 Bit 1.10 converts core 30's yes back into a no. So there's four different attacks that 2460 03:31:52,440 --> 03:32:00,440 data spam attacks, that data spam, four different vectors that data spam opens up against or 2461 03:32:00,440 --> 03:32:05,840 official support for data spam opens up against Bitcoin. The first one is this kind of ugly 2462 03:32:05,840 --> 03:32:11,360 topic that nobody likes to talk about. But just because something is ugly to talk about 2463 03:32:11,360 --> 03:32:14,680 doesn't mean that we should just ignore that the attack vector exists. That's not going 2464 03:32:14,680 --> 03:32:18,680 to make it go away. We have to actually make the attack vector go away. So we'll talk more 2465 03:32:18,680 --> 03:32:24,720 about that in a bit. UTXO set and blockchain bloat is attack number two. High fees are 2466 03:32:24,720 --> 03:32:32,400 attack number three. Cultural decay is attack number four. Each attack damages universality, 2467 03:32:32,400 --> 03:32:39,040 decentralization, or moneyness. This is the ugliest one. Sorry, again, that I have to 2468 03:32:39,040 --> 03:32:43,880 talk about this. But again, this is a real attack. We should consider this a serious 2469 03:32:43,880 --> 03:32:48,960 attack vector and do something about it. In the block size wars when the big blockers 2470 03:32:48,960 --> 03:32:52,740 would call us, oh, you're negative Nancys. You think that if we make the blocks bigger 2471 03:32:52,740 --> 03:32:56,680 then that's just going to run off a cliff. It's going to be a slippery slope. We think 2472 03:32:56,680 --> 03:33:01,560 you're worrying too much. And the small blockers said, no, we think adversarially. We try to 2473 03:33:01,640 --> 03:33:06,800 imagine if I had an infinite money printer, what are the ways that I could try to attack 2474 03:33:06,800 --> 03:33:11,640 or discredit or destroy Bitcoin. So we have to think about these things and do something 2475 03:33:11,640 --> 03:33:16,680 about them. So arbitrary storage allows attackers to place abhorrent or illegal material on 2476 03:33:16,680 --> 03:33:23,560 the chain. What this does is it discourages ordinary moral people from running nodes. 2477 03:33:23,560 --> 03:33:28,560 And the problem with this is that running nodes is already kind of hard. Barely anybody 2478 03:33:28,560 --> 03:33:33,420 runs nodes. Actually, raise your hand if you run a node. All right. So that's about 2479 03:33:33,420 --> 03:33:37,640 maybe a little more than half. Maybe about half the audience. And this is about as technical 2480 03:33:37,640 --> 03:33:43,560 of a crowd as you can get in Bitcoin. So that's a problem. We should make running nodes as 2481 03:33:43,560 --> 03:33:54,360 easy as possible. So oh, I just have a this is a tweet that Nick Sabo put out that I think 2482 03:33:54,360 --> 03:34:00,480 sort of encapsulates what the danger is. Having a feature that looks like it's intended 2483 03:34:00,480 --> 03:34:05,940 for nonfinancial content may be a much larger legal risk than having a feature intended 2484 03:34:05,940 --> 03:34:09,920 for financial transactions that is subverted to post nonfinancial content. It's not all 2485 03:34:09,920 --> 03:34:14,240 just bits in the eyes of the law. Caveat, I am not a lawyer. A feature that looks like 2486 03:34:14,240 --> 03:34:18,840 it's intended for nonfinancial content also sends a strong social signal that nonfinancial 2487 03:34:18,840 --> 03:34:23,640 content is welcome on Bitcoin. So this is what Core 30 does. And then here's an actual 2488 03:34:23,640 --> 03:34:28,000 lawyer saying Nick is, of course, right here. It goes to intent, which is the baseline consideration 2489 03:34:28,000 --> 03:34:32,080 for all crimes in the U.S. and many other jurisdictions. Storing or relaying financial 2490 03:34:32,080 --> 03:34:38,720 data, the intent of Bitcoin node runners is attacked by nonmonetary use cases, but currently 2491 03:34:38,720 --> 03:34:45,720 those are exploits or bugs. Exploits of bugs. Right? So you can argue that, you know, if 2492 03:34:45,760 --> 03:34:51,960 somebody, like, does some steganography and, like, hides an image in your computer, that 2493 03:34:51,960 --> 03:34:56,000 was done without your knowledge or consent. And so you didn't intend to do that. That's 2494 03:34:56,000 --> 03:34:59,920 what Ian is saying here. Core v30's efforts at changing the intent of Bitcoin through 2495 03:34:59,920 --> 03:35:05,400 intentional modifications to allow file storage arguably guts this no intent defense and puts 2496 03:35:05,400 --> 03:35:10,760 all Bitcoiners and node runners at much higher risk. So, again, we don't know how big of 2497 03:35:10,760 --> 03:35:15,160 a threat this is because there's lawyers that disagree about this. But, again, Bitcoin is 2498 03:35:15,160 --> 03:35:21,000 conservative. It doesn't just, like, arbitrarily impose new risks on itself and just kind of 2499 03:35:21,000 --> 03:35:24,400 hope to cross its fingers and hope for the best. Right? We don't want to leave these 2500 03:35:24,400 --> 03:35:32,320 things to chance. We want to actually fix these problems. Okay. Now that that ugly topic 2501 03:35:32,320 --> 03:35:39,280 is out of the way. Yeah. So this directly harms decentralization. Right? So that's one 2502 03:35:39,280 --> 03:35:43,160 of the core principles of Bitcoin. Bitcoin needs to be decentralized. As many people 2503 03:35:43,160 --> 03:35:47,800 need to run nodes as possible. This is a direct attack on that. UTXO set and chain 2504 03:35:47,800 --> 03:35:54,320 bloat. Basically the UTXO set increased from 4 gigabytes to 12 gigabytes during the spam 2505 03:35:54,320 --> 03:36:04,320 attacks, the ordinal attacks of 2023 and 2024. And this is another thing that hurts decentralization 2506 03:36:04,320 --> 03:36:10,800 because it slows down IBD. Bitcoin must survive for centuries and not just today. Hardware 2507 03:36:10,800 --> 03:36:14,160 improvements and Moore's law should make running nodes easier. And actually, Moore's 2508 03:36:14,160 --> 03:36:19,040 law is exponential and I don't think this has actually stopped yet. Although recently 2509 03:36:19,040 --> 03:36:25,800 the costs have gone up a lot. But I expect the exponential trend to continue. Spam attacks 2510 03:36:25,800 --> 03:36:29,880 could be orders of magnitude worse next time. So the UTXO set is actually limited by one 2511 03:36:29,880 --> 03:36:39,040 52 gigabytes per year of new UTXO set data. And the amount of new UTXO set data during 2512 03:36:39,040 --> 03:36:46,380 the spam attacks was I think it's like 1.5 gigabytes per year. No, it's like 3 gigabytes 2513 03:36:46,380 --> 03:36:50,200 per year or something like that. So the worst case is like more than ten times worse than 2514 03:36:50,200 --> 03:36:55,200 what actually happened. And what actually happened was really bad. So we should definitely 2515 03:36:55,200 --> 03:37:01,320 be thinking about this vector. And it should be noted that skipping validation, assume 2516 03:37:01,320 --> 03:37:06,240 UTXO or pruning are suboptimal and centralizing solutions. Those are not ideal. The ideal 2517 03:37:06,240 --> 03:37:10,320 solution, the low-hanging fruit solution is just filtering spam. Which is what we 2518 03:37:10,320 --> 03:37:19,840 did from 2010 until recent years. Okay. Another thing is high fees. Payments compete against 2519 03:37:19,840 --> 03:37:24,380 speculative data schemes. A payment user experiences the fee as a direct cost. A token issuer can 2520 03:37:24,380 --> 03:37:29,320 subsidize fees by selling speculation to new buyers. High fees cause a chilling effect 2521 03:37:29,320 --> 03:37:34,560 on real merchants selling real goods and services because of more expensive on-chain operations. 2522 03:37:34,560 --> 03:37:38,520 So we're looking for real L2, i.e. unilateral exit protocols like Lightning and ARK. And 2523 03:37:38,520 --> 03:37:43,640 I say unilateral exit because those are the L2s that I consider to be real L2s since they 2524 03:37:43,640 --> 03:37:53,520 are directly, you can withdraw without permission from an L2 to an L1. So the Bitcoin in a unilateral 2525 03:37:53,520 --> 03:38:00,120 exit layer 2 can be considered Bitcoin as such. Whereas these other L2s that require 2526 03:38:00,120 --> 03:38:04,120 trust I don't think should really be considered L2s. That's another controversial opinion, 2527 03:38:04,120 --> 03:38:07,360 I guess. But anyway, Lightning and ARK, we should try to make these things way better 2528 03:38:07,360 --> 03:38:11,520 because they make the pleb merchant experience much better. And they make Bitcoin a lot more 2529 03:38:11,520 --> 03:38:17,440 decentralized and better money. And high fees, of course, push users towards custodians and 2530 03:38:17,440 --> 03:38:23,600 we don't want that. That's also centralizing. So high fees impact all three principles but 2531 03:38:23,600 --> 03:38:29,800 especially money. And the last attack is this cultural decay. Basically Core30 teaches 2532 03:38:29,800 --> 03:38:35,400 Bitcoiners that arbitrary storage is legitimate. Anything paying a fee is legitimate. All valid 2533 03:38:35,400 --> 03:38:40,160 transactions are equal. These ideas erase the distinction between monetary use and abuse. 2534 03:38:40,160 --> 03:38:44,560 Once the culture forgets Bitcoin's purpose, future attacks become easier. So again, just 2535 03:38:44,560 --> 03:38:49,480 to kind of round this out, we have to remember that Bitcoin is money. And we have to remember 2536 03:38:49,480 --> 03:38:55,760 that Bitcoin needs to out-compete the dollar as money. And we need to remember that because 2537 03:38:55,760 --> 03:38:59,080 Bitcoin hasn't done this yet and is actually very far away from doing this yet, that our 2538 03:38:59,080 --> 03:39:02,400 work is very far from complete. We have to continue making Bitcoin better and better 2539 03:39:02,400 --> 03:39:06,560 and better money. If we just give up now and say it doesn't matter whether Bitcoin is money, 2540 03:39:06,560 --> 03:39:13,720 then Bitcoin dies. So we should not do that. And the four attacks kind of reinforce each 2541 03:39:13,720 --> 03:39:21,440 other in this sort of synergistic insidious way where it drives away NodeRunners, raises 2542 03:39:21,440 --> 03:39:27,240 validation costs, pushes users into custody, and teaches everyone to accept the result. 2543 03:39:27,240 --> 03:39:30,680 And the outcome is that all three principles, universal, decentralized, money, those are 2544 03:39:30,680 --> 03:39:39,920 all injured by officially sanctioning spam. So what does BIP110 do? It surgically targets 2545 03:39:39,920 --> 03:39:44,520 formats that make arbitrary storage look officially supported. So anything that could 2546 03:39:44,520 --> 03:39:52,560 possibly be argued that this format is an officially supported way of storing arbitrary 2547 03:39:52,560 --> 03:40:00,240 data on Bitcoin, it limits those as much as possible. BIP110 is airtight against the first 2548 03:40:00,240 --> 03:40:05,080 attack that I mentioned, the CSAM attack. It vastly diminishes the attack surface of 2549 03:40:05,080 --> 03:40:09,080 the other three attacks. And it does this by restricting all methods of arbitrary data 2550 03:40:09,080 --> 03:40:17,480 storage as small as possible. So it restricts the two main arbitrary data storage methods 2551 03:40:17,480 --> 03:40:23,440 that were legitimized by core 30, which are large operatrons and inscriptions. It also 2552 03:40:23,440 --> 03:40:27,240 restricts all methods of storing files of more than 256 arbitrary bytes in a single 2553 03:40:27,240 --> 03:40:31,920 contiguous data field. This is to limit image storage specifically because it's hard to 2554 03:40:31,920 --> 03:40:37,080 store an image in smaller than that. Most of the restrictions are formats already nonstandard 2555 03:40:37,080 --> 03:40:43,240 just last year. So these are basically policy rules and, like, converting the policy rules 2556 03:40:43,240 --> 03:40:48,720 into consensus rules. The exceptions to that are the OPIF and TAP script rule, the 34-byte 2557 03:40:48,720 --> 03:40:55,560 limit on script pubkeys and the 256-byte limit on data pushes. It disables all these formats 2558 03:40:55,560 --> 03:41:03,520 for one year and it grandfathers existing outputs. Oh, let's actually look at spec. 2559 03:41:03,520 --> 03:41:12,400 So just really quick, there's seven rules. So script pubkeys are limited to 34 bytes. 2560 03:41:12,400 --> 03:41:22,080 Data pushes are limited to 256 bytes. Undefined witness versions are invalid. TAP root annexes 2561 03:41:22,080 --> 03:41:28,440 are invalid. Control blocks, larger than 256 bytes, which is, sorry, 257 bytes, which allows 2562 03:41:28,440 --> 03:41:36,040 you to have depth of seven. So depth of eight or larger is invalid. And op success is invalid. 2563 03:41:36,040 --> 03:41:43,840 This is an upgrade hook. And OPIF and NOTIF are invalid. And as we already said, UTXOs 2564 03:41:43,840 --> 03:41:56,440 are grandfathered. What it doesn't do, it does not try to read people's minds and see 2565 03:41:56,440 --> 03:42:02,560 what their intent is. It does not claim that hidden data can be made mathematically impossible. 2566 03:42:02,560 --> 03:42:11,920 It does not stop all spam. This is a shockingly, surprisingly popular misconception or strawman 2567 03:42:11,920 --> 03:42:16,760 about VIP 110. It doesn't try to make spam impossible. Of course, it doesn't. I mean, 2568 03:42:16,760 --> 03:42:22,800 so of course, as a Bitcoin protocol developer, you want there to be some kind of permanent 2569 03:42:22,800 --> 03:42:27,440 change that you can just make that makes data spam impossible. But of course, with 2570 03:42:27,440 --> 03:42:32,720 data spam, that's not possible. With something like inflation, like an inflation bug, that's 2571 03:42:32,720 --> 03:42:37,040 something that's much more sort of directly addressable in the rules of consensus. But 2572 03:42:37,040 --> 03:42:44,720 with data spam, yeah, you can't know how people are intending to use something. And the more 2573 03:42:44,720 --> 03:42:48,640 you restrict it, the more they're going to hide it. But it does turn out that the more 2574 03:42:48,680 --> 03:42:53,720 hidden data spam is, the less harmful it is. So it makes sense that we should try to limit 2575 03:42:53,720 --> 03:42:59,240 the most obvious forms of data spam and the most popular forms of data spam. It does not 2576 03:42:59,240 --> 03:43:04,440 censor or limit neutrality. I hope it should be obvious why it doesn't do these things. 2577 03:43:04,440 --> 03:43:08,000 As I said, Bitcoin is decentralized and it uses proof-of-work mining, so censorship is 2578 03:43:08,000 --> 03:43:13,760 not possible and this actually increases Bitcoin's censorship resistance by allowing everybody 2579 03:43:13,760 --> 03:43:19,440 to run a node and increases Bitcoin's neutrality by allowing everybody to run a node. It draws 2580 03:43:19,440 --> 03:43:24,280 a practical line around scalable, explicit, arbitrary data publication. So, you know, 2581 03:43:24,280 --> 03:43:27,760 if something is, there's a few different, like, people are like, what is spam? And it's 2582 03:43:27,760 --> 03:43:30,920 like, okay, well, you know, just because you can't draw a clear line between which things 2583 03:43:30,920 --> 03:43:34,640 are spam and which things are not spam doesn't mean that the categories of spam and not spam 2584 03:43:34,640 --> 03:43:41,400 don't exist. There are things that are definitely spam, like BRC20, and there are things that 2585 03:43:41,440 --> 03:43:48,440 are definitely not spam, like pay-to-copy-hash or something. Or going to a, yeah, making 2586 03:43:52,760 --> 03:43:58,800 a payment at a shop. 2587 03:43:58,800 --> 03:44:03,080 It removes the guarantee, so BIP110 removes the guarantee that Bitcoin will preserve storage 2588 03:44:03,080 --> 03:44:07,040 schemes, thus making arbitrary data storage unreliable on Bitcoin, making other file storage 2589 03:44:07,040 --> 03:44:11,400 schemes comparatively much more reliable. And so we don't need to make data storage 2590 03:44:11,400 --> 03:44:16,640 impossible on Bitcoin. We just need to make it less favorable on Bitcoin economically 2591 03:44:16,640 --> 03:44:22,160 than it would be to use Ethereum or Nostr or BitTorrent or something else to store the 2592 03:44:22,160 --> 03:44:28,600 files. And again, we've done this. In 2014, there was a war against the spammers and Bitcoiners 2593 03:44:28,600 --> 03:44:32,800 committed to escalating until the spammers went away, and that's what happened. They 2594 03:44:32,800 --> 03:44:36,400 went away. And Vitalik was like, all right, I'm just going to make Ethereum on a different 2595 03:44:36,440 --> 03:44:43,440 chain. And in retrospect, that's actually the good outcome. So we should be going for 2596 03:44:43,440 --> 03:44:44,400 that. 2597 03:44:44,400 --> 03:44:50,840 Payments receive guarantees because Bitcoin is money. Arbitrary files do not. BIP110 does 2598 03:44:50,840 --> 03:44:57,360 not block covenants or do anything to inhibit LN symmetry. This is a very confusing strawman 2599 03:44:57,360 --> 03:45:04,360 or misconception about BIP110 that I've seen recently. I have no idea where this came from. 2600 03:45:04,867 --> 03:45:11,867 Actually, there are many BIP110 proponents that are in favor of adding covenants once BIP110 expires. So that would be perfectly acceptable, in my opinion. 2601 03:45:11,867 --> 03:45:25,867 So BIP110 sends a clear signal. Arbitrary data storage is abusive. Bitcoin does not officially support permanent file storage. Storage formats may be broken at any time. Data projects cannot depend on Bitcoin as stable infrastructure. Bitcoin's consensus exists primarily for money. 2602 03:45:25,867 --> 03:45:45,867 Fees are not enough. They just put a price on spam. Spammers may happily pay when speculators subsidize them. A fee market tells them how much the next block costs. It does not tell them to leave. 2603 03:45:45,867 --> 03:46:07,867 Money fees can become a marketing expense. Or could help with marketing. Fees are not an actual deterrent. There's a lot of developers that say monetary transactions will outprice spam transactions. I don't see that happening. 2604 03:46:07,867 --> 03:46:25,867 If you look at Bitcoin's history, what it looks like to me is that when Bitcoiners' hostility towards the spammers maximizes, the spam minimizes. That's actually what you're seeing right now with the movement of BIP110. Because there's a lot of angry node runners that are saying, go away spammers, the spammers have gone away. 2605 03:46:25,867 --> 03:46:50,867 I don't know if you've seen, but the fees are really low now. There's still spam here and there, but it's not a DDoS on the network and preventing people from using Bitcoin as money like it was in 2023 and 2024. Cultural hostility is stronger than fees. Bitcoiners must commit to escalating until the spammers leave. This is what worked in 2014. Storage projects need dependable formats. BIP110 tells them those formats will never be dependable. 2606 03:46:51,867 --> 03:47:12,867 The goal is not just to make spam expensive. The goal is to make clear that Bitcoiners will never accept it as legitimate. Or said another way, we don't want to make spam expensive, we want to make spam unreliable. The reason why they like spamming Bitcoin is because Bitcoin is forever. So if we just say this isn't forever, then that breaks the guarantee and that breaks the incentive for them to use it. 2607 03:47:13,867 --> 03:47:26,867 BIP110 is not a petition. It's not a request for permission from core or miners. It's a commitment by node runners. These are the blocks we will recognize as Bitcoin. The rules gain force when users actually run the software. 2608 03:47:27,867 --> 03:47:45,867 There's no leader who can sell the network. There's no headquarters to close. There's no institution that can surrender on everyone's behalf. The money printer can buy companies, politicians, media, and developers, but they can't force you to run any particular software. And so they can't force you to accept a block that you choose to reject. 2609 03:47:46,867 --> 03:48:10,867 Why BIP110 will activate. BIP110 uses the same basic mechanism as BIP148, which successfully activated in 2017. Software incentives push miners towards the stricter chain. Legacy miners risk producing blocks that may later be wiped out. And miners are risk averse. They don't want to be working on a chain longer and longer and longer and then suddenly all of that whole chain and all of their earnings get wiped out. 2610 03:48:11,867 --> 03:48:28,867 So signaling protects the value of Bitcoin and avoids unnecessary chaos and also avoids miners getting their earnings wiped out. So there's very, very strong incentives on the miners to resolve to a single chain very, very fast. And this is why it's very unlikely that there will even be a chain split. That would be basically an attack by the miners. 2611 03:48:28,867 --> 03:48:57,867 Ignoring is not a defense. Even limited hash power on the stricter chain creates continuing risk for miners on the legacy chain. I already said this, but it's worth repeating. The longer it gets, the greater the risk for the miners. Ignoring the UASF does not make the stricter chain disappear. This is another thing that's important to point out, is the shorter chain does not actually have wipeout risk. As long as the nodes that are running the UASF say, this is the real Bitcoin, then it's not a risk. 2612 03:48:58,867 --> 03:49:22,867 Then that chain continues indefinitely. So it never gets wiped out by the other chain. So the risk is very asymmetric. All of the incentives point towards converging on the stricter chain. An actual defense would require an explicit URASF. And since there is no good reason to reject Bitcoin.10's temporary restrictions, there is no reason for anybody to make or support or run a URASF. 2613 03:49:22,867 --> 03:49:51,867 For some developers, this looks like a relay policy argument. But for node runners, it's a defense of Bitcoin's purpose. Bitcoin is systemically important for humanity. Its survival is more important than short-term convenience or profit. That commitment is why the UASF has force. We're in this with our lives. This is our life mission. Running a node and being a member of this and making this thing work. We really, really care. 2614 03:49:52,867 --> 03:50:20,867 And the people on the other side don't seem to care as much. Most of them are sort of speculators and they see Bitcoin as like BTC. They see it as like this ticker that they can invest in. But there's all these other tickers of other cryptos that they can invest into. And, you know, it's like we're all in on this thing. We need it to work. And the other side doesn't. So it doesn't make sense that the other side would win. 2615 03:50:21,867 --> 03:50:40,867 We just care more and we're more correct. For some developers, let's see, what did I say? Yeah. So Core 30 gave the money printer an opening. Short-term fees, speculative demand, institutional approval, the promise of a higher price. All in exchange for redefining Bitcoin as something other than money. 2616 03:50:40,867 --> 03:51:04,867 Bitcoin's purpose is not for sale. Node runners will not accept every attack because someone pays a fee. The dominant implementation does not control Bitcoin. Users have the right and responsibility to correct attacks. Bitcoin remains universal, decentralized, and money. 2617 03:51:04,867 --> 03:51:21,867 The money printer's greatest weapon is its ability to purchase opposition. Our greatest weapon is the ability to say no. No to cultural surrender. No to unnecessary centralization. No to turning Bitcoin into a permanent file server. No to anyone who thinks enough money can purchase Bitcoin's principles. 2618 03:51:21,867 --> 03:51:49,867 Bip 110 protects Bitcoin's mission. Bip 110 proves that users remain sovereign. Not miners, not developers, not corporations, not governments. Bitcoin must remain universal, decentralized, universal, decentralized money. Bip 110 is how Bitcoin wins. It is currently our best weapon against the money printer's influence over Bitcoin. 2619 03:51:50,867 --> 03:51:52,867 Let's use it. 2620 03:51:53,867 --> 03:51:55,867 Thank you. 2621 03:52:00,867 --> 03:52:02,867 Do we have any questions from the audience? 2622 03:52:07,867 --> 03:52:09,867 I have eight minutes left. 2623 03:52:09,867 --> 03:52:11,867 Or if there's no questions, then... 2624 03:52:12,867 --> 03:52:16,867 Hello. Hey. I'm to your left. 2625 03:52:18,867 --> 03:52:20,867 Oh, Alex. 2626 03:52:20,867 --> 03:52:28,867 Can you explain the temporary nature of the soft fork? This is the first time I've seen a change or a fork that was temporary. 2627 03:52:28,867 --> 03:52:50,867 Yeah, so there actually is precedent for a temporary soft fork. There was one in 2013 to limit block sizes to 500 kilobytes. And it was when there was that problem between 0.7 and 0.8 where they changed the database format and the old version was limited to 500 kilobytes. So they just soft forked temporarily to give everybody enough time to switch over to the new version. 2628 03:52:51,867 --> 03:53:19,867 So there is precedent. Specifically in Bip 110, it's ideal for what Bip 110 is trying to do. It's trying to make a strong statement of rejection of data storage. We don't need permanent changes to the consensus rules in order to set a precedent in the culture. In order to send a signal that we are going to keep escalating to protect Bitcoin. 2629 03:53:19,867 --> 03:53:25,867 What makes you think the spammers will stay away when the rules change back to allow spam again? 2630 03:53:25,867 --> 03:53:40,867 Number one, I don't expect the rules to stay exactly the same. I expect the community to converge around some kind of more permanent solution for this. 2631 03:53:40,867 --> 03:54:02,867 The reason why I expect spammers to go away is because if we make a strong statement that data storage is not allowed, then what that does is it basically requires or incentivizes popular node implementations to implement data filters and filter spam at the policy level, which is where data spam should be countered. 2632 03:54:03,867 --> 03:54:23,867 The point of Bip 110 is not to filter out all the spam or prevent all the spam. It's just to make a strong statement of the nodes must be respected. The nodes are in charge. This is increasing our costs and increasing our centralization. 2633 03:54:24,867 --> 03:54:37,867 It's the node runner's job to enforce the consensus rules, but it's really popular node implementations' job to enforce policy rules. Core 30 has been falling down on that responsibility. 2634 03:54:38,867 --> 03:54:54,867 What the hope is is that in order to avoid another situation where data spam becomes a standard again, in order to nip that in the bud, Core and other popular node implementations will simply decide to filter spam, which is what they always did. 2635 03:54:55,867 --> 03:55:04,867 They always filtered spam from 2010, starting with Satoshi, until 2022 or 2023 when Ordinal started coming out is when they stopped doing their job. 2636 03:55:05,867 --> 03:55:07,867 Thank you. 2637 03:55:08,867 --> 03:55:10,867 Anyone else? 2638 03:55:11,867 --> 03:55:31,867 Thanks for the talk. I'm just kind of curious. What exactly is stopping someone from, let's just say, spinning up a whole bunch of machines last minute, trying to influence the voting and stuff, or the signaling? 2639 03:55:32,867 --> 03:55:41,867 Because it's not exactly the miners, you're not putting in the hashing power and whatnot, it's just nodes. So what exactly is stopping people from just spinning up these nodes like that? 2640 03:55:42,867 --> 03:55:57,867 Well, I mean, we might be seeing that, right? There could be fake BIP-110 nodes, there could be fake Core nodes. I'm sure there are some sort of Spurious or Sybil nodes on both sides. I would be very surprised if there weren't any. 2641 03:55:58,867 --> 03:56:14,867 But it does seem like the growth of at least the BIP-110 nodes, it looks like it's at organic levels now, based on the growth pattern that we've seen since the activation client was released several months ago. 2642 03:56:15,867 --> 03:56:24,867 There were some spikes where there were obvious spoofing, but those have resolved now. Those nodes were shut down. 2643 03:56:25,867 --> 03:56:34,867 We have other heuristics, right? If a bunch of nodes get spun up and nobody claims responsibility for them, that looks kind of suspect. 2644 03:56:35,867 --> 03:56:48,867 But if a bunch of nodes get spun up and a bunch of people, like actual real-life human beings that I've met in real life, are saying, yeah, I'm running a BIP-110 node, that's a pretty strong heuristic that this is actually popular within the community. 2645 03:56:49,867 --> 03:57:07,867 I did actually compile a list of businesses that are running BIP-110, and so there is a significant amount of economic weight behind the soft work as well. 2646 03:57:08,867 --> 03:57:22,867 The way I would answer it is, our side has conviction, and we know that we're right. 2647 03:57:22,867 --> 03:57:36,867 Objectively speaking, if you look at the arguments against BIP-110, they're just kind of frivolous and unserious, in my opinion. 2648 03:57:37,867 --> 03:57:45,867 Let's be clear, I guess there are some objections that are serious, but mostly are due to misunderstandings or misinterpretations of what the BIP is actually doing. 2649 03:57:46,867 --> 03:57:57,867 This is the age-old question, how do you measure consensus? We kind of don't really know, but what we do know is that BIP-148 worked. 2650 03:57:58,867 --> 03:58:04,867 And BIP-148 was like 500 nodes. So if BIP-148 can work, BIP-110 can definitely work. It has like 15,000 nodes. 2651 03:58:04,867 --> 03:58:31,867 I guess, you seem very confident, and I find it a little bit concerning, because basically all of the proposals I've seen in the past and gone into, 2652 03:58:31,867 --> 03:58:44,867 that I've interacted with, are full of trade-offs and reasonable disagreements, but people find consensus on those things anyway. 2653 03:58:45,867 --> 03:58:56,867 You say you're right, and your side has more conviction, but how do you know that you're so right, I guess, is my question. 2654 03:58:57,867 --> 03:58:58,867 I don't really know how to phrase what my concern is. 2655 03:58:58,867 --> 03:59:11,867 I mean, just thinking about the arguments objectively, the argument tends to be that. It tends to be, well, why this? Why not some other set of consensus rules? 2656 03:59:12,867 --> 03:59:18,867 Or how are you sure that miners are going to listen to you? Or how are you sure that other people are going to listen to you? 2657 03:59:18,867 --> 03:59:27,867 And it's kind of like, well, that's not how Bitcoin should work. The side that has the best arguments, those arguments should be evaluated in public, in the open. 2658 03:59:28,867 --> 03:59:40,867 And if those arguments are not defeated, then the movement will not stop. I think the only way to stop the movement is to actually defeat it with good arguments. 2659 03:59:41,867 --> 03:59:52,867 And that's how it should work, right? Bitcoin is a big truth machine. It's constantly evaluating different claims, and every Bitcoiner is responsible for evaluating those claims independently. 2660 03:59:53,867 --> 03:59:54,867 That's what's beautiful about it. 2661 03:59:54,867 --> 04:00:09,867 Hey, so in your presentation, you noted that it, correctly, that it is impossible to fully prevent all spam. 2662 04:00:10,867 --> 04:00:22,867 And from your answers to the other questions, it sounds like the intent behind BIP110 is more so as a political statement of hostility towards a specific vector of attack. 2663 04:00:22,867 --> 04:00:41,867 Right. With BIP110, node runners are saying, we do not accept arbitrary data storage as an official use case. We consider attempts to store arbitrary data on our nodes abusive. 2664 04:00:42,867 --> 04:00:49,867 So this would be a technical change to Bitcoin motivated by sociological ideation rather than based on technical merit. 2665 04:00:49,867 --> 04:00:52,867 Now, do you have any evidence on the sociological... 2666 04:00:53,867 --> 04:00:59,867 Well, it also has technical merit because the technical changes support the motivation in the strongest possible way. 2667 04:01:00,867 --> 04:01:07,867 In order to make that argument, you would need to prove that the technical changes would have the sociological outcome that you claim to. Can you back that up with any evidence? 2668 04:01:08,867 --> 04:01:11,867 That the technical changes have the sociological... 2669 04:01:12,867 --> 04:01:18,867 You're claiming that this change will disincentivize people from using Bitcoin for spam. Can you claim why that would be true? 2670 04:01:19,867 --> 04:01:30,867 I mean, because it's a clear statement of hostility against spam. And there's a historical precedent for if we show clear hostility against spammers, the spammers leave and go to other chains. 2671 04:01:31,867 --> 04:01:39,867 Can you back that up with any evidence? Because the reason you wrote the document is because of the... 2672 04:01:40,867 --> 04:01:42,867 Sorry, I can't really hear you. 2673 04:01:42,867 --> 04:01:55,867 I just have to push back on that because that's just objectively not true. Actually, what blew Ordinals up was all of Luke's criticism. It enlivened the Ordinals movement. 2674 04:01:56,867 --> 04:02:04,867 It's what made people care was the fact that it was controversial and click-baity and engagement-y. No one gave a shit about Ordinals until Luke Dash started... 2675 04:02:05,867 --> 04:02:10,867 No, so the reason why Ordinals blew up is because Core refused to filter it. If Core had just come in and been like, this is spam... 2676 04:02:10,867 --> 04:02:16,867 That's just historically completely inaccurate. Core didn't have anything to do with Ordinals when Ordinals was blowing up. 2677 04:02:17,867 --> 04:02:22,867 It's not historically inaccurate to say something that didn't happen didn't happen because it didn't happen. 2678 04:02:23,867 --> 04:02:30,867 I think it's very objectively factual that Ordinals was a market that was completely running up. There was a huge Ordinals bull market and Core wasn't even paying attention. 2679 04:02:31,867 --> 04:02:36,867 No, when Ordinals was first announced, Core could have come out with the inscription filter that Luke ended up eventually writing. 2680 04:02:36,867 --> 04:02:41,867 They could have come out with that filter right away because it was their job to filter new token spam. 2681 04:02:42,867 --> 04:02:53,867 I won't argue, but I will point out this idea that Ordinals only matters and became relevant because BIP-110 adjacent crews were the opposite. 2682 04:02:54,867 --> 04:02:59,867 The BIP-110 people is the reason why Ordinals died is just absurd. There's no evidence for that whatsoever. 2683 04:03:00,867 --> 04:03:01,867 It is demonstrably true. That is what happened. 2684 04:03:01,867 --> 04:03:05,867 It is not demonstrably true. Ordinals died when BIP-110 started going down. 2685 04:03:06,867 --> 04:03:07,867 We culturally rejected the shit-coiners. 2686 04:03:08,867 --> 04:03:09,867 There's no evidence for that. 2687 04:03:10,867 --> 04:03:15,867 The shit-coiners tried to insert themselves into our conferences, onto our platforms, onto our stages, take over our meetups, and we pushed them out. 2688 04:03:16,867 --> 04:03:19,867 We said, no, we don't accept this. That's why it died because we rejected them. 2689 04:03:20,867 --> 04:03:25,867 Ordinals are literally getting more attention right now in Mindshare because of BIP-110 right now, this month even. 2690 04:03:26,867 --> 04:03:32,867 Leonidas and Udi are crushing right now because of this conversation. 2691 04:03:33,867 --> 04:03:38,867 If we just let them take over, then it's not like the shit-coins would just go away. 2692 04:03:39,867 --> 04:03:45,867 There's a whole long tail of other crypto projects that are basically immortal. They never die. 2693 04:03:46,867 --> 04:03:49,867 We have a knob, which is the amount of hostility. 2694 04:03:50,867 --> 04:03:51,867 We turn it all the way to the right, that's maximally hostile. 2695 04:03:52,867 --> 04:03:54,867 We turn it all the way to the left, that's maximally friendly. 2696 04:03:55,867 --> 04:03:56,867 Core turned it all the way to the left. 2697 04:03:57,867 --> 04:03:59,867 They were like, we're going to just give them all sorts of places to spam. 2698 04:04:00,867 --> 04:04:02,867 That sent a signal of cultural friendliness towards spam. 2699 04:04:03,867 --> 04:04:04,867 That's what increases spam. 2700 04:04:05,867 --> 04:04:07,867 Then BIP-110 happened, and that turned it back to the right. 2701 04:04:08,867 --> 04:04:09,867 Just for clarity. 2702 04:04:10,867 --> 04:04:13,867 If you look at the incidence of spam versus those time periods, it exactly correlates. 2703 04:04:14,867 --> 04:04:17,867 Core specifically expanded the limit to enable a BitVM use case. 2704 04:04:18,867 --> 04:04:20,867 Do you consider that also spam? 2705 04:04:21,867 --> 04:04:23,867 Because that is why Core did not. 2706 04:04:23,867 --> 04:04:25,867 No, that rationale was bullshit. 2707 04:04:26,867 --> 04:04:28,867 You think Core just said that, but they were just full of shit? 2708 04:04:29,867 --> 04:04:30,867 Yes. 2709 04:04:31,867 --> 04:04:34,867 They actually just wanted the JPEGs to move from the witness into the operator. 2710 04:04:35,867 --> 04:04:37,867 I don't know what the real reason was, but I do know that the explanation they gave was not sufficient. 2711 04:04:38,867 --> 04:04:43,867 They basically said, we're worried that there's going to be 64 bytes of UTXO set bloat that may or may not happen, 2712 04:04:44,867 --> 04:04:47,867 because this Citria fraud-proof transaction, which is never expected to happen, 2713 04:04:48,867 --> 04:04:50,867 might produce 64 bytes of UTXO set bloat. 2714 04:04:50,867 --> 04:04:54,867 Do you not believe them that they didn't want people using private mempools? 2715 04:04:55,867 --> 04:04:56,867 Let me finish. 2716 04:04:57,867 --> 04:04:59,867 Meanwhile, Ordinals caused 8 gigabytes of UTXO set bloat, 2717 04:05:00,867 --> 04:05:02,867 and the reason why that happened is because they didn't filter it. 2718 04:05:03,867 --> 04:05:05,867 Core's decision had nothing to do with instruction. 2719 04:05:06,867 --> 04:05:08,867 They're saying, we're so worried about UTXO set bloat, 2720 04:05:09,867 --> 04:05:11,867 so we're going to prevent 64 bytes of spam that will never happen, 2721 04:05:12,867 --> 04:05:17,867 but we're going to pretend the 8 gigabytes of UTXO set bloat just didn't happen or didn't matter. 2722 04:05:17,867 --> 04:05:19,867 To this day, if you talk to Core devs and you say, 2723 04:05:20,867 --> 04:05:26,867 my Raspberry Pi doesn't sync anymore because of all the spam that happened and all the UTXO set bloat that happened, 2724 04:05:27,867 --> 04:05:28,867 they'll just laugh you out of the room. 2725 04:05:29,867 --> 04:05:30,867 They're just like, ha ha ha, this guy's an idiot. 2726 04:05:31,867 --> 04:05:34,867 I've talked to dozens of people that have this exact experience. 2727 04:05:35,867 --> 04:05:39,867 It's just like the conspiracy theory levels around the Core thing are really... 2728 04:05:40,867 --> 04:05:41,867 It's not a conspiracy. 2729 04:05:42,867 --> 04:05:45,867 No, no, you're saying that they're lying about their stated reasons 2730 04:05:45,867 --> 04:05:51,867 when they gave very strong technical reasons in support of the security of the network for why they made this decision. 2731 04:05:52,867 --> 04:05:53,867 Their technical reasons were bullshit. 2732 04:05:54,867 --> 04:05:57,867 Do you think the reason that they didn't want people using private mempools 2733 04:05:58,867 --> 04:05:59,867 to execute Layer 2 transactions is bullshit? 2734 04:06:00,867 --> 04:06:03,867 Because that's actually something that does matter for decentralization. 2735 04:06:04,867 --> 04:06:06,867 Those things only happen when the spammers are invited in. 2736 04:06:07,867 --> 04:06:09,867 If we show cultural hostility against the spammers, 2737 04:06:10,867 --> 04:06:12,867 then they go away and private mempools aren't an issue. 2738 04:06:13,867 --> 04:06:14,867 I encourage you guys to take up the conversation later. 2739 04:06:15,867 --> 04:06:16,867 We've got one more question and we are out of time. 2740 04:06:17,867 --> 04:06:18,867 Very brief. 2741 04:06:19,867 --> 04:06:20,867 Quick question. 2742 04:06:21,867 --> 04:06:25,867 You mentioned that, of course, it's not possible to get rid of all spam 2743 04:06:26,867 --> 04:06:29,867 and that the goal here is to create hostility towards spammers. 2744 04:06:30,867 --> 04:06:39,867 Why BIP-110 as opposed to a code comment or something that signals hostility? 2745 04:06:39,867 --> 04:06:49,867 Because BIP-110 mitigates the CSAM vector. 2746 04:06:50,867 --> 04:06:52,867 No comment would do that. 2747 04:06:53,867 --> 04:06:56,867 Secondly, a consensus change is a consensus change. 2748 04:06:57,867 --> 04:07:00,867 Every consensus change is a cultural moment for Bitcoin. 2749 04:07:01,867 --> 04:07:04,867 It sets a precedent that affects Bitcoin's culture moving forward. 2750 04:07:05,867 --> 04:07:08,867 The block size war was a culturally defining moment for Bitcoin. 2751 04:07:09,867 --> 04:07:10,867 BIP-110 is a similar moment. 2752 04:07:11,867 --> 04:07:14,867 Could we soft fork with a comment that you have to send to a node 2753 04:07:15,867 --> 04:07:17,867 in order to connect to them or put in a block header? 2754 04:07:18,867 --> 04:07:21,867 I don't think that would work. 2755 04:07:22,867 --> 04:07:26,867 When we say we're willing to escalate until the spammers go away, 2756 04:07:27,867 --> 04:07:29,867 we're willing to use technical means to do so. 2757 04:07:30,867 --> 04:07:33,867 There's way tighter restrictions that we could make on the consensus rules 2758 04:07:34,867 --> 04:07:35,867 that BIP-110 doesn't do. 2759 04:07:36,867 --> 04:07:37,867 For instance, script whitelists. 2760 04:07:37,867 --> 04:07:39,867 If somehow the spammers decide to come back, 2761 04:07:40,867 --> 04:07:41,867 or there's another thing called P2SH2, 2762 04:07:42,867 --> 04:07:45,867 where you have to prove that every piece of data in your transaction 2763 04:07:46,867 --> 04:07:49,867 is actually something financial or monetary. 2764 04:07:50,867 --> 04:07:52,867 It's like a key or a hash or something like that. 2765 04:07:53,867 --> 04:07:55,867 There's other technical means that are much more restrictive 2766 04:07:56,867 --> 04:08:00,867 and much stronger that we could do if Core continues to fail 2767 04:08:01,867 --> 04:08:04,867 at filtering data spam after BIP-110 activates. 2768 04:08:05,867 --> 04:08:09,867 Just somebody writing a comment somewhere is not authoritative. 2769 04:08:12,867 --> 04:08:13,867 Thank you, Chris. 2770 04:08:14,867 --> 04:08:15,867 Thanks, guys. 2771 04:08:16,867 --> 04:08:17,867 BIP-110. 2772 04:08:32,867 --> 04:08:33,867 I guess I'm monitoring this. 2773 04:08:34,867 --> 04:08:35,867 I'm not sure exactly... 2774 04:08:36,867 --> 04:08:37,867 I can sort of see a theme here. 2775 04:08:38,867 --> 04:08:41,867 Maybe, given your talk, there's a little bit of a similarity 2776 04:08:42,867 --> 04:08:43,867 in that you're not... 2777 04:08:44,867 --> 04:08:45,867 Are you... 2778 04:08:46,867 --> 04:08:47,867 Look at the hat. 2779 04:08:48,867 --> 04:08:49,867 He's the devil's advocate. 2780 04:08:50,867 --> 04:08:51,867 I thought it was inflation for it, 2781 04:08:52,867 --> 04:08:53,867 because you're not really pitching that. 2782 04:08:54,867 --> 04:08:55,867 He's like the null hypothesis. 2783 04:08:56,867 --> 04:08:57,867 Everyone has to fight. 2784 04:08:58,867 --> 04:08:59,867 He's the gatekeeper. 2785 04:09:00,867 --> 04:09:02,867 I guess I'm here to try to keep it civil. 2786 04:09:02,867 --> 04:09:03,867 I don't know if that'll work. 2787 04:09:04,867 --> 04:09:05,867 But I'm not pitching any... 2788 04:09:06,867 --> 04:09:07,867 I guess technically... 2789 04:09:08,867 --> 04:09:09,867 U3XO is cleverly not a fork. 2790 04:09:10,867 --> 04:09:11,867 Not a fork. 2791 04:09:12,867 --> 04:09:14,867 I guess the talk I gave was stuff that would be a soft fork, 2792 04:09:15,867 --> 04:09:16,867 but I'm sort of advocating... 2793 04:09:17,867 --> 04:09:18,867 BIP-54 helps with U3XO, right? 2794 04:09:19,867 --> 04:09:20,867 Does BIP-54 help with U3XO? 2795 04:09:21,867 --> 04:09:22,867 The BIP-30 stuff, yeah. 2796 04:09:23,867 --> 04:09:24,867 The BIP-30, yeah. 2797 04:09:25,867 --> 04:09:26,867 We've got decades before. 2798 04:09:27,867 --> 04:09:28,867 That would be nice. 2799 04:09:29,867 --> 04:09:30,867 I guess first we'll just each... 2800 04:09:30,867 --> 04:09:31,867 I'm Taj. 2801 04:09:32,867 --> 04:09:33,867 I'm not advocating for a consensus change. 2802 04:09:34,867 --> 04:09:35,867 We can each go around and say our names 2803 04:09:36,867 --> 04:09:39,867 and what the consensus change we're pushing for, I guess. 2804 04:09:41,867 --> 04:09:42,867 Hi, my name is Chris Guida, 2805 04:09:43,867 --> 04:09:47,867 and I am a tester and reviewer and cheerleader for BIP-110. 2806 04:09:49,595 --> 04:09:52,595 Yes, I'm Paul Sztorc. I propose the soft forks, BIP-300 and 301, 2807 04:09:52,595 --> 04:09:58,595 and I propose a hard fork for Bitcoin at the end of next month. 2808 04:09:58,595 --> 04:10:02,595 Go to eCash, eCash.com. 2809 04:10:02,595 --> 04:10:07,595 I'm Peter Todd. I, in this conference, propose that someone else in the future 2810 04:10:07,595 --> 04:10:12,595 propose tail emission demurrage. I don't want to do the work myself. 2811 04:10:13,595 --> 04:10:18,595 And I've also got a proposed op expiry, which fortunately another guy here in the audience 2812 04:10:18,595 --> 04:10:22,595 wants to propose another version of it that might work, too, so he can do the work for me, too. 2813 04:10:22,595 --> 04:10:27,595 This is great. I can just sit here and talk on panels. 2814 04:10:27,595 --> 04:10:31,595 Okay, I want to do... Did someone already do the show of hands for 110 support, 2815 04:10:31,595 --> 04:10:35,595 like four against indifferent or just deciding? You know what I mean? 2816 04:10:35,595 --> 04:10:39,595 Did someone do that at some point? Because wouldn't that be helpful for the 110 2817 04:10:39,595 --> 04:10:42,595 to just see what is in the room for... 2818 04:10:42,595 --> 04:10:44,595 BIP-110. Let's do BIP-110. 2819 04:10:44,595 --> 04:10:46,595 110. More panels. 2820 04:10:46,595 --> 04:10:50,595 Okay, so if you're in favor of 110, is that what that was going to be? 2821 04:10:50,595 --> 04:10:55,595 Let's do indifferent first. If you're indifferent or you haven't decided yet on 110. 2822 04:10:55,595 --> 04:10:57,595 Raise your hand if you're indifferent. 2823 04:10:57,595 --> 04:11:01,595 We have one... We have two people, right? Maybe? 2824 04:11:01,595 --> 04:11:04,595 Okay, what about... Oh, we have three people. Okay, great. 2825 04:11:04,595 --> 04:11:07,595 What about if you're in favor of 110? 2826 04:11:08,595 --> 04:11:10,595 Favor of 110. 2827 04:11:10,595 --> 04:11:14,595 We got two maybe trolling. 2828 04:11:14,595 --> 04:11:18,595 And we have maybe five, but maybe two of them are trolling. I don't know. 2829 04:11:20,595 --> 04:11:24,595 Okay, now if you're against 110, raise your hand. 2830 04:11:24,595 --> 04:11:26,595 It happened to me. 2831 04:11:26,595 --> 04:11:30,595 But are you doing a URSF? Who's URSF-ing BIP-110? 2832 04:11:30,595 --> 04:11:32,595 None of you are opposed. 2833 04:11:32,595 --> 04:11:35,595 So if we did that, we have to also do that with BIP-300. 2834 04:11:35,595 --> 04:11:37,595 That's true. We go on and on. 2835 04:11:37,595 --> 04:11:40,595 I wasn't trying to smuggle that in. I was just trying to... 2836 04:11:40,595 --> 04:11:44,595 Although I'm curious about it now that you asked, but I wasn't trying to smuggle it in. 2837 04:11:44,595 --> 04:11:49,595 I guess not going to run BIP-300 or against BIP-300. 2838 04:11:49,595 --> 04:11:52,595 Well, okay, I put out BIP-300 and it's kind of like... 2839 04:11:52,595 --> 04:11:57,595 Without enthusiastic support from users and miners, it wouldn't work anyway. 2840 04:11:57,595 --> 04:12:03,595 So it's not... It hinges on a little bit more than just maybe what 110 does. 2841 04:12:04,595 --> 04:12:10,595 Hence the desire to demonstrate it with its own thing, I think. 2842 04:12:10,595 --> 04:12:13,595 So maybe we could talk about that a little. 2843 04:12:13,595 --> 04:12:17,595 So you proposed BIP-110 a while ago, right? 2844 04:12:17,595 --> 04:12:22,595 BIP-300 is a little... BIP-300 is years old. 2845 04:12:22,595 --> 04:12:26,595 It got the BIP number in maybe 2018, I think. February 2018. 2846 04:12:26,595 --> 04:12:28,595 And BIP-110 is fairly recent, right? 2847 04:12:28,595 --> 04:12:35,595 And we should also point out for the audience that BIP-300 is a complete redesign of all the incentives in the Bitcoin system. 2848 04:12:35,595 --> 04:12:40,595 And it's a massive change. And BIP-110 is a tiny, surgical, totally common sense... 2849 04:12:40,595 --> 04:12:42,595 Well, I don't agree with that. 2850 04:12:42,595 --> 04:12:47,595 You just take an unused opcode and use it to count to 13,000, basically. 2851 04:12:47,595 --> 04:12:49,595 That's all it does under the hood. 2852 04:12:49,595 --> 04:12:56,595 And as far as the miners, it asks them to basically accept more money for merge mining, 2853 04:12:56,595 --> 04:13:00,595 which is something that we've had since Namecoin in 2010, 2011. 2854 04:13:00,595 --> 04:13:04,595 I am much closer to agreeing with Chris on this, just for the record. 2855 04:13:04,595 --> 04:13:10,595 But I think we probably shouldn't talk too much about the details of what the forks are, 2856 04:13:10,595 --> 04:13:13,595 even though I know people want to, because we did sort of just have... 2857 04:13:13,595 --> 04:13:15,595 You talked, and then you talked, and now we're all... 2858 04:13:15,595 --> 04:13:19,595 So I think most of the people here are at least somewhat familiar from the talks. 2859 04:13:19,595 --> 04:13:24,595 But I think the difference is, yeah, you're sort of saying, I'm going to do a hard fork, right? 2860 04:13:25,595 --> 04:13:28,595 I think it's actually the polite thing to do under the circumstances. 2861 04:13:28,595 --> 04:13:32,595 It's sort of like people are not... They're not lapping it up, basically. 2862 04:13:32,595 --> 04:13:37,595 But it did take so six or eight years. 2863 04:13:37,595 --> 04:13:40,595 So for eight years, could you say just a little of like, 2864 04:13:40,595 --> 04:13:43,595 okay, so for eight years, were you sort of hoping it would be a soft fork 2865 04:13:43,595 --> 04:13:45,595 and trying to pitch it in the same way? 2866 04:13:45,595 --> 04:13:47,595 Well, I was very open-minded to like... 2867 04:13:47,595 --> 04:13:51,595 I actually proposed the idea in form of writing in 2015. 2868 04:13:51,595 --> 04:13:52,595 So it's super old. 2869 04:13:52,595 --> 04:13:56,595 And I was just kind of shrugged like, whatever, maybe we won't need this. 2870 04:13:56,595 --> 04:13:59,595 Over the last ten years, what's really happened is I've seen how terrible everyone else's... 2871 04:13:59,595 --> 04:14:01,595 You know, how lightning has not worked, 2872 04:14:01,595 --> 04:14:04,595 and it seems like actually everyone has no idea what they're doing. 2873 04:14:04,595 --> 04:14:09,595 So my idea kind of stayed the same, and then all these other ideas collapsed. 2874 04:14:09,595 --> 04:14:12,595 And I thought, well, actually, my idea is actually the best idea. 2875 04:14:12,595 --> 04:14:15,595 And it's very, very misunderstood. 2876 04:14:15,595 --> 04:14:18,595 There are basic things about it that are easy to understand 2877 04:14:18,595 --> 04:14:21,595 that people have trouble grasping. 2878 04:14:21,595 --> 04:14:23,595 So I kind of just thought everything would be fine. 2879 04:14:23,595 --> 04:14:26,595 You know, the price of Bitcoin has gone up a huge amount. 2880 04:14:26,595 --> 04:14:29,595 So overall, there's been a lot of success for Bitcoin. 2881 04:14:29,595 --> 04:14:33,595 But I think I worry about how do we go up from here, 2882 04:14:33,595 --> 04:14:35,595 both in terms of adoption and in terms of price. 2883 04:14:35,595 --> 04:14:40,595 You got multiple people fighting, chasing the customers away at the front door 2884 04:14:40,595 --> 04:14:44,595 where people are saying like, you know, we got the treasury companies, 2885 04:14:44,595 --> 04:14:49,595 we got 110, we got people saying, oh, it's not a good thing to use Bitcoin. 2886 04:14:49,595 --> 04:14:52,595 So we got all kinds of weird stuff like that. 2887 04:14:52,595 --> 04:14:56,595 Okay, so in this case, the 300, you have a hard fork, 2888 04:14:56,595 --> 04:14:58,595 there's a difficulty adjustment, there's all this stuff, 2889 04:14:58,595 --> 04:15:01,595 it's going to run, and you're going to have a sustained chain. 2890 04:15:01,595 --> 04:15:03,595 With the BIP-110... 2891 04:15:03,595 --> 04:15:04,595 Something will happen. 2892 04:15:04,595 --> 04:15:08,595 Yeah, there's no, at least from my understanding, 2893 04:15:08,595 --> 04:15:11,595 there's no plan for a hard fork or difficulty adjustment at this time. 2894 04:15:11,595 --> 04:15:14,595 Is that something people have talked about in BIP-110 at all? 2895 04:15:14,595 --> 04:15:17,595 I mean, people always say like, what happens if the miners ignore it? 2896 04:15:17,595 --> 04:15:19,595 And it's like, well, they're not going to ignore it. 2897 04:15:19,595 --> 04:15:21,595 That would be an attack on Bitcoin. 2898 04:15:21,595 --> 04:15:24,595 It would be an attack on the node network. 2899 04:15:24,595 --> 04:15:26,595 There are other things we could do. 2900 04:15:26,595 --> 04:15:29,595 So what if they do, and then the response is they won't, 2901 04:15:29,595 --> 04:15:31,595 isn't really a response, right? 2902 04:15:31,595 --> 04:15:32,595 Right, exactly. 2903 04:15:32,595 --> 04:15:35,595 I mean, if the entire mining industry is malicious, 2904 04:15:35,595 --> 04:15:39,595 we have to have some kind of stronger escalation to that. 2905 04:15:40,595 --> 04:15:42,595 The next move would be a proof-of-work change. 2906 04:15:42,595 --> 04:15:45,595 Would you call the majority of the people in this room malicious? 2907 04:15:45,595 --> 04:15:48,595 It's a little tricky when they're in the room with you, right? 2908 04:15:48,595 --> 04:15:51,595 Because you only have three votes, really, four, right? 2909 04:15:51,595 --> 04:15:55,595 Well, I mean, but the people in this room are not running mining pools. 2910 04:15:55,595 --> 04:15:58,595 I mean, maybe there's a couple of people running mining pools. 2911 04:15:58,595 --> 04:16:01,595 Yeah, I mean, you know. 2912 04:16:01,595 --> 04:16:02,595 We have a marathon over there. 2913 04:16:02,595 --> 04:16:05,595 But yeah, I mean, well... 2914 04:16:05,595 --> 04:16:07,595 I wouldn't say they're not malicious. 2915 04:16:08,595 --> 04:16:11,595 Do you acknowledge that you might be in a minority position here? 2916 04:16:11,595 --> 04:16:13,595 Or are you like, no, of course we're the majority. 2917 04:16:13,595 --> 04:16:14,595 There's no way we could be a minority. 2918 04:16:14,595 --> 04:16:18,595 But again, so VIP-148 had a minority position, too. 2919 04:16:18,595 --> 04:16:21,595 And it still forced the activation of SegWit, 2920 04:16:21,595 --> 04:16:23,595 and it still forced its own activation. 2921 04:16:23,595 --> 04:16:26,595 Some people will say, oh, well, VIP-91 made it do that, 2922 04:16:26,595 --> 04:16:28,595 but it was compliant with VIP-148, 2923 04:16:28,595 --> 04:16:30,595 and obviously that wouldn't have happened if VIP-148 hadn't happened. 2924 04:16:30,595 --> 04:16:32,595 So I agree it's hard. 2925 04:16:32,595 --> 04:16:33,595 It is a hard question. 2926 04:16:33,595 --> 04:16:34,595 How do you measure consensus? 2927 04:16:34,595 --> 04:16:37,595 With the SegWit, though, it was sort of a basic... 2928 04:16:37,595 --> 04:16:41,595 As far as I know, every developer working on Bitcoin Core 2929 04:16:41,595 --> 04:16:43,595 was like, yes, SegWit. 2930 04:16:43,595 --> 04:16:45,595 And much more than just developers. 2931 04:16:45,595 --> 04:16:47,595 You know, in an equivalent conference like this, 2932 04:16:47,595 --> 04:16:50,595 you would have had essentially everyone saying SegWit's a great thing. 2933 04:16:50,595 --> 04:16:51,595 Although there were some people, like I remember... 2934 04:16:51,595 --> 04:16:52,595 There were some. 2935 04:16:52,595 --> 04:16:53,595 I remember in Hong Kong, Sipa gave the talk. 2936 04:16:53,595 --> 04:16:55,595 Right, Core was on the good guy's side in the block size war, 2937 04:16:55,595 --> 04:16:57,595 and they're on the bad guy's side this time. 2938 04:16:57,595 --> 04:17:00,595 So, you know, we have to work with what we've got. 2939 04:17:00,595 --> 04:17:01,595 I don't think we should do good-bad, 2940 04:17:01,595 --> 04:17:03,595 but I do remember in Hong Kong, 2941 04:17:03,595 --> 04:17:04,595 Sipa gave the sort of mic drop talk 2942 04:17:04,595 --> 04:17:06,595 of how you could do SegWit as a software. 2943 04:17:06,595 --> 04:17:07,595 Everyone was clapping. 2944 04:17:07,595 --> 04:17:08,595 I remember sitting next to... 2945 04:17:08,595 --> 04:17:09,595 I was standing next to Joseph Hoon, 2946 04:17:09,595 --> 04:17:10,595 and he was like, oh, great. 2947 04:17:10,595 --> 04:17:12,595 And I was like, oh, no, look. 2948 04:17:12,595 --> 04:17:13,595 Look at Roger Ver over there. 2949 04:17:13,595 --> 04:17:16,595 Like, there were people who were not happy about that. 2950 04:17:16,595 --> 04:17:18,595 And I sort of feel like that's when 2951 04:17:18,595 --> 04:17:19,595 the sort of Bitcoin Cash stuff started. 2952 04:17:19,595 --> 04:17:21,595 But anyway. 2953 04:17:21,595 --> 04:17:23,595 But it is a hard thing to measure, 2954 04:17:23,595 --> 04:17:25,595 but it does seem that like... 2955 04:17:25,595 --> 04:17:26,595 I don't want to say objectively, 2956 04:17:26,595 --> 04:17:29,595 but it's like if you're going to run VIP-110, 2957 04:17:29,595 --> 04:17:32,595 it seems like you should plan ahead of like, 2958 04:17:32,595 --> 04:17:34,595 okay, what do we do if it is minority hash rate? 2959 04:17:34,595 --> 04:17:35,595 I mean, basically, yeah, it's like, 2960 04:17:35,595 --> 04:17:38,595 what do we do if actually the nodes 2961 04:17:38,595 --> 04:17:39,595 are not in charge of Bitcoin 2962 04:17:39,595 --> 04:17:41,595 and the miners are actually in charge? 2963 04:17:41,595 --> 04:17:42,595 It's kind of like, okay, well, 2964 04:17:42,595 --> 04:17:45,595 what do we do if Bitcoin is dead? 2965 04:17:45,595 --> 04:17:46,595 You're saying that you even said 2966 04:17:46,595 --> 04:17:47,595 that it was like wildly popular 2967 04:17:47,595 --> 04:17:50,595 and had 17% right now? 2968 04:17:50,595 --> 04:17:52,595 Yeah, 15% to 17% is the sort of... 2969 04:17:52,595 --> 04:17:54,595 But that's a minority, right? 2970 04:17:54,595 --> 04:17:57,595 So what do you mean the miners are in charge? 2971 04:17:57,595 --> 04:17:59,595 That's the people who are like 2972 04:18:00,595 --> 04:18:01,595 rabidly in favor of it, 2973 04:18:01,595 --> 04:18:02,595 or maybe not rabidly, 2974 04:18:02,595 --> 04:18:03,595 but like, you know, 2975 04:18:03,595 --> 04:18:05,595 enthusiastically in favor of it, right? 2976 04:18:05,595 --> 04:18:06,595 We don't need... 2977 04:18:06,595 --> 04:18:07,595 In order to change Bitcoin's consensus rules, 2978 04:18:07,595 --> 04:18:10,595 we don't need everyone to be enthusiastically 2979 04:18:10,595 --> 04:18:11,595 in favor of the consensus rules. 2980 04:18:11,595 --> 04:18:13,595 We just need a vocal minority 2981 04:18:13,595 --> 04:18:15,595 that's really in favor of it 2982 04:18:15,595 --> 04:18:17,595 and nobody that's willing to do a URSF, 2983 04:18:17,595 --> 04:18:18,595 which is how it works today. 2984 04:18:18,595 --> 04:18:20,595 What if you're in a position where it is true 2985 04:18:20,595 --> 04:18:23,595 that the majority of users 2986 04:18:23,595 --> 04:18:25,595 actually disagree with you? 2987 04:18:25,595 --> 04:18:26,595 What then? 2988 04:18:26,595 --> 04:18:28,595 They have to run a URSF or it doesn't matter. 2989 04:18:28,595 --> 04:18:29,595 But isn't that actually not true 2990 04:18:29,595 --> 04:18:32,595 because of the mandatory signaling? 2991 04:18:32,595 --> 04:18:33,595 What? 2992 04:18:33,595 --> 04:18:34,595 Isn't that actually not true? 2993 04:18:34,595 --> 04:18:35,595 If they just don't signal, 2994 04:18:35,595 --> 04:18:40,595 then they will automatically URSF? 2995 04:18:40,595 --> 04:18:43,595 No, because there's very, very 2996 04:18:43,595 --> 04:18:45,595 crushingly huge incentives 2997 04:18:45,595 --> 04:18:47,595 to not do that, 2998 04:18:47,595 --> 04:18:48,595 because that's the legacy chain 2999 04:18:48,595 --> 04:18:49,595 and it has wipeout risk. 3000 04:18:49,595 --> 04:18:50,595 It might get wiped out. 3001 04:18:50,595 --> 04:18:51,595 Look, you believe that, 3002 04:18:51,595 --> 04:18:53,595 but if we wind up in a month 3003 04:18:53,595 --> 04:18:55,595 and there's 1% hash power 3004 04:18:55,595 --> 04:18:57,595 mining the Bitcoin 10 chain 3005 04:18:57,595 --> 04:18:59,595 and I think this is true, 3006 04:18:59,595 --> 04:19:02,595 the majority of Bitcoin nodes 3007 04:19:02,595 --> 04:19:03,595 and Bitcoin users 3008 04:19:03,595 --> 04:19:04,595 are going to say, 3009 04:19:04,595 --> 04:19:06,595 well, we don't agree with the Bitcoin 10 chain either. 3010 04:19:06,595 --> 04:19:08,595 Then what do you do? 3011 04:19:08,595 --> 04:19:09,595 Another way to put it... 3012 04:19:09,595 --> 04:19:11,595 Again, the incentives are for the miners 3013 04:19:11,595 --> 04:19:13,595 to just converge on one chain. 3014 04:19:13,595 --> 04:19:15,595 The miners need Bitcoin to be one thing. 3015 04:19:15,595 --> 04:19:16,595 If Bitcoin is two things, 3016 04:19:16,595 --> 04:19:18,595 the miners can't sell their coins 3017 04:19:18,595 --> 04:19:19,595 and pay for their electricity. 3018 04:19:19,595 --> 04:19:20,595 If you're in a minority, 3019 04:19:20,595 --> 04:19:21,595 that's bad for you 3020 04:19:21,595 --> 04:19:22,595 because they're going to want to converge 3021 04:19:22,595 --> 04:19:23,595 to one thing, 3022 04:19:23,595 --> 04:19:25,595 which would be the non-Bitcoin 10 chain. 3023 04:19:25,595 --> 04:19:26,595 It doesn't matter though 3024 04:19:26,595 --> 04:19:28,595 because even a minority chain 3025 04:19:28,595 --> 04:19:29,595 can catch up and win. 3026 04:19:31,595 --> 04:19:33,595 If there's a non-zero chance 3027 04:19:33,595 --> 04:19:35,595 that the minority chain will catch up and win, 3028 04:19:35,595 --> 04:19:37,595 then the miners have a strong incentive 3029 04:19:37,595 --> 04:19:39,595 to switch to the stricter chain. 3030 04:19:39,595 --> 04:19:41,595 What if there was a minority 3031 04:19:41,595 --> 04:19:43,595 of very vocal, zealous people 3032 04:19:43,595 --> 04:19:44,595 who said, 3033 04:19:44,595 --> 04:19:46,595 we need KYC in Bitcoin 3034 04:19:46,595 --> 04:19:47,595 and said, 3035 04:19:47,595 --> 04:19:48,595 we're only 5% of the nodes, 3036 04:19:48,595 --> 04:19:49,595 but we need this... 3037 04:19:49,595 --> 04:19:50,595 Then there would be a URSF. 3038 04:19:50,595 --> 04:19:51,595 It needs to be... 3039 04:19:51,595 --> 04:19:52,595 A URSF. 3040 04:19:52,595 --> 04:19:54,595 What if it's 1%? 3041 04:19:54,595 --> 04:19:55,595 I'm running a node. 3042 04:19:56,595 --> 04:19:57,595 I don't even pay attention. 3043 04:19:57,595 --> 04:19:58,595 If you think that change 3044 04:19:58,595 --> 04:20:00,595 is going to be harmful for Bitcoin, 3045 04:20:00,595 --> 04:20:01,595 you have to do a URSF. 3046 04:20:01,595 --> 04:20:03,595 So any minority, 3047 04:20:03,595 --> 04:20:04,595 no matter how small, 3048 04:20:04,595 --> 04:20:05,595 commands my attention 3049 04:20:05,595 --> 04:20:06,595 to do something about it? 3050 04:20:06,595 --> 04:20:07,595 Or can I just ignore it? 3051 04:20:07,595 --> 04:20:08,595 How small does it have to be 3052 04:20:08,595 --> 04:20:09,595 before I can ignore it? 3053 04:20:09,595 --> 04:20:11,595 Any minority that's at least as big 3054 04:20:11,595 --> 04:20:12,595 as BIP-148 3055 04:20:12,595 --> 04:20:13,595 demands your attention 3056 04:20:13,595 --> 04:20:15,595 because BIP-148 was successful. 3057 04:20:15,595 --> 04:20:16,595 I know, 3058 04:20:16,595 --> 04:20:17,595 but didn't we discuss 3059 04:20:17,595 --> 04:20:18,595 there was the SegWit2x... 3060 04:20:18,595 --> 04:20:19,595 There was a table 3061 04:20:19,595 --> 04:20:21,595 with people's opinions in SegWit. 3062 04:20:21,595 --> 04:20:23,595 And then SegWit had another quality 3063 04:20:23,595 --> 04:20:26,595 where other than the 4MB block size increase, 3064 04:20:26,595 --> 04:20:27,595 if you put that aside 3065 04:20:27,595 --> 04:20:29,595 so that we don't trip over that, 3066 04:20:29,595 --> 04:20:30,595 but other than that, 3067 04:20:30,595 --> 04:20:31,595 it basically just was like 3068 04:20:31,595 --> 04:20:32,595 a Pareto improvement 3069 04:20:32,595 --> 04:20:33,595 where it just said 3070 04:20:33,595 --> 04:20:34,595 you can do everything 3071 04:20:34,595 --> 04:20:35,595 you were doing before 3072 04:20:35,595 --> 04:20:37,595 plus you have this new option. 3073 04:20:37,595 --> 04:20:40,595 So it would be kind of bizarre 3074 04:20:40,595 --> 04:20:41,595 to go down the road 3075 04:20:41,595 --> 04:20:42,595 of opposing something like that 3076 04:20:42,595 --> 04:20:43,595 because you're just saying, 3077 04:20:43,595 --> 04:20:44,595 oh, we're just giving someone 3078 04:20:44,595 --> 04:20:46,595 another option for their transaction. 3079 04:20:46,595 --> 04:20:49,595 So these were things that SegWit had. 3080 04:20:49,595 --> 04:20:50,595 But you're saying 3081 04:20:50,595 --> 04:20:52,595 restricting is the difference? 3082 04:20:52,595 --> 04:20:53,595 Is a meaningful difference 3083 04:20:53,595 --> 04:20:54,595 versus expanding? 3084 04:20:54,595 --> 04:20:55,595 When you do the software 3085 04:20:55,595 --> 04:20:57,595 to add a new opcode, 3086 04:20:57,595 --> 04:20:59,595 you actually are adding something. 3087 04:20:59,595 --> 04:21:01,595 You're adding functionality. 3088 04:21:01,595 --> 04:21:02,595 So like, oh, 3089 04:21:02,595 --> 04:21:03,595 check lock time verify, 3090 04:21:03,595 --> 04:21:04,595 like Peter did. 3091 04:21:04,595 --> 04:21:06,595 It theoretically invalidates, 3092 04:21:06,595 --> 04:21:08,595 it theoretically shrinks some things, 3093 04:21:08,595 --> 04:21:10,595 but it actually, 3094 04:21:10,595 --> 04:21:13,595 since it takes the unused op-nop too, 3095 04:21:13,595 --> 04:21:14,595 I think. 3096 04:21:14,595 --> 04:21:15,595 It would be a weird progression 3097 04:21:15,595 --> 04:21:17,595 of like SegWit was a big change. 3098 04:21:17,595 --> 04:21:18,595 Tons of people liked it. 3099 04:21:18,595 --> 04:21:19,595 Companies built on it. 3100 04:21:19,595 --> 04:21:20,595 And then Taproot, 3101 04:21:20,595 --> 04:21:21,595 people were talking today 3102 04:21:21,595 --> 04:21:23,595 about Arc and all these Taproot things. 3103 04:21:23,595 --> 04:21:24,595 And then, you know, 3104 04:21:24,595 --> 04:21:25,595 and it takes forever, right? 3105 04:21:25,595 --> 04:21:26,595 It's like SegWit 2016 3106 04:21:26,595 --> 04:21:28,595 and then Taproot 2021. 3107 04:21:28,595 --> 04:21:30,595 And then the next one is BIP 110, 3108 04:21:30,595 --> 04:21:31,595 which is like, well, 3109 04:21:31,595 --> 04:21:32,595 it's kind of, 3110 04:21:32,595 --> 04:21:33,595 it's pretty different, right? 3111 04:21:33,595 --> 04:21:34,595 Like it doesn't enable as much. 3112 04:21:34,595 --> 04:21:35,595 Yeah, it's different 3113 04:21:35,595 --> 04:21:36,595 because it's the first time 3114 04:21:36,595 --> 04:21:37,595 in a long time 3115 04:21:37,595 --> 04:21:38,595 that we've done 3116 04:21:38,595 --> 04:21:40,595 a sort of defensive soft fork 3117 04:21:40,595 --> 04:21:44,595 that is basically rectifying 3118 04:21:44,595 --> 04:21:46,595 some unintended consequences 3119 04:21:46,595 --> 04:21:47,595 from previous soft forks, 3120 04:21:47,595 --> 04:21:49,595 namely SegWit and Taproot. 3121 04:21:49,595 --> 04:21:50,595 There have been forks like this 3122 04:21:51,595 --> 04:21:52,595 in the past, right? 3123 04:21:52,595 --> 04:21:54,595 There was a soft fork to eliminate the, 3124 04:21:54,595 --> 04:21:55,595 there was an emergency soft fork 3125 04:21:55,595 --> 04:21:57,595 to eliminate the inflation bug in 2010. 3126 04:21:57,595 --> 04:22:01,595 And there was also some hard fork 3127 04:22:01,595 --> 04:22:02,595 and soft fork stuff 3128 04:22:02,595 --> 04:22:04,595 around the 2013 accidental hard fork. 3129 04:22:04,595 --> 04:22:08,595 So let's just skim through this for a second. 3130 04:22:08,595 --> 04:22:09,595 So in this scenario 3131 04:22:09,595 --> 04:22:10,595 where you have 1% hash power 3132 04:22:10,595 --> 04:22:12,595 mining BIP 110, 3133 04:22:12,595 --> 04:22:14,595 let's just say hypothetically 3134 04:22:14,595 --> 04:22:16,595 that one day after that, 3135 04:22:16,595 --> 04:22:19,595 we have one day worth of blocks 3136 04:22:19,595 --> 04:22:21,595 on what we'll call the core chain, 3137 04:22:21,595 --> 04:22:24,595 which has 99% hash power at that point. 3138 04:22:24,595 --> 04:22:27,595 And then miners, you know, 3139 04:22:27,595 --> 04:22:28,595 quote unquote, wake up. 3140 04:22:28,595 --> 04:22:30,595 Now, hang on a second. 3141 04:22:30,595 --> 04:22:31,595 Why would it ever get that far? 3142 04:22:31,595 --> 04:22:32,595 Hang on a second. 3143 04:22:32,595 --> 04:22:33,595 They'd have to be asleep. 3144 04:22:33,595 --> 04:22:34,595 Hang on a second. 3145 04:22:34,595 --> 04:22:35,595 People sleep. 3146 04:22:35,595 --> 04:22:36,595 They can literally be asleep. 3147 04:22:36,595 --> 04:22:37,595 I mean, this is not a, 3148 04:22:37,595 --> 04:22:38,595 they're not sleeping. 3149 04:22:38,595 --> 04:22:39,595 They're talking, 3150 04:22:39,595 --> 04:22:40,595 the miners are talking about it. 3151 04:22:40,595 --> 04:22:41,595 You see mining disrupt, 3152 04:22:41,595 --> 04:22:42,595 they're all talking about it. 3153 04:22:42,595 --> 04:22:43,595 Hang on, just for a second, 3154 04:22:43,595 --> 04:22:44,595 let's just say 3155 04:22:44,595 --> 04:22:45,595 we wind up in that scenario. 3156 04:22:45,595 --> 04:22:47,595 I would argue very strongly 3157 04:22:47,595 --> 04:22:48,595 that the moment 3158 04:22:48,595 --> 04:22:52,595 the core chain comes out ahead, 3159 04:22:52,595 --> 04:22:54,595 there's very strong reasons 3160 04:22:54,595 --> 04:22:55,595 for people to say, 3161 04:22:55,595 --> 04:22:56,595 yeah, we're just going to 3162 04:22:56,595 --> 04:22:57,595 keep mining this 3163 04:22:57,595 --> 04:22:58,595 rather than have the PR disaster, 3164 04:22:58,595 --> 04:23:00,595 which is, you know, 3165 04:23:00,595 --> 04:23:01,595 100 blocks get wiped out. 3166 04:23:01,595 --> 04:23:02,595 That's crazy. 3167 04:23:02,595 --> 04:23:03,595 But why would you keep mining a chain 3168 04:23:03,595 --> 04:23:04,595 that might get wiped out? 3169 04:23:04,595 --> 04:23:05,595 All of your earnings are going to 3170 04:23:05,595 --> 04:23:06,595 disappear. 3171 04:23:06,595 --> 04:23:07,595 I mean, because you disagree 3172 04:23:07,595 --> 04:23:08,595 with that direction, 3173 04:23:08,595 --> 04:23:09,595 and then it looks like 3174 04:23:09,595 --> 04:23:10,595 it doesn't get wiped out, 3175 04:23:10,595 --> 04:23:11,595 and very quickly it's, 3176 04:23:11,595 --> 04:23:12,595 well, shit, we better not 3177 04:23:12,595 --> 04:23:13,595 wipe this out. 3178 04:23:13,595 --> 04:23:14,595 Yeah, but how do you trust 3179 04:23:14,595 --> 04:23:15,595 that all the other miners 3180 04:23:15,595 --> 04:23:16,595 aren't going to start moving over 3181 04:23:16,595 --> 04:23:17,595 because it's safer for them? 3182 04:23:17,595 --> 04:23:18,595 So you can collude 3183 04:23:18,595 --> 04:23:19,595 with the miners 3184 04:23:19,595 --> 04:23:20,595 to go and attack the node network? 3185 04:23:20,595 --> 04:23:21,595 Look, miners... 3186 04:23:21,595 --> 04:23:22,595 You can get your centralized 3187 04:23:22,595 --> 04:23:23,595 mining pool buddies... 3188 04:23:23,595 --> 04:23:24,595 Well, hang on, hang on, 3189 04:23:24,595 --> 04:23:25,595 you're saying miners 3190 04:23:25,595 --> 04:23:26,595 colluding to attack nodes, 3191 04:23:26,595 --> 04:23:27,595 but we've already established 3192 04:23:27,595 --> 04:23:28,595 that it seems like 3193 04:23:28,595 --> 04:23:29,595 the BIP110 nodes 3194 04:23:29,595 --> 04:23:30,595 are in the minority anyway. 3195 04:23:30,595 --> 04:23:31,595 I mean, it seems like 3196 04:23:31,595 --> 04:23:32,595 they're in the minority 3197 04:23:32,595 --> 04:23:33,595 in the technical community. 3198 04:23:33,595 --> 04:23:34,595 So, I mean, it is reasonable 3199 04:23:34,595 --> 04:23:35,595 to say they're in the minority. 3200 04:23:35,595 --> 04:23:36,595 Right, but again, 3201 04:23:36,595 --> 04:23:37,595 the same situation 3202 04:23:37,595 --> 04:23:38,595 happened with BIP148. 3203 04:23:38,595 --> 04:23:39,595 It was also a minority 3204 04:23:39,595 --> 04:23:40,595 and it also succeeded 3205 04:23:40,595 --> 04:23:41,595 in being a minority. 3206 04:23:41,595 --> 04:23:42,595 But it wasn't a minority. 3207 04:23:42,595 --> 04:23:43,595 BIP148, I was in rooms 3208 04:23:43,595 --> 04:23:44,595 where you could do hands. 3209 04:23:44,595 --> 04:23:45,595 We didn't bother to do hands 3210 04:23:45,595 --> 04:23:46,595 because every developer 3211 04:23:46,595 --> 04:23:47,595 other than... 3212 04:23:47,595 --> 04:23:48,595 Like, not every. 3213 04:23:48,595 --> 04:23:49,595 There were people 3214 04:23:49,595 --> 04:23:50,595 and this was sort of 3215 04:23:50,595 --> 04:23:51,595 the beginnings of Bitcoin Cash 3216 04:23:51,595 --> 04:23:52,595 because that did come 3217 04:23:52,595 --> 04:23:53,595 a year or two later. 3218 04:23:53,595 --> 04:23:54,595 But it ended up being 3219 04:23:54,595 --> 04:23:55,595 the same people 3220 04:23:55,595 --> 04:23:56,595 who did Bitcoin Cash. 3221 04:23:56,595 --> 04:23:57,595 But there were a few people 3222 04:23:57,595 --> 04:23:58,595 who were like, 3223 04:23:58,595 --> 04:23:59,595 no, I don't like this. 3224 04:23:59,595 --> 04:24:00,595 But it was pretty small. 3225 04:24:00,595 --> 04:24:01,595 Yeah. 3226 04:24:01,595 --> 04:24:02,595 In fact... 3227 04:24:02,595 --> 04:24:03,595 I mean, if you don't like it, 3228 04:24:03,595 --> 04:24:04,595 do a URSF. 3229 04:24:04,595 --> 04:24:05,595 Again, there's a clear 3230 04:24:05,595 --> 04:24:06,595 strategy for... 3231 04:24:06,595 --> 04:24:07,595 I don't think we're going 3232 04:24:07,595 --> 04:24:08,595 to do a URSF. 3233 04:24:08,595 --> 04:24:09,595 Do you guys think 3234 04:24:09,595 --> 04:24:10,595 that BIP110 is going to harm 3235 04:24:10,595 --> 04:24:11,595 Bitcoin? 3236 04:24:11,595 --> 04:24:12,595 Do you guys think 3237 04:24:12,595 --> 04:24:13,595 that BIP110 is going 3238 04:24:13,595 --> 04:24:14,595 to harm Bitcoin? 3239 04:24:14,595 --> 04:24:15,595 Yes, I do, yeah. 3240 04:24:15,595 --> 04:24:16,595 Why? 3241 04:24:16,595 --> 04:24:17,595 Because I think it's bad 3242 04:24:17,595 --> 04:24:18,595 to have nonsense 3243 04:24:18,595 --> 04:24:19,595 affect Bitcoin. 3244 04:24:20,595 --> 04:24:21,595 I don't know. 3245 04:24:21,595 --> 04:24:22,595 Wait. 3246 04:24:22,595 --> 04:24:23,595 How about we do... 3247 04:24:23,595 --> 04:24:24,595 These are the arguments 3248 04:24:24,595 --> 04:24:25,595 that we're dealing with. 3249 04:24:25,595 --> 04:24:26,595 This is our opposition. 3250 04:24:26,595 --> 04:24:27,595 How about we start 3251 04:24:27,595 --> 04:24:28,595 with just a poll. 3252 04:24:28,595 --> 04:24:29,595 Was Bitcoin Cash beneficial 3253 04:24:29,595 --> 04:24:30,595 to sort of Bitcoin 3254 04:24:30,595 --> 04:24:31,595 in the large sense? 3255 04:24:31,595 --> 04:24:32,595 What do you think? 3256 04:24:32,595 --> 04:24:33,595 I would actually say... 3257 04:24:33,595 --> 04:24:34,595 I don't think so. 3258 04:24:34,595 --> 04:24:35,595 Just like... 3259 04:24:35,595 --> 04:24:36,595 What's the question? 3260 04:24:36,595 --> 04:24:37,595 I missed the question. 3261 04:24:37,595 --> 04:24:38,595 Was Bitcoin Cash... 3262 04:24:38,595 --> 04:24:39,595 Was Bitcoin Cash, you know, 3263 04:24:39,595 --> 04:24:40,595 being developed, 3264 04:24:40,595 --> 04:24:41,595 splitting off from Bitcoin 3265 04:24:41,595 --> 04:24:42,595 or whatever we call it, 3266 04:24:42,595 --> 04:24:44,595 beneficial for both sides? 3267 04:24:44,595 --> 04:24:45,595 Well, can we say 3268 04:24:45,595 --> 04:24:46,595 compared to what? 3269 04:24:46,595 --> 04:24:47,595 Compared to not. 3270 04:24:47,595 --> 04:24:48,595 Compared to this, 3271 04:24:48,595 --> 04:24:49,595 they just didn't do it. 3272 04:24:49,595 --> 04:24:50,595 Compared to just staying 3273 04:24:50,595 --> 04:24:51,595 and continuing 3274 04:24:51,595 --> 04:24:52,595 to advocate for... 3275 04:24:52,595 --> 04:24:53,595 Sure, yeah. 3276 04:24:53,595 --> 04:24:54,595 I would say 3277 04:24:54,595 --> 04:24:55,595 that it is beneficial. 3278 04:24:55,595 --> 04:24:56,595 I mean, it kind of makes sense, right? 3279 04:24:56,595 --> 04:24:57,595 They wanted bigger blocks, 3280 04:24:57,595 --> 04:24:58,595 but they rejected SegWit, 3281 04:24:58,595 --> 04:24:59,595 which actually was bigger blocks, 3282 04:24:59,595 --> 04:25:00,595 which was, like, 3283 04:25:00,595 --> 04:25:01,595 just completely indefensible. 3284 04:25:01,595 --> 04:25:02,595 So, I guess, 3285 04:25:02,595 --> 04:25:03,595 what's interesting... 3286 04:25:03,595 --> 04:25:04,595 What I will say 3287 04:25:04,595 --> 04:25:05,595 is interesting about BIP110 3288 04:25:05,595 --> 04:25:06,595 is that it is 3289 04:25:06,595 --> 04:25:08,595 a potential minority 3290 04:25:08,595 --> 04:25:10,595 hash rate soft fork, 3291 04:25:10,595 --> 04:25:11,595 which has not been 3292 04:25:11,595 --> 04:25:12,595 attempted yet, right? 3293 04:25:12,595 --> 04:25:13,595 Because with Bitcoin Cash, 3294 04:25:13,595 --> 04:25:14,595 they said, 3295 04:25:14,595 --> 04:25:15,595 no, it's a soft fork 3296 04:25:15,595 --> 04:25:16,595 mainly because... 3297 04:25:16,595 --> 04:25:17,595 It's kind of weird. 3298 04:25:17,595 --> 04:25:18,595 They took the SegWit 3299 04:25:18,595 --> 04:25:19,595 SIG hashing stuff 3300 04:25:19,595 --> 04:25:20,595 and put it into theirs. 3301 04:25:20,595 --> 04:25:21,595 As the deadline approaches, 3302 04:25:21,595 --> 04:25:22,595 I don't expect it 3303 04:25:22,595 --> 04:25:23,595 to still be a minority. 3304 04:25:23,595 --> 04:25:24,595 Okay, so... 3305 04:25:24,595 --> 04:25:25,595 But that's, like, 3306 04:25:25,595 --> 04:25:26,595 what, a couple weeks, right? 3307 04:25:26,595 --> 04:25:27,595 So that's, like, real soon. 3308 04:25:27,595 --> 04:25:28,595 Okay, so... 3309 04:25:28,595 --> 04:25:29,595 So, we'll see. 3310 04:25:29,595 --> 04:25:31,595 So, we won't have to wait long. 3311 04:25:31,595 --> 04:25:32,595 But again, 3312 04:25:32,595 --> 04:25:33,595 if there's a whole bunch 3313 04:25:33,595 --> 04:25:34,595 of people who are 3314 04:25:34,595 --> 04:25:35,595 really, really for it 3315 04:25:35,595 --> 04:25:36,595 and nobody is strongly 3316 04:25:36,595 --> 04:25:37,595 against it, 3317 04:25:37,595 --> 04:25:38,595 that should activate. 3318 04:25:38,595 --> 04:25:39,595 And that's actually 3319 04:25:39,595 --> 04:25:40,595 how Bitcoin works. 3320 04:25:40,595 --> 04:25:41,595 Isn't everyone 3321 04:25:41,595 --> 04:25:42,595 strongly against it? 3322 04:25:42,595 --> 04:25:43,595 No, nobody is 3323 04:25:43,595 --> 04:25:44,595 strongly against it. 3324 04:25:44,595 --> 04:25:45,595 Right now, if people run... 3325 04:25:45,595 --> 04:25:46,595 Then write a URSF. 3326 04:25:46,595 --> 04:25:47,595 Right now, 3327 04:25:47,595 --> 04:25:48,595 if people run a client 3328 04:25:48,595 --> 04:25:49,595 that does not signal, 3329 04:25:49,595 --> 04:25:50,595 they just won't signal 3330 04:25:50,595 --> 04:25:51,595 on August 8th 3331 04:25:51,595 --> 04:25:52,595 or whatever it is. 3332 04:25:52,595 --> 04:25:53,595 So, isn't that... 3333 04:25:53,595 --> 04:25:54,595 You will fork off of that? 3334 04:25:54,595 --> 04:25:55,595 If someone mines blocks 3335 04:25:55,595 --> 04:25:56,595 on those networks, 3336 04:25:56,595 --> 04:25:57,595 that will be the fork. 3337 04:25:57,595 --> 04:25:58,595 So, that is the URSF. 3338 04:25:58,595 --> 04:25:59,595 If that has majority hash rate 3339 04:25:59,595 --> 04:26:00,595 and is not... 3340 04:26:00,595 --> 04:26:01,595 That's not a URSF. 3341 04:26:01,595 --> 04:26:02,595 So, a URSF is different 3342 04:26:02,595 --> 04:26:03,595 because you have 3343 04:26:03,595 --> 04:26:04,595 to coordinate around 3344 04:26:04,595 --> 04:26:05,595 how to reject 3345 04:26:05,595 --> 04:26:06,595 the soft fork. 3346 04:26:06,595 --> 04:26:07,595 So, you have to coordinate 3347 04:26:07,595 --> 04:26:08,595 around how to reject 3348 04:26:08,595 --> 04:26:09,595 the soft fork. 3349 04:26:09,595 --> 04:26:10,595 So, you have to coordinate 3350 04:26:10,595 --> 04:26:11,595 around how to reject 3351 04:26:11,595 --> 04:26:12,595 the soft fork. 3352 04:26:12,595 --> 04:26:13,595 If you don't do that, 3353 04:26:13,595 --> 04:26:14,595 the legacy chain 3354 04:26:14,595 --> 04:26:15,595 becomes incoherent 3355 04:26:15,595 --> 04:26:16,595 because it might just 3356 04:26:16,595 --> 04:26:17,595 continue disappearing. 3357 04:26:17,595 --> 04:26:18,595 It might get wiped out 3358 04:26:18,595 --> 04:26:19,595 a bunch of times. 3359 04:26:19,595 --> 04:26:20,595 One second. 3360 04:26:20,595 --> 04:26:21,595 Just for the audience, 3361 04:26:21,595 --> 04:26:22,595 let me just make sure 3362 04:26:22,595 --> 04:26:23,595 people realize 3363 04:26:23,595 --> 04:26:24,595 what the heck 3364 04:26:24,595 --> 04:26:25,595 you're talking about. 3365 04:26:25,595 --> 04:26:26,595 You're talking about 3366 04:26:26,595 --> 04:26:27,595 a user-rejected soft fork 3367 04:26:27,595 --> 04:26:28,595 where people decide 3368 04:26:28,595 --> 04:26:29,595 to come up with 3369 04:26:29,595 --> 04:26:30,595 some way of rejecting it. 3370 04:26:30,595 --> 04:26:31,595 One of the simplest 3371 04:26:31,595 --> 04:26:32,595 technical possibilities 3372 04:26:32,595 --> 04:26:33,595 is simply miners 3373 04:26:33,595 --> 04:26:34,595 and users 3374 04:26:34,595 --> 04:26:35,595 maybe some exchanges 3375 04:26:35,595 --> 04:26:36,595 just run the command 3376 04:26:36,595 --> 04:26:37,595 and validate block 3377 04:26:37,595 --> 04:26:38,595 on a block 3378 04:26:38,595 --> 04:26:39,595 in the BIP110 chain. 3379 04:26:39,595 --> 04:26:40,595 Simple as that. 3380 04:26:40,595 --> 04:26:41,595 Just to make sure 3381 04:26:41,595 --> 04:26:42,595 that even if it 3382 04:26:42,595 --> 04:26:43,595 somehow comes out ahead... 3383 04:26:43,595 --> 04:26:44,595 Right, so a few 3384 04:26:44,595 --> 04:26:45,595 large mining pools 3385 04:26:45,595 --> 04:26:46,595 decide that 3386 04:26:46,595 --> 04:26:47,595 the decentralized 3387 04:26:47,595 --> 04:26:48,595 node network 3388 04:26:48,595 --> 04:26:49,595 of BIP110 runners 3389 04:26:49,595 --> 04:26:50,595 the 15,000 3390 04:26:50,595 --> 04:26:51,595 plebs out there 3391 04:26:51,595 --> 04:26:52,595 that want to protect 3392 04:26:52,595 --> 04:26:53,595 Bitcoin's monetary purpose 3393 04:26:53,595 --> 04:26:54,595 that they're wrong 3394 04:26:54,595 --> 04:26:55,595 and those five 3395 04:26:55,595 --> 04:26:56,595 large mining nodes 3396 04:26:56,595 --> 04:26:57,595 are actually 3397 04:26:57,595 --> 04:26:58,595 in control of the network. 3398 04:26:58,595 --> 04:26:59,595 I hate to say this 3399 04:26:59,595 --> 04:27:00,595 but again, 3400 04:27:00,595 --> 04:27:01,595 this bit about 3401 04:27:01,595 --> 04:27:02,595 say 15,000 3402 04:27:02,595 --> 04:27:03,595 agreeing with BIP110 3403 04:27:03,595 --> 04:27:04,595 that sounds like 3404 04:27:04,595 --> 04:27:05,595 minority to me. 3405 04:27:05,595 --> 04:27:06,595 Everything I've seen 3406 04:27:06,595 --> 04:27:07,595 going to conferences 3407 04:27:07,595 --> 04:27:08,595 and all this 3408 04:27:08,595 --> 04:27:09,595 is they're actually 3409 04:27:09,595 --> 04:27:10,595 in control of the network. 3410 04:27:10,595 --> 04:27:11,595 If you have an 3411 04:27:11,595 --> 04:27:12,595 enthusiastic minority 3412 04:27:12,595 --> 04:27:13,595 that wants a change 3413 04:27:13,595 --> 04:27:14,595 and you have no 3414 04:27:14,595 --> 04:27:15,595 serious opposition 3415 04:27:15,595 --> 04:27:16,595 then the change 3416 04:27:16,595 --> 04:27:17,595 is happening. 3417 04:27:17,595 --> 04:27:18,595 There isn't any 3418 04:27:18,595 --> 04:27:19,595 serious opposition. 3419 04:27:19,595 --> 04:27:20,595 There's no URSF. 3420 04:27:20,595 --> 04:27:21,595 There is no 3421 04:27:21,595 --> 04:27:22,595 meaningful attempt 3422 04:27:22,595 --> 04:27:23,595 to resist this. 3423 04:27:23,595 --> 04:27:24,595 It feels like 3424 04:27:24,595 --> 04:27:25,595 Bitcoin Cash 3425 04:27:25,595 --> 04:27:26,595 was an enthusiastic 3426 04:27:26,595 --> 04:27:27,595 minority. 3427 04:27:27,595 --> 04:27:28,595 It just feels a lot 3428 04:27:28,595 --> 04:27:29,595 like 2017. 3429 04:27:29,595 --> 04:27:30,595 It just feels 3430 04:27:30,595 --> 04:27:31,595 a lot like that. 3431 04:27:31,595 --> 04:27:32,595 What do you mean 3432 04:27:32,595 --> 04:27:33,595 Bitcoin Cash 3433 04:27:33,595 --> 04:27:34,595 was an enthusiastic 3434 04:27:34,595 --> 04:27:35,595 minority? 3435 04:27:35,595 --> 04:27:36,595 Oh, they were trying 3436 04:27:36,595 --> 04:27:37,595 to hard fork Bitcoin. 3437 04:27:37,595 --> 04:27:38,595 That is a completely 3438 04:27:38,595 --> 04:27:39,595 different situation. 3439 04:27:39,595 --> 04:27:40,595 What's the difference? 3440 04:27:40,595 --> 04:27:41,595 Let me revise. 3441 04:27:41,595 --> 04:27:42,595 If an enthusiastic 3442 04:27:42,595 --> 04:27:43,595 minority wants to 3443 04:27:43,595 --> 04:27:44,595 restrict Bitcoin's 3444 04:27:44,595 --> 04:27:45,595 rules in a way 3445 04:27:45,595 --> 04:27:46,595 that nobody 3446 04:27:46,595 --> 04:27:47,595 actually thinks 3447 04:27:47,595 --> 04:27:48,595 is going to 3448 04:27:48,595 --> 04:27:49,595 harm Bitcoin 3449 04:27:49,595 --> 04:27:50,595 they should be able 3450 04:27:50,595 --> 04:27:51,595 to do that. 3451 04:27:51,595 --> 04:27:52,595 If somebody thinks 3452 04:27:52,595 --> 04:27:53,595 it's going to 3453 04:27:53,595 --> 04:27:54,595 harm Bitcoin 3454 04:27:54,595 --> 04:27:55,595 they have to 3455 04:27:55,595 --> 04:27:56,595 URSF. 3456 04:27:56,595 --> 04:27:57,595 Otherwise, 3457 04:27:57,595 --> 04:27:58,595 there's no defense. 3458 04:27:58,595 --> 04:27:59,595 If it's a hard fork 3459 04:27:59,595 --> 04:28:00,595 that's a completely 3460 04:28:00,595 --> 04:28:01,595 different situation. 3461 04:28:01,595 --> 04:28:02,595 Restricting Bitcoin's 3462 04:28:02,595 --> 04:28:03,595 rules in a way 3463 04:28:03,595 --> 04:28:04,595 that people don't 3464 04:28:04,595 --> 04:28:05,595 think will seriously 3465 04:28:05,595 --> 04:28:06,595 harm Bitcoin 3466 04:28:06,595 --> 04:28:07,595 but without a good 3467 04:28:07,595 --> 04:28:08,595 reason, 3468 04:28:08,595 --> 04:28:09,595 that doesn't 3469 04:28:09,595 --> 04:28:10,595 make it a 3470 04:28:10,595 --> 04:28:11,595 harm to Bitcoin. 3471 04:28:11,595 --> 04:28:12,595 Especially for this 3472 04:28:12,595 --> 04:28:13,595 kind of reason, 3473 04:28:13,595 --> 04:28:14,595 it's a social 3474 04:28:14,595 --> 04:28:15,595 precedent thing 3475 04:28:15,595 --> 04:28:16,595 that itself is 3476 04:28:16,595 --> 04:28:17,595 really ugly. 3477 04:28:17,595 --> 04:28:18,595 We actually did 3478 04:28:18,595 --> 04:28:19,595 rock, paper, scissors 3479 04:28:19,595 --> 04:28:20,595 and the person 3480 04:28:20,595 --> 04:28:21,595 next to me 3481 04:28:21,595 --> 04:28:22,595 asked the question 3482 04:28:22,595 --> 04:28:23,595 and I was going 3483 04:28:23,595 --> 04:28:24,595 to ask you 3484 04:28:24,595 --> 04:28:25,595 in the previous 3485 04:28:25,595 --> 04:28:26,595 talk was 3486 04:28:26,595 --> 04:28:27,595 let's say 3487 04:28:27,595 --> 04:28:28,595 that Bitcoin 3488 04:28:28,595 --> 04:28:29,595 Core had 3489 04:28:29,595 --> 04:28:30,595 in fact 3490 04:28:30,595 --> 04:28:31,595 responded to 3491 04:28:31,595 --> 04:28:32,595 inscriptions 3492 04:28:32,595 --> 04:28:33,595 by trying to 3493 04:28:33,595 --> 04:28:34,595 go filter them. 3494 04:28:34,595 --> 04:28:35,595 Probably what 3495 04:28:35,595 --> 04:28:36,595 inscriptions would 3496 04:28:36,595 --> 04:28:37,595 do is 3497 04:28:37,595 --> 04:28:38,595 go to 3498 04:28:38,595 --> 04:28:39,595 Bitcoin 3499 04:28:39,595 --> 04:28:40,595 Core to 3500 04:28:40,595 --> 04:28:41,595 just keep 3501 04:28:41,595 --> 04:28:42,595 on... 3502 04:28:42,595 --> 04:28:43,595 Spammers never 3503 04:28:43,595 --> 04:28:44,595 did that. 3504 04:28:44,595 --> 04:28:45,595 But we never 3505 04:28:45,595 --> 04:28:46,595 went down that 3506 04:28:46,595 --> 04:28:47,595 path. 3507 04:28:47,595 --> 04:28:48,595 The reason 3508 04:28:48,595 --> 04:28:49,595 why 3509 04:28:49,595 --> 04:28:50,595 inscriptions 3510 04:28:50,595 --> 04:28:51,595 became a 3511 04:28:51,595 --> 04:28:52,595 phenomenon 3512 04:28:52,595 --> 04:28:53,595 is because 3513 04:28:53,595 --> 04:28:54,595 there was a 3514 04:28:54,595 --> 04:28:55,595 shelling point 3515 04:28:55,595 --> 04:28:56,595 that formed 3516 04:28:56,595 --> 04:28:57,595 around that 3517 04:28:57,595 --> 04:28:58,595 particular 3518 04:28:58,595 --> 04:28:59,595 format. 3519 04:28:59,595 --> 04:29:00,595 But they 3520 04:29:00,595 --> 04:29:01,595 changed it 3521 04:29:01,595 --> 04:29:02,595 multiple times 3522 04:29:02,595 --> 04:29:03,595 for various 3523 04:29:03,595 --> 04:29:04,595 reasons. 3524 04:29:04,595 --> 04:29:05,595 There's a 3525 04:29:05,595 --> 04:29:06,595 lot of 3526 04:29:06,595 --> 04:29:07,595 people 3527 04:29:07,595 --> 04:29:08,595 who 3528 04:29:08,595 --> 04:29:09,595 are 3529 04:29:09,595 --> 04:29:10,595 trying to 3530 04:29:10,595 --> 04:29:11,595 get 3531 04:29:11,595 --> 04:29:12,595 their money 3532 04:29:12,595 --> 04:29:13,595 off of 3533 04:29:13,595 --> 04:29:14,595 Bitcoin 3534 04:29:14,595 --> 04:29:15,595 Core. 3535 04:29:15,595 --> 04:29:16,595 But 3536 04:29:16,595 --> 04:29:17,595 there was 3537 04:29:17,595 --> 04:29:18,595 never a 3538 04:29:18,595 --> 04:29:19,595 serious 3539 04:29:19,595 --> 04:29:20,595 attempt 3540 04:29:20,595 --> 04:29:21,595 by 3541 04:29:21,595 --> 04:29:22,595 Core to 3542 04:29:22,595 --> 04:29:23,595 actually 3543 04:29:23,595 --> 04:29:24,595 counter it. 3544 04:29:24,595 --> 04:29:25,595 But 3545 04:29:25,595 --> 04:29:26,595 obviously 3546 04:29:26,595 --> 04:29:27,595 if 3547 04:29:27,595 --> 04:29:28,595 Core had 3548 04:29:28,595 --> 04:29:29,595 it 3549 04:29:29,595 --> 04:29:30,595 would have 3550 04:29:30,595 --> 04:29:31,595 been... 3551 04:29:31,595 --> 04:29:32,595 We have 3552 04:29:32,595 --> 04:29:33,595 historical 3553 04:29:33,595 --> 04:29:34,595 precedent 3554 04:29:34,595 --> 04:29:35,595 that 3555 04:29:35,595 --> 04:29:36,595 there 3556 04:29:36,595 --> 04:29:37,595 was a 3557 04:29:37,595 --> 04:29:38,595 degree of 3558 04:29:38,595 --> 04:29:39,595 programmable 3559 04:29:39,595 --> 04:29:40,595 money that 3560 04:29:40,595 --> 04:29:41,595 was never 3561 04:29:41,595 --> 04:29:42,595 suitable to 3562 04:29:42,595 --> 04:29:43,595 put on 3563 04:29:43,595 --> 04:29:44,595 Bitcoin. 3564 04:29:44,595 --> 04:29:45,595 Ethereum is 3565 04:29:45,595 --> 04:29:46,595 very different. 3566 04:29:46,595 --> 04:29:47,595 Inscriptions don't 3567 04:29:47,595 --> 04:29:48,595 have 3568 04:29:48,595 --> 04:29:49,595 programmability. 3569 04:29:49,595 --> 04:29:50,595 They're just 3570 04:29:50,595 --> 04:29:51,595 pure assets. 3571 04:29:51,595 --> 04:29:52,595 They're pure 3572 04:29:52,595 --> 04:29:53,595 collectible 3573 04:29:53,595 --> 04:29:54,595 assets. 3574 04:29:54,595 --> 04:29:55,595 Don't give 3575 04:29:55,595 --> 04:29:56,595 them any 3576 04:29:56,595 --> 04:29:57,595 ideas. 3577 04:29:57,595 --> 04:29:58,595 It's a 3578 04:29:58,595 --> 04:29:59,595 different 3579 04:29:59,595 --> 04:30:00,595 problem. 3580 04:30:00,595 --> 04:30:01,595 It seems 3581 04:30:01,595 --> 04:30:02,595 like we all 3582 04:30:02,595 --> 04:30:03,595 agree that 3583 04:30:03,595 --> 04:30:04,595 if Bitcoin 3584 04:30:04,595 --> 04:30:05,595 had a 3585 04:30:05,595 --> 04:30:06,595 higher 3586 04:30:06,595 --> 04:30:07,595 hash rate 3587 04:30:07,595 --> 04:30:08,595 then that 3588 04:30:08,595 --> 04:30:09,595 would be 3589 04:30:09,595 --> 04:30:10,595 basically a 3590 04:30:10,595 --> 04:30:11,595 loss for 3591 04:30:11,595 --> 04:30:12,595 110. 3592 04:30:12,595 --> 04:30:13,595 You seem to 3593 04:30:13,595 --> 04:30:14,595 be saying 3594 04:30:14,595 --> 04:30:15,595 they will 3595 04:30:15,595 --> 04:30:16,595 come around. 3596 04:30:16,595 --> 04:30:17,595 We don't 3597 04:30:17,595 --> 04:30:18,595 have them 3598 04:30:18,595 --> 04:30:19,595 now but 3599 04:30:19,595 --> 04:30:20,595 they'll 3600 04:30:20,595 --> 04:30:21,595 come 3601 04:30:21,595 --> 04:30:22,595 around. 3602 04:30:22,595 --> 04:30:23,595 Is that 3603 04:30:23,595 --> 04:30:24,595 right? 3604 04:30:24,595 --> 04:30:25,595 It would 3605 04:30:25,595 --> 04:30:26,595 be much 3606 04:30:26,595 --> 04:30:27,595 more of a 3607 04:30:27,595 --> 04:30:28,595 loss for 3608 04:30:28,595 --> 04:30:29,595 the 3609 04:30:29,595 --> 04:30:30,595 miners. 3610 04:30:30,595 --> 04:30:31,595 The 3611 04:30:31,595 --> 04:30:32,595 miners need 3612 04:30:32,595 --> 04:30:33,595 to be 3613 04:30:33,595 --> 04:30:34,595 able to 3614 04:30:34,595 --> 04:30:35,595 collect 3615 04:30:35,595 --> 04:30:36,595 their 3616 04:30:36,595 --> 04:30:37,595 assets. 3617 04:30:37,595 --> 04:30:38,595 I mean 3618 04:30:38,595 --> 04:30:39,595 there's no 3619 04:30:39,595 --> 04:30:40,595 replay. 3620 04:30:40,595 --> 04:30:41,595 There's no 3621 04:30:41,595 --> 04:30:42,595 replay. 3622 04:30:42,595 --> 04:30:43,595 There's no 3623 04:30:43,595 --> 04:30:44,595 replay protection. 3624 04:30:44,595 --> 04:30:45,595 Replay 3625 04:30:45,595 --> 04:30:46,595 protection, 3626 04:30:46,595 --> 04:30:47,595 I guess, 3627 04:30:47,595 --> 04:30:48,595 in this 3628 04:30:48,595 --> 04:30:49,595 scenario, 3629 04:30:49,595 --> 04:30:50,595 if there 3630 04:30:50,595 --> 04:30:51,595 is a 3631 04:30:51,595 --> 04:30:52,595 split, 3632 04:30:52,595 --> 04:30:53,595 would be 3633 04:30:53,595 --> 04:30:54,595 on the 3634 04:30:54,595 --> 04:30:55,595 core 3635 04:30:55,595 --> 04:30:56,595 v30 3636 04:30:56,595 --> 04:30:57,595 side to 3637 04:30:57,595 --> 04:30:58,595 put a 3638 04:30:58,595 --> 04:30:59,595 big 3639 04:30:59,595 --> 04:31:00,595 opportune 3640 04:31:00,595 --> 04:31:01,595 in every 3641 04:31:01,595 --> 04:31:02,595 case. 3642 04:31:02,595 --> 04:31:03,595 If it has 3643 04:31:03,595 --> 04:31:04,595 majority 3644 04:31:04,595 --> 04:31:05,595 hash rate. 3645 04:31:05,595 --> 04:31:06,595 If there's 3646 04:31:06,595 --> 04:31:07,595 a minority 3647 04:31:07,595 --> 04:31:08,595 hash rate. 3648 04:31:08,595 --> 04:31:09,595 There's 3649 04:31:09,595 --> 04:31:10,595 very strong 3650 04:31:10,595 --> 04:31:11,595 incentives for 3651 04:31:11,595 --> 04:31:12,595 that. 3652 04:31:12,595 --> 04:31:13,595 Everything hinges 3653 04:31:13,595 --> 04:31:14,595 on that. 3654 04:31:14,595 --> 04:31:15,595 It becomes a 3655 04:31:15,595 --> 04:31:16,595 self-fulfilling 3656 04:31:16,595 --> 04:31:17,595 property. 3657 04:31:17,595 --> 04:31:18,595 You have a 3658 04:31:18,595 --> 04:31:19,595 little bit 3659 04:31:19,595 --> 04:31:20,595 of hash 3660 04:31:20,595 --> 04:31:21,595 rate. 3661 04:31:21,595 --> 04:31:22,595 Why not 3662 04:31:22,595 --> 04:31:23,595 have a 3663 04:31:23,595 --> 04:31:24,595 signaling 3664 04:31:24,595 --> 04:31:25,595 that requires 3665 04:31:25,595 --> 04:31:26,595 90% 3666 04:31:26,595 --> 04:31:27,595 like all 3667 04:31:27,595 --> 04:31:28,595 the other 3668 04:31:28,595 --> 04:31:29,595 soft forks 3669 04:31:29,595 --> 04:31:30,595 have? 3670 04:31:30,595 --> 04:31:31,595 Those were 3671 04:31:31,595 --> 04:31:32,595 minor 3672 04:31:32,595 --> 04:31:33,595 vetoable 3673 04:31:33,595 --> 04:31:34,595 forks. 3674 04:31:34,595 --> 04:31:35,595 That's 3675 04:31:35,595 --> 04:31:36,595 one 3676 04:31:36,595 --> 04:31:37,595 philosophy. 3677 04:31:37,595 --> 04:31:38,595 Yours is 3678 04:31:38,595 --> 04:31:39,595 also 3679 04:31:39,595 --> 04:31:40,595 minor 3680 04:31:40,595 --> 04:31:41,595 vetoable, 3681 04:31:41,595 --> 04:31:42,595 right? 3682 04:31:42,595 --> 04:31:43,595 Isn't that 3683 04:31:43,595 --> 04:31:44,595 what you 3684 04:31:44,595 --> 04:31:45,595 said a 3685 04:31:45,595 --> 04:31:46,595 moment ago? 3686 04:31:46,595 --> 04:31:47,595 It's not. 3687 04:31:47,595 --> 04:31:48,595 It activates 3688 04:31:48,595 --> 04:31:49,595 regardless of 3689 04:31:49,595 --> 04:31:50,595 whether there's 3690 04:31:50,595 --> 04:31:51,595 any hash 3691 04:31:51,595 --> 04:31:52,595 rate. 3692 04:31:52,595 --> 04:31:53,595 It looks 3693 04:31:53,595 --> 04:31:54,595 like BIP 3694 04:31:54,595 --> 04:31:55,595 110 is 3695 04:31:55,595 --> 04:31:56,595 in the 3696 04:31:56,595 --> 04:31:57,595 minority 3697 04:31:57,595 --> 04:31:58,595 in terms 3698 04:31:58,595 --> 04:31:59,595 of people 3699 04:31:59,595 --> 04:32:00,595 voting 3700 04:32:00,595 --> 04:32:01,595 for it. 3701 04:32:01,595 --> 04:32:02,595 It's 3702 04:32:02,595 --> 04:32:03,595 going to 3703 04:32:03,595 --> 04:32:04,595 become the 3704 04:32:04,595 --> 04:32:05,595 majority. 3705 04:32:05,595 --> 04:32:06,595 The same 3706 04:32:06,595 --> 04:32:07,595 way that 3707 04:32:07,595 --> 04:32:08,595 mandatory 3708 04:32:08,595 --> 04:32:09,595 signaling 3709 04:32:09,595 --> 04:32:10,595 in BIP 3710 04:32:10,595 --> 04:32:11,595 148 3711 04:32:11,595 --> 04:32:12,595 was 100% 3712 04:32:12,595 --> 04:32:13,595 signaling 3713 04:32:13,595 --> 04:32:14,595 after 3714 04:32:14,595 --> 04:32:15,595 August 1st. 3715 04:32:15,595 --> 04:32:16,595 The 3716 04:32:16,595 --> 04:32:17,595 majority 3717 04:32:17,595 --> 04:32:18,595 liked 3718 04:32:18,595 --> 04:32:19,595 SegWit. 3719 04:32:19,595 --> 04:32:20,595 They 3720 04:32:20,595 --> 04:32:21,595 thought it 3721 04:32:21,595 --> 04:32:22,595 was a 3722 04:32:22,595 --> 04:32:23,595 great 3723 04:32:23,595 --> 04:32:24,595 idea. 3724 04:32:24,595 --> 04:32:25,595 The 3725 04:32:25,595 --> 04:32:26,595 majority 3726 04:32:26,595 --> 04:32:27,595 did not 3727 04:32:27,595 --> 04:32:28,595 like SegWit 3728 04:32:28,595 --> 04:32:29,595 unless 3729 04:32:29,595 --> 04:32:30,595 you have 3730 04:32:30,595 --> 04:32:31,595 majority 3731 04:32:31,595 --> 04:32:32,595 mining 3732 04:32:32,595 --> 04:32:33,595 support. 3733 04:32:33,595 --> 04:32:34,595 You are 3734 04:32:34,595 --> 04:32:35,595 saying we 3735 04:32:35,595 --> 04:32:36,595 will activate 3736 04:32:36,595 --> 04:32:37,595 with a 3737 04:32:37,595 --> 04:32:38,595 minority hash 3738 04:32:38,595 --> 04:32:39,595 rate. 3739 04:32:39,595 --> 04:32:40,595 We hope we 3740 04:32:40,595 --> 04:32:41,595 don't. 3741 04:32:41,595 --> 04:32:42,595 You hope it 3742 04:32:42,595 --> 04:32:43,595 is the 3743 04:32:43,595 --> 04:32:44,595 majority 3744 04:32:44,595 --> 04:32:45,595 hash rate. 3745 04:32:45,595 --> 04:32:46,595 You are 3746 04:32:46,595 --> 04:32:47,595 saying it's 3747 04:32:47,595 --> 04:32:48,595 in the 3748 04:32:48,595 --> 04:32:49,595 code. 3749 04:32:49,595 --> 04:32:49,742 If we 3750 04:32:49,742 --> 04:32:55,862 enforce this rule. You explicitly are saying we will still enforce this rule with minority 3751 04:32:55,862 --> 04:33:02,622 hash rate. Right. The BIP 110 chain is Bitcoin. It's going to be the same as the SegWit chain 3752 04:33:02,622 --> 04:33:10,782 because it has the same mechanism. In order to avoid activating BIP 110, whoever is against 3753 04:33:10,782 --> 04:33:18,782 it is going to have to fork off. Let's say hypothetically that SegWit had in fact ended up 3754 04:33:18,782 --> 04:33:24,242 activating from the perspective of people running SegWit nodes with minority hash rate. That is 3755 04:33:24,242 --> 04:33:30,162 really the scenario I think we're trying to get at here. Say that again? There is a scenario 3756 04:33:30,162 --> 04:33:37,582 where SegWit could have activated with minority hash rate but majority node support. SegWit had 3757 04:33:37,582 --> 04:33:46,122 20 or 30% leading up to the UASF. Core would not have followed that. There was a UASF. I never 3758 04:33:46,122 --> 04:33:51,962 ran any software that would have gone on. I want to talk about replay protection real quick. In 3759 04:33:51,962 --> 04:33:57,342 this case you are saying this is Bitcoin. There will be no fork. There will be no split. There is 3760 04:33:57,342 --> 04:34:06,122 no replay. Although two op returns is a good idea because that's smaller. In the BIP 300, there is 3761 04:34:06,162 --> 04:34:11,422 a fork. There is sort of replay protection. You can opt into it. By default, there is not. By 3762 04:34:11,422 --> 04:34:16,282 default, if you are indifferent, then I say you haven't picked a side, which is fine, but your 3763 04:34:16,282 --> 04:34:24,582 transaction will be on both chains. You may lose out on the e-cash part if maybe that doesn't 3764 04:34:24,582 --> 04:34:29,882 matter to people if they are indifferent. If you wish, you can make a special transaction that 3765 04:34:29,882 --> 04:34:34,122 splits them permanently and then there are other ways of splitting. 3766 04:34:34,122 --> 04:34:38,122 What is the simplest possible transaction that would achieve that? 3767 04:34:38,122 --> 04:34:43,242 We changed it so the end lock time, if you do one less than the 500 year one or something, it's 3768 04:34:43,242 --> 04:34:49,742 like maybe 1,000 years or something. I'm not sure. That one will be mysteriously valid on e-cash 3769 04:34:49,742 --> 04:34:55,542 immediately. That will just cut the rule and return true for that one. That is the way. That is 3770 04:34:55,542 --> 04:34:59,582 the easiest way. We have an arbitrary backdoor. 3771 04:34:59,582 --> 04:35:04,202 You have to make a transaction on the e-cash side that won't be replayed on the Bitcoin side. 3772 04:35:04,202 --> 04:35:10,702 You couldn't make one. You can't really make a Bitcoin one that won't be replayed on... 3773 04:35:10,702 --> 04:35:14,582 I'm sure it must be theoretically possible, but I wouldn't say that would be the way to do it. 3774 04:35:14,582 --> 04:35:18,582 You would anticipate then there is going to be trading between these different things. 3775 04:35:18,582 --> 04:35:20,082 Absolutely. Of course. Yes. 3776 04:35:20,082 --> 04:35:21,582 But it is still SHA-2. 3777 04:35:21,582 --> 04:35:23,582 SHA-2 with D6D, yes. 3778 04:35:24,582 --> 04:35:30,582 I have a question for you guys. If and when BIP-110 gets 100% signaling and it looks like 3779 04:35:30,582 --> 04:35:37,582 it's definitely going to succeed, will you hard fork like the B-cashers to reject BIP-110? 3780 04:35:37,582 --> 04:35:42,582 No, it's temporary, right? So it's all good. 3781 04:35:42,582 --> 04:35:43,582 Right? 3782 04:35:43,582 --> 04:35:44,582 I don't understand. 3783 04:35:44,582 --> 04:35:46,582 Totally common sense and harmless. 3784 04:35:46,582 --> 04:35:50,582 If it actually got 100%, that would be an interesting discussion. 3785 04:35:50,582 --> 04:35:57,582 If, however, it gets, say, 50%, then this is a curious thing. 3786 04:35:57,582 --> 04:35:59,582 And if it gets, say, 5%... 3787 04:35:59,582 --> 04:36:00,582 Why would Binary do that? 3788 04:36:00,582 --> 04:36:01,582 Hang on. Hang on. 3789 04:36:01,582 --> 04:36:06,582 If it gets less, then maybe there's some discussion. 3790 04:36:06,582 --> 04:36:11,582 But I suspect if it gets 100%, it would say, yeah, you guys won. 3791 04:36:11,582 --> 04:36:18,582 I mean, I personally would not change any of my transactions, because I don't make inscriptions or... 3792 04:36:18,582 --> 04:36:25,582 But the tree depth, that's kind of like, ooh, I don't want that. 3793 04:36:25,582 --> 04:36:28,582 Okay, but you can have it once BIP-110 expires. 3794 04:36:28,582 --> 04:36:32,582 If this happens, I would be a lot less interested in working on Bitcoin further, 3795 04:36:32,582 --> 04:36:37,582 because what this would tell me is that the Bitcoin community and miners are fucking crazy 3796 04:36:37,582 --> 04:36:40,582 and are willing to go and do things that are a bad idea. 3797 04:36:40,582 --> 04:36:41,582 I agree completely with that. 3798 04:36:41,582 --> 04:36:45,582 But if Bitcoin Core just does its job and filters spam, then none of this has to happen. 3799 04:36:45,582 --> 04:36:49,582 Well, look, we fundamentally disagree on how technically feasible that is. 3800 04:36:49,582 --> 04:36:55,582 He said it in his talk that you said that there's no way to stop the spam. 3801 04:36:55,582 --> 04:36:58,582 You said it's a straw man and stuff. 3802 04:36:58,582 --> 04:37:00,582 No, you can't stop spam. 3803 04:37:00,582 --> 04:37:04,582 But they constantly equivocate on this basic point that is at the heart of the matter. 3804 04:37:04,582 --> 04:37:06,582 They say, oh, sure, we can't do it. 3805 04:37:06,582 --> 04:37:08,582 We are completely powerless to stop spam. 3806 04:37:08,582 --> 04:37:10,582 I didn't say completely powerless. 3807 04:37:10,582 --> 04:37:11,582 You're just making that up. 3808 04:37:11,582 --> 04:37:14,582 It's like saying, can you stop people from breaking into your house? 3809 04:37:14,582 --> 04:37:15,582 Well, of course not. 3810 04:37:15,582 --> 04:37:17,582 But are you just going to get rid of your door and your fence? 3811 04:37:17,582 --> 04:37:19,582 In practice, I have stopped people. 3812 04:37:19,582 --> 04:37:21,582 No one has broken into my house. 3813 04:37:21,582 --> 04:37:25,582 Okay, but you just get rid of your door and your fence because somebody got in one time? 3814 04:37:25,582 --> 04:37:28,582 Well, if they didn't work at all, this is the heart of the matter. 3815 04:37:28,582 --> 04:37:29,582 You keep dancing around. 3816 04:37:29,582 --> 04:37:31,582 You want to have it both ways. 3817 04:37:31,582 --> 04:37:32,582 You want to say, yeah, sure. 3818 04:37:32,582 --> 04:37:35,582 It's just a serialized set of bytes. 3819 04:37:36,582 --> 04:37:40,582 It's interpreted as an image later by whatever reads those bytes. 3820 04:37:40,582 --> 04:37:42,582 These are fundamental. 3821 04:37:42,582 --> 04:37:44,582 This is like a knife to the heart of your argument. 3822 04:37:44,582 --> 04:37:45,582 It kills it instantly. 3823 04:37:45,582 --> 04:37:47,582 It's a bullet to the head of your argument. 3824 04:37:47,582 --> 04:37:49,582 And then you say, well, sure, that's true. 3825 04:37:49,582 --> 04:37:50,582 But we can do it. 3826 04:37:50,582 --> 04:37:52,582 And I wrote down some of these comments. 3827 04:37:52,582 --> 04:37:54,582 Not that it should be like a quote-off or whatever. 3828 04:37:54,582 --> 04:37:56,582 But basically saying it's not possible to stop spam. 3829 04:37:56,582 --> 04:37:58,582 More hidden, better. 3830 04:37:58,582 --> 04:38:00,582 Hostility is the deterrent. 3831 04:38:00,582 --> 04:38:04,582 Then some other guy, that guy over there, he said, hey, is it code or is it hostility? 3832 04:38:04,582 --> 04:38:05,582 There's more equivocation on that. 3833 04:38:05,582 --> 04:38:07,582 It's just constantly going back and forth. 3834 04:38:07,582 --> 04:38:08,582 It's code as hostility. 3835 04:38:08,582 --> 04:38:10,582 Filters are, it's like your immune system, right? 3836 04:38:10,582 --> 04:38:12,582 You can't prevent all pathogens forever. 3837 04:38:12,582 --> 04:38:14,582 But you can put up a defense against them. 3838 04:38:14,582 --> 04:38:16,582 So is relay policy enough hostility? 3839 04:38:16,582 --> 04:38:21,582 What if Core said, you know, version 33, we revert back to 80 byte max data carrier, 3840 04:38:21,582 --> 04:38:22,582 whatever. 3841 04:38:22,582 --> 04:38:25,582 Would that remove the impetus for VIC-110? 3842 04:38:25,582 --> 04:38:27,582 Or is it like, no, we're on this track. 3843 04:38:27,582 --> 04:38:28,582 They'd also have to filter inscriptions. 3844 04:38:28,582 --> 04:38:30,582 They'd also have to filter inscriptions. 3845 04:38:30,582 --> 04:38:31,582 OK. 3846 04:38:32,582 --> 04:38:34,582 But like, why is this happening now? 3847 04:38:34,582 --> 04:38:36,582 Because inscriptions sort of are dead. 3848 04:38:36,582 --> 04:38:37,582 I mean, they're not dead. 3849 04:38:37,582 --> 04:38:39,582 But like, 2023, it was like, whoa. 3850 04:38:39,582 --> 04:38:44,582 But there's still a kind of could be argued that they are an officially supported way 3851 04:38:44,582 --> 04:38:47,582 of storing large files on Bitcoin. 3852 04:38:47,582 --> 04:38:48,582 And that's the problem. 3853 04:38:48,582 --> 04:38:50,582 People did it, and then it didn't. 3854 04:38:50,582 --> 04:38:51,582 Well, they're still doing it. 3855 04:38:51,582 --> 04:38:52,582 Can I ask you this? 3856 04:38:52,582 --> 04:38:53,582 I actually don't know how common they are now. 3857 04:38:53,582 --> 04:38:54,582 Runes are more popular or whatever. 3858 04:38:54,582 --> 04:38:57,582 Isn't a transaction a file? 3859 04:38:57,582 --> 04:38:58,582 Is what? 3860 04:38:58,582 --> 04:38:59,582 Is a transaction a file? 3861 04:38:59,582 --> 04:39:00,582 Is a Bitcoin transaction a file? 3862 04:39:00,582 --> 04:39:01,582 I mean, technically, no. 3863 04:39:01,582 --> 04:39:03,582 There's block files. 3864 04:39:03,582 --> 04:39:04,582 There's .dat files. 3865 04:39:04,582 --> 04:39:07,582 You can export it to a file. 3866 04:39:07,582 --> 04:39:08,582 As file, yeah. 3867 04:39:08,582 --> 04:39:14,582 So you just say, then, it's the exporting that changes the set of bytes into a file. 3868 04:39:14,582 --> 04:39:19,582 I mean, you could interpret arbitrary data as a file. 3869 04:39:19,582 --> 04:39:20,582 And that's what they're doing, right? 3870 04:39:20,582 --> 04:39:22,582 They're saying, this is a format. 3871 04:39:22,582 --> 04:39:26,582 And if you just read it as a common file type, then it is a file. 3872 04:39:26,582 --> 04:39:28,582 We're speaking a different language here. 3873 04:39:28,582 --> 04:39:29,582 It's impossible. 3874 04:39:29,582 --> 04:39:30,582 This is a very interesting question. 3875 04:39:30,582 --> 04:39:35,582 Let's just say, hypothetically, Core went and added all the filtering rules that you want, 3876 04:39:35,582 --> 04:39:36,582 and so on and so forth. 3877 04:39:36,582 --> 04:39:42,582 What would happen if a tiny minority continued to run LibreRelay, and basically, it just 3878 04:39:42,582 --> 04:39:46,582 ended up being all of the stuff you don't like went through LibreRelay, and blocks were 3879 04:39:46,582 --> 04:39:47,582 still full of it? 3880 04:39:47,582 --> 04:39:49,582 I mean, there's more technical defenses that we can keep escalating. 3881 04:39:49,582 --> 04:39:50,582 Wait, wait, wait. 3882 04:39:50,582 --> 04:39:51,582 Remember. 3883 04:39:51,582 --> 04:39:52,582 Like, in terms of mempo files. 3884 04:39:52,582 --> 04:39:53,582 Yeah, what would those be? 3885 04:39:53,582 --> 04:39:55,582 Like, would you say, no, we have to do a consensus change? 3886 04:39:56,582 --> 04:40:01,582 What I'm saying is, at that point, especially, well, you're saying after Bit.10 activates, 3887 04:40:01,582 --> 04:40:03,582 or if Core puts in filters? 3888 04:40:03,582 --> 04:40:04,582 No, no, no. 3889 04:40:04,582 --> 04:40:08,582 I'm saying, in the scenario where we say, let's just say Core had implemented all of 3890 04:40:08,582 --> 04:40:12,582 these filters, all of the mempo filters. 3891 04:40:12,582 --> 04:40:17,582 Now, in a scenario like that, where, let's just say, hypothetically, 90% of nodes are 3892 04:40:17,582 --> 04:40:22,582 running Core, they filter all this stuff, but the small minority running LibreRelay 3893 04:40:23,582 --> 04:40:25,582 go and mean that blocks are still full of this stuff. 3894 04:40:25,582 --> 04:40:26,582 What would you say? 3895 04:40:26,582 --> 04:40:29,582 Yeah, so the miners that are working with LibreRelay are malicious, and they're attacking 3896 04:40:29,582 --> 04:40:30,582 the network. 3897 04:40:30,582 --> 04:40:33,582 They're doing something that the nodes consider to be antisocial. 3898 04:40:33,582 --> 04:40:34,582 So, do you want to fork them off? 3899 04:40:34,582 --> 04:40:37,582 Like, would you say, in that scenario, that we should do some kind of consensus change 3900 04:40:37,582 --> 04:40:39,582 to force off the miners that are doing that? 3901 04:40:39,582 --> 04:40:41,582 Like, do you just get back to consensus changes still? 3902 04:40:41,582 --> 04:40:43,582 It depends on how much damage is possible. 3903 04:40:43,582 --> 04:40:44,582 Right? 3904 04:40:44,582 --> 04:40:45,582 So, the thing about intentional... 3905 04:40:45,582 --> 04:40:46,582 Let's say 25% of blocks are this. 3906 04:40:46,582 --> 04:40:47,582 What? 3907 04:40:47,582 --> 04:40:50,582 Let's say 25% of blocks are by miners who do this. 3908 04:40:50,582 --> 04:40:53,582 I mean, the biggest factor is the toxic data factor. 3909 04:40:53,582 --> 04:40:54,582 Right? 3910 04:40:54,582 --> 04:40:58,582 Like, does Bitcoin look like it intentionally stores large files or not? 3911 04:40:58,582 --> 04:40:59,582 Right? 3912 04:40:59,582 --> 04:41:00,582 That is the vector. 3913 04:41:00,582 --> 04:41:04,582 Here, like, 90% of nodes, you know, quote, unquote, don't allow this, et cetera, et cetera. 3914 04:41:04,582 --> 04:41:07,582 Like, do you just allow this situation to go on indefinitely? 3915 04:41:07,582 --> 04:41:09,582 It depends on how much damage is being caused. 3916 04:41:09,582 --> 04:41:13,582 I would say, like, the UTXO set went from 4 gigabytes to 12 gigabytes pretty fast, and 3917 04:41:13,582 --> 04:41:16,582 if it had kept going to 50 gigabytes or 100 gigabytes or 200 gigabytes... 3918 04:41:16,582 --> 04:41:19,582 Well, I mean, that's not related to putting data in transactions, though. 3919 04:41:19,582 --> 04:41:20,582 What? 3920 04:41:20,582 --> 04:41:25,582 In fact, the operaturns, those don't bloat the UTXO set, so it's actually helping the nodes. 3921 04:41:25,582 --> 04:41:28,582 See, this is the sort of technical argument that you get from poor people, where they 3922 04:41:28,582 --> 04:41:29,582 look at the... 3923 04:41:29,582 --> 04:41:33,582 They say a statement, oh, the operaturn causes less bloat than... 3924 04:41:33,582 --> 04:41:34,582 It certainly does. 3925 04:41:34,582 --> 04:41:38,582 Yeah, so we're actually helping with UTXO set bloat, and it's like, no, but you're removing 3926 04:41:38,582 --> 04:41:40,582 all of the context from that. 3927 04:41:40,582 --> 04:41:41,582 If you added all the operaturns to the UTXO set, it'd be huge. 3928 04:41:41,582 --> 04:41:45,582 The context is that being friendly to spam is what causes spam, and spam is what causes 3929 04:41:45,582 --> 04:41:46,582 UTXO set bloat. 3930 04:41:46,582 --> 04:41:47,582 If we're hostile to spam, there will be... 3931 04:41:47,582 --> 04:41:51,582 But spam, according to you, does not cause UTXO bloat. 3932 04:41:51,582 --> 04:41:52,582 Yes, it does. 3933 04:41:52,582 --> 04:41:53,582 No, it does not, because... 3934 04:41:53,582 --> 04:41:56,582 BRC20 is spam, and that was the main cause of UTXO set bloat. 3935 04:41:56,582 --> 04:41:58,582 You defined it as operaturn as spam. 3936 04:41:58,582 --> 04:42:01,582 After you said, in your talk, you said it's not possible to define spam, but then you 3937 04:42:01,582 --> 04:42:08,582 said it's really clear that some things are, and operaturn does not bloat the UTXO set. 3938 04:42:08,582 --> 04:42:13,582 Just because it's impossible to draw an objective line between spam and non-spam does not mean 3939 04:42:13,582 --> 04:42:15,582 that the categories of spam and non-spam don't exist. 3940 04:42:16,582 --> 04:42:17,582 Would you... 3941 04:42:17,582 --> 04:42:21,582 Okay, so it sounds like there's mempool policy versus consensus. 3942 04:42:21,582 --> 04:42:26,582 In a BIP-110, let's say BIP-110 succeeds, or even if it forks off some way, and there's 3943 04:42:26,582 --> 04:42:33,582 its own implementation, would the idea be, let's make consensus and mempool relay policy 3944 04:42:33,582 --> 04:42:35,582 as close as possible, or just... 3945 04:42:35,582 --> 04:42:36,582 No. 3946 04:42:36,582 --> 04:42:38,582 You want them to be different. 3947 04:42:38,582 --> 04:42:39,582 Yeah, no. 3948 04:42:39,582 --> 04:42:42,582 Satoshi clearly designed the consensus rules to be really, really loose so that we don't 3949 04:42:42,582 --> 04:42:44,582 have to hard fork in new functionality. 3950 04:42:44,582 --> 04:42:49,582 And he clearly designed policy to be robust to prevent people from doing crazy stuff on 3951 04:42:49,582 --> 04:42:50,582 the network that harms the network. 3952 04:42:50,582 --> 04:42:51,582 What if there's a LibreRelay-110? 3953 04:42:51,582 --> 04:42:52,582 What? 3954 04:42:52,582 --> 04:42:55,582 Because this guy might make a LibreRelay-110, right? 3955 04:42:55,582 --> 04:42:56,582 Well, of course. 3956 04:42:56,582 --> 04:42:57,582 I'm sure he will. 3957 04:42:57,582 --> 04:42:58,582 He probably will. 3958 04:42:58,582 --> 04:42:59,582 He definitely will. 3959 04:42:59,582 --> 04:43:02,582 So then you have to keep making consensus changes sort of reactively? 3960 04:43:02,582 --> 04:43:03,582 Well, no. 3961 04:43:03,582 --> 04:43:05,582 So this is exactly why it's different from SegWit. 3962 04:43:05,582 --> 04:43:10,582 So the situation right now is that Bitcoin is not hostile towards spam because Bitcoin 3963 04:43:10,582 --> 04:43:12,582 Core is not hostile to spam. 3964 04:43:12,582 --> 04:43:14,582 This is a new situation. 3965 04:43:14,582 --> 04:43:17,582 Bitcoin Core and Bitcoin were always hostile to spam in the past. 3966 04:43:17,582 --> 04:43:20,582 Even if Core were, there's a guy with a hat, and it's like 110. 3967 04:43:20,582 --> 04:43:24,582 Right, but what I'm saying is he's an attacker, right? 3968 04:43:24,582 --> 04:43:28,582 He's a malicious actor, and we have technical defenses against that, and we can keep... 3969 04:43:28,582 --> 04:43:29,582 Are we supposed to be doing questions or something? 3970 04:43:29,582 --> 04:43:30,582 Is that what's happening? 3971 04:43:30,582 --> 04:43:32,582 Do we want to leave 10 minutes for questions? 3972 04:43:32,582 --> 04:43:33,582 Okay, sure. 3973 04:43:33,582 --> 04:43:34,582 Sure, sure. 3974 04:43:34,582 --> 04:43:35,582 Oh, it says three minutes there. 3975 04:43:35,582 --> 04:43:36,582 All right. 3976 04:43:36,582 --> 04:43:37,582 Yeah, but we... 3977 04:43:37,582 --> 04:43:38,582 I think we did that. 3978 04:43:38,582 --> 04:43:40,582 Any questions from the audience? 3979 04:43:40,582 --> 04:43:41,582 Yeah. 3980 04:43:42,582 --> 04:43:45,582 Thank you. 3981 04:43:45,582 --> 04:43:52,582 To the fork authors, what are your plans following up the activation of your respective forks 3982 04:43:52,582 --> 04:43:54,582 in different contingencies? 3983 04:43:54,582 --> 04:43:58,582 Wow, that's a wildly abstract wording of that question. 3984 04:43:58,582 --> 04:44:02,582 But it's funny because, of course, he was just saying a moment ago, we don't need any 3985 04:44:02,582 --> 04:44:04,582 contingency plans because we're all... 3986 04:44:04,582 --> 04:44:08,582 So yeah, I think with mine, it's a little bit easier because we deliberately hard fork 3987 04:44:08,582 --> 04:44:09,582 off to a different thing. 3988 04:44:10,582 --> 04:44:11,582 We cut the difficulty down. 3989 04:44:11,582 --> 04:44:12,582 So something will exist. 3990 04:44:12,582 --> 04:44:14,582 There will be some blocks mined. 3991 04:44:14,582 --> 04:44:17,582 There may be crazy difficulty adjustments or something. 3992 04:44:17,582 --> 04:44:19,582 The chain may stall out. 3993 04:44:19,582 --> 04:44:20,582 There may be people renting. 3994 04:44:20,582 --> 04:44:21,582 Who knows? 3995 04:44:21,582 --> 04:44:24,582 But something will happen, and we'll probably learn from the experiment. 3996 04:44:24,582 --> 04:44:29,582 So even if it isn't successful, we would all gain at least some information. 3997 04:44:29,582 --> 04:44:34,582 And then, of course, if it could have limited success, it could be cool as a demo. 3998 04:44:34,582 --> 04:44:37,582 It could have outrageous extra success. 3999 04:44:37,582 --> 04:44:40,582 It could be more successful than other famous projects. 4000 04:44:40,582 --> 04:44:41,582 It would be fun. 4001 04:44:41,582 --> 04:44:45,582 So I think that's where it goes for me. 4002 04:44:45,582 --> 04:44:47,582 And then BIP-300 is the soft fork. 4003 04:44:47,582 --> 04:44:49,582 Anyone could use that at any time. 4004 04:44:49,582 --> 04:44:54,582 And in fact, I'm pretty sure that Litecoin, they have plans to make use of the enforcer. 4005 04:44:54,582 --> 04:44:57,582 And so that will probably happen also. 4006 04:44:57,582 --> 04:44:59,582 What was the question again? 4007 04:44:59,582 --> 04:45:00,582 Sorry. 4008 04:45:00,582 --> 04:45:04,582 Basically, what are you going to do in the follow-up after the activation of your fork 4009 04:45:04,582 --> 04:45:07,582 and the different realities where things might play out? 4010 04:45:07,582 --> 04:45:09,582 In the follow-up of the activation? 4011 04:45:09,582 --> 04:45:10,582 Two weeks from now. 4012 04:45:10,582 --> 04:45:11,582 Are you on your computer? 4013 04:45:11,582 --> 04:45:22,582 So it expires after a year, and the BIP says that we should plan to activate some other 4014 04:45:22,582 --> 04:45:25,582 better permanent solution to this. 4015 04:45:25,582 --> 04:45:31,582 And I can't speak for the BIP authors, but my opinion is that this would be a good time 4016 04:45:31,582 --> 04:45:33,582 to do covenants. 4017 04:45:34,582 --> 04:45:37,582 So that would be a good follow-up, I think. 4018 04:45:37,582 --> 04:45:45,582 Something that prevents large contiguous data, larger than 256 bytes, and covenants is what 4019 04:45:45,582 --> 04:45:46,582 I would say. 4020 04:45:46,582 --> 04:45:48,582 But that's just my personal opinion. 4021 04:45:48,582 --> 04:45:50,582 I can't speak for the actual BIP authors. 4022 04:45:50,582 --> 04:45:52,582 Another question? 4023 04:45:55,582 --> 04:45:57,582 Don't be shy. 4024 04:45:59,582 --> 04:46:00,582 Thanks so much. 4025 04:46:00,582 --> 04:46:02,582 This question is to Paul. 4026 04:46:02,582 --> 04:46:09,582 You're hard-forking to e-cash, which seems to me like you want e-cash to be a lot more 4027 04:46:09,582 --> 04:46:15,582 expressive, kind of like programmable, or just express whatever you want with it, right? 4028 04:46:15,582 --> 04:46:17,582 I'm just kind of curious. 4029 04:46:17,582 --> 04:46:21,582 Have you considered just building this on something like Bitcoin Cash first, instead 4030 04:46:21,582 --> 04:46:23,582 of just doing a hard fork? 4031 04:46:23,582 --> 04:46:26,582 No, because I don't think that would really help. 4032 04:46:27,582 --> 04:46:32,582 Layer one in e-cash is just exactly the same as Bitcoin Core. 4033 04:46:32,582 --> 04:46:35,582 So the idea is to try to keep as much of what people already like. 4034 04:46:35,582 --> 04:46:37,582 The thing is, it could be interesting. 4035 04:46:37,582 --> 04:46:40,582 I mean, nothing's stopping Bitcoin Cash from using the activator. 4036 04:46:40,582 --> 04:46:44,582 So that's part of the advantage of the Q-SYS, the core and touch software. 4037 04:46:44,582 --> 04:46:53,582 So you could, but having optional large block L2 over a smaller block L1, that is sort of 4038 04:46:53,582 --> 04:46:58,582 just more efficient than, like, you wouldn't even really be. 4039 04:46:58,582 --> 04:47:02,582 So I haven't really thought about that, but as I mentioned, I'm pretty sure Litecoin will 4040 04:47:02,582 --> 04:47:09,582 try to use the Q-SYS 30031 activator. 4041 04:47:09,582 --> 04:47:12,582 So it's certainly possible that Bitcoin Cash could do it as well. 4042 04:47:12,582 --> 04:47:17,582 And I know at some point there was some telegram group about Bitcoin Cash drive chain or whatever. 4043 04:47:18,582 --> 04:47:22,582 I think nothing's really stopping. 4044 04:47:22,582 --> 04:47:31,582 To just maybe re-explain this part, all the L2 software that we build, that works with the 4045 04:47:31,582 --> 04:47:36,582 BIP300301 activator and that could kind of work with almost any blockchain. 4046 04:47:36,582 --> 04:47:43,582 So actually it should be possible to just take the entire stack of stuff if anyone likes it. 4047 04:47:43,582 --> 04:47:48,582 And it would be mostly independent of the L1. 4048 04:47:48,582 --> 04:47:51,582 So I think that we probably will see some people do that. 4049 04:47:55,582 --> 04:48:05,582 For, I guess, all four of you, preferably one at a time, how confident are you in your 4050 04:48:05,582 --> 04:48:10,582 thoughts on the forks and why? 4051 04:48:11,582 --> 04:48:15,582 You can go first. 4052 04:48:15,582 --> 04:48:21,582 Well, I can't believe I'm on a panel where Paul Sztorc, of all people, is a reasonable one. 4053 04:48:21,582 --> 04:48:29,582 And I guess, yeah, I'm actually pretty confident that Paul Sztorc's drive chain's badly named 4054 04:48:29,582 --> 04:48:33,582 e-cash thing will, you know, become its own separate currency and do whatever and it might 4055 04:48:33,582 --> 04:48:35,582 die eventually, whatever. 4056 04:48:35,582 --> 04:48:46,582 As for the BIP110 thing, I think, at the moment, I think it's more likely than not it gets 4057 04:48:46,582 --> 04:48:50,582 sufficiently little hash power that it just dies out and doesn't even really become a 4058 04:48:50,582 --> 04:48:51,582 separate currency. 4059 04:48:51,582 --> 04:48:56,582 But, you know, I think it's a pretty high chance in the double digits that it does get 4060 04:48:56,582 --> 04:48:59,582 a minority hash power and then ultimately becomes a separate currency. 4061 04:48:59,582 --> 04:49:03,582 That may at some point die out, but that'll be a little ugly. 4062 04:49:03,582 --> 04:49:07,582 And I'd say it has a very low chance, but not zero, that somehow it actually does get 4063 04:49:07,582 --> 04:49:11,582 majority hash power, which will be very interesting. 4064 04:49:11,582 --> 04:49:17,582 I can say, yeah, the drive chain, hard fork, that seems like it'll just happen, right? 4065 04:49:17,582 --> 04:49:19,582 You can do that. 4066 04:49:19,582 --> 04:49:21,582 It'll be a lot of fun. 4067 04:49:21,582 --> 04:49:23,582 I'm pretty confident you can do that. 4068 04:49:23,582 --> 04:49:27,582 I'm not advocating for doing that, but, you know, it'll happen. 4069 04:49:27,582 --> 04:49:31,582 It may encourage more people, because I think there are some innovations, like the sort 4070 04:49:31,582 --> 04:49:38,582 of one-way replay, which people probably like, because, well, anyway, and then taking the 4071 04:49:38,582 --> 04:49:39,582 old coins. 4072 04:49:39,582 --> 04:49:43,582 And so you might see research, because back in a few years ago, we had a lot of different 4073 04:49:43,582 --> 04:49:47,582 hard forks, forking off from Bitcoin with, like, Bitcoin Diamond, Bitcoin Gold, whatever. 4074 04:49:47,582 --> 04:49:51,582 So, like, hey, maybe people get into that stuff again with new rules. 4075 04:49:52,582 --> 04:49:56,582 With the BIP110 one, yeah, I don't know. 4076 04:49:56,582 --> 04:49:58,582 It might be minority. 4077 04:49:58,582 --> 04:50:02,582 It'll be interesting in the next two weeks, because it might be like, oh, well, actually 4078 04:50:02,582 --> 04:50:07,582 we realized that we don't have enough support, so we need to change something or tweak something, 4079 04:50:07,582 --> 04:50:09,582 you know, or push it off. 4080 04:50:09,582 --> 04:50:10,582 I don't know. 4081 04:50:10,582 --> 04:50:11,582 We'll see what happens. 4082 04:50:11,582 --> 04:50:15,582 If it does end up being minority, it sounds like the people running it, if you're a representative 4083 04:50:15,582 --> 04:50:19,582 of them, don't want to have a minority split side, right? 4084 04:50:19,582 --> 04:50:23,582 And so that would sort of be, like, not a good outcome for BIP110 people. 4085 04:50:23,582 --> 04:50:25,582 So, hopefully we can avoid that. 4086 04:50:25,582 --> 04:50:31,582 Yeah, I mean, like, all I know, I mean, I'm very confident, like I said, because of the 4087 04:50:31,582 --> 04:50:37,582 precedent of BIP148, so, but, like, if something crazy happens and, you know, the miners collude 4088 04:50:37,582 --> 04:50:43,582 to not activate BIP110 against the wishes of the nodes, which are the soul of Bitcoin, 4089 04:50:43,582 --> 04:50:48,582 which is crying out to limit spam, you know, all I know is, like, activating it, if it 4090 04:50:48,582 --> 04:50:52,582 activates, that's how Bitcoin is supposed to work, and if it doesn't activate, that's 4091 04:50:52,582 --> 04:50:56,582 not how Bitcoin is supposed to work, and we have much bigger problems if BIP110 doesn't 4092 04:50:56,582 --> 04:50:59,582 activate, you know. 4093 04:50:59,582 --> 04:51:03,582 Okay, let me give you, like, a metaphor, because the question was how confident are you, and 4094 04:51:03,582 --> 04:51:07,582 the metaphor is this, we're on the Titanic and we're headed maybe for an iceberg, we 4095 04:51:07,582 --> 04:51:11,582 don't know, because it could be, like, a parallel universe or something, but I'm, like, grabbing 4096 04:51:11,582 --> 04:51:15,582 all the dining room tables and I'm, like, sawing them apart and trying to make, like, 4097 04:51:15,582 --> 04:51:20,582 life rafts, like, as quickly as possible, and I hope that we miss the iceberg and that 4098 04:51:20,582 --> 04:51:24,582 everything's fine and that lightning works out really well and all the other stuff we do 4099 04:51:24,582 --> 04:51:29,582 works great and everyone adopts Bitcoin and everything's fine, and I think that would be 4100 04:51:29,582 --> 04:51:32,582 wonderful, if we miss the iceberg, that would be great. 4101 04:51:32,582 --> 04:51:35,582 Now, do I think these life rafts are going necessarily to save us all? 4102 04:51:35,582 --> 04:51:39,582 Probably not also, so I just think, but, like, what else would you do in this situation? 4103 04:51:39,582 --> 04:51:44,582 So, I mean, to me it kind of blows my mind we even spend so much time talking about BIP110, 4104 04:51:44,582 --> 04:51:49,582 that was low on my list of derangements that I alluded to in my talk about, I had this 4105 04:51:49,582 --> 04:51:53,582 long, long list of problems with Bitcoin, and the problem with BIP110 is not just that 4106 04:51:53,582 --> 04:51:57,582 we have it, but that it's somehow monopolized so much of the conversation for, like, a year 4107 04:51:57,582 --> 04:51:59,582 and a half, I think that's very bizarre. 4108 04:51:59,582 --> 04:52:02,582 Because it's really important, people running those actually care. 4109 04:52:02,582 --> 04:52:07,582 With respect to BIP110, currently my expectation is that on August 9th it will just, like, 4110 04:52:07,582 --> 04:52:09,582 not have blocks. 4111 04:52:09,582 --> 04:52:15,582 I agree with Peter, again, it's funny that we sometimes do agree, where, like, if it 4112 04:52:15,582 --> 04:52:20,582 somehow got 100% hash rate, I would just think, like, wow, I guess for some reason I'm not 4113 04:52:20,582 --> 04:52:23,582 looking at the world, like, I see something, I'm not seeing something about the world. 4114 04:52:23,582 --> 04:52:28,582 I would almost then think, though, we're about to hit an even bigger iceberg or some other, 4115 04:52:28,582 --> 04:52:32,582 that we're even more screwed than we were before, so I don't know exactly what I would 4116 04:52:32,582 --> 04:52:34,582 conclude from that, but those are my thoughts on this. 4117 04:52:34,582 --> 04:52:36,582 Can I do an article analogy, too? 4118 04:52:37,582 --> 04:52:42,582 I think we're on a nuclear submarine, and, like, we're the best top of the line U.S. 4119 04:52:42,582 --> 04:52:46,582 nuclear submarine, and no one's going to fucking touch us, because we're on such an awesome 4120 04:52:46,582 --> 04:52:50,582 boat, but with tail emission, I do think we're probably going to run out of reactor fuel 4121 04:52:50,582 --> 04:52:55,582 in 20 years, and we should think ahead 20 years to how we're going to make that work. 4122 04:52:55,582 --> 04:52:59,582 These guys, on the other hand, seem really pissed off that someone forgot to go and load 4123 04:52:59,582 --> 04:53:04,582 all of the frozen pizzas in, and we're missing that one nice thing, but we'll survive without 4124 04:53:04,582 --> 04:53:05,582 frozen pizzas. 4125 04:53:05,582 --> 04:53:08,582 We'll get some more in 90 days when we restock. 4126 04:53:08,582 --> 04:53:09,582 I think the analogy is more like this. 4127 04:53:09,582 --> 04:53:15,582 The iceberg is this arbitrary data thing that's coming at Bitcoin, and it's basically going 4128 04:53:15,582 --> 04:53:21,582 to kill any hope of Bitcoin being used as money for the foreseeable future, and maybe 4129 04:53:21,582 --> 04:53:24,582 forever, because if Bitcoin's culture forgets that Bitcoin is supposed to be money, then 4130 04:53:24,582 --> 04:53:29,582 at that point, it just becomes Ethereum, and nobody cares where it goes, and there's a 4131 04:53:29,582 --> 04:53:36,582 little button that all the miners have that just zaps the iceberg and makes it go away, 4132 04:53:36,582 --> 04:53:39,582 and that's flipping the bit to activate Bitcoin. 4133 04:53:39,582 --> 04:53:42,582 The nuclear submarine goes under the iceberg, just to be clear. 4134 04:53:42,582 --> 04:53:44,582 I mean, why is it so important to you? 4135 04:53:44,582 --> 04:53:46,582 It's so important. 4136 04:53:46,582 --> 04:53:49,582 I'm talking about having 8 billion users and Zcash privacy. 4137 04:53:49,582 --> 04:53:54,582 It seems like this is a completely different realm of significance to whether or not some 4138 04:53:54,582 --> 04:53:57,582 people sometimes put large op returns. 4139 04:53:57,582 --> 04:54:00,582 I'm honestly, I'm honest to God, curious. 4140 04:54:00,582 --> 04:54:04,582 This is your iceberg. 4141 04:54:04,582 --> 04:54:05,582 Why is it so important? 4142 04:54:05,582 --> 04:54:13,582 I just told you, if we allow arbitrary data storage as an officially accepted use case, 4143 04:54:13,582 --> 04:54:17,582 then it outcompetes the monetary use case, and it makes everyone forget that Bitcoin 4144 04:54:17,582 --> 04:54:20,582 is supposed to be money, and you're actually seeing this with Michael Saylor. 4145 04:54:20,582 --> 04:54:22,582 He's saying Bitcoin isn't money. 4146 04:54:22,582 --> 04:54:27,582 He's saying my STRC derivative is going to be digital money, and Bitcoin is digital capital. 4147 04:54:27,582 --> 04:54:30,582 It's like turning into this thing that isn't money. 4148 04:54:30,582 --> 04:54:32,582 So you're forking Bitcoin because of Saylor. 4149 04:54:32,582 --> 04:54:36,582 I know, and it's terrible, because Saylor does say, he literally says everything both ways. 4150 04:54:36,582 --> 04:54:39,582 I almost have a list where he said Bitcoin is money. 4151 04:54:39,582 --> 04:54:43,582 He has tweets where he says Bitcoin is money, then he says Bitcoin is capital, Bitcoin is real estate. 4152 04:54:43,582 --> 04:54:45,582 I don't think he said Bitcoin is money for a while. 4153 04:54:45,582 --> 04:54:50,582 He used to say it back in the old days, back when he was ingratiating himself to the Bitcoin community. 4154 04:54:50,582 --> 04:54:54,582 But he's not into ordinals and runes, right? Or yet? 4155 04:54:54,582 --> 04:54:58,582 No, he wanted to use inscriptions for his digital ID thing. 4156 04:54:58,582 --> 04:55:01,582 Originally he had some kind of ordinals company thing. 4157 04:55:01,582 --> 04:55:03,582 But he just does everything every way. 4158 04:55:03,582 --> 04:55:05,582 I don't think he has any idea what he's actually talking about. 4159 04:55:05,582 --> 04:55:06,582 I agree. 4160 04:55:06,582 --> 04:55:08,582 Guys, we have a last question here. 4161 04:55:08,582 --> 04:55:12,582 Well, thank you for the panel. It's very entertaining. 4162 04:55:12,582 --> 04:55:14,582 That's for sure. 4163 04:55:15,582 --> 04:55:23,582 I think all the people on the panel seem to be in agreement that Bitcoin, at the minimum, 4164 04:55:23,582 --> 04:55:30,582 has some small realistic chance of activating and there's some chance of a giant split. 4165 04:55:30,582 --> 04:55:36,582 So given that, I guess I wanted to ask the opinion of everybody on the panel. 4166 04:55:36,582 --> 04:55:45,582 How do we think centralized exchanges should react at that point of activation, 4167 04:55:45,582 --> 04:55:49,582 given there is some uncertainty on what will happen, 4168 04:55:49,582 --> 04:55:54,582 and following a losing chain for a centralized exchange? 4169 04:55:55,102 --> 04:55:59,102 I mean, I don't think there's going to be any uncertainty leading up to the fork. 4170 04:55:59,102 --> 04:56:04,102 Like, a few days before the deadline, the miners are all just going to turn it on and everything is going to be fine. 4171 04:56:04,102 --> 04:56:10,102 Maybe. So bizarre. I mean, like, yeah, I agonize over every detail of, like, oh, what if maybe this would happen? 4172 04:56:10,102 --> 04:56:15,102 It's like you're piloting the nuclear sub and then someone's like, hey, what if we, like, just, like, we're not, like, looking where we're going. 4173 04:56:15,102 --> 04:56:18,102 What if we just hit something? No, we're definitely not going to hit anything. 4174 04:56:18,102 --> 04:56:20,102 That's what Core did with ripping out the opportunity. 4175 04:56:20,102 --> 04:56:26,102 I think it's funny that if you do launch something that may split the chain, you kind of are screwing over the exchanges, 4176 04:56:26,102 --> 04:56:32,102 which I think is kind of funny because the exchanges, you know, they made so much money and they kind of had the run of the place, you know. 4177 04:56:32,102 --> 04:56:39,102 And I just honestly, I think given how much money the exchange make, and I think it'd probably be the right thing to try to, 4178 04:56:39,102 --> 04:56:44,102 if there is a chain split, just split it, like, under the hood, especially because it's like Bitcoin Core is the node, 4179 04:56:45,102 --> 04:56:51,102 and just split it and make it, like, the two things, and if the 110 people won't give it a name, call it Bitcoin 110, 4180 04:56:51,102 --> 04:56:55,102 and then just credit everyone with it. I think that's what they should do. 4181 04:56:55,102 --> 04:56:59,102 And so will they actually do that? I don't know. 4182 04:56:59,102 --> 04:57:04,102 And if they don't do that, will it just be total chaos as their, like, transactions are replayed and drained from them? 4183 04:57:04,102 --> 04:57:11,102 Or is it a bad precedent for them to set and say any random Yahoo who does a hard fork, 4184 04:57:11,102 --> 04:57:18,102 now they have to have this build this infrastructure? I don't know, but I'm saying in terms of August 2026, 4185 04:57:18,102 --> 04:57:24,102 I would just say, just, you know, just credit everyone's coins and kind of let them trade, 4186 04:57:24,102 --> 04:57:27,102 because they make more money trading. So that's my actual answer. 4187 04:57:27,102 --> 04:57:30,102 As to what they will really do, I have no idea. 4188 04:57:30,102 --> 04:57:38,102 I think it will be really interesting as the days approach, because exchanges failing to go put up the press releases, 4189 04:57:38,102 --> 04:57:45,102 saying what they're going to do, will be a very strong sign that what I think is the most realistic outcome is going to happen, 4190 04:57:45,102 --> 04:57:49,102 which is BIP 110 basically just fails. 4191 04:57:49,102 --> 04:57:52,102 I think that's the least likely outcome. 4192 04:57:52,102 --> 04:57:55,102 The most likely outcome is the miners are going to be like, wait, 4193 04:57:55,102 --> 04:57:58,102 so you're telling me there's a bunch of people who really, really want to activate this, 4194 04:57:58,102 --> 04:58:02,102 and they're going to start throwing away our blocks, and there's absolutely no reason to oppose it? 4195 04:58:02,102 --> 04:58:06,102 Let's just turn it on. The legacy chain is going to have a bunch of vulnerabilities that the new chain doesn't have. 4196 04:58:06,102 --> 04:58:08,102 Let me answer this poor guy's question. 4197 04:58:08,102 --> 04:58:15,102 So if exchanges do start putting up those press releases, then I agree with Paul there, 4198 04:58:15,102 --> 04:58:19,102 which is the obvious thing to do is just credit both sides and then start letting people trade. 4199 04:58:19,102 --> 04:58:24,102 From a technical level, it's a bit of a nuisance, because you have to do a few extra steps 4200 04:58:24,102 --> 04:58:30,102 to make sure you do BIP 110 non-compliant transactions to cleanly separate both sides. 4201 04:58:30,102 --> 04:58:34,102 But fortunately, putting two up returns in one is enough to do that. 4202 04:58:34,102 --> 04:58:40,102 It's not terrible, but certainly with cold storage, the nature of cold storage is 4203 04:58:40,102 --> 04:58:44,102 often the systems that actually handle those coins are really locked down, 4204 04:58:44,102 --> 04:58:46,102 and touching them is something that no one ever wants to do. 4205 04:58:46,102 --> 04:58:49,102 So it might be the case that some of these cold storage systems, 4206 04:58:49,102 --> 04:58:53,102 it's going to be a pain in the ass to change them to let the coins get split. 4207 04:58:53,102 --> 04:58:54,102 But we'll see. 4208 04:58:54,102 --> 04:59:01,102 I think maybe what we maybe all agree on is that since exchanges are trusted third parties, 4209 04:59:02,102 --> 04:59:07,102 it's always better, no matter what the case is, to have your own keys and have your own coins, 4210 04:59:07,102 --> 04:59:10,102 and then whatever happens, you'll have everything. 4211 04:59:10,102 --> 04:59:12,102 Do people agree with that? 4212 04:59:12,102 --> 04:59:16,102 I hate to say this, but one catch with this is a lot of wallets are not going to give you a way 4213 04:59:16,102 --> 04:59:18,102 to cleanly split things. 4214 04:59:18,102 --> 04:59:20,102 If you had to write it on an exchange, you would. 4215 04:59:20,102 --> 04:59:23,102 Yeah, but at least you're free to do it if you can figure out how to do it. 4216 04:59:23,102 --> 04:59:26,102 But I don't think it's worth it to even talk about a chain split, 4217 04:59:26,102 --> 04:59:29,102 because the historical precedent is that there won't be a chain split. 4218 04:59:29,102 --> 04:59:32,102 All of the miners will just figure it out in the days leading up to the deadline. 4219 04:59:32,102 --> 04:59:34,102 But yeah, withdraw from exchanges. 4220 04:59:34,102 --> 04:59:40,102 Not your keys, not your coins. 4221 04:59:40,102 --> 04:59:42,102 One super last question. 4222 04:59:42,102 --> 04:59:44,102 I was just going to say... 4223 04:59:44,102 --> 04:59:46,102 I'll go for like eight hours, whatever, I don't care. 4224 04:59:46,102 --> 04:59:50,102 Would you just quickly TLDR why you decided to hard fork specifically, 4225 04:59:50,102 --> 04:59:55,102 and is it because to use Taj's language, you just want this to actually happen? 4226 04:59:55,102 --> 04:59:57,102 We haven't had enough competition. 4227 04:59:58,102 --> 05:00:00,102 I think things have actually been really boring over the last ten years. 4228 05:00:00,102 --> 05:00:02,102 And the fact that we're talking about 1.10... 4229 05:00:02,102 --> 05:00:05,102 No, and it's like, 1.10, I think Peter was clearly... 4230 05:00:05,102 --> 05:00:10,102 I was waiting to get rid of the op return limit for a really, really long time. 4231 05:00:10,102 --> 05:00:15,102 I always thought these standardness limits were misleading, mostly. 4232 05:00:15,102 --> 05:00:20,102 And I just can't believe that the fact that this is what we're talking about is 1.10, 4233 05:00:20,102 --> 05:00:24,102 and we're not talking about how to add privacy to Bitcoin or how to do anything cool. 4234 05:00:24,102 --> 05:00:26,102 We're just talking about all this nonsense. 4235 05:00:27,102 --> 05:00:30,102 We need to have some other thing to do. 4236 05:00:30,102 --> 05:00:34,102 And I think that, obviously, all the altcoins people really don't like, 4237 05:00:34,102 --> 05:00:37,102 and a lot of them, most 99% of them, are terrible. 4238 05:00:37,102 --> 05:00:40,102 And we don't really want to give Ethereum any... 4239 05:00:40,102 --> 05:00:42,102 So I thought this would be a cool thing. 4240 05:00:42,102 --> 05:00:43,102 Everyone will get coins. 4241 05:00:43,102 --> 05:00:47,102 If you have people who are very interested in doing something with whatever, 4242 05:00:47,102 --> 05:00:51,102 Opcat or whatever, they want to do some kind of near-Bitcoin thing. 4243 05:00:51,102 --> 05:00:53,102 We have some other flavor. 4244 05:00:53,102 --> 05:00:56,102 So I just say, well, give us some other thing to do. 4245 05:00:56,102 --> 05:00:58,102 I think things have been very boring. 4246 05:00:58,102 --> 05:01:03,102 Of course, saving Bitcoin from existential threats is not the most glamorous or sexy thing. 4247 05:01:03,102 --> 05:01:06,102 I definitely agree with that, but that doesn't mean it's not important. 4248 05:01:08,102 --> 05:01:10,102 Okay. Thank you to our panelists. 4249 05:01:10,102 --> 05:01:12,102 A huge applause, please. 4250 05:01:24,102 --> 05:01:27,102 All right. 4251 05:01:27,102 --> 05:01:30,102 That was an incredible final panel. 4252 05:01:30,102 --> 05:01:32,102 I think a really great last day. 4253 05:01:32,102 --> 05:01:37,102 So thank you, everyone, for showing up for all the talks, workshops, presentations, 4254 05:01:37,102 --> 05:01:40,102 the hackathon finals that we did today. 4255 05:01:40,102 --> 05:01:41,102 You know what they say. 4256 05:01:41,102 --> 05:01:43,102 Sometimes when you set off fireworks, you get to watch a forest fire. 4257 05:01:43,102 --> 05:01:44,102 Oh, I see. 4258 05:01:48,102 --> 05:01:51,102 Oh, that did happen in Canada recently. 4259 05:01:51,102 --> 05:01:52,102 Okay. 4260 05:01:52,102 --> 05:01:56,102 Without further ado, this is the final presentation that we have for today. 4261 05:01:56,102 --> 05:02:00,102 So we are going to hand out a couple of awards. 4262 05:02:02,102 --> 05:02:04,102 What else have we got, Alex? 4263 05:02:04,102 --> 05:02:05,102 Yeah. 4264 05:02:05,102 --> 05:02:06,102 This is an amazing conference. 4265 05:02:06,102 --> 05:02:09,102 Let's finish up and give away some awards. 4266 05:02:09,102 --> 05:02:14,102 Final Day of Clothing Awards. 4267 05:02:14,102 --> 05:02:16,102 I don't remember what we're... 4268 05:02:16,102 --> 05:02:17,102 Yeah, so we had 16 projects. 4269 05:02:17,102 --> 05:02:19,102 So thank you for everybody that participated in the hackathon. 4270 05:02:19,102 --> 05:02:20,102 This was incredibly impressive. 4271 05:02:20,102 --> 05:02:24,102 The judges were blown away by the quality of your projects. 4272 05:02:24,102 --> 05:02:28,102 I can attest that there was vociferous arguments in the judges' room. 4273 05:02:28,102 --> 05:02:31,102 People were at their throats arguing for your projects. 4274 05:02:31,102 --> 05:02:35,102 So, again, congratulations to everybody for making incredible projects. 4275 05:02:35,102 --> 05:02:36,102 Wow. 4276 05:02:36,102 --> 05:02:37,102 Look at all the projects. 4277 05:02:45,102 --> 05:02:47,102 Again, we have a new hackathon platform. 4278 05:02:47,102 --> 05:02:54,102 So for all of posterity, you can view your hackathon projects at bccpp.dev. 4279 05:02:54,102 --> 05:02:58,102 In addition, you'll see your hackathon project on your dashboard. 4280 05:02:58,102 --> 05:03:03,102 So as you go to more Bitcoin++'s and compete in more hackathons, 4281 05:03:03,102 --> 05:03:06,102 you'll see all of your projects on the site organized. 4282 05:03:06,102 --> 05:03:08,102 It'll be pretty amazing to see how this grows over time. 4283 05:03:08,102 --> 05:03:17,102 So we had a record number of prizes. 4284 05:03:17,102 --> 05:03:23,102 17 million Satoshis worth of stats and in-kind gifts that we're giving out. 4285 05:03:23,102 --> 05:03:28,102 So thank you to all of our sponsors and projects that put up prizes. 4286 05:03:28,102 --> 05:03:32,102 And thank you for all of you for competing to win them. 4287 05:03:32,102 --> 05:03:35,102 So very excited to be handing out some cool stuff today. 4288 05:03:36,102 --> 05:03:42,102 We had a couple of bonus challenges that were put up by a lot of our sponsors. 4289 05:03:42,102 --> 05:03:43,102 Exactly. 4290 05:03:43,102 --> 05:03:44,102 Yeah, thank you to all of our sponsors. 4291 05:03:44,102 --> 05:03:47,102 First, Soapbox is our official hackathon sponsor. 4292 05:03:47,102 --> 05:03:50,102 They support us for all of our hackathons. 4293 05:03:50,102 --> 05:03:56,102 And we saw a bunch of very impressive projects using Shakespeare 4294 05:03:56,102 --> 05:03:59,102 to vibe code your projects on FreedomTech. 4295 05:04:00,102 --> 05:04:07,102 Winning one million Satoshis to the best project built with Soapbox Technologies 4296 05:04:07,102 --> 05:04:09,102 goes to BitVote. 4297 05:04:09,102 --> 05:04:10,102 Congratulations. 4298 05:04:10,102 --> 05:04:18,102 And when you get an award, feel free to come on stage, 4299 05:04:18,102 --> 05:04:20,102 receive your prize, take a picture. 4300 05:04:20,102 --> 05:04:23,102 Unless TeamVote BitVote is not here. 4301 05:04:23,102 --> 05:04:25,102 BitVote's not here. 4302 05:04:25,102 --> 05:04:26,102 Oh, they're there. 4303 05:04:26,102 --> 05:04:27,102 Come on down. 4304 05:04:28,102 --> 05:04:29,102 I'll give it to them. 4305 05:04:29,102 --> 05:04:30,102 We'll take a picture after. 4306 05:04:30,102 --> 05:04:31,102 We'll take a picture after. 4307 05:04:31,102 --> 05:04:32,102 There's a lot of stares. 4308 05:04:32,102 --> 05:04:33,102 Okay. 4309 05:04:33,102 --> 05:04:34,102 But yeah, another thing, if you don't want to be on camera, 4310 05:04:34,102 --> 05:04:36,102 obviously don't come on stage. 4311 05:04:36,102 --> 05:04:37,102 Just, yes. 4312 05:04:37,102 --> 05:04:38,102 Cool. 4313 05:04:38,102 --> 05:04:39,102 Shout out to Bitcoin DevKit. 4314 05:04:39,102 --> 05:04:43,102 The Bitcoin DevKit Foundation has supported several of our hackathons. 4315 05:04:43,102 --> 05:04:48,102 So, unfortunately, Thunderbiscuit had to leave. 4316 05:04:48,102 --> 05:04:53,102 But winning one million Satoshis for the best project built with BDK 4317 05:04:53,102 --> 05:04:57,102 goes to BDK Compact Block Filters and Bowl. 4318 05:04:57,102 --> 05:05:22,102 Congratulations. 4319 05:05:22,102 --> 05:05:23,102 Pablo. 4320 05:05:23,102 --> 05:05:28,102 It's not every conference that someone will present on something at a presentation 4321 05:05:28,102 --> 05:05:30,102 and someone will include it in their project in the hackathon. 4322 05:05:30,102 --> 05:05:33,102 So, that's really cool to see. 4323 05:05:33,102 --> 05:05:34,102 Yeah. 4324 05:05:34,102 --> 05:05:37,102 Next up, we had Blockstream, who I believe put up some jades. 4325 05:05:37,102 --> 05:05:42,102 Watch your step. 4326 05:05:42,102 --> 05:05:44,102 I'll try not to trip like the other day. 4327 05:05:44,102 --> 05:05:46,102 Okay. 4328 05:05:46,102 --> 05:05:47,102 Yeah, you want to present it? 4329 05:05:47,102 --> 05:05:49,102 Oh, go ahead. 4330 05:05:49,102 --> 05:05:50,102 Where are you? 4331 05:05:50,102 --> 05:05:53,102 I gave you the wallet. 4332 05:05:53,102 --> 05:05:54,102 I'm here. 4333 05:05:54,102 --> 05:05:55,102 I need to show you. 4334 05:05:55,102 --> 05:06:01,102 Basically, I was suggested that we should give a hardware wallet to the winner. 4335 05:06:01,102 --> 05:06:03,102 I already gave him a virtual call. 4336 05:06:03,102 --> 05:06:06,102 So, this is just a shake of hands. 4337 05:06:06,102 --> 05:06:07,102 Congratulations. 4338 05:06:07,102 --> 05:06:11,102 And, yeah, thank you for using something that looks like ours. 4339 05:06:11,102 --> 05:06:12,102 And now you can use it. 4340 05:06:12,102 --> 05:06:13,102 No problem. 4341 05:06:13,102 --> 05:06:14,102 Awesome. 4342 05:06:14,102 --> 05:06:15,102 Thank you. 4343 05:06:16,102 --> 05:06:22,102 Yeah. 4344 05:06:22,102 --> 05:06:25,102 Next up, we have... 4345 05:06:25,102 --> 05:06:26,102 Leo. 4346 05:06:26,102 --> 05:06:28,102 Leo, are you here for the presentation? 4347 05:06:28,102 --> 05:06:32,102 Here you go. 4348 05:06:32,102 --> 05:06:33,102 This is also exciting. 4349 05:06:33,102 --> 05:06:37,102 The Lightning Labs just launched a new project this week, 4350 05:06:37,102 --> 05:06:39,102 and Leo's here to present an award for it. 4351 05:06:39,102 --> 05:06:43,102 Yeah, very cool to see two projects implementing Wavelength. 4352 05:06:43,102 --> 05:06:44,102 I heard good things. 4353 05:06:44,102 --> 05:06:46,102 I am aware of some of the limitations. 4354 05:06:46,102 --> 05:06:50,102 It was very cool to see you integrate it so quickly into your web apps. 4355 05:06:50,102 --> 05:07:00,102 The winner of the prize, which is a demo presentation at the quarterly demo day 4356 05:07:00,102 --> 05:07:06,102 and also a one-hour vibe coding session with a Lightning Labs engineer, 4357 05:07:06,102 --> 05:07:08,102 goes to OpenStays. 4358 05:07:08,102 --> 05:07:24,102 Congratulations. 4359 05:07:24,102 --> 05:07:26,102 Congratulations, OpenStays. 4360 05:07:26,102 --> 05:07:27,102 Great. 4361 05:07:27,102 --> 05:07:28,102 Thank you very much. 4362 05:07:28,102 --> 05:07:32,102 Thanks. 4363 05:07:32,102 --> 05:07:35,102 Peter. 4364 05:07:36,102 --> 05:07:38,102 I think this is our second-to-last bonus challenge. 4365 05:07:38,102 --> 05:07:41,102 How many of you have ever used OpenTimestamps before? 4366 05:07:41,102 --> 05:07:42,102 We have one, two. 4367 05:07:42,102 --> 05:07:43,102 Okay, a handful of people. 4368 05:07:43,102 --> 05:07:44,102 That's really great. 4369 05:07:44,102 --> 05:07:45,102 I'd say about half. 4370 05:07:45,102 --> 05:07:46,102 This is a special prize. 4371 05:07:46,102 --> 05:07:48,102 This is the... 4372 05:07:48,102 --> 05:07:51,102 Yeah, Peter, do you want to explain what this prize is? 4373 05:07:51,102 --> 05:07:54,102 Well, so, you know, OpenTimestamps has this interesting property 4374 05:07:54,102 --> 05:07:57,102 where it's just timestamping data, 4375 05:07:57,102 --> 05:08:00,102 which means that almost anything you can timestamp data. 4376 05:08:01,102 --> 05:08:07,102 So this is the 42,000 sats prize for the most unnecessary use of OpenTimestamps 4377 05:08:07,102 --> 05:08:09,102 in otherwise serious projects. 4378 05:08:09,102 --> 05:08:12,102 In the very serious project, I forget what the heck the name was, 4379 05:08:12,102 --> 05:08:14,102 but, you know, it involves prime numbers, 4380 05:08:14,102 --> 05:08:21,102 and timestamping prime numbers is completely fucking useless. 4381 05:08:21,102 --> 05:08:26,102 Congratulations, CanYouHackBTC. 4382 05:08:26,102 --> 05:08:29,102 Yeah, CanYouHackBTC, a very cool educational project. 4383 05:08:29,102 --> 05:08:31,102 There you go. 4384 05:08:31,102 --> 05:08:33,102 And I'll give you some lightning later. 4385 05:08:33,102 --> 05:08:38,102 Awesome. 4386 05:08:38,102 --> 05:08:40,102 Great, congratulations. 4387 05:08:40,102 --> 05:08:45,102 Watch yourself. 4388 05:08:45,102 --> 05:08:48,102 All right, and last but certainly not least goes to, 4389 05:08:48,102 --> 05:08:51,102 we like to give this prize out every Bitcoin++ conference, 4390 05:08:51,102 --> 05:08:53,102 to the best beginner hack. 4391 05:08:53,102 --> 05:08:55,102 So this goes to teams where every member 4392 05:08:55,102 --> 05:08:59,102 is either a first-time contributor to open source or Bitcoin. 4393 05:08:59,102 --> 05:09:15,102 And this one, we are very excited to give out to NodeSignal. 4394 05:09:15,102 --> 05:09:18,102 Congratulations, watch yourself. 4395 05:09:18,102 --> 05:09:19,102 Congratulations on your first hack. 4396 05:09:19,102 --> 05:09:30,102 It was incredible, yeah. 4397 05:09:30,102 --> 05:09:32,102 Awesome, all right. 4398 05:09:32,102 --> 05:09:34,102 Yeah, moving on to our honorable mentions. 4399 05:09:34,102 --> 05:09:37,102 These are overall fantastic teams across the board 4400 05:09:37,102 --> 05:09:41,102 that created very quality projects generally, 4401 05:09:41,102 --> 05:09:43,102 but didn't quite make it into the top three. 4402 05:09:43,102 --> 05:09:47,102 So we have six incredible projects to present honorable mentions to. 4403 05:09:47,102 --> 05:10:00,102 The first goes to Silent Receipts. 4404 05:10:00,102 --> 05:10:07,102 The second goes to BitVote. 4405 05:10:07,102 --> 05:10:10,102 Oh, come on up, yeah. 4406 05:10:10,102 --> 05:10:11,102 I also got the... 4407 05:10:11,102 --> 05:10:13,102 Watch yourself. 4408 05:10:13,102 --> 05:10:15,102 We get two of these, I think, right? 4409 05:10:15,102 --> 05:10:19,102 Okay, one, and then... 4410 05:10:19,102 --> 05:10:20,102 Oh, that's all right. 4411 05:10:20,102 --> 05:10:32,102 Well, congratulations, yeah. 4412 05:10:32,102 --> 05:10:35,102 Okay. 4413 05:10:35,102 --> 05:10:38,102 Final challenge is getting off the stage. 4414 05:10:38,102 --> 05:10:40,102 All right, we have a couple more. 4415 05:10:40,102 --> 05:10:41,102 What's up next? 4416 05:10:41,102 --> 05:11:00,102 We've got CryptoProof Visualizer. 4417 05:11:00,102 --> 05:11:01,102 Congratulations, Sundar. 4418 05:11:01,102 --> 05:11:02,102 What a great project, yeah. 4419 05:11:02,102 --> 05:11:12,102 Congratulations. 4420 05:11:12,102 --> 05:11:24,102 Our next honorable mention goes to NodeSignal. 4421 05:11:24,102 --> 05:11:26,102 Do you want to leave the name up? 4422 05:11:26,102 --> 05:11:40,102 Leave the name up, yeah. 4423 05:11:40,102 --> 05:11:42,102 Our next honorable mention goes to... 4424 05:11:42,102 --> 05:11:44,102 All right, what else have we got? 4425 05:11:44,102 --> 05:11:46,102 Is This Good for Bitcoin? 4426 05:11:46,102 --> 05:11:48,102 Just Ask Bits. 4427 05:11:49,102 --> 05:11:59,102 All right. 4428 05:11:59,102 --> 05:12:02,102 A couple of guys coming. 4429 05:12:02,102 --> 05:12:03,102 Great. 4430 05:12:03,102 --> 05:12:04,102 Well done, Tuma. 4431 05:12:05,102 --> 05:12:24,102 Nicely done, guys. 4432 05:12:24,102 --> 05:12:26,102 Great. 4433 05:12:26,102 --> 05:12:30,102 And our final honorable mention goes to... 4434 05:12:31,102 --> 05:12:40,102 Okay, compact block filters in bowl. 4435 05:12:40,102 --> 05:12:55,102 Congratulations. 4436 05:12:55,102 --> 05:12:57,102 All right. 4437 05:12:57,102 --> 05:13:00,102 Some very incredible projects that went through. 4438 05:13:00,102 --> 05:13:03,102 Unfortunately, only three of them could make it to the top overall. 4439 05:13:03,102 --> 05:13:05,102 Yeah, the moment we've all been waiting for. 4440 05:13:05,102 --> 05:13:09,102 So a reminder, in third place is going to be winning 750,000 4441 05:13:09,102 --> 05:13:13,102 Satoshis along with Bitcoin++ tickets and an even bigger 4442 05:13:13,102 --> 05:13:16,102 Bottle of maple syrup, which they get bigger over time. 4443 05:13:16,102 --> 05:13:20,102 And second place is going to be getting 1.75 million Satoshis as 4444 05:13:20,102 --> 05:13:24,102 Well as Bitcoin++ tickets and an even bigger bottle of maple 4445 05:13:24,102 --> 05:13:25,102 Syrup. 4446 05:13:25,102 --> 05:13:29,102 And finally, first place is winning a whopping 2.5 million 4447 05:13:29,102 --> 05:13:33,102 Satoshis, Bitcoin++ tickets, and the max addy of them all, 4448 05:13:33,102 --> 05:13:35,102 Bottles of maple syrup. 4449 05:13:35,102 --> 05:13:38,102 Enough maple syrup for a year, depending on how many pancakes 4450 05:13:38,102 --> 05:13:39,102 You eat. 4451 05:13:39,102 --> 05:13:40,102 All right. 4452 05:13:40,102 --> 05:13:43,102 So in third place goes to... 4453 05:13:43,102 --> 05:13:46,102 Actually, we have a few sponsors to thank first. 4454 05:13:46,102 --> 05:13:50,102 Bitcoin++ would not be possible without generous support of our 4455 05:13:50,102 --> 05:13:51,102 Sponsors. 4456 05:13:51,102 --> 05:13:54,102 So I want to call out to NIDIG and the human rights foundation 4457 05:13:54,102 --> 05:13:57,102 Who are our headline sponsors for not just this conference but 4458 05:13:57,102 --> 05:14:00,102 All of the other events we're doing the rest of this year. 4459 05:14:00,102 --> 05:14:02,102 So a very big thank you to them. 4460 05:14:02,102 --> 05:14:05,102 Also want to shout out stacks, who's our workshop sponsor. 4461 05:14:05,102 --> 05:14:07,102 They help us run our workshops every year. 4462 05:14:07,102 --> 05:14:09,102 So a big thank you to them. 4463 05:14:09,102 --> 05:14:12,102 And then it's not on the slides, but also thank you to layer 2 4464 05:14:12,102 --> 05:14:15,102 Labs and Paul for sponsoring this event. 4465 05:14:15,102 --> 05:14:18,102 Some really lovely banners, decorations that got contributed 4466 05:14:18,102 --> 05:14:19,102 For them. 4467 05:14:19,102 --> 05:14:22,102 So thank you very much, Paul, for making this possible. 4468 05:14:22,102 --> 05:14:24,102 We are doing an after party. 4469 05:14:24,102 --> 05:14:25,102 It's unofficial. 4470 05:14:25,102 --> 05:14:27,102 So bring some sats for beer. 4471 05:14:27,102 --> 05:14:30,102 But it will be at the rhino, which I believe is like maybe a 4472 05:14:30,102 --> 05:14:32,102 Ten-minute walk down the street. 4473 05:14:32,102 --> 05:14:36,102 So I think we'll probably get there around 637 and hope to see 4474 05:14:36,102 --> 05:14:40,102 Many of you there where we can continue talking about projects 4475 05:14:40,102 --> 05:14:42,102 And forks and consensus and bitcoin. 4476 05:14:42,102 --> 05:14:44,102 So thank you very much. 4477 05:14:44,102 --> 05:14:46,102 All right. 4478 05:14:46,102 --> 05:14:48,102 Without further ado. 4479 05:14:48,102 --> 05:14:49,102 All right. 4480 05:14:49,102 --> 05:14:50,102 Third. 4481 05:14:50,102 --> 05:14:53,102 In third place, we have actually before announcing third place, 4482 05:14:53,102 --> 05:14:57,102 We have one more very important award to give out, which is our 4483 05:14:57,102 --> 05:14:59,102 Star volunteer award. 4484 05:14:59,102 --> 05:15:02,102 So we like to give this out to the volunteer that we feel like 4485 05:15:02,102 --> 05:15:05,102 Showed up early, stayed late, was down to help out with 4486 05:15:05,102 --> 05:15:07,102 Whatever was necessary. 4487 05:15:07,102 --> 05:15:10,102 Bitcoin++ would not be possible without our volunteers. 4488 05:15:10,102 --> 05:15:13,102 So I want to issue a very heartfelt thank you to each and 4489 05:15:13,102 --> 05:15:15,102 Every one of you for signing up and showing up. 4490 05:15:15,102 --> 05:15:18,102 We're definitely looking for more volunteers for future events. 4491 05:15:18,102 --> 05:15:21,102 So if you enjoyed the conference and want to get more of a 4492 05:15:21,102 --> 05:15:24,102 Behind-the-scenes look at an upcoming event, we'll be having 4493 05:15:24,102 --> 05:15:27,102 Events in berlin and in seoul later this year, and we'd love 4494 05:15:27,102 --> 05:15:29,102 To see you there to help out. 4495 05:15:29,102 --> 05:15:31,102 So without further ado, a big thank you. 4496 05:15:31,102 --> 05:15:34,102 Oh, and they're getting hall of fame and our token of 4497 05:15:34,102 --> 05:15:37,102 Appreciation, which I seem to have lost. 4498 05:15:37,102 --> 05:15:40,102 This goes to hugo boss. 4499 05:15:41,102 --> 05:15:44,102 So congratulations, hugo. 4500 05:15:44,102 --> 05:15:48,102 My understanding is he had to catch a train already, but we're 4501 05:15:48,102 --> 05:15:49,102 Big. 4502 05:15:49,102 --> 05:15:50,102 Okay. 4503 05:15:50,102 --> 05:15:51,102 Cool. 4504 05:15:51,102 --> 05:15:52,102 Great. 4505 05:15:52,102 --> 05:15:53,102 Where were we? 4506 05:15:53,102 --> 05:15:54,102 Oh, yeah. 4507 05:15:54,102 --> 05:15:55,102 Third place. 4508 05:15:55,102 --> 05:15:59,102 So can we get a little bit of, yeah. 4509 05:15:59,102 --> 05:16:04,102 And third place goes to winning 750,000 satoshis and bitcoin++ 4510 05:16:04,102 --> 05:16:09,102 Tickets and a medium-sized bottle of maple syrup goes to 4511 05:16:10,102 --> 05:16:15,102 mtp. 4512 05:16:15,102 --> 05:16:19,102 I believe he already had to head to the airport, so big thank you 4513 05:16:19,102 --> 05:16:20,102 To him. 4514 05:16:20,102 --> 05:16:21,102 Okay. 4515 05:16:21,102 --> 05:16:27,102 Second, winning 1.75 million satoshis and bitcoin++ tickets 4516 05:16:27,102 --> 05:16:32,102 Goes to can you hack btc. 4517 05:16:33,102 --> 05:16:58,102 All right. 4518 05:16:58,102 --> 05:17:02,102 So that leaves for first place where 2.5 million satoshis and 4519 05:17:02,102 --> 05:17:04,102 Tickets to upcoming bitcoin++ tickets. 4520 05:17:04,102 --> 05:17:06,102 And a massive bottle of maple syrup. 4521 05:17:06,102 --> 05:17:10,102 And the title of overall winner of bitcoin++ consensus edition 4522 05:17:10,102 --> 05:17:14,102 Hackathon goes to template watcher. 4523 05:17:14,102 --> 05:17:16,102 Template watcher. 4524 05:17:16,102 --> 05:17:39,102 Thank you. 4525 05:17:39,102 --> 05:17:40,102 Incredible. 4526 05:17:40,102 --> 05:17:44,102 So we're all very excited about watching the upcoming forks 4527 05:17:44,102 --> 05:17:46,102 Over the next few weeks on template watcher. 4528 05:17:46,102 --> 05:17:50,102 So we hope we get it shipped to production and are looking 4529 05:17:50,102 --> 05:17:52,102 Forward to paying attention. 4530 05:17:52,102 --> 05:17:53,102 Yeah. 4531 05:17:53,102 --> 05:17:55,102 Good job. 4532 05:17:55,102 --> 05:17:57,102 I think that's all we've got, guys. 4533 05:17:57,102 --> 05:18:00,102 Thank you again to each and every one of you for showing up 4534 05:18:00,102 --> 05:18:04,102 To bitcoin++ and i can't wait to see you at a future conference. 4535 05:18:04,102 --> 05:18:06,102 So see you at the bar. 4536 05:18:06,102 --> 05:18:10,102 Massive thank you to the toronto community for welcoming us. 4537 05:18:10,102 --> 05:18:14,102 And thank you for matthew and leo who are local canadians who 4538 05:18:14,102 --> 05:18:17,102 Made this event i think a lot easier than it would have been. 4539 05:18:17,102 --> 05:18:19,102 Also kevin who works with the bitcoin++ team. 4540 05:18:19,102 --> 05:18:23,102 Alex for running the hackathon and all of our crew behind the 4541 05:18:23,102 --> 05:18:25,102 Scenes making bitcoin++ work. 4542 05:18:25,102 --> 05:18:27,102 It wouldn't be possible without you. 4543 05:18:27,102 --> 05:18:30,102 And thank you to all of you again for coming and i can't 4544 05:18:30,102 --> 05:18:32,102 Wait to see you at a future event. 4545 05:18:32,102 --> 05:18:34,102 So thank you very much and until next time. 4546 05:18:35,102 --> 05:18:40,102 Applause. 4547 05:18:40,102 --> 05:18:46,102 Music. 4548 05:18:46,102 --> 05:18:52,102 Music. 4549 05:18:52,102 --> 05:18:53,102 Hey, peter. 4550 05:18:53,102 --> 05:18:54,102 Howdy. 4551 05:18:54,102 --> 05:18:55,102 How are you doing? 4552 05:18:55,102 --> 05:18:57,102 Another conference. 4553 05:18:57,102 --> 05:18:59,102 This one is a little different. 4554 05:18:59,102 --> 05:19:00,102 Yeah. 4555 05:19:00,102 --> 05:19:02,102 It's in the town i grew up in. 4556 05:19:02,102 --> 05:19:03,102 You grew up here? 4557 05:19:03,102 --> 05:19:04,102 Like, here, here. 4558 05:19:04,102 --> 05:19:07,102 I mean, I used to have, like, an art studio just up that way. 4559 05:19:07,102 --> 05:19:11,102 I mean, the first time I was here, I was probably, like, 14 or something. 4560 05:19:11,102 --> 05:19:14,102 What was your medium of art that you explored? 4561 05:19:14,102 --> 05:19:17,102 So, I did, like, electronic art. 4562 05:19:17,102 --> 05:19:21,102 Made a bunch of stuff that you could kind of call clocks. 4563 05:19:21,102 --> 05:19:24,102 I made systems that showed behavior over time. 4564 05:19:24,102 --> 05:19:28,102 And I grew to go and hate how bullshit my entire field was. 4565 05:19:28,102 --> 05:19:30,102 Because we were really not very good at it. 4566 05:19:31,102 --> 05:19:33,102 The clock industry? 4567 05:19:33,102 --> 05:19:36,102 The entire, like, integrated media art industry. 4568 05:19:36,102 --> 05:19:39,102 I mean, there's this sort of thing where all of these electronic art pieces, 4569 05:19:39,102 --> 05:19:41,102 They all become a game of, like, spot the sensor. 4570 05:19:41,102 --> 05:19:42,102 And there will be a sensor. 4571 05:19:42,102 --> 05:19:44,102 You hit the sensor, and it does something. 4572 05:19:44,102 --> 05:19:45,102 And that's it. 4573 05:19:45,102 --> 05:19:53,102 So, you know, I tried very hard to make all my art pieces have no direct interaction with the person there. 4574 05:19:53,102 --> 05:19:55,102 It would rather be some, like, slow, long-term thing. 4575 05:19:55,102 --> 05:19:59,102 Which, again, gets back to, you kind of call them clocks. 4576 05:19:59,102 --> 05:20:02,102 Yeah, then it's kind of like a sidecar, right? 4577 05:20:02,102 --> 05:20:05,102 It's like, here's the art, and then here's the technical integration. 4578 05:20:05,102 --> 05:20:07,102 And you stick the thing in, and it's all... 4579 05:20:07,102 --> 05:20:11,102 I hate to say this, but working on Bitcoin Soft Forks is much more artistically meaningful. 4580 05:20:11,102 --> 05:20:14,102 Oh, where do you see the artistry? 4581 05:20:14,102 --> 05:20:16,102 Art is in everything. 4582 05:20:16,102 --> 05:20:17,102 Art is in a beautiful idea. 4583 05:20:17,102 --> 05:20:19,102 Check, lock, time, verify. 4584 05:20:19,102 --> 05:20:22,102 You check the lock time, and you verify. 4585 05:20:22,102 --> 05:20:25,102 It's a beautiful piece of code. 4586 05:20:25,102 --> 05:20:30,102 Now I see check, lock, time, verify in a completely different light. 4587 05:20:30,102 --> 05:20:33,102 Did you write it in Toronto? 4588 05:20:33,102 --> 05:20:37,102 Check, lock, time, verify... 4589 05:20:37,102 --> 05:20:39,102 Yeah, I would have written it in the GTA area. 4590 05:20:39,102 --> 05:20:43,102 I won't narrow it down more than that, but GTA area. 4591 05:20:43,102 --> 05:20:45,102 Although, it's possible some of it I've written while I was traveling. 4592 05:20:45,102 --> 05:20:48,102 I mean, since roughly 2014, when I was doing this full-time, 4593 05:20:48,102 --> 05:20:53,102 I suspect I've probably been to something like one Bitcoin conference every one to two months 4594 05:20:53,102 --> 05:20:56,102 for, you know, 12 years straight. 4595 05:20:56,605 --> 05:20:57,605 Yeah, that seems like a lot. Yeah, it is a lot. 4596 05:20:58,605 --> 05:21:05,605 One question I was interested to talk to you about today. One of the things that we saw a lot in these panels is this recurring theme of 4597 05:21:05,605 --> 05:21:15,605 you have to fire the miners. If the miners go against what the users want, the miners are adversarial, so they must be removed. 4598 05:21:16,605 --> 05:21:23,605 Can you explain to me, like, what is that thought process? Like, what are they trying to articulate, and do you agree with it or disagree with it? 4599 05:21:24,605 --> 05:21:33,605 So, in theory, I agree with the idea that you can go fire miners. The problem is, this is coming up in the context of BIP-110, 4600 05:21:33,605 --> 05:21:40,605 where it looks like on activation day, there's a pretty good chance they're going to have 1% hash power. 4601 05:21:41,605 --> 05:21:49,605 And under that circumstance, all right, maybe fire the miners. But to fire the miners and not have a fork, 4602 05:21:49,605 --> 05:21:55,605 the people who do the firing need to represent some kind of economic majority. 4603 05:21:55,605 --> 05:22:01,605 You know, enough people to meaningfully make the coins on the other side not worth enough. 4604 05:22:01,605 --> 05:22:06,605 And if you do a show of hands, and the people attending this, do they run a BIP-110 node? 4605 05:22:06,605 --> 05:22:09,605 I really should have done it while on stage, but I suspect it might be, you know, two, three people. 4606 05:22:09,605 --> 05:22:13,605 Like, they just, they don't have the numbers. Now, you compare that to, say, SegWit, 4607 05:22:13,605 --> 05:22:19,605 where through the UASF movement to activate SegWit, there's a legitimate fire the miners moment. 4608 05:22:19,605 --> 05:22:23,605 Now, do I think they necessarily had the economic majority? That's not clear. 4609 05:22:23,605 --> 05:22:29,605 But it was sufficiently unclear that miners said, you know what, let's avoid creating a bunch of drama 4610 05:22:29,605 --> 05:22:33,605 and just do this reasonable thing called SegWit. BIP-110 is not reasonable. 4611 05:22:34,605 --> 05:22:38,605 What's this wipe-out scenario that they keep talking about? 4612 05:22:38,605 --> 05:22:45,605 So, their hope is, I'm going to say hope, is that even if they get a minority of hash power, 4613 05:22:45,605 --> 05:22:52,605 they can threaten the majority chain, the chain that Core and all the other implementations follow, 4614 05:22:52,605 --> 05:22:57,605 in the sense that if the minority, the BIP-110 minority, eventually gets majority hash power, 4615 05:22:57,605 --> 05:23:03,605 from the point of view of the Bitcoin Core nodes and LibreRelay and so on, they would then switch. 4616 05:23:03,605 --> 05:23:06,605 Because BIP-110 is the software, it only tightens the rules. 4617 05:23:06,605 --> 05:23:13,605 From the perspective of Bitcoin Core, BIP-110 compliant blocks are all valid. 4618 05:23:13,605 --> 05:23:20,605 Now, the problem with that argument is that, yes, that might be a reasonable argument, 4619 05:23:20,605 --> 05:23:25,605 40% hash power was on BIP-110, but it'll probably have 1%. 4620 05:23:25,605 --> 05:23:30,605 And in 1%, what's the chance of 1% catching up for very low? 4621 05:23:30,605 --> 05:23:35,605 There's another thing Chris says, where it's like, okay, it's only the 1% of the hash power today, 4622 05:23:35,605 --> 05:23:39,605 but imminently before activation, the miners are going to make the switch. 4623 05:23:39,605 --> 05:23:41,605 Is there some merit to it? 4624 05:23:41,605 --> 05:23:46,605 Like, someone else told me is that if there was more fees and more economic activity 4625 05:23:46,605 --> 05:23:51,605 on the tighter ruleset chain, then the miners would switch, and it doesn't matter what happens before, 4626 05:23:51,605 --> 05:23:54,605 because after activation is when that switch would happen. 4627 05:23:54,605 --> 05:23:59,605 You know, the lack of replay protection might actually go and shoot themselves in the foot there, 4628 05:23:59,605 --> 05:24:04,605 because there will be the same amount of fees and activity on either side. 4629 05:24:04,605 --> 05:24:12,605 Now, maybe going further on, or I should say, there will be the same amount of fees and activity 4630 05:24:13,605 --> 05:24:17,605 on either side of BIP-110 compliant transactions, right? 4631 05:24:17,605 --> 05:24:21,605 Because on the BIP-110 chain, if you make a transaction, it's valid on BIP-Concord. 4632 05:24:21,605 --> 05:24:25,605 Now, that can kind of change over time as people split their coins and whatnot, 4633 05:24:25,605 --> 05:24:31,605 but it's certainly plausible that BIP-110 would not get all of this interest, 4634 05:24:31,605 --> 05:24:34,605 because it would be creating blocks a lot slower. 4635 05:24:34,605 --> 05:24:38,605 Just to give an example, let's say BIP-110 gets 1% of the hash power. 4636 05:24:38,605 --> 05:24:43,605 Now, multiply 10 minutes by 100, are you going to keep using it? 4637 05:24:43,605 --> 05:24:46,605 Well, some diehards might. You'll get roughly a block a day, 4638 05:24:46,605 --> 05:24:51,605 which is enough to go trade your coins, but it's not a pretty picture. 4639 05:24:51,605 --> 05:24:57,605 Your next halving is going to come well into the future, 4640 05:24:57,605 --> 05:25:01,605 and the halving is only going to cut the difficulty by a factor of 4. 4641 05:25:01,605 --> 05:25:05,605 So, your blocks are still slow, and then the next one will be another factor of 4, 4642 05:25:05,605 --> 05:25:08,605 and again, they're still slow. So, that'll be ugly. 4643 05:25:08,605 --> 05:25:12,605 Can you explain what replay protection is? 4644 05:25:12,605 --> 05:25:20,605 So, that is where you design the rules of the side that forks off, 4645 05:25:20,605 --> 05:25:29,605 so that transactions on the old side are not valid on the new side, or vice versa. 4646 05:25:29,605 --> 05:25:32,605 There's some different ways doing replay protection, 4647 05:25:32,605 --> 05:25:36,605 but because the BIP-110 people are convinced that they will be Bitcoin, 4648 05:25:36,605 --> 05:25:40,605 that what we call Bitcoin will be their chain, they have not done this. 4649 05:25:40,605 --> 05:25:45,605 Now, compare that to say, I think, what's a good example? 4650 05:25:45,605 --> 05:25:50,605 There are a few examples where they've just changed one little thing in the transaction format 4651 05:25:50,605 --> 05:25:54,605 to ensure that transactions don't happen on both sides. 4652 05:25:54,605 --> 05:25:59,605 This is an issue for wallets that want to cleanly separate the coins, 4653 05:25:59,605 --> 05:26:00,605 then trade them separately. 4654 05:26:00,605 --> 05:26:04,605 So, if you have good replay protection, there should be an easy way to cleanly separate them. 4655 05:26:04,605 --> 05:26:12,605 And BIP-110, the only good way to do that is deliberately create a BIP-110 non-compliant transaction. 4656 05:26:12,605 --> 05:26:16,605 Probably the simplest way to do this is just put two up-returns in it. 4657 05:26:16,605 --> 05:26:21,605 There is a video I watched from you of a talk you gave in 2015, 4658 05:26:21,605 --> 05:26:25,605 and you're describing that there's three groups in Bitcoin. 4659 05:26:25,605 --> 05:26:29,605 There's miners, the devs, and there's users. 4660 05:26:29,605 --> 05:26:34,605 So, how do we see that today? 4661 05:26:34,605 --> 05:26:39,605 What is it that the miners and the users and the devs, they're all in harmony? 4662 05:26:39,605 --> 05:26:46,605 And what is it that the miners are doing adversarially that would warrant firing them? 4663 05:26:46,605 --> 05:26:49,605 From my point of view, nothing. 4664 05:26:49,605 --> 05:26:51,605 I just don't agree with the BIP-110 guys. 4665 05:26:51,605 --> 05:26:59,605 Now, from their point of view, they think the adversariality is the fact that they have not filtered out, 4666 05:26:59,605 --> 05:27:03,605 as they term it, or censorship as other people term it, 4667 05:27:03,605 --> 05:27:06,605 transactions that the BIP-110 guys consider spam. 4668 05:27:06,605 --> 05:27:12,605 And at the moment, something like half of the transactions being mined at the moment, 4669 05:27:12,605 --> 05:27:17,605 I mean, I literally looked at memepool.space about an hour ago, 4670 05:27:17,605 --> 05:27:23,605 but half the transactions are things that BIP-110 considers spam. 4671 05:27:23,605 --> 05:27:27,605 So, other than Ocean, they're all mining this. 4672 05:27:27,605 --> 05:27:32,605 And even Ocean actually mines some of these blocks containing quote-unquote spam, 4673 05:27:32,605 --> 05:27:39,605 because miners pointing their hash power at Ocean have chosen to mine the concordant client rule, 4674 05:27:39,605 --> 05:27:41,605 you know, mempool policies. 4675 05:27:41,605 --> 05:27:45,605 Does that mean that if there's a set of all transactions right now in the mempool, 4676 05:27:45,605 --> 05:27:47,605 half of them are spam? 4677 05:27:47,605 --> 05:27:53,605 So, assuming that there was no changes in the transactions that are being made, 4678 05:27:53,605 --> 05:28:01,605 then when the fork happens, the NOTS BIP-110 chain will only be mining a subset. 4679 05:28:01,605 --> 05:28:03,605 Yes. 4680 05:28:03,605 --> 05:28:06,605 And because they're only mining a subset, 4681 05:28:06,605 --> 05:28:11,605 it wouldn't make sense that they would be able to attract the miners over to their chain, 4682 05:28:11,605 --> 05:28:15,605 because the miners would rather have the fees from the more loose rules. 4683 05:28:15,605 --> 05:28:18,605 That's a good argument. 4684 05:28:18,605 --> 05:28:24,605 Like, yeah, I mean, of course, an issue with this is at least at the moment, 4685 05:28:24,605 --> 05:28:26,605 fee revenue in general is just really low. 4686 05:28:26,605 --> 05:28:29,605 So, you can kind of go say it just doesn't matter either way. 4687 05:28:29,605 --> 05:28:35,605 But, you know, one way this plays out is you could imagine leading up to this, 4688 05:28:35,605 --> 05:28:37,605 there's more hyperannot descriptions, 4689 05:28:37,605 --> 05:28:42,605 and they push fee revenue up in a way that the BIP-110 chain doesn't. 4690 05:28:42,605 --> 05:28:47,605 However, BIP-110 does not successfully actually stop all this stuff. 4691 05:28:47,605 --> 05:28:52,605 One bizarre outcome of this could be that the inscription guys, 4692 05:28:52,605 --> 05:28:54,605 you know, that meme coin community, 4693 05:28:54,605 --> 05:28:57,605 they create a meme coin that's deliberately BIP-110 compatible, 4694 05:28:57,605 --> 05:29:00,605 and ironically push up fees on the BIP-110 chain, 4695 05:29:00,605 --> 05:29:04,605 because they're trading stuff that BIP-110 claims that they're going to stop. 4696 05:29:04,605 --> 05:29:07,605 So, this can play out in strange ways. 4697 05:29:07,605 --> 05:29:12,605 Now, in that circumstance, you could also have a circumstance 4698 05:29:12,605 --> 05:29:16,605 where most of those transactions get replayed on core, or maybe not. 4699 05:29:16,605 --> 05:29:18,605 I mean, it all depends on how this plays out. 4700 05:29:18,605 --> 05:29:21,605 But there are a lot of weird things that can happen here. 4701 05:29:21,605 --> 05:29:25,605 Does that mean that unless there is a URSF, 4702 05:29:25,605 --> 05:29:30,605 it really could be possible that the core chain would be wiped out 4703 05:29:30,605 --> 05:29:32,605 and re-org'd into an AUX chain? 4704 05:29:32,605 --> 05:29:35,605 It's absolutely possible. I think it is not likely. 4705 05:29:35,605 --> 05:29:37,605 And one reason I think it's not likely is like, 4706 05:29:37,605 --> 05:29:41,605 let's suppose that AUX survives more than a day or two. 4707 05:29:41,605 --> 05:29:44,605 So, it does have some blocks. 4708 05:29:44,605 --> 05:29:46,605 I mean, really, of course, given how slow blocks are, 4709 05:29:46,605 --> 05:29:48,605 we're really going to be talking like a week or two. 4710 05:29:48,605 --> 05:29:52,605 But if it does survive, it's quite possible the way miners deal with this, 4711 05:29:52,605 --> 05:29:58,605 they should say, look, you know, we ran invalidate block on their chain. 4712 05:29:58,605 --> 05:30:00,605 It certainly isn't going to switch. 4713 05:30:00,605 --> 05:30:02,605 It wasn't likely to switch anyway, 4714 05:30:02,605 --> 05:30:05,605 but you can be confident that the core chain is going to continue 4715 05:30:05,605 --> 05:30:07,605 even if something weird happens. 4716 05:30:07,605 --> 05:30:10,605 And one example of something weird happening could be 4717 05:30:10,605 --> 05:30:14,605 maybe the Bitcoin 10 guys do an attack against Bitcoin. 4718 05:30:14,605 --> 05:30:18,605 Maybe they start creating poison blocks that take a very long time to validate 4719 05:30:18,605 --> 05:30:24,605 to try to get hash power either off the core chain entirely, 4720 05:30:24,605 --> 05:30:26,605 or make it ineffective. 4721 05:30:26,605 --> 05:30:29,605 Maybe there's something entirely different that we didn't know about. 4722 05:30:29,605 --> 05:30:31,605 I mean, maybe there's some way that they can remotely 4723 05:30:31,605 --> 05:30:34,605 denial of service attack pools. 4724 05:30:34,605 --> 05:30:37,605 You know, the sky's the limit for what's possible. 4725 05:30:37,605 --> 05:30:40,605 Do we still poison blocks today? 4726 05:30:40,605 --> 05:30:44,605 Well, we have seen them in the past by accident. 4727 05:30:44,605 --> 05:30:46,605 A good example is F2Pool. 4728 05:30:46,605 --> 05:30:50,605 Many, many years ago, they accidentally created a block that took, 4729 05:30:50,605 --> 05:30:53,605 I think, at the time, like, say, two, three minutes to validate 4730 05:30:53,605 --> 05:30:57,605 because they create a very, very big transaction 4731 05:30:57,605 --> 05:31:01,605 that, quote-unquote, cleaned up a lot of very small transactions. 4732 05:31:01,605 --> 05:31:05,605 Sorry, a lot of small dust, if you will, outputs. 4733 05:31:05,605 --> 05:31:09,605 And due to the quadratic signature hashing bug, 4734 05:31:09,605 --> 05:31:15,605 in the particular variance that they ran into used to existing core, 4735 05:31:15,605 --> 05:31:17,605 that block just took forever to validate. 4736 05:31:17,605 --> 05:31:19,605 Now, in that case, that block stayed. 4737 05:31:19,605 --> 05:31:23,605 They didn't get re-org'd out by conflicting blocks being found, 4738 05:31:23,605 --> 05:31:25,605 so they got lucky there. 4739 05:31:25,605 --> 05:31:28,605 But there are quadratic hashing issues that remain 4740 05:31:28,605 --> 05:31:30,605 that could be exploited intentionally, 4741 05:31:30,605 --> 05:31:33,605 and maybe the Notts guys try to go do this. 4742 05:31:33,605 --> 05:31:36,605 Maybe this is part of a PR saying, like, you know, 4743 05:31:36,605 --> 05:31:38,605 Bitcoin Core failed to fix these issues. 4744 05:31:38,605 --> 05:31:43,605 We fixed it by virtue of the fact that you can't really do much with Notts. 4745 05:31:45,605 --> 05:31:48,605 I'm interested to know, we talked about how 4746 05:31:48,605 --> 05:31:51,605 the miners would be attracted to the fees, 4747 05:31:51,605 --> 05:31:53,605 whichever chain has more fees on it. 4748 05:31:53,605 --> 05:31:57,605 Is that what people are talking about when they refer to economic nodes, 4749 05:31:57,605 --> 05:31:59,605 that only the economic nodes matter? 4750 05:31:59,605 --> 05:32:02,605 Because they would be broadcasting the transactions 4751 05:32:02,605 --> 05:32:04,605 that have more fees for the miners? 4752 05:32:04,605 --> 05:32:06,605 Well, it's more than that, though. 4753 05:32:06,605 --> 05:32:12,605 Economic nodes is also about people willing to buy Bitcoin, 4754 05:32:12,605 --> 05:32:15,605 be it worth coins, be it whatever chain it is. 4755 05:32:15,605 --> 05:32:20,605 So, as an example, let's suppose I don't personally do many, if any, transactions, 4756 05:32:20,605 --> 05:32:25,605 but I'm willing to go buy all of your coinbase outputs 4757 05:32:25,605 --> 05:32:27,605 and give you fiat in return. 4758 05:32:27,605 --> 05:32:31,605 I, from your point of view, am a very relevant economic node 4759 05:32:31,605 --> 05:32:33,605 because you, as a miner, want to earn money, 4760 05:32:33,605 --> 05:32:35,605 and I'm willing to go pay you for it. 4761 05:32:35,605 --> 05:32:38,605 And my idea of what Bitcoin is is the thing that Bitcoin Core does, 4762 05:32:38,605 --> 05:32:41,605 not the thing that Notts does. 4763 05:32:41,605 --> 05:32:44,605 So I am making your coins valuable. 4764 05:32:44,605 --> 05:32:45,605 Now, it could go the other way. 4765 05:32:45,605 --> 05:32:48,605 Maybe someone says, all right, I'm only buying BIP110 coins. 4766 05:32:48,605 --> 05:32:50,605 End of story. 4767 05:32:50,605 --> 05:32:52,605 Well, a miner who chooses to mine BIP110, 4768 05:32:52,605 --> 05:32:55,605 they now have an outlet to go sell their coins. 4769 05:32:55,605 --> 05:33:01,605 Of course, the moment I go say I'm willing to buy BIP110 coins, 4770 05:33:01,605 --> 05:33:03,605 people who think Core is the way to go, 4771 05:33:03,605 --> 05:33:08,605 they can split their coins and then start dumping their supply of BIP110 coins on me, 4772 05:33:08,605 --> 05:33:10,605 and now the price goes down. 4773 05:33:10,605 --> 05:33:12,605 Now, that's assuming there even is an exchange. 4774 05:33:12,605 --> 05:33:15,605 I mean, it's quite a likely outcome of this 4775 05:33:15,605 --> 05:33:18,605 is exchanges don't even think this is going to be a thing, 4776 05:33:18,605 --> 05:33:20,605 so they don't actually provide a way to sell these coins, 4777 05:33:20,605 --> 05:33:22,605 and BIP110 just dies. 4778 05:33:22,605 --> 05:33:25,605 Has there been any response from exchanges? 4779 05:33:25,605 --> 05:33:28,605 Not that I'm aware of. 4780 05:33:28,605 --> 05:33:30,605 I don't pay a ton of attention to exchanges, 4781 05:33:30,605 --> 05:33:31,605 so I could certainly miss something, 4782 05:33:31,605 --> 05:33:34,605 but this isn't like in the lead-up to SACWIS, 4783 05:33:34,605 --> 05:33:36,605 where there were already even futures markets on this 4784 05:33:36,605 --> 05:33:39,605 in the sense that you could already pre-trade coins. 4785 05:33:40,605 --> 05:33:44,605 Okay, and then my last question I'd like to talk about is, 4786 05:33:44,605 --> 05:33:49,605 do the node runners run Bitcoin, or is it the miners? 4787 05:33:52,605 --> 05:33:54,605 Depends on what you're talking about, 4788 05:33:54,605 --> 05:33:56,605 and I think there's not a simple answer here. 4789 05:33:56,605 --> 05:34:00,605 The node runners have power, economic nodes have power, 4790 05:34:00,605 --> 05:34:02,605 miners have a type of power, 4791 05:34:02,605 --> 05:34:04,605 devs have a type of power, 4792 05:34:04,605 --> 05:34:07,605 thought leaders and influencers have a type of power. 4793 05:34:08,605 --> 05:34:10,605 There are many different types of power, 4794 05:34:10,605 --> 05:34:12,605 and it depends on what kind of thing you're talking about. 4795 05:34:12,605 --> 05:34:19,605 And I think BIP110 is a type of thing where node runners, 4796 05:34:19,605 --> 05:34:23,605 who are in a minority, who think they have power 4797 05:34:23,605 --> 05:34:25,605 because they just choose to go run some software, 4798 05:34:25,605 --> 05:34:27,605 will find the hard way they have much less power 4799 05:34:27,605 --> 05:34:29,605 than they think they do, 4800 05:34:29,605 --> 05:34:31,605 because they're not really part of the economic majority, 4801 05:34:31,605 --> 05:34:33,605 they're just a small number of people. 4802 05:34:33,605 --> 05:34:35,605 They think they can just kick the miners to the curb, 4803 05:34:35,605 --> 05:34:39,605 but unless they get a lot more people adopting this, 4804 05:34:39,605 --> 05:34:41,605 there's not much they can really do. 4805 05:34:41,605 --> 05:34:43,605 And this is particularly true in a scenario 4806 05:34:43,605 --> 05:34:46,605 where hash power just doesn't substantially mine 4807 05:34:46,605 --> 05:34:48,605 the BIP110 chain. 4808 05:34:49,605 --> 05:34:52,605 In that circumstance, you might get, like I said, 4809 05:34:52,605 --> 05:34:54,605 a block a day, and a block a day looks like a chain 4810 05:34:54,605 --> 05:34:56,605 that's useless and doesn't work. 4811 05:34:59,605 --> 05:35:02,605 An interesting question somebody asked me today, 4812 05:35:03,605 --> 05:35:06,605 he was asking about, you know, there's some proposals for BIPs 4813 05:35:06,605 --> 05:35:09,605 that seem like, okay, this is so far out there, 4814 05:35:09,605 --> 05:35:11,605 away from feasibility, like something like 4815 05:35:11,605 --> 05:35:13,605 activating simplicity. 4816 05:35:13,605 --> 05:35:14,605 Yeah. 4817 05:35:14,605 --> 05:35:16,605 That is like light years away. 4818 05:35:16,605 --> 05:35:19,605 And then you have something like check SIG from stat. 4819 05:35:19,605 --> 05:35:22,605 Fairness, I believe Liquid just did activate simplicity. 4820 05:35:22,605 --> 05:35:25,605 So the code is there, it could be done. 4821 05:35:25,605 --> 05:35:27,605 It just needs to be formally verified. 4822 05:35:27,605 --> 05:35:29,605 Yeah, well. 4823 05:35:30,605 --> 05:35:33,605 And then you have something like check SIG from stack, 4824 05:35:33,605 --> 05:35:38,605 which nobody seems to really have a strong opposition to. 4825 05:35:38,605 --> 05:35:41,605 And then it seems that the rest of the proposals 4826 05:35:41,605 --> 05:35:43,605 have some spectrum in between. 4827 05:35:43,605 --> 05:35:46,605 So for all of these different competing BIPs and proposals, 4828 05:35:46,605 --> 05:35:50,605 what does the path to consensus look like for activation? 4829 05:35:51,605 --> 05:35:54,605 Well, I mean, I did get a soft fork in, 4830 05:35:54,605 --> 05:35:57,605 check locked on verify, and my path to consensus there 4831 05:35:57,605 --> 05:35:59,605 is to pick something so simple, 4832 05:35:59,605 --> 05:36:01,605 you actually could get wide agreement. 4833 05:36:01,605 --> 05:36:04,605 And I think the next likely thing that we'll get wide agreement 4834 05:36:04,605 --> 05:36:06,605 is the great consensus cleanup. 4835 05:36:06,605 --> 05:36:09,605 It's almost everyone agrees it's a good idea, 4836 05:36:09,605 --> 05:36:11,605 fixes some issues. 4837 05:36:11,605 --> 05:36:14,605 Some people have some opposition to certain things, 4838 05:36:14,605 --> 05:36:16,605 some of it on really kind of kooky, 4839 05:36:16,605 --> 05:36:18,605 well, we'd rather exploit this bug 4840 05:36:18,605 --> 05:36:20,605 to like do this thing on Bitcoin, 4841 05:36:20,605 --> 05:36:23,605 but probably it will be uncontroversial enough 4842 05:36:23,605 --> 05:36:25,605 that there will be a path forward there. 4843 05:36:25,605 --> 05:36:28,605 And since it's uncontroversial, 4844 05:36:28,605 --> 05:36:31,605 it's possible the way this gets forward 4845 05:36:31,605 --> 05:36:34,605 is you try a minor activated soft fork first, 4846 05:36:34,605 --> 05:36:38,605 just on the basis that, look, we can all agree to go do this. 4847 05:36:38,605 --> 05:36:41,605 Of course, some people say that's controversial 4848 05:36:41,605 --> 05:36:43,605 because it puts miners first. 4849 05:36:44,605 --> 05:36:46,605 And that's BIP 54. 4850 05:36:46,605 --> 05:36:49,605 I may have my memory wrong, but you're probably right. 4851 05:36:49,605 --> 05:36:51,605 It's the one Antoine is working on. 4852 05:36:51,605 --> 05:36:53,605 Yeah, that could be right. 4853 05:36:53,605 --> 05:36:55,605 There's so many BIPs now, it's hard to remember. 4854 05:36:55,605 --> 05:36:58,605 Can you just summarize what is the great consensus cleanup? 4855 05:36:58,605 --> 05:37:04,605 So there's two main issues to exploits in Bitcoin 4856 05:37:04,605 --> 05:37:06,605 that are reasonably important, 4857 05:37:06,605 --> 05:37:08,605 which is the poison blocks issue 4858 05:37:08,605 --> 05:37:11,605 where it's roughly being related to quadratic caching. 4859 05:37:11,605 --> 05:37:13,605 If you have a really big transaction, 4860 05:37:13,605 --> 05:37:16,605 you can hash a lot of data over and over and over again 4861 05:37:16,605 --> 05:37:18,605 trying to validate the signatures. 4862 05:37:18,605 --> 05:37:21,605 We partially fix some of those issues with signature caches, 4863 05:37:21,605 --> 05:37:23,605 and there are ways to bypass that 4864 05:37:23,605 --> 05:37:26,605 and create blocks that are just really slow to validate. 4865 05:37:26,605 --> 05:37:28,605 The other issue is a time warp attack, 4866 05:37:28,605 --> 05:37:30,605 which you can kind of summarize 4867 05:37:30,605 --> 05:37:35,605 as it lets you bypass the 10 minutes per block average 4868 05:37:35,605 --> 05:37:37,605 and create blocks very close together, 4869 05:37:37,605 --> 05:37:39,605 even like seconds apart. 4870 05:37:39,605 --> 05:37:42,605 And that A has a problem 4871 05:37:42,605 --> 05:37:45,605 that you can mine through all the subsidy quickly. 4872 05:37:45,605 --> 05:37:48,605 There's disagreement on how much of a problem that is. 4873 05:37:48,605 --> 05:37:50,605 Some people like the idea. 4874 05:37:50,605 --> 05:37:52,605 I think what we can widely agree on 4875 05:37:52,605 --> 05:37:55,605 is being able to mine blocks that closely together 4876 05:37:55,605 --> 05:37:58,605 really screws up Bitcoin coming to consensus 4877 05:37:58,605 --> 05:38:00,605 at a technical level. 4878 05:38:00,605 --> 05:38:02,605 Because 6 seconds, or whatever the number is, 4879 05:38:02,605 --> 05:38:05,605 is so fast that it's hard for the data 4880 05:38:05,605 --> 05:38:08,605 to actually propagate around the world 4881 05:38:08,605 --> 05:38:11,605 in sufficient time that all miners are mining fairly. 4882 05:38:11,605 --> 05:38:13,605 Speed of light is slow. 4883 05:38:13,605 --> 05:38:17,605 6 seconds relative to the circumference of the earth 4884 05:38:18,605 --> 05:38:21,605 is a lot of time. 4885 05:38:23,605 --> 05:38:26,605 It means that a miner with negligible hash power 4886 05:38:26,605 --> 05:38:29,605 is going to spend a lot of their time just waiting, 4887 05:38:29,605 --> 05:38:32,605 not mining, because they haven't gotten the data. 4888 05:38:32,605 --> 05:38:34,605 Whereas a miner with, say, 30% hash power, 4889 05:38:34,605 --> 05:38:36,605 well, they're at an advantage 4890 05:38:36,605 --> 05:38:39,605 because it's much more likely they're building on their own block. 4891 05:38:39,605 --> 05:38:41,605 That's a real problem. 4892 05:38:41,605 --> 05:38:44,605 It's interesting to me how you think that 4893 05:38:45,605 --> 05:38:49,605 Greikinson's cleanup has such ubiquitous support. 4894 05:38:49,605 --> 05:38:51,605 There's no strong opposition to it. 4895 05:38:53,605 --> 05:38:55,605 Now we have this soft fork 4896 05:38:55,605 --> 05:38:58,605 where there's this big army of people running Bitcoin 10. 4897 05:38:58,605 --> 05:39:01,605 They say, haven't you consulted with me first? 4898 05:39:01,605 --> 05:39:04,605 Why haven't you asked me what my opinion is first? 4899 05:39:04,605 --> 05:39:06,605 What do you think about this scenario 4900 05:39:06,605 --> 05:39:08,605 when it comes to soft forks? 4901 05:39:08,605 --> 05:39:11,605 Gets the issue of not everyone's voice 4902 05:39:11,605 --> 05:39:13,605 is really considered equally. 4903 05:39:13,605 --> 05:39:16,605 Like it or not, if you have a big army of people 4904 05:39:16,605 --> 05:39:18,605 who we think are advocating for something dumb, 4905 05:39:18,605 --> 05:39:20,605 other people aren't going to listen to them. 4906 05:39:20,605 --> 05:39:24,605 And you see this in how you don't have a big army of exchanges 4907 05:39:24,605 --> 05:39:27,605 saying, yeah, we're certainly going to do Bitcoin 10. 4908 05:39:27,605 --> 05:39:30,605 Like, you know, saner economic nodes, 4909 05:39:30,605 --> 05:39:32,605 businesses on Bitcoin, 4910 05:39:32,605 --> 05:39:34,605 people with a lot of Bitcoin even, 4911 05:39:34,605 --> 05:39:36,605 they're not for this. 4912 05:39:36,605 --> 05:39:39,605 I mean, hell, even Saylor recently came out 4913 05:39:39,605 --> 05:39:41,605 saying he really didn't like Bitcoin 10. 4914 05:39:41,605 --> 05:39:43,605 Some people say the thing he wrote, 4915 05:39:43,605 --> 05:39:46,605 say he didn't like it, looked AI-generated and whatnot. 4916 05:39:46,605 --> 05:39:48,605 But the point is he was able to, 4917 05:39:48,605 --> 05:39:50,605 he was willing to come out and say, 4918 05:39:50,605 --> 05:39:52,605 yeah, I don't like this. 4919 05:39:52,605 --> 05:39:54,605 That's a very strong signal, 4920 05:39:54,605 --> 05:39:56,605 even if the way he may have written that 4921 05:39:56,605 --> 05:39:58,605 might not have met your standards. 4922 05:39:58,605 --> 05:40:01,605 Yeah, he's the biggest public holder 4923 05:40:01,605 --> 05:40:03,605 with his identity attached. 4924 05:40:03,605 --> 05:40:04,605 Yeah. 4925 05:40:04,605 --> 05:40:06,605 Indirect holder. 4926 05:40:06,605 --> 05:40:08,605 I mean, obviously it's not actually his coins, 4927 05:40:08,605 --> 05:40:10,605 but he's responsible. 4928 05:40:10,605 --> 05:40:12,605 It's not his coins and they're not held in his custody 4929 05:40:12,605 --> 05:40:14,605 and held through Coinbase. 4930 05:40:14,605 --> 05:40:16,605 But it has influence. 4931 05:40:16,605 --> 05:40:18,605 I mean, he has economic influence there 4932 05:40:18,605 --> 05:40:20,605 and that he ultimately makes decisions 4933 05:40:20,605 --> 05:40:22,605 that lead to people actually holding the coins 4934 05:40:22,605 --> 05:40:24,605 decide what is or isn't valid. 4935 05:40:24,605 --> 05:40:26,605 And, you know, one outcome of this, 4936 05:40:26,605 --> 05:40:28,605 hypothetically, could be 4937 05:40:28,605 --> 05:40:30,605 Saylor talks to the board of strategy 4938 05:40:30,605 --> 05:40:32,605 and they ultimately go tell Coinbase, 4939 05:40:32,605 --> 05:40:34,605 yeah, we want to go split the coins 4940 05:40:34,605 --> 05:40:36,605 held in storage 4941 05:40:36,605 --> 05:40:38,605 and dump them on the Bitcoin 10 markets. 4942 05:40:38,605 --> 05:40:40,605 Maybe that crashes price. 4943 05:40:40,605 --> 05:40:42,605 Who knows? 4944 05:40:42,605 --> 05:40:44,605 So, in summary, in conclusion, 4945 05:40:44,605 --> 05:40:46,605 not all actors in Bitcoin 4946 05:40:46,605 --> 05:40:48,605 are created equal. 4947 05:40:48,605 --> 05:40:50,605 Yep. 4948 05:40:50,605 --> 05:40:52,605 And Bitcoin does not 4949 05:40:52,605 --> 05:40:54,605 absolutely belong 4950 05:40:54,605 --> 05:40:56,605 to the node runners. 4951 05:40:56,605 --> 05:40:58,605 Like it or not, 4952 05:40:58,605 --> 05:41:00,605 Bitcoin is not a democracy. 4953 05:41:00,605 --> 05:41:02,605 Bitcoin is a marketplace. 4954 05:41:02,605 --> 05:41:04,605 And marketplaces can look 4955 05:41:04,605 --> 05:41:06,605 a little democratic. 4956 05:41:06,605 --> 05:41:08,605 Yes, there are, but it's not the same thing 4957 05:41:08,605 --> 05:41:10,605 as a, you know, one person, 4958 05:41:10,605 --> 05:41:12,605 one vote democracy. 4959 05:41:12,605 --> 05:41:14,605 Very good. Thank you. 4960 05:41:14,605 --> 05:41:16,605 Thank you. 4961 05:41:36,605 --> 05:41:38,605 Thank you.