1 00:00:00,000 --> 00:00:15,100 In a world where fiat trembles and the mempool never sleeps, one signal cuts through the noise. 2 00:00:15,880 --> 00:00:25,140 Welcome to Pleb Chain Radio, Layer 2, your premium passage to the hidden rifts of Bitcoin 3 00:00:25,140 --> 00:00:29,640 culture. Buckle up and feel the voltage. 4 00:00:43,900 --> 00:00:46,040 Jameson, welcome to Plapchain Radio. 5 00:00:47,040 --> 00:00:51,940 Glad to finally have an opportunity to speak with one of my favorite shitcoiners. 6 00:00:51,940 --> 00:01:01,620 well played well played jameson so we'll start with the op return dust up which seems like the 7 00:01:01,620 --> 00:01:07,980 dust is settling just a little bit but it was late april early may it was all the talk of the 8 00:01:07,980 --> 00:01:18,060 nostiverse and indeed uh the twitterverse so for our non-technical listeners uh and actually for 9 00:01:18,060 --> 00:01:23,780 Anyone, what is your perspective on what exactly went down with the op-return controversy? 10 00:01:25,300 --> 00:01:26,680 Oh, boy. 11 00:01:27,320 --> 00:01:34,920 It's really complicated because the op-return debate goes back a decade. 12 00:01:35,520 --> 00:01:43,780 So there's a lot of minutiae and technical nuance as to how we got to where we are today. 13 00:01:43,780 --> 00:02:01,700 But I think if we skip over the decade of debate over how to try to disincentivize people from putting stupid data into the Bitcoin blockchain, we can fast forward to where we are today. 14 00:02:01,700 --> 00:02:17,000 where essentially we have, I would say, Luke Dashier being kind of a head or center of this whole concept of trying to fight against spam 15 00:02:17,000 --> 00:02:25,500 or fight against uses of Bitcoin that are considered non-financial, non-monetary, 16 00:02:25,500 --> 00:02:35,760 and therefore not appropriate for Bitcoin as a protocol, as a network, as a data structure, you know, the blockchain itself. 17 00:02:36,620 --> 00:02:51,600 And I think that really it just it all came to a head where this one pull request was essentially resurrected after a two-year hibernation 18 00:02:51,600 --> 00:02:57,080 because it's pretty much the exact same pull request that was made by Peter a couple of years ago. 19 00:02:58,100 --> 00:03:03,460 And it came back for a few different reasons, 20 00:03:03,680 --> 00:03:08,200 but mainly because the Bitcoin Core developer Antoine Ponce, 21 00:03:08,460 --> 00:03:10,760 hopefully I pronounced that correctly, 22 00:03:11,600 --> 00:03:17,940 was at MIT Bitcoin Expo with me, actually, a couple of months ago. 23 00:03:17,940 --> 00:03:42,600 And he was speaking to some developers from Citraya, and they were telling him about essentially the hacky stuff that they had to do to work around some of the limitations of the Bitcoin protocols policy, or at least Bitcoin core's policy with regard to relaying transactions and how you're allowed to use Opratern to store little chunks of data. 24 00:03:42,600 --> 00:03:53,600 And essentially this has to do with Citraeus Groth 16 proof, which is used by their zero knowledge roll up system. 25 00:03:53,600 --> 00:03:57,420 It's the second layer system that they are developing. 26 00:03:57,420 --> 00:04:17,320 And there's this one particular fraud challenge edge case where if you think a validator is trying to defraud people and lying to them about the actual state of the roll up, the second layer, then you can challenge that and essentially steal the money from them. 27 00:04:17,320 --> 00:04:42,140 This is a disincentive. And so this is an extreme edge case, but Antoine basically realized, oh, this is a pretty hacky solution that they came up with because they essentially are creating these other outputs that are tiny little dust outputs and are going to arguably pollute the UTXO set for all eternity. 28 00:04:42,140 --> 00:04:47,040 and they're doing this because they can't simply put all of the data into the op return itself. 29 00:04:47,040 --> 00:04:50,560 So they had to split up the data, put it in a few different places. 30 00:04:51,560 --> 00:04:53,320 And so this made him concerned. 31 00:04:54,520 --> 00:05:04,880 And he basically went and said, hey, Peter, I think that we should talk about raising the limit on the relay policy again 32 00:05:04,880 --> 00:05:10,120 so that it incentivizes people not to do this hacky workaround. 33 00:05:10,120 --> 00:05:18,440 and so Peter said sure whatever he you know recreated the PR and that then got onto the 34 00:05:18,440 --> 00:05:25,740 radar of people who are you know vehemently against any sort of non-financial data in Bitcoin 35 00:05:25,740 --> 00:05:37,320 and I well I suspect you know they got pretty frustrated but as a result of several different 36 00:05:37,320 --> 00:05:38,240 of things that happen, right? 37 00:05:38,240 --> 00:05:41,980 So the thing that I think really kicked it all off 38 00:05:42,940 --> 00:05:57,676 and put it into hyperdrive and spilled over into social media is when one of the people commenting on the pull requests then started commenting that oh you know Jameson has commented on this pull request 39 00:05:57,676 --> 00:06:05,036 and he should disclose that he has a conflict of interest because he's an investor in Citraea and so on. 40 00:06:05,036 --> 00:06:10,876 and that was actually, by commenting on that, 41 00:06:11,676 --> 00:06:15,396 that was actually a violation of one of the rules 42 00:06:15,396 --> 00:06:18,876 of participating in rational discourse 43 00:06:18,876 --> 00:06:20,396 on the Bitcoin Core repository, 44 00:06:20,396 --> 00:06:23,036 which is that to stay on topic, 45 00:06:23,156 --> 00:06:26,356 you have to talk about the actual proposal, the idea, 46 00:06:26,636 --> 00:06:29,176 and not about the people who are discussing 47 00:06:29,176 --> 00:06:30,696 the proposal of the idea. 48 00:06:30,696 --> 00:06:39,136 and so I think that got the person's comment removed they may have been banned for a day or two 49 00:06:39,136 --> 00:06:44,156 then Bitcoin Mechanic came in right after that and was like hey this person got banned it was wrong 50 00:06:44,156 --> 00:06:50,176 and I think he got banned as a result of doing that and these bans of course are only for a day 51 00:06:50,176 --> 00:06:55,076 or two it's not a permanent thing but you know that's when things I think really got spilled over 52 00:06:55,076 --> 00:07:00,276 into social media and it turned into a whole oh Bitcoin Core is censoring people so on and so 53 00:07:00,276 --> 00:07:05,816 forth when it was, in fact, enforcement of the moderation policy. 54 00:07:07,376 --> 00:07:12,956 It then, of course, got worse when a lot of people from social media come in on the pull 55 00:07:12,956 --> 00:07:13,476 request. 56 00:07:13,956 --> 00:07:21,376 Generally, I think under the mistaken assumption that pull requests operate via democracy and 57 00:07:21,376 --> 00:07:28,776 voting, people who don't understand how the actual system of acts and acts work, and that 58 00:07:28,776 --> 00:07:34,216 just simply saying ACK or NAC doesn't really do anything. You're not adding signal. You're just 59 00:07:34,216 --> 00:07:41,536 adding noise. You have to present novel new arguments or perspectives and add to the 60 00:07:41,536 --> 00:07:47,836 conversation constructively. So that got out of control and it got eventually to the point where 61 00:07:47,836 --> 00:07:55,976 the whole PR conversation got shut down. And I think that ended up pissing some more people off 62 00:07:55,976 --> 00:08:04,116 even more than that. And yeah, then it continued for several weeks and we can go more into details 63 00:08:04,116 --> 00:08:12,716 and stuff there. But I think one interesting thing that I would want to note is that the original 64 00:08:12,716 --> 00:08:19,356 claim that I have a conflict of interest as a result of my investment in Citraea is actually 65 00:08:19,356 --> 00:08:26,676 incorrect. Now, it's true that I have a financial interest in Citra, an extremely tiny one, 66 00:08:26,736 --> 00:08:32,776 you know, compared to my Bitcoin holdings. So, you know, it would be illogical for me to do 67 00:08:32,776 --> 00:08:39,076 anything that is bad for Bitcoin just because it's good for Citra, you know, from my own 68 00:08:39,076 --> 00:08:44,496 financial perspective. But even beyond that, the reason why it's not a conflict of interest 69 00:08:44,496 --> 00:08:50,996 is because this proposal does not actually benefit Citraea. 70 00:08:51,516 --> 00:08:53,656 Citraea doesn't need the change. 71 00:08:54,016 --> 00:08:56,216 Citraea never asked for the change. 72 00:08:56,216 --> 00:09:02,216 And even if the change is made, it will have no impact upon Citraea's operation. 73 00:09:02,796 --> 00:09:10,136 Because, as I said, this is only used in one really specific edge case 74 00:09:10,136 --> 00:09:14,936 where a validator is lying and trying to defraud people. 75 00:09:15,836 --> 00:09:18,856 So the way that the game theory and the incentives are set up 76 00:09:18,856 --> 00:09:21,796 for Cetrea and their validators is that 77 00:09:21,796 --> 00:09:25,016 this is probably never actually going to happen. 78 00:09:25,656 --> 00:09:28,996 If it did happen, very bad things would result, right? 79 00:09:29,076 --> 00:09:33,816 So this is kind of analogous to if you have a lightning channel open 80 00:09:33,816 --> 00:09:38,476 and you try to close that with an old stale state 81 00:09:38,476 --> 00:09:44,516 and defraud someone by settling the channel in a way that the balances are not actually up to date 82 00:09:44,516 --> 00:09:52,116 to try to get your money back. And so, you know, there are penalties and ways that essentially that 83 00:09:52,116 --> 00:09:56,836 can be challenged by the person that you're trying to defraud. And that's why we don't see that 84 00:09:56,836 --> 00:10:01,536 actually happening very much. It's incredibly rare for that to happen. And there's, you know, 85 00:10:01,576 --> 00:10:06,856 tens of thousands of lightning channels open. Whereas with Cetrea, there is going to be one 86 00:10:06,856 --> 00:10:14,176 zero knowledge roll up and i think maybe a dozen validators who are all like well-known and vetted 87 00:10:14,176 --> 00:10:21,716 enterprise entities so on and so forth but that's my high level rant and we can get into 88 00:10:21,716 --> 00:10:27,696 any more details if you want yeah i certainly want to avoid the twitter drama that happened 89 00:10:27,696 --> 00:10:32,096 i don't think that's particularly constructive although it's directionally indicative 90 00:10:32,096 --> 00:10:35,296 of perhaps the issue at hand, right? 91 00:10:36,176 --> 00:10:38,416 So, yeah, let's not get into personalities 92 00:10:38,416 --> 00:10:40,236 or the drama itself. 93 00:10:40,916 --> 00:10:42,876 But you did say, it sounds like, Jameson, 94 00:10:42,876 --> 00:10:46,016 what you said was a conversation 95 00:10:46,016 --> 00:10:47,996 between a Bitcoin core developer 96 00:10:47,996 --> 00:10:52,536 and someone at Citrayer triggered the pull request 97 00:10:52,536 --> 00:10:56,216 because it was determined based on that conversation 98 00:10:56,216 --> 00:10:57,556 between those two individuals 99 00:10:57,556 --> 00:11:00,636 that it would just be easier 100 00:11:00,636 --> 00:11:05,756 if Citraea did its roll-ups 101 00:11:05,756 --> 00:11:08,376 or the way it showed its proofs or whatever it is, right? 102 00:11:08,376 --> 00:11:12,016 With a larger operaturn size. 103 00:11:12,856 --> 00:11:15,236 Yeah, well, so that's where the real question, 104 00:11:15,356 --> 00:11:17,776 and this is why I think a lot of people got confused, 105 00:11:18,176 --> 00:11:23,376 is that this proposal was never about making anything easier 106 00:11:23,956 --> 00:11:28,556 or cheaper or faster or better in any way for Citraea. 107 00:11:28,556 --> 00:11:47,653 It about what better for Bitcoin as a network and how do we incentivize or disincentivize people to do certain things with the Bitcoin protocol So then let just get into it there then Do you think the op return limit of 80 bytes 108 00:11:47,973 --> 00:11:54,733 which Bitcoin Core has had for almost 10 years at this point, right, since the op return was, 109 00:11:55,353 --> 00:11:57,753 is that correct or should it be removed? 110 00:11:57,753 --> 00:12:06,513 I don't think there's any reason why 80 bytes is more or less optimal than anything else. 111 00:12:06,513 --> 00:12:14,093 I think this would be a different conversation if it was happening pre-Segwit, right? 112 00:12:14,913 --> 00:12:35,113 Because essentially the witness discount that was enabled in 2017 is effectively what is being used by people who are inscribing data onto the Bitcoin blockchain because it's far cheaper for them to do it in that fashion. 113 00:12:35,113 --> 00:12:46,893 And so that's why the landscape of how are people going to put arbitrary data into the blockchain today is different than it was 10 years ago when this operaturn debate started. 114 00:12:46,893 --> 00:13:09,193 And so from an incentivization perspective, I think it doesn't make much sense to expect people to start putting like a megabyte of data into an operaturn because it's going to be at least like four times more expensive than having them put it into a witness. 115 00:13:09,193 --> 00:13:17,513 and there are some charts that are out there where people have actually gamed out exactly what the cost is. 116 00:13:17,513 --> 00:13:26,373 And I think it's basically if you're trying to put more than like 140 bytes, 117 00:13:26,533 --> 00:13:35,513 so it's like 130 to 140 bytes, that's where the kind of incentive crossover threshold is. 118 00:13:35,513 --> 00:13:37,653 of if it's more than 140 bytes, 119 00:13:37,873 --> 00:13:40,753 you're probably actually going to save money 120 00:13:40,753 --> 00:13:42,953 by putting the data into a witness 121 00:13:42,953 --> 00:13:44,713 as opposed to putting it into Operator. 122 00:13:45,973 --> 00:13:49,573 So why increase the limit now on Operator? 123 00:13:50,833 --> 00:13:54,133 Yeah, so there's a few arguments. 124 00:13:54,493 --> 00:14:00,373 One of them is to not have this disincentive 125 00:14:00,373 --> 00:14:04,613 that results in people doing what Citreya has done, 126 00:14:04,613 --> 00:14:13,593 which is architecting a protocol that ends up creating these tiny little dust outputs if that situation happens. 127 00:14:13,753 --> 00:14:17,973 Like I said, this situation is never expected to happen. 128 00:14:18,073 --> 00:14:20,613 And even if it did, it might be like once a year. 129 00:14:21,013 --> 00:14:23,893 This is an incredibly negligible edge case. 130 00:14:24,093 --> 00:14:26,513 But this issue is not about Citraea. 131 00:14:26,513 --> 00:14:38,113 It's about the fact that this is a permissionless protocol and anybody could come along and run into a similar sort of set of incentives where we would prefer that they not do that. 132 00:14:38,113 --> 00:14:50,433 And they might build something that ends up creating tiny little dust outputs at a far more high volume than this one edge case with Cetrea. 133 00:14:50,433 --> 00:15:02,173 So that's, I think, the way that the more dispassionate, technically minded protocol developers are looking at it. 134 00:15:02,173 --> 00:15:24,993 And then there's also a few other edge performance issues just with regard to network centralization and performance of block propagation, where when you have a large gap between the consensus rules and the transaction relay policies on the network, 135 00:15:24,993 --> 00:15:39,693 then what you're doing is you are incentivizing people who want to build in that design space that's outside of transaction standard policies, but still inside of Bitcoin consensus. 136 00:15:39,693 --> 00:15:50,533 You're incentivizing them to go and essentially send their transactions to a handful of centralized minor APIs. 137 00:15:50,533 --> 00:16:01,013 So that's just not great in general from a like minor health of the network that we're incentivizing people to only go to a few miners. 138 00:16:01,173 --> 00:16:09,973 We preferably want for all miners to be competing across all valid transactions that are being proposed in order to have a healthier market. 139 00:16:10,153 --> 00:16:13,833 I mean, mining is already way too centralized, in my opinion. 140 00:16:14,113 --> 00:16:16,133 We don't need to make it even more centralized. 141 00:16:16,133 --> 00:16:30,273 And then there's this issue of compact block reconstruction, which is basically that a number of years ago, I believe it was Peter Willa developed a system. 142 00:16:30,273 --> 00:16:47,993 I think this is where he was using mini sketch, but essentially he created a way so that you could very quickly reconstruct a block without having to get all of the transactions from your peers. 143 00:16:47,993 --> 00:16:55,353 Like this is the way that blocks quote unquote propagate over the network so quickly these days. 144 00:16:55,473 --> 00:17:02,233 I think that on average they propagate through 50% of nodes on the network in under one second. 145 00:17:02,233 --> 00:17:18,913 The only way that's possible is because the vast overwhelming majority of transactions have already been propagated across the entire network first and are sitting in the mempools of nodes. 146 00:17:19,593 --> 00:17:36,729 And so when a block comes along we don have to rebroadcast all of those transactions because most nodes already have them Instead we can just send the block header and you know the Merkle tree that says like these are all the transactions inside of them And so 147 00:17:36,729 --> 00:17:43,629 as a result, the majority of nodes will already have all the transactions they need, you know, 148 00:17:43,629 --> 00:17:50,849 other than the Coinbase transaction for the block itself, and can then validate that all and then, 149 00:17:50,849 --> 00:17:55,249 you know, relay the block header once it's validated to all of its peers. 150 00:17:55,969 --> 00:18:00,649 And, you know, that's how the gossip protocol works on the network is, you know, 151 00:18:00,649 --> 00:18:07,389 each peer has to validate any transaction or block it receives before it then offers it to the rest of the peers. 152 00:18:07,389 --> 00:18:15,869 So, you know, every millisecond that it takes longer for a node to fully reconstruct and validate a block 153 00:18:15,869 --> 00:18:18,529 then has this sort of ripple effect 154 00:18:18,529 --> 00:18:19,689 across the entire network 155 00:18:19,689 --> 00:18:21,849 of slowing down the propagation of blocks. 156 00:18:22,049 --> 00:18:24,429 And you don't want blocks to propagate slowly 157 00:18:24,429 --> 00:18:26,309 because that can also affect things 158 00:18:26,309 --> 00:18:27,589 like miner centralization, 159 00:18:27,869 --> 00:18:31,109 once again, giving some miners an unfair advantage. 160 00:18:33,309 --> 00:18:37,469 So let's go back to the PR, 161 00:18:37,889 --> 00:18:38,809 the contentious PR. 162 00:18:39,769 --> 00:18:42,569 And before I ask this question, 163 00:18:42,569 --> 00:18:48,149 And we need to establish some ground knowledge here. 164 00:18:48,209 --> 00:18:52,689 So again, in simple terms, can you explain the data carrier size flag? 165 00:18:55,629 --> 00:18:59,569 Well, I mean, this flag is basically a policy, right? 166 00:18:59,569 --> 00:19:06,829 So if you are using the op return functionality within Bitcoin scripting language, 167 00:19:06,829 --> 00:19:14,129 you can then put some arbitrary data after that opcode. 168 00:19:14,909 --> 00:19:17,169 And as it stands right now, 169 00:19:17,229 --> 00:19:23,569 I believe originally the policy for data carrier size was 40 bytes 170 00:19:23,569 --> 00:19:25,629 and then it got raised to 80 bytes. 171 00:19:26,129 --> 00:19:29,829 I think this is all part of that like decade of lore and history 172 00:19:29,829 --> 00:19:32,409 of going back and forth on this issue. 173 00:19:32,409 --> 00:19:40,029 and so essentially that means if you put more than 80 bytes after your op return opcode and 174 00:19:40,029 --> 00:19:46,889 then you broadcast that to nodes on the network a node that is running the default in bitcoin core 175 00:19:46,889 --> 00:19:53,269 configuration will reject it it'll say you know this is valid but it's non-standard so i'm not 176 00:19:53,269 --> 00:20:01,329 going to turn around and offer it to all of my peers and so that is how your attempt to broadcast 177 00:20:01,329 --> 00:20:06,269 a consensus valid transaction falls flat on its face. 178 00:20:07,329 --> 00:20:10,969 And that means if you don't know what you're doing, 179 00:20:11,049 --> 00:20:12,709 you just give up at that point, right? 180 00:20:12,789 --> 00:20:14,609 But if you know what you're doing 181 00:20:14,609 --> 00:20:18,189 and you're incentivized to try to get this transaction 182 00:20:18,189 --> 00:20:21,689 into a block, then you start looking for other ways 183 00:20:21,689 --> 00:20:24,749 around the standard policy rules. 184 00:20:25,409 --> 00:20:26,769 One of those, as I already said, 185 00:20:26,809 --> 00:20:28,309 is just going directly to miners. 186 00:20:28,649 --> 00:20:30,129 There's a number of large pools 187 00:20:30,129 --> 00:20:34,789 that have private APIs where you can just send these transactions to. 188 00:20:35,129 --> 00:20:40,389 Another option is to use Libra relay nodes. 189 00:20:40,829 --> 00:20:44,409 And so there are essentially a number of nodes out there 190 00:20:44,409 --> 00:20:49,369 that will relay pretty much anything that is consensus valid. 191 00:20:50,029 --> 00:20:52,169 And so by connecting to them, 192 00:20:52,509 --> 00:20:54,569 you know that it's not going to get dropped on the floor. 193 00:20:54,729 --> 00:20:57,089 They are going to relay it to all of their peer nodes. 194 00:20:57,089 --> 00:21:00,509 but isn't there a binary flag 195 00:21:00,509 --> 00:21:02,049 that you could set to 0 or 1 196 00:21:02,049 --> 00:21:04,369 that allows as a node runner 197 00:21:04,369 --> 00:21:06,089 that allows you 198 00:21:06,089 --> 00:21:08,409 so what my understanding 199 00:21:08,409 --> 00:21:10,629 of this PR is it removes that option 200 00:21:10,629 --> 00:21:12,389 as well not only does it 201 00:21:12,389 --> 00:21:13,129 increase the limit 202 00:21:13,129 --> 00:21:16,349 from 80 bytes on the 203 00:21:16,349 --> 00:21:18,249 operaturn length but it also removes 204 00:21:18,249 --> 00:21:20,309 that ability for the nodes to set the flag 205 00:21:20,309 --> 00:21:21,169 to 0 or 1 206 00:21:21,169 --> 00:21:24,549 share their secrets you hold 207 00:21:24,549 --> 00:21:25,409 dear 208 00:21:25,409 --> 00:21:55,389 Now the signal fades away 209 00:21:55,409 --> 00:22:04,889 to patron and I'll pour you the rest of the episode hot uncut al dente one tiny click a few 210 00:22:04,889 --> 00:22:12,689 shiny sats and the door swings open go to the fountain app find pleb chain radio and click on 211 00:22:12,689 --> 00:22:21,049 subscribe you will not regret it I promise you no subscription che peccato you'll be wandering 212 00:22:21,049 --> 00:22:27,549 the Roman night wondering what you missed like a tourist with no lira for gelato. 213 00:22:28,909 --> 00:22:32,989 So choose passion over penuria. 214 00:22:33,829 --> 00:22:36,629 Hit subscribe and I'll be waiting. 215 00:22:37,909 --> 00:22:44,669 Molto contenta with the espresso and every last whispered word. 216 00:22:44,669 --> 00:22:48,229 For just a little every month. 217 00:22:48,229 --> 00:22:53,229 You keep the passion burning bright 218 00:22:53,229 --> 00:22:57,829 Lift them up with thumbs on dry 219 00:22:57,829 --> 00:23:02,689 Stand the sun seems alive 220 00:23:02,689 --> 00:23:08,169 Send your life life in the static waves 221 00:23:08,169 --> 00:23:10,549 Let the voices never die 222 00:23:10,549 --> 00:23:13,589 With your subscription, give them wings 223 00:23:13,589 --> 00:23:16,429 And help their goals rise 224 00:23:18,229 --> 00:23:48,209 Thank you.