Trascrizione completa di BIP 110 Explained: Bitcoin's Biggest Battle

did say in the intro, but I'm going to reiterate, we are all Bitcoin monetary maximalists here. 33 00:01:54,860 --> 00:01:58,880 So this is not like we, none of us are spam apologists or anything like that. 34 00:01:58,880 --> 00:02:02,100 But we want to take a nuanced perspective as we look at this stuff. 35 00:02:02,340 --> 00:02:06,960 So Kyle, you have done a lot of the background work on this episode here. 36 00:02:07,160 --> 00:02:14,620 Why don't you walk us through how we got to this op return debate, the core versus nots, all the fighting that we see online. 37 00:02:15,040 --> 00:02:16,400 Where did this all begin? 38 00:02:16,860 --> 00:02:24,300 First, I think we should talk about Upperturn and how that came about, because that leads into this conversation with BIP110. 39 00:02:24,980 --> 00:02:29,420 So Upperturn was first introduced in 2014 with a 40-byte limit. 40 00:02:30,000 --> 00:02:33,660 And the whole purpose of this was to mark an output as unspendable. 41 00:02:34,220 --> 00:02:37,240 And so because it's unspendable, the nodes can throw it away and prune it. 42 00:02:37,340 --> 00:02:45,000 And so it was created as a small, safe place to put non-monetary data so people can store data into the UTXO set. 43 00:02:45,000 --> 00:02:49,660 because the UTXO set is basically a giant database of all the unspent coins. 44 00:02:50,460 --> 00:02:55,760 And if there's transactions in there that are stored in your RAM that bloated up, 45 00:02:56,000 --> 00:02:58,440 it means your node has to store more and more data. 46 00:02:58,920 --> 00:03:03,780 And so if that data cannot be pruned or that transaction cannot be pruned because of that data, 47 00:03:04,220 --> 00:03:08,000 then the database that your node has to hold keeps growing forever. 48 00:03:08,000 --> 00:03:14,140 So the whole purpose is to keep unnecessary data out of the UTXO set. 49 00:03:14,140 --> 00:03:17,660 And then a year later in 2015, it was raised to 80 bytes. 50 00:03:18,000 --> 00:03:20,860 And then in 2016, it was raised to 83 bytes. 51 00:03:21,400 --> 00:03:28,080 And so since 2016, we've had pretty much a standard where the default was 83 bytes. 52 00:03:28,780 --> 00:03:42,160 And then that allowed node operators to, if they wanted to, they could always change that setting and restrict that to a lower amount or increase it to a higher amount if they wanted to. 53 00:03:42,160 --> 00:03:49,160 So that worked fine for a decade, pretty much, until inscriptions arrived in late 2022. 54 00:03:49,860 --> 00:03:52,100 So that's when the ordinals came around. 55 00:03:52,300 --> 00:03:56,560 That's when we had inscriptions, and they bypassed OpRoturn entirely. 56 00:03:57,060 --> 00:04:01,760 Because instead of putting that data into the prunable output, the OpRoturn, 57 00:04:02,300 --> 00:04:08,180 it started to stuff arbitrary things like images, videos, text, into the taproot witness. 58 00:04:08,940 --> 00:04:14,800 And so that piece of the transaction holds

a proof of what you're authorized to spend, like signatures and scripts. 59 00:04:15,140 --> 00:04:17,700 And that was introduced by SegWit in 2017. 60 00:04:18,700 --> 00:04:26,100 But I think an important thing to mention here is that witness data gets a 75% fee discount because of SegWit. 61 00:04:26,100 --> 00:04:33,140 So for every byte of data or witness data, it costs a quarter to put it in. 62 00:04:33,140 --> 00:04:44,060 And that discount was designed to encourage moving the signatures and scripts into the witness, not to make it cheap to store images or videos and things like that. 63 00:04:44,520 --> 00:04:51,320 So, for example, if you had a four megabyte witness block, that would cost the same in fees as a one megabyte of normal data. 64 00:04:51,640 --> 00:04:55,960 But it takes four times as much data on the node operators. 65 00:04:56,340 --> 00:04:58,580 So the inscriptions basically exploit that. 66 00:04:59,500 --> 00:05:02,520 And there have been people that have talked about this for a while. 67 00:05:02,520 --> 00:05:07,700 this has been a debate for quite some bit. For example, Blockstream's director of research, 68 00:05:07,820 --> 00:05:13,160 Andrew Folstra, he posted to the Bitcoin dev mailing list and he said data storage is toxic 69 00:05:13,160 --> 00:05:21,340 to the network. But he didn't see that there was a technical way to stop that. And with the data 70 00:05:21,340 --> 00:05:28,400 carrier size of being able to limit or change how much the operator is for your specific node, 71 00:05:28,400 --> 00:05:32,520 in mid-2023, it was basically deprecated. 72 00:05:33,140 --> 00:05:40,640 So they added a code change to basically say that it only covers script pubkey, which basically 73 00:05:40,640 --> 00:05:41,980 excludes witness data. 74 00:05:42,920 --> 00:05:47,600 And before that change, you could say that that setting covered all data. 75 00:05:47,960 --> 00:05:50,220 But after that, it says that it only covers for operator. 76 00:05:50,580 --> 00:05:56,460 That's basically the main story from the data carrier size and how we got to that point 77 00:05:56,460 --> 00:06:02,460 up until around 2023, 2025 and 2024, that period. 78 00:06:03,160 --> 00:06:05,320 Bert, do you want to chime in on what happened after that? 79 00:06:05,700 --> 00:06:10,800 Yeah, I think it's first very important to distinguish between consensus, 80 00:06:11,220 --> 00:06:16,020 so what is possible on the nodes itself versus mempool policy. 81 00:06:16,680 --> 00:06:22,680 So if you look at mempool policy, which is basically if you transact 82 00:06:22,680 --> 00:06:26,700 and you send a transaction out onto the network, 83 00:06:26,700 --> 00:06:31,240 it goes into this basically waiting pool of transactions 84 00:06:31,240 --> 00:06:32,620 that's going to be mined. 85 00:06:33,620 --> 00:06:35,960 And what gets into the pool 86 00:06:35,960 --> 00:06:39,400 that is determined by all the nodes on the network. 87 00:06:40,040 --> 00:06:43,280 But there are also consensus rules 88 00:06:43,280 --> 00:06:45,980 and that's what's actually possible to get into the block. 89 00:06:46,080 --> 00:06:47,620 So those are two different things. 90 00:06:48,140 --> 00:06:50,300 You've got the space where you're waiting 91 00:06:50,300 --> 00:06:51,780 for something to get into the block 92 00:06:51,780 --> 00:06:55,660 and you've got what is actually going to get into the block. 93 00:06:56,320 --> 00:06:59,100 And there's consensus rules for what can get into the block. 94 00:06:59,340 --> 00:07:04,540 And there is, let's say, rules that you can determine on your own node 95 00:07:04,540 --> 00:07:09,180 with regards to what you want to be in the waiting area before it hits the block. 96 00:07:09,980 --> 00:07:13,940 And that's a very, very important thing to distinguish here 97 00:07:13,940 --> 00:07:18,160 because in the discussions that we had, let's say, 98 00:07:18,160 --> 00:07:21,280 up until we are now here in this BIP 110 area, 99 00:07:21,780 --> 00:07:30,040 was mostly about the mempool policy part where indeed, you know, there was a relaxation of the limit, 100 00:07:30,140 --> 00:07:31,920 what can actually be in this waiting ground. 101 00:07:32,720 --> 00:07:39,220 And the reason for this is because people can actually put something straight into the blocks, 102 00:07:39,580 --> 00:07:41,120 going straight to miners. 103 00:07:41,640 --> 00:07:43,880 And that is already happening at mass scale. 104 00:07:43,880 --> 00:07:49,580 We've got some very, let's say, not so nice miners, in my opinion, in the US, 105 00:07:49,580 --> 00:07:55,960 they are letting people just side load stuff within the consensus limits onto the Bitcoin blockchain. 106 00:07:57,040 --> 00:08:00,280 And that's purely a terminal consensus. 107 00:08:00,900 --> 00:08:05,260 Okay, so maybe if I could simplify, well, I want you guys to correct me where I might be wrong, 108 00:08:05,320 --> 00:08:07,780 because I am by far the least technical person on this call. 109 00:08:08,320 --> 00:08:13,320 So when you send a Bitcoin transaction, there are different places where you can place data, 110 00:08:13,420 --> 00:08:15,060 as maybe a simplified way of thinking of it. 111 00:08:15,060 --> 00:08:18,680 The UTXO set, though, is required for you to run a node. 112 00:08:18,680 --> 00:08:38,560 And that lives in memory and eventually you run out of space. And so you need to be able to verify spendable transactions very quickly. And so if arbitrary data, we'll call it images, videos, to Kyle's point, are bloating the UTXO set, then you have this problem that you run out of space, it becomes harder to run a node. 113 00:08:39,240 --> 00:08:41,040 Op return is sort of a compromise. 114 00:08:41,320 --> 00:08:49,220 We know people are going to have metadata or something that they might want to put into a transaction that you can then prune from your node. 115 00:08:49,300 --> 00:08:51,320 So it's not bloating

the UTXO set. 116 00:08:51,380 --> 00:08:52,580 It's not taking up that space. 117 00:08:52,580 --> 00:08:59,060 I'm sure something I said, was that directionally correct, even if maybe I spoke about it in a less technical way? 118 00:08:59,140 --> 00:09:00,840 Is that a fair way of framing it? 119 00:09:01,140 --> 00:09:08,160 It's very important to, again, distinguish between what you are relaying and holding into the mempool. 120 00:09:08,160 --> 00:09:15,300 so into the pool that's going to be mined versus what is going into the set block set that are mined. 121 00:09:15,940 --> 00:09:22,100 You are always relaying in the current situation the nodes that have actually been mined, 122 00:09:22,320 --> 00:09:24,520 and that is based on consensus rules. 123 00:09:25,400 --> 00:09:30,240 Then mempool policy, you can just set freely yourself what you want to relay in your own mempool. 124 00:09:30,800 --> 00:09:35,660 And that determines, of course, on the miner side, what they are actually mining. 125 00:09:35,660 --> 00:09:46,880 So the node that the mining pool or the individual solo miner is actually running determines in their specific mempool what is going to get into the block when they mine a block. 126 00:09:47,140 --> 00:09:57,740 What is very important here is with this whole discussion, again, when you come back to the op return, the op return consensus was already on a max cap. 127 00:09:57,880 --> 00:09:59,780 There was no cap limit there. 128 00:09:59,780 --> 00:10:12,300 So if you would have a direct connection with the miners or you would be mining yourself and you have sufficient hash rate, you could just very easily fill your block with up returns, of course, very, very large transactions. 129 00:10:13,300 --> 00:10:18,260 And in the consensus rules itself, there are limits to what can be in the block. 130 00:10:18,260 --> 00:10:31,780 Now, if we would all be using Bitcoin properly, you know, as monetary maximalists, so just going back to what we initially were introduced to, I make transactions every day. 131 00:10:31,920 --> 00:10:32,980 I run a shop also. 132 00:10:33,720 --> 00:10:36,260 There's transactions, Bitcoin transactions happening every day. 133 00:10:36,380 --> 00:10:42,280 If more people would do that, then BlockSpace would be utilized for monetary use. 134 00:10:43,060 --> 00:11:01,540 Currently, there are so little use of Bitcoin that there are indeed, as Kyle is saying, very cheap transactions being able to put into, let's say, scripts on a cheaper way that can fill this space that is limited, that is kept by consensus. 135 00:11:02,220 --> 00:11:05,060 And that is actually being filled up at the moment. 136 00:11:05,380 --> 00:11:07,420 And a lot of people see this as an issue. 137 00:11:07,420 --> 00:11:25,580 But it might be the main issue that we currently have is that not enough people are using Bitcoin and that we should actually, you know, especially if we look at our clients, which are at the moment thousands, they should do more transactions, test transactions, you know, try to do some transaction on the network itself. 138 00:11:25,580 --> 00:11:35,020 Because if sufficient people do this, it will crowd out the entire problem, which is, let's say, misuse of the Bitcoin network. 139 00:11:35,020 --> 00:11:56,280 And the main thing that we can focus on with regards to using Bitcoin more is that when everyone is actually paying for actual transactions, is that these very small extra things that are added, which we see as malicious, will be crowded out directly. 140 00:11:57,100 --> 00:12:01,780 Now, I think we should go back indeed to Kyle's point. 141 00:12:01,780 --> 00:12:04,760 He was trying to set the timeline of the op-return. 142 00:12:05,400 --> 00:12:10,260 So let's say last year it was changed. 143 00:12:10,600 --> 00:12:12,840 The op-return discussion was changed a bit. 144 00:12:13,380 --> 00:12:20,840 And we went into a discussion with regards to, okay, we can set mempool policy, but that's very easily routed around, right? 145 00:12:20,860 --> 00:12:25,240 Because there are still nodes that are, you know, running different mempool policies. 146 00:12:25,560 --> 00:12:29,340 These minor operators are still allowing everything in. 147 00:12:29,780 --> 00:12:32,860 So we need to change on the consensus level. 148 00:12:33,340 --> 00:12:37,520 I think that's when I want to give it back to Kyle to talk more on the consensus level. 149 00:12:37,520 --> 00:12:46,540 I think an important point before you even get to that part is during those periods, the years before they made the change, 150 00:12:46,940 --> 00:12:55,380 which really sparked this whole debate of Bit.10 and caused it to spark that proposal for Bit.10, is the Core v30. 151 00:12:55,380 --> 00:13:09,288 And the core V30 basically before that the default for the operator was 83 bytes on the nodes So you could think that majority of nodes people that are not checking their configuration 152 00:13:10,088 --> 00:13:14,348 they just run it as whatever the defaults are, they get 83 bytes. 153 00:13:14,488 --> 00:13:18,888 And then with Core V30, that changed it to the, as Bert said, 154 00:13:19,488 --> 00:13:23,788 that it is possible to make your upper turn limit basically unlimited. 155 00:13:23,788 --> 00:13:28,128 And so they basically in v30 changed it so that the default is unlimited. 156 00:13:28,688 --> 00:13:36,228 And so we can think that the most people that when they upgrade to v30, they're not going to change the configuration. 157 00:13:36,368 --> 00:13:39,788 Let's say most people would not if they're just going to run the defaults. 158 00:13:40,848 --> 00:13:48,608 And so those nodes are running with this uncapped version where basically anything can be stored on their mempool. 159 00:13:48,728 --> 00:13:50,708 So images or whatever that gets stored. 160 00:13:50,708 --> 00:13:55,388 And obviously, as Bert was saying, that the filters get routed around. 161

00:13:56,208 --> 00:14:02,868 And because, you know, let's say I have a very conservative node, Michael has a conservative node, but Bert and some other people don't. 162 00:14:03,148 --> 00:14:05,928 They have a more liberal mempool policy. 163 00:14:06,228 --> 00:14:11,068 Then maybe I don't get in my mempool images or whatever, but maybe Bert does. 164 00:14:11,068 --> 00:14:14,588 or even in the case like Bert was saying about certain miners, 165 00:14:14,928 --> 00:14:17,368 you can just submit the transaction straight to the miner 166 00:14:17,368 --> 00:14:23,028 and bypass the nodes in general in terms of relaying that transaction 167 00:14:23,028 --> 00:14:24,188 and get it into a block. 168 00:14:25,348 --> 00:14:28,108 And so the whole purpose of BIP-110 is basically saying, 169 00:14:28,208 --> 00:14:31,068 okay, well, if the filters are just going to get routed around, 170 00:14:31,588 --> 00:14:34,588 then we will just have to implement it into consensus. 171 00:14:34,988 --> 00:14:37,248 And that's really where the whole debate came from. 172 00:14:37,848 --> 00:14:40,288 And one thing I'd say that I think is really important 173 00:14:40,288 --> 00:14:42,668 is that the miner just gets paid once, 174 00:14:43,088 --> 00:14:44,108 but the node operator, 175 00:14:44,548 --> 00:14:46,468 everyone has to store that data forever. 176 00:14:47,168 --> 00:14:49,648 And so if we don't make a stand of, 177 00:14:49,868 --> 00:14:50,848 you know, in terms of 178 00:14:50,848 --> 00:14:53,428 what are we willing to store on our nodes, 179 00:14:53,428 --> 00:14:54,928 because it's our property, 180 00:14:54,928 --> 00:14:56,468 and in 20, 30 years, 181 00:14:56,688 --> 00:14:58,788 will it become prohibitively expensive, 182 00:14:59,248 --> 00:15:01,148 both from a hardware cost 183 00:15:01,148 --> 00:15:03,728 and just from data costs and all that, 184 00:15:04,068 --> 00:15:06,188 for people to run their own full nodes, 185 00:15:06,348 --> 00:15:07,368 full archival nodes? 186 00:15:07,368 --> 00:15:09,308 And are people going to have to be forced to use, 187 00:15:09,468 --> 00:15:10,268 you know, like, 188 00:15:10,288 --> 00:15:16,008 a prune node or trust someone else's node to give them the blockchain state. 189 00:15:16,468 --> 00:15:20,628 Yeah, I see that a little bit differently because we have this consensus limit already 190 00:15:20,628 --> 00:15:23,728 where we have this four megabyte block size. 191 00:15:24,008 --> 00:15:27,968 So already there is a cap limit that is already hard enforced. 192 00:15:28,228 --> 00:15:32,148 And indeed, what we are really discussing here on the consensus changes, 193 00:15:32,148 --> 00:15:34,788 what can actually get into the node. 194 00:15:35,368 --> 00:15:38,308 And just to come back one second to the mempool, you mentioned, 195 00:15:38,308 --> 00:15:42,408 if you're on the mempool policy running different policies, 196 00:15:42,708 --> 00:15:44,508 you're actually not storing it yet.

197 00:15:44,648 --> 00:15:47,968 You're just temporarily holding that on your node. 198 00:15:48,908 --> 00:15:51,088 And then when the block is actually mined, 199 00:15:51,148 --> 00:15:52,388 that is what actually settled. 200 00:15:52,928 --> 00:15:55,188 So we did a very nice thing, Kyle, 201 00:15:55,188 --> 00:15:57,508 if you remember where you were running nodes, 202 00:15:57,948 --> 00:15:58,968 I was running core. 203 00:15:59,628 --> 00:16:01,868 And core is actually capable of doing 204 00:16:01,868 --> 00:16:05,488 sub one set per virtual byte transactions. 205 00:16:05,488 --> 00:16:11,548 So if Kyle looks at his mempool, you can see it live and very nicely visualized. 206 00:16:11,728 --> 00:16:17,328 If you run a node, you can see exactly what is waiting to be mined on your node itself. 207 00:16:17,888 --> 00:16:20,448 And if you run nodes, that's a very empty mempool. 208 00:16:20,968 --> 00:16:29,288 And if you run core and you have relaxed limits and you run basically a very free node where you accept everything, you will see a lot of transactions there. 209 00:16:29,728 --> 00:16:32,128 And you can also go sub one. 210 00:16:32,128 --> 00:16:36,288 so lower than one Satoshi per virtual byte on that core 211 00:16:36,288 --> 00:16:38,188 and then relay it through the network. 212 00:16:39,068 --> 00:16:43,688 And once that block is actually mined with the sub one, 213 00:16:43,788 --> 00:16:47,028 it will actually also be embedded on Kyle's node, 214 00:16:47,148 --> 00:16:48,028 which is the nodes node. 215 00:16:48,448 --> 00:16:50,108 And that's currently the case. 216 00:16:50,788 --> 00:16:53,768 Now, when you start to go on the consensus level, 217 00:16:53,768 --> 00:16:56,708 which Bit.1.10 is, there are a lot of transactions 218 00:16:56,708 --> 00:17:01,108 that are currently being embedded in the blockchain on core 219 00:17:01,108 --> 00:17:06,448 that Kyle is not going to accept even on his node, on his hardware itself. 220 00:17:07,008 --> 00:17:09,908 And that's basically where BIP-110 starts to come in, 221 00:17:10,348 --> 00:17:12,588 where you do a consensus change and you say, 222 00:17:12,688 --> 00:17:16,828 okay, I don't actually really don't want this on my node itself. 223 00:17:17,168 --> 00:17:19,348 And that is where we are heading for now. 224 00:17:19,748 --> 00:17:23,408 Okay, so we're going to talk more about BIP-110 and what it changes, 225 00:17:23,408 --> 00:17:27,428 but just to make sure that the remainder of the history is discussed. 226 00:17:27,428 --> 00:17:36,868 So in June 25, Core V30, or I guess it was proposed that they're going to blow out the OpReturn relay limit from 83 to 100,000 bytes. 227 00:17:37,288 --> 00:17:40,908 So basically, you can put almost anything that you want in OpReturn. 228 00:17:41,788 --> 00:17:45,768 That was when really the vocal opposition heated up. 229 00:17:45,948 --> 00:17:49,108 We saw many people begin running NOTS nodes. 230 00:17:49,788 --> 00:17:55,748 It's not perfectly, by the way, for all of our listeners, it is not perfectly verifiable if these are real individuals, 231 00:17:55,748 --> 00:18:01,108 if these are virtual machines, bots, you can't know that for certain. 232 00:18:01,648 --> 00:18:05,308 One comment I'll make is it seems to be something of a grassroots movement. 233 00:18:05,988 --> 00:18:11,448 I had Matt Hill on the podcast recently, or his episode might be coming out after this, actually. 234 00:18:11,608 --> 00:18:14,708 But one of the things he talked about was actually showing some of their revenues. 235 00:18:14,708 --> 00:18:23,368 They started selling a lot of nodes afterwards, indicating that there were a lot of people who maybe were discontented with the core move to blow out the op return limit 236 00:18:23,368 --> 00:18:26,348 in order to start running a node for maybe the first time 237 00:18:26,348 --> 00:18:28,608 and presumably to some degree running not. 238 00:18:28,728 --> 00:18:32,188 So his point was a lot more nodes actually are coming online. 239 00:18:32,328 --> 00:18:35,608 It doesn't seem evident that it's at least not all virtual machines. 240 00:18:36,108 --> 00:18:40,868 Any comments on the controversy around the op return limit being removed? 241 00:18:40,868 --> 00:18:42,508 And then I guess that took effect. 242 00:18:42,608 --> 00:18:44,248 Was that the October 10th? 243 00:18:45,408 --> 00:18:47,068 That was the big move. 244 00:18:47,248 --> 00:18:48,228 Core V30 came out. 245 00:18:48,368 --> 00:18:49,628 Everyone blamed the price crash. 246 00:18:50,688 --> 00:18:52,768 October 10th was when V30 came out, 247 00:18:52,768 --> 00:18:59,248 But the actual PR that you're mentioning, where it moved from 83 bytes to 100,000, was in June. 248 00:18:59,668 --> 00:19:01,348 And there was a lot of community backlash. 249 00:19:01,888 --> 00:19:06,608 Because in that PR as well, they basically deprecated data carrier size. 250 00:19:07,068 --> 00:19:10,968 So it doesn't really matter whether you choose to restrict it or not. 251 00:19:11,308 --> 00:19:14,908 Because now the default would be basically uncapped. 252 00:19:14,908 --> 00:19:21,648 And so when you're sending it through the network, and there's other nodes that just accept the uncapped version, 253 00:19:21,648 --> 00:19:26,888 then it doesn't really matter because they can either do that or they could just send it to the 254 00:19:26,888 --> 00:19:31,268 miner and then the miner can just put it in the block and then you have to store it forever. 255 00:19:31,948 --> 00:19:36,648 And so the other thing I think is also important to mention is that this bit.10 is temporary. So it 256 00:19:36,648 --> 00:19:41,608 only lasts for one year and then it expires automatically. So I'm not, and I don't think 257 00:19:41,608 --> 00:19:48,988 any other people within the spec itself of bit.10, it doesn't stop spam. It doesn't, this isn't like 258 00:19:48,988 --> 00:19:53,848 the end

goal. But it's a way to give us time to figure out from a long-term perspective, 259 00:19:53,848 --> 00:19:58,628 how are we going to solve this problem? So would it be fair to say then running 260 00:19:58,628 --> 00:20:06,048 knots is a philosophical stance because those transactions with the arbitrary data are still 261 00:20:06,048 --> 00:20:10,348 going to be routed either directly to a miner, something like Slipstream, for example, or 262 00:20:10,348 --> 00:20:14,168 through the peer-to-peer network, because many people are going to be running 263 00:20:14,168 --> 00:20:20,588 Core v30 or have changed data carrier size to allow these larger op return transactions. 264 00:20:21,448 --> 00:20:27,188 And so running NOTS alone doesn't prevent these transactions from being broadcast throughout 265 00:20:27,188 --> 00:20:29,428 the network and for a miner getting them into the block. 266 00:20:29,428 --> 00:20:34,728 But it might be a way to signal discontent with what Core has done. 267 00:20:34,948 --> 00:20:39,448 Is that a fair way of framing for folks who are currently running NOTS or considering it? 268 00:20:39,848 --> 00:20:42,368 That's currently the case, Michael, exactly as you're saying. 269 00:20:42,368 --> 00:20:53,128 But now, of course, during this signaling period and the BIP 110 movement happening, especially during this period, we might see a chain split. 270 00:20:53,808 --> 00:21:03,808 And that's becoming very interesting because if we are going to see a chain split, I think that's very exciting for a lot of Bitcoiners because it's a very interesting time. 271 00:21:03,928 --> 00:21:07,228 We haven't seen a chain split for almost nine years, right? 272 00:21:07,288 --> 00:21:11,628 It's 2017 when we saw the user activated software. 273 00:21:12,368 --> 00:21:19,208 And that was totally different in comparison with what we are going to see at this specific activation period. 274 00:21:19,408 --> 00:21:32,068 So currently, you could see NOTs and the NOTs until 29.3.1 came about, see it as being some kind of discontent movement with core. 275 00:21:32,068 --> 00:21:42,508 And I agree, you know, it should have been taken more seriously with regards to doing a change on the mempool policy. 276 00:21:42,768 --> 00:21:52,548 There should have been more insight with regards to governance structure on the core side and what you actually are doing on the core side. 277 00:21:52,548 --> 00:21:56,308 I think it's in that sense a poor management, let's say. 278 00:21:56,488 --> 00:22:10,848 But the current direction where we see NOLS slash BitPunk 10, where we basically have a single person controlling that implementation, a single person who has the merge access, is also a huge risk. 279 00:22:11,428 --> 00:22:16,168 And I think it's very nice that Kyle is saying, yeah, it's temporary and we just need to figure it out. 280 00:22:16,728 --> 00:22:20,648 Yes, I think we need to figure out how we want to continue on Bitcoin in and by itself. 281 00:22:20,648 --> 00:22:23,508 but the current direction has risks. 282 00:22:23,788 --> 00:22:26,508 And that's something that I think we really have to talk about 283 00:22:26,508 --> 00:22:28,968 with regards to if a chain split occurs, 284 00:22:29,408 --> 00:22:31,028 that you know what you are doing, 285 00:22:31,348 --> 00:22:32,808 what are you actually running, 286 00:22:33,428 --> 00:22:35,348 and what could the impact be. 287 00:22:35,808 --> 00:22:39,908 Okay, so this is where the rift lies between the two of you. 288 00:22:40,228 --> 00:22:43,128 You guys, I think it would be fair to say 289 00:22:43,128 --> 00:22:45,068 you agree on the history of what's happened. 290 00:22:45,588 --> 00:22:47,328 You both have your own issues 291 00:22:47,328 --> 00:22:49,808 with the way things have played out thus far. 292 00:22:49,808 --> 00:22:55,028 and where you seem to part ways is specifically on running knots. 293 00:22:55,828 --> 00:22:58,368 So Barrett, I'm going to let Kyle sort of run with this first, 294 00:22:58,428 --> 00:22:59,488 and I want you to respond to him. 295 00:22:59,888 --> 00:23:03,448 But running knots, but then maybe more significantly, BIP-110. 296 00:23:04,328 --> 00:23:08,988 So Kyle, why don't you describe what BIP-110 is? 297 00:23:08,988 --> 00:23:12,288 What does it do for this approximately a year? 298 00:23:12,968 --> 00:23:16,428 And why is it something that you find appealing? 299 00:23:16,428 --> 00:23:21,388 And then Bert, you get to explain what some of those risks are that you believe exist. 300 00:23:21,388 --> 00:23:29,268 Sure. And I just want to mention something on what Bert said about the chain split risk is that it is a risk with any user activated software. 301 00:23:29,268 --> 00:23:31,788 So I don't think it's something specific to BIP-110. 302 00:23:31,788 --> 00:23:48,128 And if we look in the past, like SegWit, BIP-148 was actually much more new in terms of what it was doing was much different from today with BIP-110, which is actually just constricting to what we had a year ago. 303 00:23:48,748 --> 00:23:50,708 But yes, it is also temporary. 304 00:23:51,028 --> 00:23:54,288 So there are obviously differences with that. 305 00:23:54,288 --> 00:24:09,448 But I think the other thing is that the miner revenue with the inscriptions of what they would lose, let's say, in this year period, if Bit.10 is activated, then I don't really see why a miner would sustain a chain split over a tiny percent of spam revenue. 306 00:24:10,028 --> 00:24:11,808 I'm not sure, Bert, if you disagree with that. 307 00:24:12,248 --> 00:24:17,148 Yeah, so now this is becoming a bit difficult, I think, for the listener to understand. 308 00:24:17,928 --> 00:24:23,288 There is, let's say, a chain split risk on both sides. 309 00:24:23,288 --> 00:24:24,148 Let's say yes. 310 00:24:24,248 --> 00:24:25,968 Explain the concept of a chain split. 311 00:24:26,348 --> 00:24:27,588 Explain what that means exactly.

312 00:24:27,808 --> 00:24:32,248 I mean, I think it seems self-evident to us probably, but for someone who's listening. 313 00:24:32,888 --> 00:24:39,548 Yeah, so you have very much restrictions on BIP-110, what it accepts on its own nodes. 314 00:24:39,548 --> 00:24:56,088 So the people that are running BIP-110 will say when a miner was running Core or Libre Relay or one of the other Bitcoin node types, a block which doesn't fulfill the consensus of these NOTs BIP-110 nodes. 315 00:24:56,588 --> 00:25:03,928 That block will actually not be accepted on the NOTs nodes with the BIP-110 activation. 316 00:25:03,928 --> 00:25:25,688 So at that point, they will only build forward on their own block that was or has to be mined by a BIP-110 signaling miner that is actually running BIP-110 and only accepting the blocks under the accordance of the BIP-110 consensus rules. 317 00:25:25,688 --> 00:25:39,148 Now, the expectation is that not the majority of miners might go along with running BIP-110 and heavy restrictions on their blocks that they are mining. 318 00:25:39,688 --> 00:25:51,988 So what could then occur is that there are some miners that do, some miners that don't, and then the BIP-110 miners will only build forward on their restrictive blocks. 319 00:25:51,988 --> 00:26:08,936 while the ore or Libre Relay or other miners that are much more liberal and much more open to mine everything will just build forward on everything They have no restrictions so they will build forward And then the question is 320 00:26:08,936 --> 00:26:15,096 who is going to be the majority? And that is what a split basically means. We will get 321 00:26:15,096 --> 00:26:23,896 two Bitcoin networks where either one of them, let's say, wins the race of having the most 322 00:26:23,896 --> 00:26:27,756 proof of work and most blocks at the end of a certain period. 323 00:26:28,596 --> 00:26:35,636 And at the end of that period, it is determined if it's either Bit.1.10 or the current situation 324 00:26:35,636 --> 00:26:36,396 where we are. 325 00:26:37,356 --> 00:26:43,436 And that split could mean that if you are on a Bit.1.10 node and you're actually doing 326 00:26:43,436 --> 00:26:49,176 transactions where blocks are only built on the conservative side, that you are actually 327 00:26:49,176 --> 00:26:55,496 splitting off the actual Bitcoin network and you're in a different split of the network and 328 00:26:55,496 --> 00:27:02,976 you reside there with your transaction. So that's why in general, I think that's what both Kyle and 329 00:27:02,976 --> 00:27:09,116 I, but also the broad technical team within the Bitcoin way has concluded, it might be wise if 330 00:27:09,116 --> 00:27:15,816 you're not very tech savvy to maybe not do a transaction during the activation period if you're, 331 00:27:15,816 --> 00:27:23,376 for example, running bit.10, but also if you're running core, again, it might not be the best 332 00:27:23,376 --> 00:27:28,616 period to do transactions

because there might be some chaos with regards to this split. 333 00:27:29,516 --> 00:27:39,016 And in general, it might then make sense to think twice about what you are actually running and what 334 00:27:39,016 --> 00:27:43,916 is actually happening. And I think we need to supply us with some really nice resources that 335 00:27:43,916 --> 00:27:49,516 we already discussed before this recording, where you can actually see what happens with 336 00:27:49,516 --> 00:27:55,496 what percentage of mining rate is actually signaling a certain direction. 337 00:27:56,356 --> 00:28:00,016 And this will give you more clarity of what might happen. 338 00:28:00,396 --> 00:28:01,136 But we don't know. 339 00:28:01,376 --> 00:28:02,076 Kyle doesn't know. 340 00:28:02,336 --> 00:28:03,396 I don't know. 341 00:28:03,556 --> 00:28:06,676 And the entire Bitcoin way team doesn't actually know. 342 00:28:07,296 --> 00:28:12,876 And I think that is very important for us to emphasize that we can see a little bit of 343 00:28:12,876 --> 00:28:16,256 chaos in August, and people need to be aware of that. 344 00:28:16,456 --> 00:28:20,716 Yeah, and I also say that if we look at Segwit, for example, for a long time, there wasn't 345 00:28:20,716 --> 00:28:22,736 signaling until the last period. 346 00:28:22,736 --> 00:28:29,036 So I agree with Bert that we shouldn't assume anything until we get closer to the activation 347 00:28:29,036 --> 00:28:33,596 date and then figuring out from there what to do, because we don't know what's going 348 00:28:33,596 --> 00:28:33,936 to happen. 349 00:28:34,116 --> 00:28:37,016 And signaling can happen very quickly from the miner side. 350 00:28:37,416 --> 00:28:42,016 But one thing I also think is worth mentioning, if the chain does split, people should not 351 00:28:42,016 --> 00:28:47,116 be afraid in the sense that they're not going to lose your Bitcoin. You're going to have the coins 352 00:28:47,116 --> 00:28:52,896 or the keys to control the coins on both sides of the chain. So nobody is losing any ownership of 353 00:28:52,896 --> 00:28:59,856 the Bitcoin that you already have. And just to be a little bit attached to that. So in my specific 354 00:28:59,856 --> 00:29:05,656 personal situation, I run a Lightning node. And let's say that that chain split does occur and I 355 00:29:05,656 --> 00:29:11,496 would be running BIP110 with my Lightning node. I might indeed be in the chain split of BIP110 356 00:29:11,496 --> 00:29:16,256 and then I basically disconnect with my peers 357 00:29:16,256 --> 00:29:18,096 that are still on the other network. 358 00:29:18,456 --> 00:29:21,616 That means that you get forced closures on your Lightning node 359 00:29:21,616 --> 00:29:24,476 and that costs quite some money. 360 00:29:25,076 --> 00:29:28,436 So there are some risks for the more advanced users, 361 00:29:28,656 --> 00:29:32,876 but we expect them to be the people that understand this risk anyway 362 00:29:32,876 --> 00:29:37,296 and

would be careful with regards to this split risk. 363 00:29:37,476 --> 00:29:39,076 So it would now be a good time. 364 00:29:39,436 --> 00:29:40,916 I pulled this up on my screen. 365 00:29:40,916 --> 00:29:46,416 these different scenarios for how this could play out. So scenario A is BIP-110 activates with 366 00:29:46,416 --> 00:29:51,776 majority hash rate. Kyle, do you want to walk through what all this means and maybe talk through 367 00:29:51,776 --> 00:29:56,996 what people might anticipate? So if BIP-110 activates with majority hash rate, then obviously 368 00:29:56,996 --> 00:30:03,356 if you are running NOTS with the RDTS, RDTS is a synonym for BIP-110. It stands for reduced data 369 00:30:03,356 --> 00:30:09,816 temporary software. That's just the name of what BIP-110 is. So in the case that BIP-110 activates 370 00:30:09,816 --> 00:30:11,476 with majority hash rate. 371 00:30:11,856 --> 00:30:13,196 We're looking here at the risks. 372 00:30:13,736 --> 00:30:15,736 If you're running NOTS and the BIP-110, 373 00:30:16,336 --> 00:30:19,176 then there's pretty much no risk there. 374 00:30:19,276 --> 00:30:22,056 You are basically enforcing all of the BIP-110 rules 375 00:30:22,056 --> 00:30:24,076 and then you would be on the longest chain. 376 00:30:24,536 --> 00:30:28,076 And so if you're using 29.3 core or core V30 377 00:30:28,076 --> 00:30:31,116 or NOTS without BIP-110, 378 00:30:31,716 --> 00:30:34,296 then basically it would be recommended 379 00:30:34,296 --> 00:30:36,296 that you upgrade your node. 380 00:30:36,636 --> 00:30:38,816 And you basically, if you don't upgrade your node, 381 00:30:38,816 --> 00:30:41,436 then you're basically trusting the miners. 382 00:30:41,696 --> 00:30:45,316 If on that chain they're producing, for example, an invalid block, 383 00:30:46,056 --> 00:30:51,256 you would be able to see, let's say, an invalid transaction on your node, for example, 384 00:30:51,636 --> 00:30:55,736 that is not actually there because you're not on the right chain effectively. 385 00:30:56,216 --> 00:31:01,776 Okay. And then if you're running an earlier version of Core, Core v30, 386 00:31:02,516 --> 00:31:07,236 maybe just kind of describe some of these, or Barrett, if you have any comments. 387 00:31:07,236 --> 00:31:14,936 If you're running core 29.3 or B30 or NOTs before without BIP110, then your node is just following the longest chain. 388 00:31:15,196 --> 00:31:18,216 So you're just trusting the miners and your node is not enforcing the rules. 389 00:31:18,596 --> 00:31:20,696 The whole purpose of running a node is to enforce the rules. 390 00:31:21,296 --> 00:31:27,556 So your node basically cannot confirm from a consensus perspective what those rules are. 391 00:31:27,756 --> 00:31:31,316 And so you're just trusting what the miners are giving you effectively on your node. 392 00:31:31,316 --> 00:31:53,256 One very important detail here, you see that at the top, BIP110 activates with majority hash rate. If it

doesn't activate with majority hash rate, there is much more risk. And that's the next page, where indeed, if you're then running BIP110, then you get into a fork. And that's the chain split, which we were basically discussing. 393 00:31:53,256 --> 00:32:09,036 Right. And I think also the whole bet behind Bit.10 is that the miners will not sustain a chain split for a tiny percentage of the revenue, which is driven by spam and these JPEGs and ordinals and things like that. 394 00:32:09,036 --> 00:32:29,176 And so the idea would be that, let's say it activates without majority hash rate, that if you think about an economic node, people that are using Bitcoin, paying with Bitcoin, receiving Bitcoin with their own nodes, that they would end up moving over to that BIP110 chain because there's no point to go on the other chain. 395 00:32:29,176 --> 00:32:34,736 and like i said before that this is a temporary activation so it's not something that would last 396 00:32:34,736 --> 00:32:39,976 forever but it is something that that is a trade-off if you are going to run knots with 397 00:32:39,976 --> 00:32:45,356 bit 110 you need to understand that in the event there is a chain split you are basically betting 398 00:32:45,356 --> 00:32:49,436 that there's going to be people moving over to that chain and if that doesn't happen then you're 399 00:32:49,436 --> 00:32:54,316 basically on a minority fork effectively and then that goes back to bird's points that you should 400 00:32:54,316 --> 00:32:59,076 understand the risks associated with that okay and that and that's the user activated soft fork 401 00:32:59,076 --> 00:33:02,496 is that migration. Is that correct? 402 00:33:03,096 --> 00:33:03,296 Right. 403 00:33:03,796 --> 00:33:08,736 And then obviously if it activates without majority hash rate, 404 00:33:08,876 --> 00:33:11,416 all of these other older versions of Core, Core v30, 405 00:33:11,876 --> 00:33:13,236 you're on the majority chain. 406 00:33:13,376 --> 00:33:16,116 There's really nothing problematic about that. 407 00:33:16,216 --> 00:33:19,796 And so the big question is, which is it going to do? 408 00:33:19,836 --> 00:33:21,016 And are you going to be prepared? 409 00:33:21,516 --> 00:33:24,276 Could maybe you guys talk a little bit about if you're a node runner, 410 00:33:24,276 --> 00:33:27,336 let's say you're running NOTS, you're signaling BIP 110, 411 00:33:27,336 --> 00:33:33,716 and BIP-110 does not activate with majority hash rate 412 00:33:33,716 --> 00:33:36,156 or it activates without majority hash rate, 413 00:33:36,396 --> 00:33:37,076 what do you do? 414 00:33:37,196 --> 00:33:39,916 Is there like a period of time that you waited out to see? 415 00:33:39,916 --> 00:33:41,516 To Baird's point earlier, 416 00:33:41,716 --> 00:33:44,416 you don't send transactions during this period. 417 00:33:44,656 --> 00:33:47,096 What should people be thinking about here? 418 00:33:47,576 --> 00:33:51,156 So I think it's wise to not upgrade,

419 00:33:51,396 --> 00:33:53,676 let's say to the latest version of Core. 420 00:33:54,036 --> 00:33:57,256 It's not wise to upgrade to the latest version of Nots. 421 00:33:57,336 --> 00:34:01,216 that's actually running Bit.10 because you can just wait this out. 422 00:34:01,936 --> 00:34:05,536 So you can be the Switzerland, let's say, in the wars, right? 423 00:34:05,676 --> 00:34:09,616 So you can just sit back, relax, and enjoy the show 424 00:34:09,616 --> 00:34:11,316 and see whatever is going to happen. 425 00:34:11,936 --> 00:34:17,876 And for sure, your Bitcoin is just sitting, let's say, in self-custody. 426 00:34:18,556 --> 00:34:19,916 You are running a node. 427 00:34:19,916 --> 00:34:23,176 You might be signaling either an earlier version of nodes 428 00:34:23,176 --> 00:34:25,676 or signaling an earlier version of core. 429 00:34:26,656 --> 00:34:34,776 But during this period, if you don't do much, then there is no real risk in any fashion because you're not transacting. 430 00:34:35,096 --> 00:34:39,216 So you're not in any of the blocks where some of this chaos ensues. 431 00:34:39,996 --> 00:34:54,496 Now, if you want to be at the forefront of the Bit110 and you want to signal and you still want to use your Bitcoin lavishly during this period, there is this little risk of being in this chain split. 432 00:34:54,496 --> 00:35:03,516 and then of course again your bitcoin will be in this chain split and then you might be able to call 433 00:35:03,516 --> 00:35:09,416 us at the end you know i'm in this chain split and i don't know what to do if you're not technical 434 00:35:09,416 --> 00:35:18,096 so we prefer that not to happen we prefer people to just remain on a conservative stance watch what 435 00:35:18,096 --> 00:35:24,596 happens. And then when that period is over, it's a signaling period that will take a couple of 436 00:35:24,596 --> 00:35:31,736 weeks. When that is over, then you can upgrade if you like. But being conservative has always been 437 00:35:31,736 --> 00:35:38,076 one of the best ways if you're just a hodler and not a very active participant in the network, 438 00:35:38,476 --> 00:35:42,916 which currently most of our clients are. They are mostly hodlers, not people that are daily 439 00:35:42,916 --> 00:35:46,596 transacting on the Bitcoin and on the Bitcoin blockchain itself. 440 00:35:47,236 --> 00:35:49,756 Yeah, I think if you're going to be running, for example, 441 00:35:51,036 --> 00:35:54,376 the older versions of Core or the older version of Nuts without the Bit.10, 442 00:35:54,616 --> 00:35:58,376 if Bit.10 activates with majority hash rate, you will still be on the same chain. 443 00:35:59,136 --> 00:36:02,896 If Bit.10 doesn't activate without majority hash rate, 444 00:36:03,496 --> 00:36:06,396 then obviously you'd still be on the majority chain. 445 00:36:06,796 --> 00:36:08,416 So there's no real change from the status quo. 446 00:36:08,736 --> 00:36:10,196 I think if you want to make the

choice, 447 00:36:10,196 --> 00:36:15,596 Obviously, I think everyone should just do their own due diligence and education on what they want to choose. 448 00:36:16,036 --> 00:36:31,216 But ultimately, if you do choose to run NOTS with BIP 110, then the whole thesis is that if BIP 110 activates with minority hash rate, that your bet is that the miners are going to follow the economic activity. 449 00:36:31,216 --> 00:36:36,056 So merchants, users, exchanges would move to that chain and use that. 450 00:36:36,056 --> 00:36:43,756 So the node operators are basically forcing the miners to comply by threatening to reject any non-signaling blocks that they produce. 451 00:36:44,656 --> 00:36:48,416 And I think that's, at the end of the day, the decision that people have to make. 452 00:36:48,976 --> 00:36:56,596 And like Bert said, if you don't understand this stuff, if you think that this is too complicated, then it's best focus on being neutral. 453 00:36:57,056 --> 00:36:59,756 Don't do something that you're not really sure of. 454 00:36:59,756 --> 00:37:14,156 So I think that's the main thing that if you're watching this and you're still not sure, it's better to be neutral than to run something that you don't really understand and then be in a situation where you need help and you don't know what's going on. 455 00:37:14,476 --> 00:37:16,556 And then you're in an uncomfortable situation. 456 00:37:16,556 --> 00:37:35,836 So just to spell it out, the most neutral you could be might be something like running Core v29, where you're not indicating support for Core v30, but you're not taking on the risk that Baird outlined, which, by the way, I want to dig into more of being on an implementation with effectively a single maintainer. 457 00:37:37,056 --> 00:37:44,556 That's what you would define as like the most, that's plain Switzerland, is running something like Core v28, Core v29. Is that correct? 458 00:37:44,556 --> 00:37:50,016 Yeah, and that's the conservative approach and you just see what happens. 459 00:37:50,276 --> 00:38:05,956 And coming back to the beginning, I think it's very important that if we really want to, let's say, kill the spam and get rid of all this stuff that is basically polluting the network, we need to start doing this. 460 00:38:05,956 --> 00:38:09,876 I grabbed this specifically, which is called a coin join. 461 00:38:10,476 --> 00:38:21,856 And people should start to dig into that because if sufficient people start to run coin joins and to anonymize, even though it's a little part maybe of their stack, it's active use for Bitcoin. 462 00:38:22,436 --> 00:38:29,356 So you constantly basically mix coins and you create a growing anonymization set of coins on the network. 463 00:38:29,356 --> 00:38:50,116 And if that group of anonymized coins is large enough, it becomes almost impossible for analysis companies to actually, you know, get back to tracing who's actually holding which coins, which is currently the majority with

regards to all the KYC policies, especially where I'm from in Europe, but also in the US. 464 00:38:50,116 --> 00:39:12,484 And the amazing thing is if we actually focus on that part you know privacy security and using Bitcoin in and by itself then we are for sure going to win And that something that I really missing We are really diverting into a discussion which sounds quite you know like oh there an emergency on Bitcoin 465 00:39:13,264 --> 00:39:14,524 It's not an emergency. 466 00:39:14,824 --> 00:39:15,884 That's not how I see it. 467 00:39:15,884 --> 00:39:24,504 I think the real emergency that we have is that we're not using it enough and we could use it very, very nicely by doing coin joins, 468 00:39:24,504 --> 00:39:31,764 doing anonymization with our transactions and then using the network properly and therefore 469 00:39:31,764 --> 00:39:37,604 pushing the fees up a little bit and crowding out all the stuff that we don't like to see there. 470 00:39:38,124 --> 00:39:42,724 I agree. Definitely use your Bitcoin. Okay, so guys, I've got a question for you. I'm reluctant 471 00:39:42,724 --> 00:39:49,704 to ask this because I don't want anyone to take away like that we're putting odds on anything. But 472 00:39:49,704 --> 00:39:56,324 if you were to bet based on what you're seeing in terms of signaling, activation, growth of knots, 473 00:39:56,664 --> 00:40:01,944 online discourse, all of these variables, what do you think is going to happen during this 474 00:40:01,944 --> 00:40:07,044 activation period? And no one should take this as like, you know, a crystal ball, but I'm curious 475 00:40:07,044 --> 00:40:13,344 if you guys have any. I don't know. I don't know. This is the amazing thing. I don't know. And you 476 00:40:13,344 --> 00:40:19,984 have to be honest if you don't know right like i'm also just trying to put it in the right words 477 00:40:19,984 --> 00:40:25,224 so for the general public and i think kyle is doing it exactly the same from his perspective 478 00:40:25,224 --> 00:40:31,144 i'm doing it from my perspective but in general i i don't know what exactly is going to happen 479 00:40:31,144 --> 00:40:38,484 and that's also why i think it's wise to not be at the forefront uh with maybe some transactions 480 00:40:38,484 --> 00:40:39,884 going into a chain split. 481 00:40:40,404 --> 00:40:43,764 If you are not 100% sure what is going to happen there. 482 00:40:43,884 --> 00:40:45,844 And I think the people that are saying, 483 00:40:46,024 --> 00:40:48,304 I know 100% sure what's going to happen, 484 00:40:49,384 --> 00:40:52,124 you have to be careful with that kind of stuff. 485 00:40:52,424 --> 00:40:56,424 We've seen a lot of people promising a lot of stuff in Bitcoin before. 486 00:40:56,784 --> 00:40:59,604 And that turned out in general quite risky. 487 00:41:00,184 --> 00:41:00,624 Yeah, I agree. 488 00:41:00,624 --> 00:41:03,964 I think, like you said, I don't think anybody knows. 489 00:41:03,964 --> 00:41:14,704 And I think for sure, both on the side of if you're overconfident on BIP 110, but also on the other side, if you're overconfident that BIP 110, that it will just go away. 490 00:41:14,764 --> 00:41:24,864 This is similar to how we got here in the first place, where when they merge these changes, these controversial changes, and they just think, you know, people are just going to have to deal with it. 491 00:41:25,244 --> 00:41:28,644 And then it turns out, well, no, people are not just going to deal with it. 492 00:41:28,644 --> 00:41:37,804 They're going to come up with solutions to that problem, which maybe are not perfect, but there is a significant amount of people who are not just going to go along with it. 493 00:41:37,804 --> 00:41:41,564 But I agree completely that nobody really knows what's going to happen. 494 00:41:42,664 --> 00:41:51,304 I see a lot of times people look at the signaling numbers, but SegWit had near zero signaling for months before there was a big change right beforehand. 495 00:41:51,684 --> 00:41:53,804 And then that caused BIP-148 to go through. 496 00:41:54,564 --> 00:42:00,944 And I think personally that the temporary nature of BIP110 limits the downside in both directions. 497 00:42:00,944 --> 00:42:08,284 So that if for whatever reason, this is not the path forward, then it out of expires in one year. 498 00:42:09,004 --> 00:42:16,524 And to me, I personally run BIP110 because I think Bitcoin is money and it should only be used for money. 499 00:42:16,604 --> 00:42:18,184 And we should make a stand for that. 500 00:42:18,184 --> 00:42:20,884 but I definitely understand 501 00:42:20,884 --> 00:42:21,744 Bert's point of view 502 00:42:21,744 --> 00:42:23,584 and other people that are skeptical 503 00:42:23,584 --> 00:42:25,524 or do not want to run 504 00:42:25,524 --> 00:42:27,464 Notts or BIP 110 505 00:42:27,464 --> 00:42:29,124 and another thing 506 00:42:29,124 --> 00:42:30,164 I also just wanted to mention 507 00:42:30,164 --> 00:42:30,984 just for clarification 508 00:42:30,984 --> 00:42:32,504 is that from let's say 509 00:42:32,504 --> 00:42:33,664 a call a neutral perspective 510 00:42:33,664 --> 00:42:34,224 if you're not 511 00:42:34,224 --> 00:42:36,204 if you don't want to run BIP 110 512 00:42:36,204 --> 00:42:37,684 you don't necessarily have to run 513 00:42:37,684 --> 00:42:39,644 core like the older versions 514 00:42:39,644 --> 00:42:40,604 you could also run 515 00:42:40,604 --> 00:42:41,704 an older version of Notts 516 00:42:41,704 --> 00:42:42,964 if you still have 517 00:42:42,964 --> 00:42:44,244 that philosophical understanding 518 00:42:44,244 --> 00:42:45,364 of I want to 519 00:42:45,364 --> 00:42:47,924 I don't want to store spam on my node 520 00:42:47,924 --> 00:42:51,084 But I also don't want to bring it at a consensus level. 521 00:42:51,904 --> 00:43:02,004 And I think it goes back to Michael's question about philosophically, if you're running NOTS, you are

basically saying, I don't want to store spam mascot on my node. 522 00:43:02,544 --> 00:43:11,064 And BIP-110 is just going a step further and saying, I don't think at a network level, at least for a year, there should be anyone, any node storing this data. 523 00:43:11,744 --> 00:43:16,684 So we've been talking a lot about BIP-110 and the possibility of activation. 524 00:43:17,264 --> 00:43:21,644 Let's dig in a little bit further on what exactly it does at the consensus level. 525 00:43:22,104 --> 00:43:27,004 Kyle, you shared seven rules would change at the consensus level if BIP-110 were to activate. 526 00:43:28,084 --> 00:43:38,044 Could you walk through as I'm looking at these and I'm like, okay, I can sit down and think about this really hard, maybe kind of grasp it, but try to make this as non-technical as possible. 527 00:43:38,044 --> 00:43:43,604 Could you walk through these and then interject throughout as you, you know, and by the way, so I know. 528 00:43:43,604 --> 00:43:49,924 So as someone who is signaling BIP-110, Kyle, you're going to probably frame these in a more positive light. 529 00:43:50,424 --> 00:43:53,384 Barrett, you've got concerns about this not being the solution. 530 00:43:53,564 --> 00:43:57,644 So maybe you interject with some of your issues with any of these. 531 00:43:58,224 --> 00:43:59,984 Yeah, sure. We'll just go through one by one. 532 00:44:00,284 --> 00:44:04,764 So BIP-110, like Michael said, it adds seven restrictions at the consensus level. 533 00:44:05,304 --> 00:44:09,524 Obviously, this means that these are rules that determine which blocks are valid. 534 00:44:09,524 --> 00:44:17,724 So this is very different from mempool policy relay rules, which just control what your node passes along the network. 535 00:44:18,264 --> 00:44:29,104 So any blocks during this period of BIP-110 of activation, any blocks that violate these seven consensus rules will be rejected by nodes that are running BIP-110. 536 00:44:29,624 --> 00:44:32,604 They're not just filtered by individual nodes. 537 00:44:32,684 --> 00:44:37,384 They're actually just blocked and they cannot be added to the blockchain. 538 00:44:37,384 --> 00:44:44,464 So the first rule is the output size cap basically limits upper turn to 83 bytes. 539 00:44:45,644 --> 00:44:52,604 And this goes back to what Bitcoin was a year ago and over 10 years was at just 83 bytes. 540 00:44:52,864 --> 00:44:56,884 And this is at a consensus level limiting upper turn. 541 00:44:56,884 --> 00:45:04,444 So basically what your node can store from a data perspective, not only from the node perspective, but also from a block perspective. 542 00:45:04,444 --> 00:45:08,784 if there are any transactions that have up return over 83 bytes will be blocked. 543 00:45:09,304 --> 00:45:14,184 And so any monetary transaction of Bitcoin will be accepted. 544 00:45:14,184 --> 00:45:18,384 But if you're storing large amounts of data, videos, text, and so on, 545 00:45:18,764 -->

00:45:23,304 this basically gets blocked from being added to the blockchain during this one year period. 546 00:45:23,824 --> 00:45:25,244 Bert, do you have anything to add for this one? 547 00:45:25,664 --> 00:45:32,424 Yeah, I always have a problem with images and videos stored on. 548 00:45:32,424 --> 00:45:39,604 That sounds like you basically have videos and images stored on Bitcoin. 549 00:45:40,204 --> 00:45:47,764 Either way, everything is in that sense interpretations of ones and zeros, which I really, really have problems with. 550 00:45:47,764 --> 00:46:05,104 And this comes back to a specific part where letters were sent out to the mining pools, large mining operators by, let's say, Ocean slash Luke with regards to the whole CSAM debate, which we saw before BIP.10 actually came about. 551 00:46:05,104 --> 00:46:19,964 And the risk here is that this path that we are taking with regards to Bit.10 is that we see restrictions on the consensus level, where we also open a box of Pandora with regards to legal framing. 552 00:46:20,624 --> 00:46:29,684 When you say, oh, there are people that are running certain hardware that can store information that is illegal and that can be shut down. 553 00:46:30,544 --> 00:46:32,504 Now, this can, of course, extend. 554 00:46:32,504 --> 00:46:36,604 Now, it's up return and some of the other things that Kyle is going to walk through. 555 00:46:37,244 --> 00:46:55,844 But it can also extend into other areas where you can think of the fungibility of Bitcoin in and by itself, where we're talking about certain people or certain countries having certain amounts of Bitcoin on addresses where you could go in that direction, which I find very risky in and by itself. 556 00:46:56,484 --> 00:47:05,664 Well, one thing I think is important to mention as part of BIP 110 is that any UTXOs before the activation date are grandfathered in. 557 00:47:05,664 --> 00:47:07,044 So they're still spendable. 558 00:47:07,804 --> 00:47:17,344 But any transactions that want to occur in the future or during that BIP 110 period of one year, those are going to be blocked by these rules. 559 00:47:17,984 --> 00:47:34,464 So if, for example, there is some entity that has one of these UTXOs that let's call it would be blocked or transactions that would be blocked during the one year period, if they add the UTXO before the activation height, then that will still be spendable. 560 00:47:34,464 --> 00:47:40,224 Going to rule number two, this is the data push and witness element cap of 256 bytes. 561 00:47:40,624 --> 00:47:41,784 So this is a pretty big one. 562 00:47:41,844 --> 00:47:51,824 This is basically saying that it limits any individual piece of data in the witness, which is primarily where these ordinals and inscriptions were stored, to 256 bytes. 563 00:47:52,344 --> 00:48:02,204 And that's more than enough for multi-sig, for any type of legitimate Bitcoin transaction, but not for embedding an image in one continuous piece. 564 00:48:02,204 --> 00:48:07,464 And so that goes back to what Bert was saying about what are we willing to store on our nodes. 565 00:48:08,064 --> 00:48:15,144 And I think one of the main things in the spec of BIP 110 is that this is not going to stop spam. 566 00:48:15,424 --> 00:48:20,684 It's not going to stop steganography and ways of putting bad stuff on the chain. 567 00:48:20,784 --> 00:48:21,744 That's still going to happen. 568 00:48:22,164 --> 00:48:28,444 But if I'm running a node, and not only from a legal perspective, because if I don't care about the legality about it, 569 00:48:28,444 --> 00:48:33,204 Or if I live in a jurisdiction where maybe the laws are more liberal, that might not matter. 570 00:48:33,204 --> 00:48:50,124 But just as an ethical and a moral perspective, if I know that I have to store certain data that I don't want to on my node just to download the Bitcoin blockchain so I can validate it myself, that's going to cause people like me and others to not run a node because I don't want to store that data. 571 00:48:50,244 --> 00:48:52,024 I find that abhorrent. 572 00:48:52,024 --> 00:49:09,924 And so if that becomes the case where there's this bad data on the chain, let's say images or videos that I don't want to see or I find are morally not good, and I have to store that to run my own node, that's going to stop people from running it. 573 00:49:09,924 --> 00:49:11,944 And that's just from a moral and ethical perspective. 574 00:49:11,944 --> 00:49:23,364 If there are jurisdictions that have legal ramifications for holding certain of this data, for example, CSAM, then it could become something where the law could go after you. 575 00:49:23,644 --> 00:49:26,944 And obviously, there is no court cases that we've seen in the past about this. 576 00:49:27,384 --> 00:49:30,444 But there is data, CSAM data on the chain already. 577 00:49:30,564 --> 00:49:32,684 They've done investigations on that. 578 00:49:33,204 --> 00:49:37,464 But it's not something that's contiguous in your note. 579 00:49:37,464 --> 00:49:40,304 So you would have to use a separate tool to put that together. 580 00:49:40,704 --> 00:49:48,204 And now if you're in your node, there's contiguous data of this videos or whatever, it becomes a lot more trickier from that perspective. 581 00:49:48,904 --> 00:49:54,724 So what I think is very important in what you just explained, the witness data is then basically capped. 582 00:49:54,844 --> 00:49:56,564 So it's becoming less wide. 583 00:49:56,564 --> 00:50:09,684 So, of course, if malicious actors still want to embed a lot of data, they will just cut it into smaller pieces and still, you know, use Bitcoin with regards to using this specific type, but just the smaller chunks. 584 00:50:10,144 --> 00:50:13,644 So the real problem is it's very easily circumvented. 585 00:50:14,084 --> 00:50:23,884 And the other issue you have here is that you are actually stopping some operators from using some of the

functionality that they are using currently. 586 00:50:23,884 --> 00:50:45,484 So specifically, for example, Anchor Watch, but also some very advanced features with regards to Taproot Miniscript, where I've personally also worked on, is where, for example, Liana, which is also a wallet that very tech-savvy people might use, is that you can build certain setups where you can obfuscate your key structure. 587 00:50:45,484 --> 00:50:48,204 So the key structure is not public. 588 00:50:48,804 --> 00:50:52,504 That's the new privacy features that are actually enabled by Taproot. 589 00:50:53,024 --> 00:50:57,224 And you are not revealing all of your signers when you do a transaction. 590 00:50:57,864 --> 00:51:05,444 This not only increases privacy, but this also creates less weight in the actual larger multi-sig transactions. 591 00:51:05,444 --> 00:51:17,744 And this is specifically interesting for larger holders that want to be very private about how many keys there actually are and how they transact. 592 00:51:18,224 --> 00:51:20,324 And this is all working in practice. 593 00:51:20,744 --> 00:51:23,384 And this will not work anymore when Bit110 activates. 594 00:51:23,804 --> 00:51:26,644 And that's why some people say this is a very niche scenario. 595 00:51:26,924 --> 00:51:32,144 And, of course, it's still niche because exactly as one, we are testing all these features. 596 00:51:32,144 --> 00:51:40,344 There's just a few wallets that are actually capable of doing this, but we expect this to be rolled out more broad. 597 00:51:40,604 --> 00:51:48,864 And this will bring a huge privacy increase on holders with large sums, with complex setups in and by itself. 598 00:51:49,384 --> 00:51:58,444 So this witness part is, in my opinion, it's debatable and it's questionable if you want to actually do this. 599 00:51:58,444 --> 00:52:02,944 But just to be clear, are you are you referring to the the you said 600 00:52:02,944 --> 00:52:04,944 mini script? Are you talking about like the no? No? 601 00:52:04,992 --> 00:52:07,872 for like the tap leaf construction? 602 00:52:08,832 --> 00:52:11,112 No, just the data itself. 603 00:52:11,512 --> 00:52:14,172 So the size when you go through larger setups. 604 00:52:15,412 --> 00:52:16,912 Like a larger multi-sig setup? 605 00:52:17,192 --> 00:52:17,872 Yes, correct. 606 00:52:18,832 --> 00:52:19,112 Okay. 607 00:52:19,272 --> 00:52:23,092 Yeah, that's basically above eight keys. 608 00:52:23,772 --> 00:52:24,292 Correct. 609 00:52:24,912 --> 00:52:27,032 But anything below that seven keys, three of six, 610 00:52:27,132 --> 00:52:29,692 three of five, two of three, multi-sig still works. 611 00:52:29,972 --> 00:52:30,532 So that is true. 612 00:52:30,592 --> 00:52:32,212 There are some more advanced setups. 613 00:52:32,212 --> 00:52:34,512 I think AnchorWatch is one of them using 10 keys. 614 00:52:34,992 --> 00:52:37,132 And that would be 243 bytes. 615 00:52:37,352 --> 00:52:41,952 That would be above the

256 byte limit that Bit.10 would be constraining. 616 00:52:41,952 --> 00:52:44,412 But obviously, this is only temporary. 617 00:52:44,972 --> 00:52:53,732 And hopefully, we can figure out a solution to be able to stop this spam debate without needing these rules for a longer period of time. 618 00:52:54,252 --> 00:52:54,512 Okay. 619 00:52:55,032 --> 00:52:56,932 Number three, what do you got, Kyle? 620 00:52:57,452 --> 00:53:00,152 No spending undefined witness versions. 621 00:53:00,772 --> 00:53:02,972 Bitcoin has different versions of how witnesses work. 622 00:53:03,292 --> 00:53:04,192 Version zero is SegWit. 623 00:53:04,192 --> 00:53:09,912 version one is taproot. Versions beyond that are undefined and reserved for future upgrades. 624 00:53:10,572 --> 00:53:14,232 Right now, they have no rules on their data, meaning they could be abused for unlimited data 625 00:53:14,232 --> 00:53:18,892 storage. BIP 110 blocks spending from these undefined versions during the temporary period. 626 00:53:19,492 --> 00:53:23,752 Any future upgrade would need more than a year of coordination anyway. So this doesn't block 627 00:53:23,752 --> 00:53:28,652 anything real. I think that that's more of a minor one. I'm not sure, Bert, if you have anything 628 00:53:28,652 --> 00:53:33,372 to say about that. I'll let you finish the list first. That's good. For rule number four, 629 00:53:33,372 --> 00:53:38,692 no taproot annex. The annex is an extra data field in taproot transactions with unlimited size 630 00:53:38,692 --> 00:53:43,452 reserved for future use. And so this is blocked since there's no legitimate use for this today. 631 00:53:44,572 --> 00:53:50,932 Rule number five, control block cap. Taproot lets you set up multiple spending conditions 632 00:53:50,932 --> 00:53:58,772 organizing a tree structure. So this is basically limiting the conditions for certain complex 633 00:53:58,772 --> 00:54:06,072 transactions. So this can be limiting for projects like Bitfm, which is working on advanced computation 634 00:54:06,072 --> 00:54:12,372 on Bitcoin. But there's no real world transactions on Bitcoin today of Bitfm, at least that I'm aware 635 00:54:12,372 --> 00:54:17,472 of. And so that one year expiry means that limitation would end before Bitfm is likely to 636 00:54:17,472 --> 00:54:22,672 launch. For rule number six, we have no Ops, Access and Taproot scripts. These are placeholder 637 00:54:22,672 --> 00:54:26,872 instructions reserved for future upgrades, no legitimate use today. So those are blocked. 638 00:54:26,872 --> 00:54:30,992 And then the last one, rule number seven, I think this one is an interesting one. 639 00:54:31,972 --> 00:54:34,992 No op-if or op-not-if in Taproot scripts. 640 00:54:36,032 --> 00:54:41,492 So op-if lets a script choose between two different code paths based on a condition. 641 00:54:41,892 --> 00:54:46,852 This is useful in older Bitcoin scripts, but Taproot was specifically designed to replace it. 642 00:54:47,332 --> 00:54:53,252 So in Taproot, each condition gets its own branch in the tree, and only the branch you actually use is revealed on the blockchain. 643 00:54:53,892 --> 00:54:58,052 Using op-if inside a Taproot script is redundant because you're publishing code that never runs, 644 00:54:58,392 --> 00:55:00,392 which is exactly what Taproot was built to eliminate. 645 00:55:00,992 --> 00:55:05,592 Op-if in Taproot scripts is commonly abused to embed data that gets skipped during execution. 646 00:55:05,912 --> 00:55:12,952 Now, I actually put up a PR in the Rust miniscript that got merged by Andrew Polstra. 647 00:55:13,652 --> 00:55:19,352 And basically, it adds a fix whereby if you currently use op-if in a Taproot script, 648 00:55:19,352 --> 00:55:25,492 it allows you to compile these conditions into separate branches automatically. 649 00:55:25,772 --> 00:55:30,752 So it gives you the same wallet functionality you would have before Bit.110 650 00:55:30,752 --> 00:55:34,772 and allows you to do so where you don't need OpF. 651 00:55:35,132 --> 00:55:38,652 So for any developers that currently use OpF in their Taproot scripts 652 00:55:38,652 --> 00:55:42,552 and they're looking to see how can they continue to have the same functionality 653 00:55:42,552 --> 00:55:44,292 during the Bit.110 period, 654 00:55:44,632 --> 00:55:48,772 they can just use that new functionality in a mini script. 655 00:55:48,772 --> 00:55:50,612 But those are the seven rules. 656 00:55:50,872 --> 00:55:52,432 You have anything to add, Bert? 657 00:55:52,832 --> 00:55:54,472 Yeah, so you mentioned a couple of times, 658 00:55:54,692 --> 00:55:57,152 these are temporary solutions. 659 00:55:57,812 --> 00:56:02,072 And I think it's very important to come back to that. 660 00:56:04,072 --> 00:56:07,252 It's seen, I think, if you look at it, 661 00:56:07,252 --> 00:56:20,346 how it pushed how many fast updates we saw when the first Bit docs were starting to be released There were also some serious very serious Bitcoiners looking at it 662 00:56:20,346 --> 00:56:23,226 And there was quite some quick iterations there. 663 00:56:24,466 --> 00:56:30,866 But most people that are, let's say, on a longer timescale, 664 00:56:30,966 --> 00:56:36,906 trying to be as serious as possible with regards to a more than $1 trillion network, 665 00:56:36,906 --> 00:56:43,526 don't like to see temporary solutions that are almost like a hip-shoot solution 666 00:56:43,526 --> 00:56:46,766 to something that will not kill Bitcoin. 667 00:56:47,006 --> 00:56:51,186 I don't know how you look at it, Kyle, but if Bit.110 does not activate, 668 00:56:51,606 --> 00:56:54,866 will Bitcoin die in any short term? 669 00:56:55,326 --> 00:56:56,146 No, I don't think so. 670 00:56:56,146 --> 00:57:03,166 But I think the use case of Bitcoin as money is going to take a hit from that perspective 671 00:57:03,166 --> 00:57:06,646 because then it says there is a legitimate use case 672

00:57:06,646 --> 00:57:08,866 for storing data on nodes. 673 00:57:09,466 --> 00:57:11,686 And if you're running an IPFS or something else, 674 00:57:11,826 --> 00:57:15,066 some other data storage, decentralized data storage protocol, 675 00:57:15,386 --> 00:57:18,066 you can delete or you can remove certain data 676 00:57:18,066 --> 00:57:19,606 from that node you're running. 677 00:57:19,746 --> 00:57:20,646 But with Bitcoin, you cannot. 678 00:57:21,146 --> 00:57:24,246 Every single person in the future will have to store this data 679 00:57:24,246 --> 00:57:28,266 that could be morally apprehensive. 680 00:57:28,786 --> 00:57:30,526 And what if we start to use Bitcoin more, 681 00:57:30,586 --> 00:57:33,026 as I mentioned a couple of times already, 682 00:57:33,166 --> 00:57:39,166 I certainly don't disagree with that. I mean, I think everyone should be using Bitcoin more, but I don't see how that would affect Bit.110. 683 00:57:40,066 --> 00:57:48,706 But in the short term, as you mentioned, it will not kill Bitcoin. And I think it's very important that we get to a solid solution for the long term. 684 00:57:48,706 --> 00:57:51,646 And we all need to work on that. 685 00:57:52,026 --> 00:57:59,426 And I think, indeed, we both agree that core is not a very nice path that has been taken there. 686 00:57:59,586 --> 00:58:08,386 But also not for sure, as I mentioned before, with a single person that has merge access is an insane risk, too. 687 00:58:09,046 --> 00:58:12,706 So we have to really think about... 688 00:58:13,346 --> 00:58:14,646 There's a lot to work on, basically. 689 00:58:14,806 --> 00:58:16,626 There's a lot of improvements to make all around. 690 00:58:16,626 --> 00:58:22,106 And I think something very telling is that this issue has been around for many years. 691 00:58:22,366 --> 00:58:27,706 And only now in December, this BIP 110 was proposed and accepted in the BIPs repo. 692 00:58:28,206 --> 00:58:31,006 And we've had six months or more now. 693 00:58:31,266 --> 00:58:37,406 And even before the BIP 110, the proposal was added into the BIPs repo and accepted. 694 00:58:37,826 --> 00:58:40,346 This debate has been going on for far longer than that. 695 00:58:40,686 --> 00:58:46,246 And we still don't have anybody else really coming out and saying, this is our solution. 696 00:58:46,246 --> 00:58:53,446 We've seen some other node implementations talked about, for example, production ready, although they don't have a client that you can run. 697 00:58:53,946 --> 00:58:59,686 There are obviously governance structural issues with core, as you mentioned, and other people have said the same thing. 698 00:58:59,866 --> 00:59:03,006 Same with NOTS, with Luke being the only maintainer there. 699 00:59:03,426 --> 00:59:10,766 But ultimately, I think at the end of the day, and also the fact that it's temporary, is that this is not the end result. 700 00:59:10,766 --> 00:59:13,766 We need to figure out how do we solve these issues. 701

00:59:13,766 --> 00:59:19,946 We need to move forward and basically figure out how do we solve this from a long-term perspective? 702 00:59:20,526 --> 00:59:22,806 How do we fix these issues? 703 00:59:23,366 --> 00:59:31,286 And I think more Node implementations are clearly better than just having everyone corralled into core and then they make a change that everyone has to accept. 704 00:59:31,706 --> 00:59:33,546 I love that you say corral into core. 705 00:59:33,846 --> 00:59:35,266 So I think it's very important here. 706 00:59:35,366 --> 00:59:37,026 There are some other Node implementations. 707 00:59:37,146 --> 00:59:40,046 You already mentioned production-ready, but it's not production-ready. 708 00:59:40,046 --> 00:59:49,566 And the nice thing is that you actually have Libitcoin, which has been under development for over a decade, which looks really, really solid. 709 00:59:49,766 --> 00:59:53,446 And we need more people to actually also work on that and focus on that. 710 00:59:53,586 --> 01:00:04,846 We need multiple implementations where there's more effort being put in so that we don't see the current binary choice of like you either run NOTS or you run Core, but there's nothing else. 711 01:00:04,846 --> 01:00:11,846 we would like to see much more than that publicly available and easily accessible for node runners, 712 01:00:11,846 --> 01:00:34,060 which will open up basically people being able to participate in the network even more easily And I think that the most positive node in that sense because everyone is now getting aware of how important it is to run a node and that you actually can become fully sovereign when you run a node 713 01:00:35,000 --> 01:00:39,580 And that's why I'm wearing this little pin, which says node runners will inherit the earth. 714 01:00:39,780 --> 01:00:44,760 In the end, if you're not a participant, you are relying on someone else. 715 01:00:44,980 --> 01:00:47,440 And that's not what the goal of Bitcoin is. 716 01:00:47,440 --> 01:00:49,640 The goal of Bitcoin is to become sovereign. 717 01:00:50,320 --> 01:01:04,680 And that's what this whole discussion in the end will also make sure that you all become because whatever path is being taken, Bitcoin will get stronger and we will see more adoption of Bitcoin through it. 718 01:01:04,680 --> 01:01:10,840 Yeah, one thing I'll add before you go, Michael, is just we're all having this conversation about nodes and all this stuff. 719 01:01:11,160 --> 01:01:22,420 But I think what's really important is if you're listening to this and you are not running a node, then you should ask yourself a question of do you truly have control over what you see on your wallet, for example. 720 01:01:23,380 --> 01:01:29,480 And if you're just trusting someone else, then maybe they go core, maybe they go nuts, maybe they have bit.10, maybe they don't. 721 01:01:29,760 --> 01:01:31,760 But you have no say if you don't run your own node. 722 01:01:31,760 --> 01:01:43,320 So

I think that's really important to come out of this conversation. If you're not running a node, ask yourself why not, because that's the whole purpose of Bitcoin, not to trust someone else, not to give them control over your actions. 723 01:01:43,940 --> 01:01:54,040 Yes, completely. I think we can all agree we need more nodes online. If you want to be a sovereign individual, you need to run a node. And hopefully we've given you some takeaways here to consider what you might run. 724 01:01:54,040 --> 01:02:23,440 So quick question for you, Kyle. So if you were to frame the objective of BIP-110, do you view it as a solution, a tactic designed to give us more runway to find a solution, or just maybe a year-long period to keep some of the scammers or spammers, however you want to define them or describe them, away that they go chase some other cryptocurrency and go 725 01:02:24,040 --> 01:02:26,320 know, dump on their projects or whatever? 726 01:02:26,580 --> 01:02:28,640 Or is it some combination of those things? 727 01:02:29,200 --> 01:02:31,280 I think it's a combination of those things. 728 01:02:33,000 --> 01:02:35,820 Ultimately, it exists because filters are going to get routed around. 729 01:02:36,200 --> 01:02:42,440 And so if we want to figure out a long term solution, we at least have to cap the potential 730 01:02:42,440 --> 01:02:46,800 gap that has now been brought about by v30. 731 01:02:47,160 --> 01:02:51,820 So that means we have to do at a consensus level, because I think if BIP 110 came out 732 01:02:51,820 --> 01:02:56,380 and said, we're going to do this permanently, which again, some skeptics are like, why is it 733 01:02:56,380 --> 01:03:01,060 temporary? If it became permanent at the consensus level, I think that would, I mean, we're already 734 01:03:01,060 --> 01:03:05,340 having a lot of debate and controversy around Bit.10. But if it was permanent, I think it would 735 01:03:05,340 --> 01:03:09,880 be way worse. And I think it would have less, much less support. But the fact that it is temporary, 736 01:03:10,220 --> 01:03:15,140 that it does out or expire, in my head, it's not a permanent solution. It's not the long term 737 01:03:15,140 --> 01:03:21,240 solution. But it is something, even if it's not perfect, we need something to make a stand that 738 01:03:21,240 --> 01:03:25,800 Bitcoin is money. We've been having this conversation for many years, and it seems like 739 01:03:25,800 --> 01:03:30,440 nobody wants to listen to us from the core side. And obviously, NOTS is not the most, 740 01:03:31,160 --> 01:03:36,920 from a governance perspective, just like core is. There's issues there, obviously. But 741 01:03:36,920 --> 01:03:42,980 the idea that a miner gets paid once and then every node operator has to store that data forever 742 01:03:42,980 --> 01:03:49,180 is very dangerous, in my opinion. And I think more people need to run nodes. And if we keep trying to 743 01:03:49,180 --> 01:03:55,600 make it easier to run nodes, then I think that's a win for Bitcoin. And that's why I believe that 744 01:03:55,600 --> 01:04:01,020 Bit.10 will succeed in the end. By the way, Barrett, if you want to double down, 745 01:04:01,020 --> 01:04:08,020 we want to avoid anything ad hominem, slanderous. But one of your concerns you expressed offline was 746 01:04:08,020 --> 01:04:13,640 you've got Luke sort of sitting at the center of a lot of this. He's the single maintainer for 747 01:04:13,640 --> 01:04:19,640 He didn't initially, I don't think, release the PR for VIP 110, 748 01:04:19,640 --> 01:04:21,640 but he was noted as a contributor. 749 01:04:21,640 --> 01:04:23,640 I'm sure he was heavily involved in that. 750 01:04:23,640 --> 01:04:25,640 That's been one of your concerns as well, 751 01:04:25,640 --> 01:04:40,874 is just the mechanics sort of underlying the issuance of these PRs and these proposals Could you maybe touch on that a little bit Yeah I haven named any person in our current talk and I like to keep it that way 752 01:04:40,874 --> 01:04:47,494 I think it's best for people to just do deep research on people involved in general with regards to implementations. 753 01:04:48,174 --> 01:04:53,394 We've seen a very nice article come about the corruption within core. 754 01:04:53,554 --> 01:04:56,194 It's heavily shared and talked about a lot. 755 01:04:56,194 --> 01:05:01,554 but I think the other side should also be heavily investigated and checked upon 756 01:05:01,554 --> 01:05:04,774 because there is also a lot of question marks over there. 757 01:05:05,554 --> 01:05:11,274 And then we come back to let's be conservative, run something conservatively, 758 01:05:11,714 --> 01:05:15,614 and let's build on something that actually lasts for the long-term future 759 01:05:15,614 --> 01:05:18,454 because the kids depend on it, Michael. 760 01:05:19,454 --> 01:05:19,974 Perfect. 761 01:05:21,134 --> 01:05:24,074 Okay, I'm looking through some of these notes that we have here. 762 01:05:24,074 --> 01:05:30,034 What, Kyle, what have we not gotten to, if anything, that you were hoping to discuss? 763 01:05:30,794 --> 01:05:32,194 I think we covered everything. 764 01:05:33,114 --> 01:05:35,614 I'm not sure there was anything else. 765 01:05:36,134 --> 01:05:39,874 I think it seems to me like we've done a pretty good job. 766 01:05:39,994 --> 01:05:47,734 I think at the end of the day, what I've really enjoyed about this, guys, is that there's just so much division, tribalism. 767 01:05:47,894 --> 01:05:54,054 If you look at X and see the debate unfolding, I think this is hopefully much more educational and constructive. 768 01:05:54,074 --> 01:05:59,034 for people, probably a little bit technical. I think you can only keep it high level for so long 769 01:05:59,034 --> 01:06:02,934 before you have to get into the weeds a little bit. Tell me if I'm missing anything here. I think 770 01:06:02,934 --> 01:06:08,554 the big takeaways are run a node. You need to be

running a node regardless of implementation. 771 01:06:09,214 --> 01:06:14,574 Try to take some of what you've learned listening to this chat and make an informed determination. 772 01:06:14,814 --> 01:06:19,914 Go do your own research. Don't trust verify. And then be ready for this activation period. 773 01:06:19,914 --> 01:06:25,794 Make sure you're thoughtful about should you be sending transactions, you know, depending on what you choose to do. 774 01:06:26,074 --> 01:06:26,914 Maybe there are some other considerations. 775 01:06:27,934 --> 01:06:28,854 Am I missing anything? 776 01:06:28,994 --> 01:06:32,514 Like, what do you guys want to make sure that people hear as a result of this episode? 777 01:06:33,034 --> 01:06:35,574 Learn to CoinJoin, not your node, not your code. 778 01:06:36,034 --> 01:06:36,614 I agree with that. 779 01:06:36,894 --> 01:06:39,514 And the big one, verify, don't trust. 780 01:06:39,874 --> 01:06:41,154 Not even us, not anybody. 781 01:06:41,594 --> 01:06:42,554 Do your own research. 782 01:06:43,014 --> 01:06:43,814 Make your own decision. 783 01:06:44,154 --> 01:06:47,974 Don't ever be in a situation where you're like, oh, well, somebody told me. 784 01:06:47,974 --> 01:06:49,914 or, oh, I'm going to trust someone else, 785 01:06:50,054 --> 01:06:51,374 or maybe I'm not running a node. 786 01:06:51,434 --> 01:06:55,774 I'm just going to have whatever they choose for me. 787 01:06:55,954 --> 01:06:57,314 That's like a sheep mentality. 788 01:06:57,794 --> 01:06:59,694 And in Bitcoin, we're not sheep. 789 01:06:59,994 --> 01:07:04,354 We need to focus on educating yourself, being sovereign. 790 01:07:04,594 --> 01:07:06,154 And that means taking action on your own, 791 01:07:06,434 --> 01:07:07,474 whether you want to be neutral, 792 01:07:07,794 --> 01:07:10,774 whether you're for Bit.10 or against it. 793 01:07:11,234 --> 01:07:13,054 At least you can see at the end of the day, 794 01:07:13,434 --> 01:07:17,474 I'm making my own decision based off my own interpretation. 795 01:07:17,974 --> 01:07:21,794 Well said. Guys, I think that's a good place to wrap up. Thank you both for doing this. Kyle, 796 01:07:21,854 --> 01:07:25,634 I know you in particular put a lot of time into pulling some notes together. And Barrett, 797 01:07:25,674 --> 01:07:30,194 I know you were going back and finding lots of resources. So this has been incredibly helpful 798 01:07:30,194 --> 01:07:34,334 for me, hopefully helpful for our viewers. And I'm really grateful for both of your time. 799 01:07:34,854 --> 01:07:35,234 Thank you. 800 01:07:35,494 --> 01:07:35,994 Cheers, guys. 801 01:07:36,534 --> 01:07:41,274 And that's a wrap. Again, hope you enjoyed this discussion. I thought this was incredibly helpful, 802 01:07:41,734 --> 01:07:44,754 very enlightening for me, especially as someone who is not a developer. 803 01:07:44,754 --> 01:07:49,654 and hope you learned a lot and are now ready to go run your node and make a determination about 804 01:07:49,654 --> 01:07:53,414 how you want to proceed, what implementation you want to run. But again, the most important thing 805 01:07:53,414 --> 01:07:58,734 is take self-custody, run a node. If you need help doing that, go to thebitcoinway.com slash 806 01:07:58,734 --> 01:08:03,394 podcast. You can schedule a free 30-minute consult with a member of our team. It could also help you 807 01:08:03,394 --> 01:08:08,334 with online privacy, setting up a privacy phone. We have an awesome plan B residency option in 808 01:08:08,334 --> 01:08:14,314 Panama too. Again, it's thebitcoinway.com slash podcast. If you stuck around this long, do me a 809 01:08:14,314 --> 01:08:18,594 huge favor, like and subscribe to the channel. We'd really appreciate that. Share it with someone, 810 01:08:18,694 --> 01:08:23,734 anything you could do to help feed the algorithm. We would really, really appreciate. Go follow us 811 01:08:23,734 --> 01:08:29,094 on X. We're at the Bitcoin way underscore. I'm there as well at the other M Jordan. And until 812 01:08:29,094 --> 01:08:34,314 next time, stay safe, stay sovereign. And remember the yield on Bitcoin is freedom.