{ "episodeId": "SLP661", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "antoine_poinsot": { "name": "Antoine Poinsot", "role": "guest", "tag": "ANTOINE" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.38, "text": "At the end of the day, if Bitcoin Core doesn't adapt to the demand for Bitcoin, it will be replaced by something that adapts to Bitcoin demand. There are two things. First of all, you're never going to reach your stated goal of preventing the arbitrary on-chain storage. You're only going to limit it. Second of all, to not even reach your stated goal, you're going to significantly alter Bitcoin's very like core and how it works. And I don't think that must be Bitcoin users would be very happy with" }, { "speaker": "antoine_poinsot", "time": "00:37", "start": 37.24, "text": "this. Hi everyone, and welcome back to Stephan Livera podcast, brought to you by Bold. For American listeners, you can buy Bitcoin at getbold.io. Now, rejoining me on the show today is Antoine Poinsot. Antoine is a Bitcoin core developer, and we're gonna be getting into this whole op return and spam. spam question and filters and all these things, obviously it's quite, controversial at the moment, but, I thought it would be good to have, you know, people explain some different perspectives on this. so, Antoine, first of, first of all, welcome back to the show." }, { "speaker": "stephan", "time": "01:16", "start": 75.62, "text": "Thank you. Thanks for having me." }, { "speaker": "antoine_poinsot", "time": "01:18", "start": 78.03, "text": "Yeah, so let's set the context a bit. I understand there's different pieces to kind of understand here because this specific- Poll request and mailing list discussion relates to OP_RETURN specifically, but there's also this broader sort of spam on the chain and filtering conversation, and maybe sometimes the wires get crossed a little bit there or arguments sort of go across from both sides. So do you wanna just set the context from your perspective on the OP_RETURN side of it and then the spam and filtering broader aspect of this?" }, { "speaker": "stephan", "time": "01:51", "start": 110.62, "text": "Sure. so there is this question around, tightening Bitcoin Core's release policy. which is not Bitcoin, but just Bitcoin Core standalone policy to filter inscriptions which have been in use since twenty twenty-three. It has been-- Sorry, just to," }, { "speaker": "antoine_poinsot", "time": "02:12", "start": 132.03, "text": "just quickly explain the, the relay part and the consensus part just for people who aren't familiar with that." }, { "speaker": "stephan", "time": "02:17", "start": 137.3, "text": "Yes. So," }, { "speaker": "stephan", "time": "02:21", "start": 140.71, "text": "Bitcoin is defined by its, by its consensus rules. That is what sets the incentives of actors in the Bitcoin system, of users, of miners, of everybody. Bitcoin Core, not only is the reference implementation of consensus rules, but it's also in addition, it does a lot more than just implementing the consensus rules. in particular, it's," }, { "speaker": "stephan", "time": "02:53", "start": 173.04, "text": "It's the backbone for a public relay of unconfirmed tr-transactions. There is no consensus on unconfirmed transactions, otherwise we wouldn't need blocks. and for these unconfirmed transactions, there is Tighter rules than consensus rules, for whether Bitcoin Core is going to relay these transactions through its peer-to-peer relay network. the reason we have tighter rules for, unconfirmed transactions is that, well, first of all, these transactions don't have any proof of work attached. So you basically have a software that listens to the, to the entire world where anybody with no identity can just send you transactions, and some of these transactions can be, Harder to validate or can indirectly lead your software to do a heavy amount of computation because it needs to rearrange its mempool or for other reasons. For these reasons, we have, M-much tighter rules on this, on these transactions, for relay." }, { "speaker": "antoine_poinsot", "time": "04:11", "start": 251.24, "text": "Yeah, let me, let me just try and repeat some of that just to make sure everyone's following along, and, you know, here's my understanding. You correct me if I'm getting anything wrong. So we have this concept of what is consensus valid, i.e., what goes into a block. There are kind of slightly looser rules for that, but there is a slightly tighter set of rules about-- that's known as policy or relay, and this set of rules is slightly tighter, and there are, I guess three, two or three main reasons for that. One of them is known as DOS reasons, denial of service. So because of this DOS risk, as you pointed out, they don't have proof of work attached to them That's one of the reasons why policy is a bit tighter than consensus. The other one I've, I've heard of is that there are upgrade hooks, so to kind of help miners support kind of the upgrades in the future with soft forks, that's another reason. And then thirdly, as I understand, there's this kind of light deterrent or slight discouragement, but maybe this is a point of contention where some people see that as historically that was like a gentleman's agreement without real force behind it, and others see this like, \"No, no, actually, these spam filters do work.\" So can A bit of your view there." }, { "speaker": "stephan", "time": "05:18", "start": 317.52, "text": "Yes. so maybe I can also just detail the second point, which is interesting, which might lead us into the, the third one. the second point is that By definition, when we make a soft fork on Bitcoin, we're going to make currently valid transactions by consensus invalid by consensus. And by virtue of having Bitcoin Core be the, basically the only implementation in use on the Bitcoin with re-real, on the Bitcoin network with real money behind we could leverage Bitcoin Core's standardness rules to have anything we are going to make invalid in a soft fork, we're going to try for it to be inval- to be, Already invalid by Bitcoin Core stand-alone rules. This makes sure that any miner that is using Bitcoin Core stand-alone rules, which is all miners Will not include, newly invalid transactions in, in its blocks after the soft fork. It, it makes it significantly, safer to roll out the soft fork because now we have Very good guarantees that, we aren't going to have a, a chain that is healed by some hash rate, with invalid transactions according to the soft fork rules after the soft fork. So we don't-- we aren't going to have users that can get tricked, with, confirmations in the, in a chain that isn't valid beca- just because they haven't upgraded. So, but this, this is a very nice property to have. It makes running outside fork much, much safer. On the other hand, it's only a property that we can have because Bitcoin Core is the," }, { "speaker": "antoine_poinsot", "time": "07:16", "start": 435.52, "text": "It's like a dominant node implementation. Yeah. One other quick clarification for listeners, just when we're talking about relay policy and consensus, the other term that we're using here is standardness. So it means if something is considered standard, it means it's inside a policy, and a standard Bitcoin Core node will relay that on the public relay network of Bitcoin. And if something is non-standard, it means it is consensus valid, but not considered to be, you know, the standard Bitcoin Core node Modes will relay that on the network. So we-- that kind of comes up later in the discussion about standardness versus non-standard. Okay? So, just, so I guess we've spoken about the DOS aspect of it, the upgrade hook of it. Now, let's talk a bit about the, the, let's say, the light deterrent or the gentleman's agreement. Can you explain your perspective on? yeah, on that, on that third component." }, { "speaker": "stephan", "time": "08:09", "start": 488.7, "text": "Yes. so" }, { "speaker": "stephan", "time": "08:13", "start": 492.79, "text": "historically, there has been little demand for anything that was outside of Bitcoin Core's and Daon's rules. therefore We, we, we, we need to distinguish Bitcoin users and Bitcoin Core users. And Bitcoin users have had little economic demand for transactions that are outside of Bitcoin Core's standards rules. Therefore, Bitcoin Core could keep fairly tight, sets of stardomness rules. Then, back in twenty thirteen, I think, some people started using transactions that were stardom according to Bitcoin Core, but created like that were, that imposed a significant negative externality on all node users, and these transactions were using fake, public keys in outputs, which created forever unspendable outputs in reaction to- This, the Bitcoin Core developers standardized, an output type which is the operator output, which let these people because Because there was economic demand be-be-behind this use case, like Bitcoin Core couldn't, like the, the only reaction to it would have been to make it, consensus invalid, which was not possible because you're not going to make public keys consensus invalid in Bitcoin. So second best option, try to standardize a be- a way of doing this that is less harmful to all users, that was done with of return, along with this Caving, let's say, as some like to say, the up return output was on the other hand limited in size, to, to try to say, well, if you are going to build a protocol, try to not, include more than eighty bytes of arbitrary data in your output, and, and that's what people did, because they had, for, for newer protocol, people just used the standard way Of, of doing thing, of doing things because digital gold, there wasn't much demand for using more data and they could take advantage of the public relay network of and confirm transactions. So that, that's just the, the way they did it. So that's a bit of the history." }, { "speaker": "antoine_poinsot", "time": "10:38", "start": 638.05, "text": "Okay. A couple other questions, I think these are just kind of the upfront, kind of obvious questions that I think listeners will wanna hear the answer. So, you know, a-and even, I'll answer it as well from my perspective as well. I'm not paid by any spamming or shitcoining companies, as far as I'm aware. I don't hold any investments in, in any spamming or shitcoining companies. I hold Bitcoin, and I might occasionally invest in Bitcoin companies and have some equity in Bitcoin companies. That's at least from my perspective. Do you wanna answer that from" }, { "speaker": "stephan", "time": "11:06", "start": 665.72, "text": "Yes, I work on Bitcoin Core, I'm very personally invested in Bitcoin's future. I have shares of my former company, without selling, which is a Bitcoin security company, working on Liana, which is a wallet that already exists and doesn't need any changes to Bitcoin. I don't have any financial interest in JPEGs or whatever stupid things that people might be doing." }, { "speaker": "antoine_poinsot", "time": "11:36", "start": 695.96, "text": "Gotcha. And there was another one, like a screenshot that's kind of going around because people were sort of arguing back and forth on this. So this particular pull request was opened by, as I understand, it was opened by Peter Todd on your request because he had opened an initial pull request two years ago in twenty twenty-three, which was similar or the same PR, and apparently he was paid by Christopher Allen to do This, are you able to explain from your perspective, is that a smoking gun from your perspective or the arguments stand on their own merits? What's your perspective on that?" }, { "speaker": "stephan", "time": "12:06", "start": 725.5, "text": "I don't know, I, I don't know why Christopher Allen paid Peter to, to open this pre-request, and I didn't, I didn't even look in Peter's original pre-request, I knew through at the time, inscriptions that just had came out. And, I knew it would be unproductive to try to engage in the thread, so I was pretty dismissive. I felt like, I felt like Peter Tad just wanted to trigger the, the filters and lawyers and, by saying it makes no sense. I, i-in a way, I agreed with him, but I was like, it's not a good use of my time to try to argue in his favor, not a good use of Bitcoin Core's GitHub repository. Create a thread that is obviously going to be, to be, controversial at this time. so I didn't engage and I have no clue why Christopher Arline would even pay him for this." }, { "speaker": "antoine_poinsot", "time": "13:06", "start": 785.9, "text": "Okay. Maybe" }, { "speaker": "stephan", "time": "13:06", "start": 786.1, "text": "there, maybe there was a, maybe there was a good reason as well. Like, I get paid to work on Bitcoin Core by people that, by the way, don't even tell me anything about what I, I should do or not. many people do get paid on Bitcoin Core just for the simple reason that it's very hard and you're going to spend your days doing it. So if you want people to be working on the thing, they will need to be financed at the end of the day. And if people's getting financed or the source of their finance is how- How we are going to judge changes, we have a much bigger problem than the size of operator and bystander." }, { "speaker": "antoine_poinsot", "time": "13:41", "start": 821.32, "text": "Also, can you just distinguish for listeners this particular operator PR and the broader campaign on spam filtering? Whether that's a good idea or not a good idea. Can you just explain your perspective and, you know, how people, or at least how you think of that, how you think of those two different things?" }, { "speaker": "stephan", "time": "14:02", "start": 842.25, "text": "Yes, so just to give a bit of context, in, twenty twenty-three, people started using inscriptions, which were basically arbitrary data stored in, in witness, in, an input witness, the witness data being discounted by consensus and not by policy, like some people say. it's discounted by consensus, therefore it's four times cheaper to store this data there, given that there is very little demand for using Bitcoin at all, it appears. these people just started storing whatever Stupid things on chain, and they're starting to create a hype, and the hype create, brought more demand, which introduced more supply of such protocols and triggered a large usage of the, of the Bitcoin blockchain to store this data. at the time, some people believed that if Bitcoin Core, was to try to- To tighten its standoness rules to make these, inscription transactions that store in val- arbitrary data in their input witness invalid by standoness, it would prevent" }, { "speaker": "stephan", "time": "15:27", "start": 926.65, "text": "no, it wouldn't prevent, that's not what they say, it would raise the cost to them to use, to use them, and therefore they would go away and start using Outcoins or whatnot to store their data. Unfortunately, I believe it's incorrect, but it led to a lot of debate at the time. Fast forward to twenty twenty-three, twenty twenty-five, two years after twenty twenty-three and the inscriptions debate, Bitcoin Core still has the same standards rules, in this regard, not in others, but in this regard, the craze around inscriptions have Mostly died off. Bitcoin block space usage is back to what it was before, which is pretty low. and I suggest to standardize larger output and outputs. For very technical reasons, some users of the public relay networks want to be storing transaction in transaction outputs, which is not to store a large amount of data as it was the case for inscriptions back in twenty twenty-three, because if they wanted to do so, they can already do so and for four times less through the witness. What they want is a small amount of data in their transaction's outputs, and it's something that they can already do by Bitcoin Core standards rules, and they just do it by, again, same as in twenty thirteen, using fake public keys in outputs. So that's what they do today. I met with one of the funders of such a protocol or, let's say, an application because it's, it's a user of the Bitcoin relay network, and he just told me that they were doing this, and I was like, \"No, that's bad. How about we standardize, we standardize large up- and out-put instead?\" He was like, \"Fine, I didn't, I didn't implement it entirely yet, as people aren't actively using the, the version with pay-per-key, I can, I can still change to up-return if you guys standardize it.\" in any case, in any case, he's going to broadcast stuff through the Pi- Bitcoin peer-to-peer relay network. I- so it's either fake public data that is forever expendable outputs that everyone has to store forever, or it's on our operator outputs. So I emailed mailing lists, saying we, we should just get rid of the staleness, limits on operator. In one way, Peter thought it was right two years ago, it- this Tightening, this tight policy created incentives to use more harmful ways, and they're unnecessary in the first place because people that want to store data are using a structure that cost them four times less in any case. So we might just as well get rid of this limit and stop, stop creating perverse incentives for users of the relay network." }, { "speaker": "antoine_poinsot", "time": "18:35", "start": 1115.29, "text": "The lead sponsor of this show is Bold, the best place to buy, sell, and save Bitcoin. For listeners in the US, Bold lets you secure your financial future with complete peace of mind by integrating a low fee Bitcoin only brokerage with next gen multisig vaults. With Bold, you can smash buy Bitcoin or set a DCA plan for only zero point nine nine percent fees and seamlessly deposit the Bitcoin direct to your Bold Vault. The Bold Vault is a two or three collaborative multisig where you hold two keys and Bold holds one as a redundant key. backup, protecting against loss or theft. You can use Trezor, Ledger, or cold card hardware wallets to spin up a Bold Vault in just a few minutes, and the Bold Vault is the only collaborative custody vault available with zero monthly fees. They're also offering zero fees on your first ten thousand dollars of Bitcoin buys and twenty five dollars of free Bitcoin when you buy a hundred dollars of Bitcoin or more. Try Bold today and upgrade your stacking experience over at getbold.io. And now, back to the show. Okay, so let me just, explain again. Is, is very technical, but as I understand, the inscription-- So it's a bit complicated. So in twenty twenty-three, that was sort of when we saw this craze known as ordinals, and associated with ordinals, there were other things like inscriptions, BRC twenty, SRC twenty, et cetera. Now, ordinals, the, the protocol itself relates to kind of the serialization of satoshis and kind of the first sat in a block or the first sat in a halving or et cetera, the first sat in a difficulty adjustment, these kinds of things. And there was this inscriptions thing which relates to things like putting, putting JPEGs in the chain and so on. Typically, that inscriptions thing uses this thing known as, I guess it's colloquially known as the Taproot inscription envelope, and that relates to, as I understand, it's like a, it's a, it's a type of script that's written in a way, it's like OP_FALSE, OP_IF, and then they push some data, and then that, inside of that, there's like this commit and reveal structure, and that is What they're using to put this, put these JPEGs into the chain, this is going into what's known as the witness section of the data, and it never enters the UTXO set. That's one side, that's the inscription aspect of this. On the other side of this, you have this, these fake pub keys that are- That are going into the UTXO set, and the downside on that is you cannot, prune those, every node has to download those. We saw this expansion over that time of the UTXO set from about four gig to, I think, maybe twelve gigs, something like this, and every full node on the network Even a prune node has to maintain that, and so it's kind of an increased requirement on every node runner. Have I summarized it correctly?" }, { "speaker": "stephan", "time": "21:17", "start": 1276.88, "text": "Yes, absolutely, and it's very important to point out that there are two different concerns." }, { "speaker": "stephan", "time": "21:26", "start": 1285.79, "text": "me dis- proposing to re- to, to remove the limits on the offer return Gave an opportunity, for people that were discontent with Bitcoin Core's current relay, policy to not have tightened them back in twenty twenty-three to restart this debate. And it led to the two discussions to be mixed up together of whether we want to remove the limits on our returns and whether we want to filter, filter-- I don't, I don't think it's a good term because it's not going to filter anything, but whether- Either we want to tighten Bitcoin cost and onus rules to prevent relaying arbitrary data storage. So the, these are two different constraints. My proposal isn't going to enable anything new with regard to data storage. My proposal isn't to accommodate any specific company, it's not to accommodate any specific usage, that would be needed for new users, they don't need it. We do. Like we, Bitcoin users, need it for them to, to use a less harmful way of storing data, but they don't." }, { "speaker": "antoine_poinsot", "time": "22:38", "start": 1357.53, "text": "And I guess there's, I, I should have asked this a bit earlier as well, beca-one of the, let's say, upfront obvious questions, because this has become a bit of a, a meme online that people are saying Bitcoin core developers don't see Bitcoin as money, they see it as this database for arbitrary storage. So- Just, just asking the question so you can answer it. Do you view Bitcoin as money, and do most core devs see it that way?" }, { "speaker": "stephan", "time": "23:00", "start": 1379.62, "text": "Yeah, I, I replied online as well. It's, it's like a tautology, right? To see Bitcoin as money, as Bitcoin is money. the way it's, it is implemented, because even if you say Bitcoin is money, probably you're talking about the assets, the asset is enabled by a, a network, and this network Physically, the, it contains data, and people are always going to try to use the data for other things. one, one interesting example is to, the ordinals that you mentioned earlier. they're just Change the meaning without storing any data on the chain, change the meaning of this set. Oh, this, this set is worth more than this set. The, yeah, you, you just can't prevent this. But yes, I do see Bitcoin as money, obviously. all Bitcoin core developers see Bitcoin as money, and then I think there is maybe different perspectives on how bad people storing data on chain is. I think some people view it as really inevitable, some people see it as at least someone is using the chain and maybe we'll get some money for miners once we don't have subsidy anymore, and some people are really discontent about people actively using the chain to store data and wish it would go away, but realize that trying to act upon it at the relay policy Later is going to make things worse. So yeah, everyone sees Bitcoin as money, that's why we are all interested in Bitcoin, that's why we are spending our career improving Bitcoin and spending all our days, for some of us, our weekends, trying to make Bitcoin better. So it's, it's, it's really a misperception of Core devs, as being I don't know, nerds that don't even care about Bitcoin ideologically, I think. That's very, very different. Like, most people I can think of right now on the top of my head care deeply about Bitcoin and Bitcoin emission." }, { "speaker": "antoine_poinsot", "time": "25:24", "start": 1523.72, "text": "So let's go back to this narrow op-return PR, and just ask a few questions around that. So I think some of the discussion in that thread was sort of saying You know, why uncapped it instead of going up to, I don't know, a hundred and fifty bytes or so? Was it seen like that would be an arbitrary decision? W-what's the-- Because some people are saying, \"Oh, why raise it all the way now to, I think it was a hundred kilobytes is now the theoretical limit?\" Can you explain your perspective on that?" }, { "speaker": "stephan", "time": "25:53", "start": 1553.32, "text": "Yes, so, I think hundred and fifty would be just enough for Citrea, but I'm not really concerned about Citrea's use case. I don't know if I defined Citrea as basically the users that I met, that I met that are saying that they're going to use the fake public keys. So it would, the, the immediate concern of these guys would be covered by increasing the limit to hundred and fifty bytes. But the, their usage is going to be very, very limited, it's, it's some sort of challenge transactions in, in the unhappy path, for using their protocol. So these transactions that is going to blow the UTXO set should never happen on chain in normal condition. So probably we would see, I don't know, a few, a few per year But what I'm really concerned about is that it's a signal, it's a signal to Bitcoin Core that there are users of Bitcoin that Want to use the, the, the, the, the chain differently and because they want to use the Bitcoin Core relay network, you are pushing them to use more harmful ways of doing what they're trying to do. So I think it's a, it's a strong signal to act upon, and so, I'm more worried about future use cases, therefore, just limiting it to hundred and fifty bytes. It's just Trying to patch it in a rush, whereas I think we should more, be more concerned about what's, what's, what's, what's going to be the next application, are the developers of the next application going to be as willing to engage with us as Citra has been? Because Me asking them to use a return instead is just, that's up to them. They don't care, they have no incentive to use a return instead. So maybe the next ones won't be able, won't be willing to change. So I want to have a limit that is future proof, let's say. So maybe, maybe you could say raising it to one thousand, one kilobytes would be enough? and I think it would be pretty hard to make the case to bump it all the way back from one K to a hundred K, on, on the basis of this argument of future usages. But on the other hand It's just an unnece-unnecessary limit that we have in Bitcoin Core that is an artifact of more than a decade ago, a limit being introduced, back when blocks weren't full, back when Bitcoin Core was even more dominant, and if Bitcoin Core hadn't been dominant in the past decade, it would just not be a discussion anymore. These trans-transactions would be related in mind. So So I, I, I think it's, it makes no sense for us to just keep on maintaining this, these limits. Having these cards isn't necessary, and it's just good excuse to get, finally get rid of unnecessary card." }, { "speaker": "antoine_poinsot", "time": "29:02", "start": 1742.0, "text": "Okay. And so on this op-return issue, how urgent do you believe it is to fix this issue? Is it a must-fix now? Is it a medium-term thing? Is it more like a long, long-term thing that, you know, has to be fixed for the incentives of the network to try to stave off miner centralization? How urgent is, is this for you?" }, { "speaker": "stephan", "time": "29:23", "start": 1762.91, "text": "The miner centralization concerns are separate, they are for the inscription filtering thing. Like for the up return, in any case, for the up return, it's transactions that would be already stand out, so There would be no incentive for them to be using, private bridges to miners. So the, this is a big topic that is probably more interesting than the size of fucking operators, but that's, that's a separate conversation. For the urgency to fix, it's hard to say. If we only consider Citria, it's not that urgent. But also we need to consider That it's, it's, it's a signal, it's piece of information that, hey, you're, you're creating perverse incentives which should make us pause. We should make, like, creating perverse incentives pretty, pretty bad in, in- In our case, and I think we should act quick to make sure that new applications don't, build on top of the technique that is used by Citra that is harmful, because I'm, I'm convinced that new applications once they're built You're going to have a very hard time to ask the, them to go back, re-implement their constructions, convince their users to switch back to the new version of the protocol just to be nice. I feel like people can do things just to be nice, but if they're not financially motivated, there isn't so much that they're willing to do to help you." }, { "speaker": "antoine_poinsot", "time": "31:04", "start": 1863.6, "text": "I see. And so I guess the concern I can see kind of both sides there. On one side of it, you can see every now and again there's like some new meta protocol that comes out, and maybe that's part of the broader kind of spam filter discussion where, you know, there might be some Chinese meta pro-- new meta protocol, and maybe kind of, you know, Bitcoin Core developers aren't really in touch with them per se, and they might just come out with some new meta protocol, and then we're all just dealing with them kind of in the mempool and doing whatever. But I, I guess others would see that, Say, I guess kind of the, the censorship resistance maxis might sort of take the, the view of, I guess we're kind of going more into the broader filtering discussion. So one other, one other area I wanna get into, just on this op return specific point before we go to the kind of the broader conversation, some people are saying, \"Why not give people the option? Why not let the node user have a config or a command line option to, to, to, to choose what they want to?\" Relay, because there was a concern that this would potentially get deprecated, and so there was some discussion there saying, \"Okay, well, deprecated just means it still exists now, but it's probably gonna get deleted in the next version.\" So that was the concern. What's your view on giving people an option or a flag, to choose their own relay policy, let's say?" }, { "speaker": "stephan", "time": "32:30", "start": 1949.65, "text": "my personal view is, that the option isn't necessary and that if we are going to change the default, then we need to rem- we sh- no, not we need, we don't need to do anything, but we should remove the option. it appears to not be consensual among contributors to the project, which is a thing, like Bitcoin Core isn't one mind thinking, alike on all issues. People have different views. I'm not going to die on this hill, but I personally think we should get rid of the option. I-- before making the point of why I believe we should get rid of it, let me state that in any case, it's an objection to the implementation of the change. And it's not an objection to changing the default per se. and" }, { "speaker": "stephan", "time": "33:20", "start": 1999.99, "text": "for, as for why I believe we should remove the option is That once, let's face it, once Bitcoin Core changes the default, it's going to become the de facto policy on the network. And, if it becomes the de facto policy on the network, one local node changing His own option isn't going to have any effect whatsoever globally. So the only reason one may want to change the option is for maybe some sort of local use case. So let's consider what can be a local use case. Well, I don't want to be, storing operator data in my mempool. Sure, but if you don't have it in your mempool, you're going to store it anyways because it's going to arrive in a block. then, but in addition, not having it in your mempool is going to be a footgun for you if you are using Bitcoin, to transact, because then you're going to blind yourself to some transactions that you're competing for Or, block space with. And if you are a miner, even more importantly, you are going to make block propagation to you, slower and therefore, Marginally reduce your, effective hash rate. I don't think there's str- these are strong options to, strong, strong reasons to, not have the option at all, but the-- there's definitely no good reason, no valid reason to have the option. Because there is no reason to have the option, because having an option imposes a cost on the project and on users. Bitcoin Core has hundred and fifty startup options at this time. It's crazy. I don't think we should have an option that has no to mildly negative effect on the user. And, a-and it's something that we just do normally as well. We don't have us-- we don't have options that are going to be, to have a negative effect on the- The user and we don't have options that are going to have no change whatsoever for the user. So I think we should remove it. But it's also-- I'm not going to die on this hill, currently what Bitcoin Core is going for, well, I didn't open the PR request, someone else opened a new PR request and it seems that most Bitcoin Core contributors act this PR request and this new PR request doesn't get rid of the option. It does mark it as deprecated, as you, as you mentioned." }, { "speaker": "stephan", "time": "36:05", "start": 2165.16, "text": "we'll see how it, how it goes. last time we marked an option as deprecated, we removed it, it was for MPO for LBF, but, sometimes we mark stuff as deprecated and we never go-- come around to removing it. But it doesn't matter, it shouldn't matter, because the option does effectively nothing for the user" }, { "speaker": "antoine_poinsot", "time": "36:24", "start": 2184.35, "text": "Okay. And so you mentioned, mempool full RBF. Now, this is, perhaps, perhaps there's some parallels here, that it's sort of this, even though- It w- you know, it was kind of changed at, at Bitcoin Core, it's kind of like this emergent behavior on the network that if enough users do this thing, have full RBF, then the network effectively just operates that way, partially because Bitcoin Core was so dominant, but also just kind of the incentive of it. And so, I guess in a way, I'm sort of seeing this as a similar thing that it's probably gonna end up going in a similar way. But what do you think? Do you agree or disagree, or do you see parallels or no?" }, { "speaker": "stephan", "time": "37:03", "start": 2223.26, "text": "I agree. I, I definitely see parallels, both in accusations around, around that to Bitcoin Core trying to change things and about pseudo-motivations, although it's become worse with the, with the filter, filter people. And I see parallels as well in terms, technical reality. if you want To make a change to prevent some transactions to access the miners, you're going to need basically consensus. You're going to need everyone to agree, everyone to make this change, everyone to turn it on And if you want to make a, a, a transaction, you just need one person to relay these transactions that others don't want to make. And we- Which is kind of the purpose, kind of the purpose of Bitcoin. But yes, you, you just need one path to miners, you just need some percentage of the hash rates to, or some, some percentage of the relay network, or just an alternative relay network for the transaction that other people don't want you to make, to, to be made. Therefore it was the same with full RBF, the transaction in this case that people didn't want you to make is a replacement of a transaction that didn't explicitly signal which it was up for replacement, and in our case, it would be, Since sort of very large op return, but nobody asks for large op returns today, they just use fake public keys instead. But yeah, I see parallels, I agree." }, { "speaker": "antoine_poinsot", "time": "38:46", "start": 2326.4, "text": "Alright, so let's now talk about the, yeah, so we've kind of spoken about the specific op return pull request, or there, there were multiple, but the one you mentioned that's still open is, InstaGibbs, Greg Sanders' one is still the open one, Peter Todd's one was closed as I, see it. and so now if we talk about the broader- I guess spam and filtering conversation. There have been various arguments made, accusations, et cetera, so I guess we should deal with some of those or at least hear your perspective on some of those. So For example, people like Mechanic have made this argument that, \"Oh, there's this apparent double standard that core people are trying to argue on one hand that filters don't work, but on the other hand that filters do work. Which one is it? And is that, is that just some kind of rhetorical move or is that ignoring a nuance? What's your view on this question of do filters work?\"" }, { "speaker": "stephan", "time": "39:41", "start": 2381.01, "text": "Yeah, I think it's a pretty good re- rhetorical move. I don't want to ascribe intentions to, to mechanic for doing it, but I think it's, it's absolutely false, but it was very effective in swaying some people to, to his side. It's mixing up two things as being the same thing and saying that, \"Oh, we are contradicting ourselves.\" It isn't the case. in the case of, The up return, what Citria wants to do is to use the public relay network because they want the properties brought by the public relay network. Therefore, they ha- they need a way to make their data work through this public relay network. So that's In, in this sense, the standardness rules work because they are using something that is defined by the standardness rules. so in this case, they're just going to use fake public key data instead. But where Bitcoin Core says, \"Well, Bitcoin Core doesn't say anything,\" I say things, where I can say that filters don't work is that in preventing people from using Bitcoin to store data, because what defines Bitcoin is Its consensus rules and, trying to change Bitcoin Core to prevent Bitcoin users from using Bitcoin in a, in a, in a specific way isn't not going to prevent To Bitcoin user from using it how they want, it's just going to prevent Bitcoin Core from having adoption. People just not gonna use Bitcoin Core anymore, they're just gonna use a separate implementation or direct way to contact people to get, the transactions mined. So it doesn't work at preventing people from using on, from using the chain as they want. It does prevent people from using the standard public relay network, because that's, yeah, how it is, how it's defined." }, { "speaker": "antoine_poinsot", "time": "41:46", "start": 2506.35, "text": "Okay, so your answer is they, they can work in certain contexts, but in this context, it's not an applicable argument, is that? No, like, how else would- Yeah, because, but," }, { "speaker": "stephan", "time": "41:59", "start": 2518.96, "text": "but I, I don't like, I don't think it's a good reply because it works in some context and not in others would be too vague. It, it does, it works for the public standard transactions relay because like standardness rules work for the public standard relay, consensus rules work for- Bitcoin blocks" }, { "speaker": "antoine_poinsot", "time": "42:21", "start": 2541.32, "text": "what goes into blocks," }, { "speaker": "stephan", "time": "42:23", "start": 2542.52, "text": "yeah. And so saying that standards rules are going to prevent data from entering blocks is incorrect. Saying that standards rules are going to prevent, data from entering the standard public relay is correct, although to their credit, the argument that, they are making is that Changing the standard public relay network is going to affect how people use the blockchain, but maybe it's going to be another question." }, { "speaker": "antoine_poinsot", "time": "42:51", "start": 2571.44, "text": "Gotcha. Okay. and so another point of discussion, maybe it's a broader point or maybe it's a specific op return thing, but people are saying there have not been very many non-standard op returns in the last few months. Therefore, you know, you're kind of making a big deal to change this big PR when really it's not really gonna be used that much." }, { "speaker": "stephan", "time": "43:12", "start": 2591.85, "text": "Yeah, it's not about changing non-standard op returns. So that's besides the point, and I'm not making a big deal, I think it's a pretty boring change, and people aren't making a big deal out of it." }, { "speaker": "antoine_poinsot", "time": "43:24", "start": 2603.7, "text": "And now, another argument I've heard is from the filter camp, they might say things like, \"Okay, look, yeah, the core developers are saying these concerns about UTXO bloat, miner centralization, block propagation, these are technically real, but they're being overplayed by core and maybe interviews. They'll say this, it's being overplayed by shitcoiners and spammers because they want...\" They want to make it easier to spam, or they want to make Bitcoin a database and not money. That's kind of their argument. What's your perspective on that?" }, { "speaker": "stephan", "time": "43:53", "start": 2632.61, "text": "I don't think that the arguments for miner centralizations from people that-- from people that are contributing to Bitcoin Core or contributed to Bitcoin Core in the past are overblown. I think miner centralization is probably one of the biggest issues of Bitcoin right now And making it worse is going to be pretty, pretty bad. Like if we have very centralized mining, we don't have censorship resistance anymore. If we don't have censorship resistance anymore, Bitcoin is entirely uninteresting. Like you might as well use other types of Money that can be censored and are much more effective than Bitcoin if, if you're going to lose this censorship resistant aspect. so I believe concerns about miner centralization should always be taken very seriously just because of their impact. in addition, I think the, miners' centralization arguments are pretty well articulated and have very strong arguments for them with regards to, trying to use the NFTs to change the demand for block space. and the last one, people trying to change Bitcoin for making it a database. Nobody is trying to change Bitcoin. Like Bitcoin is what it is, we aren't, like, nobody is present, is trying to propose a consensus change. Bitcoin is what it is. Bitcoin users will want to use Bitcoin how they want to be using it, if we want to change some usage of Bitcoin, we need to change Bitcoin, so we need to change the consensus rules. it's, there is no such proposal on the table, even from the fixed filters people, to change Bitcoin. So it's It's, it's beyond the point besides saying that some people have motivation of making Bitcoin a database or speculating on motivations is a waste of time and also trying to work like to, it, it's also a red flag in discussions because it's like trying to appeal to resentment and emotions instead of logical objective arguments. And, yeah, they don't I don't want to change Bitcoin because nobody is trying to change Bitcoin. Well, some people are trying to change Bitcoin Core, I do because I think it would be a better change for Bitcoin Core users. At the end of the day, if, Bitcoin Core doesn't adapt to the demand for Bitcoin, it will be Replaced by something that adapts to Bitcoin demand." }, { "speaker": "antoine_poinsot", "time": "46:41", "start": 2800.6, "text": "Back to the show in a moment. This show brought to you by CoinKite dot com, the creators of the best Bitcoin hardware security devices, such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on those, the seed word cards, and keep that Secure. Now you can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Bacter Desktop or Nunchuk as a few examples. Now you have a range of security features that you can use with these devices such as passphrases, you can use seed x or, or my favorite is multi-signature. Now if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code Livera to get a discount on your cold card. This episode brought to you by Galloy. They are building banking software for the Bitcoin age. So if you are with a bank, a fintech, or a startup looking to offer some- Some kind of Bitcoin product, whether that is a Bitcoin collateralized loan, deposit account, or payments, Galloy can help you. Their latest product is called LANA. It is a loans management platform, and you can use this to come to market quickly and offer a loans, Bitcoin collateralized lending product for your customers. Now, Galloy have a lot of experience in the space. They started with Blink Wallet in twenty twenty, and they've since grown this to become a community favorite over time, and so they have a lot of experience making things work. In a secure, reliable, and scalable way. So if you need assistance coming to market quickly with a Bitcoin banking product such as lending or deposits or payments, talk to the team at Galloy. You can email them, the email is biz at galloy dot io, or go to the website galloy dot io. And now, back to the show. Okay. And so essentially what you're drawing there is a distinction between Bitcoin, the overall protocol, let's say the consensus, and Bitcoin Core, which is merely one client Though it is the dominant client or server or app software that drives that network. So it's, I guess, you're trying to draw that distinction there, whereas, let's say, the filter guys are saying things like, you know Bitcoin Core should tighten, standardness rules. It should, do more to do things like stopping the, the current version of the Taproot in-inscription envelope or to stop bare multisig and stop, you know, this data carrier size issue and some of these aspects. So that's kind of my understanding of this. Now, I mean, just for listeners' sake, I, I'm trying to obviously reflect, you know, the concerns that I'm hearing in the community, but f-f, you know, for me personally, I, I think- While I, I see issues in terms of the kind of the GitHub moderation and maybe the communications of it, I think most of the core developers are technically correct and sort of reflecting the reality of the network. So personally, I think Bitcoin core developers are kind of being-- It's kind of like the mes-- people are shooting the messenger when the reality is There's maybe not so much that can be done about the spam, but we're gonna talk a bit about some of those con-concerns because some people maybe in their view think that if Bitcoin Core was doing more, that you could stop the spam per se. That's maybe that's the, a filter position, let's say. and so I guess- A filter position that I seem to see is they sort of say, \"If enough people ran filters, let's say they ran not, then miners who mine spam are effectively being- Penalized on their block propagation. What do you say? What do you think about that?" }, { "speaker": "stephan", "time": "50:46", "start": 3046.09, "text": "I don't think it's very persuasive as an argument. Or" }, { "speaker": "antoine_poinsot", "time": "50:49", "start": 3049.27, "text": "in other words, would it be like, what level of, let's say, node adoption or filter client adoption would we need to see before it actually started to make a real difference? Do you have a, like a, a guess or an idea of that? Or no," }, { "speaker": "stephan", "time": "51:05", "start": 3065.02, "text": "I don't think it's going to make much of a difference, to be honest. And in, in any case, what matters is the Propagation between miners. Miners are going to be incentivized, so what they want is always a superset of, because you can have many implementations that all have different policy rules, different standards rules, and miners are incentivized to have A set of policy that englobes all of them, because then they can get the fees from all the, the various, sub relay networks. And in this case Well, they're going to include all the transactions, including the spam ones, and therefore they're probably going to want to be connected directly to each other, and therefore it won't, it won't have any effect whatsoever on propagation to miners, might have different effect on propagation between users, but It would be a matter of seconds, and matter of seconds is only going to matter for miners and not for users." }, { "speaker": "antoine_poinsot", "time": "52:03", "start": 3122.92, "text": "Okay. And so, yeah, I guess i-important context for listeners who maybe aren't as familiar There are the-- there's this thing, as an example, Mara is running this thing called Slipstream, which is like a priv-- kind of like a private mempool or a private API that people can Submit non-standard transactions that are consensus valid but not policy valid or whatever, not, relayed. And there are-- and it's been known that this is like a thing people can do, like, I think F2Pool has done this kind of thing in the past. And so- There's kind of a, a concern there that this private mempools is a concern just generally. That's kind of one thing people have spoken about, but the, the point here is more like, if you increase the filtering on the relay network, it's gonna drive people to use like Myra, Slipstream, or another thing is a- A one off kind of implementation called Libra Relay by Peter Todd, which also is kind of like a more openly relaying, thing. And so I, I, as I understand It would be like really difficult to actually stop the propagation of these things because you would need to get like a really, really high supermajority of, let's say, filtering clients, whether that's people running nodes or something like that, to actually stop these transactions propagating. Is that Fair to say, or what do you think about that?" }, { "speaker": "stephan", "time": "53:28", "start": 3208.48, "text": "I think as long as these transactions are going to be consensus valid, you, you have two, you have two choices. Either there is significant economic demand behind them or there isn't. If there isn't, it's not a problem in the first place. They're not going to be using any blog space whatsoever, don't, don't, like you can't try to filter them, this probably going to work because there is very little demand Behind them, if there is significant demand, such as we have seen with audios, which is hundreds of Bitcoin, like forking Bitcoin Core and changing the, the size of a variable, like the, the value of a variable, sponsoring even a develop-- Bitcoin practical developers using alternative implementations, it's not so hard to do So if, as long as there is economic demand behind it, you're always going to have either people or routing around the public relay network. Or having separate public relay network that are being built, and miners are going, always going to be incentivized to be using the more liberal, relay network as long as they don't get dust, to, To get more fees. So, yeah, I don't, I, I don't think that even if everybody was using, was running that, like, let's say, let's say Bitcoin Core, In twenty twenty-three, merges Luke Junior's poll request to match, inscriptions, which is the exact structure you detailed at the beginning, that they are using in the script to store their, their data." }, { "speaker": "stephan", "time": "55:15", "start": 3314.83, "text": "people don't really pay that much, much attention because of Bitcoin Core's track, record, the upgrade to the new version of Bitcoin Core, or they might even think that it's marginally good thing to do, the upgrade. And now the major, like the whole public and confirmed transaction relay network, doesn't accept inscriptions anymore. People are just going to move to using a website, such as Slipstream, instead of running their Bitcoin nodes and sending the transaction through the public relay network. They're just going to send a website. If there is no website and you have hundreds of Bitcoin of demand for direct access to miners, you are going to find a miner that is going to take you hundreds of bitcoins and mine your transactions. And you're going to have Bitcoin that are going, people that are going to start building infrastructure, for you, for portions of these bitcoins, and you're going to have people that are going to, build the open source software that is going to, create a new peer-to-peer relay network to propagate your transaction, and miners are going to be, to be connecting to it, It's like, I think a good analogy here would be, let's say we have, the Bitcoin core GUI and we have a button to send to a specific address. And There is one address that we don't like, it's like some sort of terrorist organization or whatnot, and we, and then one group is saying, \"Oh, if we change the Bitcoin core GUI, To just refuse sending to this specific address, people are going to stop using Bitcoin to send to this specific address. I think it's completely delusional. It's, people are just going to fork the open source project, remove the check for this specific address, and let people send, Bitcoin to this address because Bitcoin allows it. If Bitcoin allows it, trying to change it in Bitcoin Core isn't going to change the Bitcoin, the behavior of Bitcoin Core users, of Bitcoin users, it's going to To change the adoption of Bitcoin Core, and when people are saying that, \"Oh, if only Bitcoin Core adopted this new policy, because it is the dominant implementation,\" they're flipping the, the argument on its head. Bitcoin Core is the dominant implementation because it matches the economic demand for the network. If it didn't, it wouldn't be." }, { "speaker": "antoine_poinsot", "time": "57:42", "start": 3461.64, "text": "Yeah, and, there's this concern, I guess, the filter camp, the filter roars or whatever you wanna call it, the filter guys, they have this view almost of, you know, it's about the nodes, and if the miners mine spam, that We the users, we the nodes should treat them as hostile. What's your perspective on that?" }, { "speaker": "stephan", "time": "58:03", "start": 3482.84, "text": "I think it's the, so just yesterday, we are recording this on Thursday, May fifteenth, and just yesterday I was discussing with, Jason from Ocean's, very respectfully, and I think we got to the bottom of the disagreement, which is Believing that we, the, we, it is like, we have a saying in French which means, we, \"on est un con,\" it means \"we is a praque.\" Because, and you can always say \"we,\" oh, we are doing this, oh, we are doing this. It's just obfuscates, who, what individual is going to do what exactly, and there isn't a \"we.\" If there was a \"we\" that could reach agreements on, exactly what is, what is valid and what the chain is going to be, we wouldn't need proof of work in the first place. so we can coordinate around a change in consensus rules, so that that- That's a, potentially, risky thing to do, to change the Bitcoin protocol, but that's a we, that all Bitcoin users change the consensus rules. But doing so to try to change the proof of work to ch- to fire the miners is not going to reset the incentives that are in place in the system. Like you, you, you wouldn't need to find a new system than Bitcoin, like changing the proof of work isn't it? So, sorry, maybe I jumped to the conclusion. we should treat, the, what you said is that, people say, \"Yeah, well, we should, if miners just act upon their economic incentive and mine these transactions, then we should treat them as, as hostile,\" and the obviously the conclusion of this is, well, If miners are hostile to the Bitcoin users, we should, punish them. We should fire the miners. We should change the proof-of-work, and that's why I was replying to, to this. It wouldn't, it would have no effect. What you want is a different system from Bitcoin." }, { "speaker": "antoine_poinsot", "time": "01:00:10", "start": 3610.06, "text": "Okay. Yeah. And to be clear, that this, change to the proof of work is viewed as like, that's a very, that's like the nuclear last, last resort option, but it sort of comes up in some of these conversations because it's kind of like, fire the miners, and that, that would be the, the theoretical way to, quote unquote, fire the miners. one other big point that's been coming up a lot is the UTXO set growth. So the UTXO set is the unspent outputs. There has been a large growth in this Like four gigs to maybe twelve gigs, it went from something like seventy million or eighty million outputs up to like maybe two hundred at the peak, and maybe now, nowadays we're at about a hundred and seventy million. To be fair, a lot of that was related to Spam, ordinals, inscriptions, etcetera. BRC twenty, I believe, actually is the specific protocol that makes up a lot of that spam because of kind of a sp-s-special dynamic about how they did like a deploy and a mint, kind of, it was like a, yeah, funny dynamic, but basically it created all these extra UTXOs. The argument from the filter camp is, well, Bitcoin Core isn't serious about UTXO bloat because, you know, they're making this argument that Satria and maybe other zk-rollup startups are gonna- I want to, you know, quote-unquote, spam our UTXO set, but they didn't do anything to stop this massive spam that already happened. You know, they aren't serious about stopping UTXO bloat. What's your thought or response on that?" }, { "speaker": "stephan", "time": "01:01:36", "start": 3696.39, "text": "Again, explaining the terms because, it's confusing forever unspendable UTXOs with, uneconomic UTXOs, uneconomic UTXOs such as created by, BRC20 is spendable still. so it's not a forever thing. it, it only takes financial incentives, in-incentivizing them to Spend, this output to relieve everyone or just doing, to avoid annoying everyone else? It happened in the past, it just, it's not a historical. Some people have been sweeping dust output in the past But it's also unrelated to the upfront output, but I can understand how, like, it's unrelated to the upfront output's change, but I can understand how they feel that, oh yeah, but Citrix never going to use the chain anyway, it's going to be a hundred, like, hundred bytes. Few, few times a year, let's say one kilobyte, and we have eight gigs of, of huge x set usage, which is not bloated because it's not forever expandable, it's like four, eight gigs of Usage, usage that we dislike, and, Bitcoin Core didn't do anything against them. They should filter inscriptions. Filtering inscriptions for, for BRC20 is also not going to be effective. BRC20 is a meta protocol, they're, They are not using inscription to store large amount of data. It's like, what, a hundred ba-byte or a hundred and fifty bytes that they use in the, in the witness data, and if we filtered this specific use case, either they would just, well, nowadays, given all the, all the private bridges to miner, they could just use a, use a website and broadcast through the website, but alternatively, what they could have done is just Change the structure of this transaction, they don't really need to store the data, they just need to interpret the Bitcoin data, differently, which is the Meta Protocol, and we can't filter Meta Protocol. So there was eight gigabytes of usage of the UTXO set that was related to Meta Protocol, that turned out to be using inscription, but It's filtering inscription isn't going to remove the demand for midap protocol unfortunately." }, { "speaker": "antoine_poinsot", "time": "01:04:06", "start": 3846.01, "text": "And so there was a lot of, I guess, pushback and arguments back and forth, especially two years ago when Luke Dashow opened that, I think it's the infamous data carrier size PR. Now the, the filter camp, the filter guys see that as, \"Look, that was a bug that enabled this taproot inscription envelope. Bitcoin Core should have closed that, should have closed that loophole to- At least try to mitigate the spam. What, what do you think about that? Is it just the same answer, the same thing?" }, { "speaker": "stephan", "time": "01:04:36", "start": 3876.42, "text": "I think, so again This is a Bitcoin Core thing and it's not a bit-- it's allowed by Bitcoin, so you can change in, change it in Bitcoin Core however you like, it's not going to affect how Bitcoin works. I think charitably, we could say that maybe if it wasn't standard at Bitcoin Core in the first place, it wouldn't have led to such hype to be created, and the hype itself created the demand, which made it Basically impossible for Bitcoin Core to remove, like, to, to remove Bitcoin darkness because we would be shooting ourselves and all our users in the foot. so Maybe had the stonewallness rules been tighter in the beginning, we wouldn't have seen such economic demand, but trying to remove it after the fact is going to lead to all the Consequences that we already discussed, it's not going to prevent Bitcoin user from using Bitcoin, they're just going to switch to s- another implementation or whatnot." }, { "speaker": "antoine_poinsot", "time": "01:05:41", "start": 3941.92, "text": "And it's worthwhile, I'd just add a quick point. It's, we have to be honest and pragmatic here. Even if hypothetically two years ago that PR was merged, people don't all update to the newest version of Bitcoin Core straight away. Many people are on older versions. So in practice, whatever, what would, would it have been twenty-seven two years ago or whatever, whatever version, there'd be a ton of users who are still on twenty-five, twenty-six, twenty-four, and Those nodes would still see these transactions as standard, right?" }, { "speaker": "stephan", "time": "01:06:11", "start": 3971.35, "text": "Yes, and even, even at the time that Luke opened the request, there was already significant, economic demand behind it. So it was already too late. But by the time it would have been released by Bitcoin Core, adopted by the network, it would have been way, way too late. So late actually that probably some would have refused to upgrade because they wanted this usage, and again, so you would have two different Current network, so because probably then they would get someone to implement some sort of preferential peering for their, network that doesn't have the filtering, and same argument all over again, people would just use an implementation that doesn't have this filtering." }, { "speaker": "antoine_poinsot", "time": "01:06:55", "start": 4015.52, "text": "Okay. Now there was another related issue, we've, we've touched on this before, but bare multisig. So as I understand, this is-- and you can correct me again if I'm getting any of this wrong, this is kind of like an old, old school multisig, right? Like, it's not P2SH multisig, it's not like any of the, you know, or pay to taproot, no, music, it's like this old school kind of multisig, and some of the filter guys wanted to, again, make that, non-standard Why did Bitcoin Core not try to stop the bare multisig spam?" }, { "speaker": "stephan", "time": "01:07:28", "start": 4048.87, "text": "Because Bitcoin Core can't prevent Bitcoin users from using Bitcoin, It's like the, the bare minimum usage is so unfortunate. It's people that are self-proclaimed attack of Bitcoin that want to be using, the Bitcoin network to its full potential to harm its users Fortunately, there is limits in Bitcoin, not in Bitcoin Core, there is limits in Bitcoin to, prevent the maximum usage of resources, an evil, evil, a user may have on everyone else. But these limits are pretty high, and as long as there is economic demand behind this type of transaction, trying to blind Bitcoin Core nodes from these transactions, it's just going to harm these nodes, harm miners running, running Bitcoin Core, harm users using Bitcoin Core, and not proving these transactions in the first place." }, { "speaker": "antoine_poinsot", "time": "01:08:29", "start": 4109.43, "text": "Yeah, so I guess similar kind of concerns to what we were talking about, it's understanding, okay, there's Bitcoin, the protocol, and there's Bitcoin- Core, which is one client, admittedly the dominant client, but, but one client of the broader protocol. one concern I've seen from some developers on this is this \"Quote unquote cat and mouse game.\" And if I had to try to summarize maybe one of the key contention points in this issue between the Nots filter guys and, let's say, most of the core developers in the Bitcoin technical community, is the Nots people sort of see it like, \"Yeah, we should play the cat and mouse game against the spammers,\" whereas I, as I understand, most of the core developers in Bitcoin technical people don't wanna play this game. What's your view on this so-called cat and mouse game or whack-a-mole game?" }, { "speaker": "stephan", "time": "01:09:13", "start": 4153.58, "text": "Yes. I, so my view is that it wouldn't play out like, okay, that's no scheme, but I can describe it and explain why Bitcoin Core, dislike it. So the argument goes like that. the cat, which is here, a Bitcoin Core, the Bitcoin Core client, and the mouse is, people using Bitcoin in ways that we don't like. So the, what the, what the cat, the cat is going to- To do is to try to, change the standardness rules to match, the template of script that these people are using, in ways, like, that you described at the beginning, the upfalls of F and data. To not relay them through the Bitcoin Core public relay network. And the thing is that by nature of what Bitcoin Core is, it's a critical piece of infrastructure, it's slow, it's slow to release, it's, slow to have code reviewed for a very good reason. and the, by its nature, the miners here, the Deejans wanting to put JPEGs on chain or just more swift to adapt, and they have an infinite amount of templates that they can use. Therefore, trying to play the cat and mouse game is going to lead to, Bitcoin Core having to publish much more frequent updates of the software, so either new binaries that people have to run or that the software itself would auto-update or auto-updating some sort of scripts, for relay policy. And basically Bitcoin Core's position is that's, that's a red line. It's like, \"Fuck no, we are never going to release software that auto-updates through a central point, basically phone back home, updates what your software runs.\" It's like completely anti-ethical to what Bitcoin is, and Bitcoin Core refuses to do this." }, { "speaker": "stephan", "time": "01:11:27", "start": 4287.64, "text": "And yeah, basically not to say that's fine. so I think it's a non-issue because in reality it wouldn't, it wouldn't play like that. And the reality is the mouse doesn't care about the cat. The mouse, the mouse is a honey badger. If, if, if the cat is trying to filter it, it's just going to use an alternative peer-to-peer relay network, it's just going to use direct bridges to miners, it's just going to use Bitcoin in other ways than the way provided by Bitcoin Core." }, { "speaker": "antoine_poinsot", "time": "01:11:57", "start": 4317.01, "text": "I see. Yeah. And so, I, I guess playing it out just, for argument's sake, if there were to be some kind of soft fork done to- Titan consensus to be in line with policy. Is that, is there, is that a hypothetical possibility or is there some reason that's not practical? Is it just a really big lift for very little practical gain? Is that, is such a thing feasible or even desirable?" }, { "speaker": "stephan", "time": "01:12:24", "start": 4344.71, "text": "So I think the, so my personal issue with, this usage of Bitcoin is that it, It might be useful for Meta Protocol, and Meta Protocol might skew the incentives of actors, specifically miners, in the Bitcoin system because now they're incentivized by, non-Bitcoin stuff, and that's pretty bad trying to limit the amount of stored data on chain by consensus. It's possible to reduce the amount of data that one can store on chain you can just first of all reduce the block size, then you can, reduce, some technical fields that are used in the transaction, in how it's serialized, some of them allow for more or less, Flexibility in how they are used. But there's two things. First of all, you're never going to reach your stated goal of preventing arbitrary on-chain storage. You're only going to limit it. Second of all To not even reach your stated goal, you're going to significantly alter Bitcoin's very like core and how it works, and I don't think that most Bitcoin users would be very happy with this." }, { "speaker": "antoine_poinsot", "time": "01:13:44", "start": 4424.16, "text": "Can you spell out what that would look like in practice? Does it mean transaction type whitelisting, reduced scripting capability? What would it mean?" }, { "speaker": "stephan", "time": "01:13:52", "start": 4432.42, "text": "I think the, the most obvious one is first of all, reduced, reduced scripting capabilities, Get rid of the Taproot and X, get rid of too large scripts, put potentially on the allowing some very small types of scripts, and then maybe if you want to go even further, trying to, prove that data that you're putting on chain is actual valid data, such as, for instance, if you're going to put a public key, provide a signature along with it to prove that it was indeed a public key and not some garbage. Page, that, that would sig-significantly reduce the ability to use the protocol, it would significantly reduce the ability to scale the protocol, flexible scripts are at the core of making Bitcoin more scalable and accessible to more people at the same time, and it would just be a significant change to Bitcoin And I think our presumption should always be, not changing Bitcoin. I think we should be able to change Bitcoin if we have a very good reason, but the very good reason should be presented, and that's not it." }, { "speaker": "antoine_poinsot", "time": "01:15:04", "start": 4504.54, "text": "And I guess even in the extreme case, they could still spam the UTXO set, right? Like they could just use valid signatures to spam the UTXO set in any case. So it's sort of like we would be like hamstringing ourselves significantly. so I think- Okay, so there is this kind of broader mining decentralization idea, and I, as I understand, there are various efforts to try to maintain the public relays and the public mempools system, So do you want to touch a little bit on that because that seems to be another concern that people have, that they're saying, \"Well, you guys seem to be concerned about driving, you know, the use of Mara, Slipstream, and other things, but what about just general-- Accelerators. Anyway, is that not also a concern?" }, { "speaker": "stephan", "time": "01:15:53", "start": 4553.85, "text": "All of them are concerns, and this is why it's been a priority for the Bitcoin Core project to Work on this for the past, I would say for the past five years, trying to find solutions to pinning issues which drove people toward accelerator or making RBF easier to use, which drove people toward accelerators as well," }, { "speaker": "stephan", "time": "01:16:21", "start": 4581.2, "text": "Or at the, the same type of issue that, the concerns raised by core developers around Changing Bitcoin cost and audeness rules to not, to, to be different from what the Bitcoin economic reality is, because It would create miner extracted value, and it would-- we basically what we want with Bitcoin is that to have miners that play on an even playing field, and they all compete only based on the hash rate, so only based on the expended energy. If they don't, then if your, if X percent, increase in your hash rate isn't giving you X percent more probability to find blocks, we have an issue, because if it comes, for instance, from direct submission to, from your API, then you're, you have An edge over the rest of the network. So it doesn't mean that entry on the ma-the-the mining market is entirely impossible, but it makes it significantly higher because miners have tight margins and, now a new entrant on the market not only has to compete on this tight margin, but also they don't have all the fees, and the existing miners on the market have the fees. So it's just a self-reinforcing Force that drives not only centralization of mining, but also, make, make, making the current state of miners sticky. It's, it's a very good property of Bitcoin to have that new miners enter the market and all miners leave, and we want to keep it as such." }, { "speaker": "antoine_poinsot", "time": "01:18:14", "start": 4694.17, "text": "So Summing things up, we've gone through a lot of different arguments back and forth, but I guess let's try to summarize the key arguments, 'cause we've kind of covered a lot of technical ground here. But there's the specific op-return issue, and then there's the broader spam filter wars kind of debate. So on this op-return issue, what do you think is the likely path forward? And I guess while we're here, one concern raised by people is, look, is it worth all this drama for a very minute, small fix?" }, { "speaker": "stephan", "time": "01:18:46", "start": 4726.65, "text": "Is it worth all the drama? so I, I said on Twitter yesterday that, in hindsight, I would have rather spend my time on something else because it has pretty limited impact, than, spending my time tweeting, but also- I'm not sure. I think it just unveiled something that was already there. There was, miscommunication between protocol developers and lack of communication between protocol developers and, Bitcoin en-enthusiast, I don't want to say Bitcoin users, because there's so many Bitcoin users and nowadays that the Bitcoin, the Bitcoin owners are a small, part of them, but they're a very important part of Bitcoin users and, we should have better communication between protocol developers and Bitcoin enthusiasts, and I think my proposal in the very casual manner that I made it without prepared communication engagement with the community, because I was just, \"Oh, it's a boring change and it's obvious.\" Well, it wasn't to everybody, and, Maybe it was good to do it now and have all this drama hash it out, rather than having it, you know, further down the road where, the perception are even further split. So I'm not sure." }, { "speaker": "antoine_poinsot", "time": "01:20:15", "start": 4815.05, "text": "So, i-in terms of where do you think we're going on OpReturn, like, is it likely that, let's say, InstaGibbs PR is going to be merged and that it, the default of OpReturn will be raised to a hundred kilobytes and that it will likely be- Deprecated or, or do you, do you have a view on that or do you know or no?" }, { "speaker": "stephan", "time": "01:20:36", "start": 4836.36, "text": "I don't know, nobody knows for sure because it depends on coordination among many people, so far Greg's poll request seems to have a lot of support from active contributors. My personal opinion is that we should hold off for a bit. work on the communication. so that's what I did in the past week. I, published this detailed, addressing all objections from the community and that will be in the" }, { "speaker": "antoine_poinsot", "time": "01:21:09", "start": 4869.3, "text": "show notes for listeners so you can check that out. It's over at Delving Bitcoin." }, { "speaker": "stephan", "time": "01:21:12", "start": 4872.77, "text": "yes. So we should work on this, hold off the change for now. There's no rush for merging it, like it makes no difference if we merge it today or in one month. So we can just hold off, better communicate our views, address concerns or objections even if they're not the most correct one, and, then move on with the change if we still think it's the best way forward. so that's my view. What is going to happen is Outside of my control, I can try to influence it. I'm going to raise my opinion that the project isn't just me, sir Wilson." }, { "speaker": "antoine_poinsot", "time": "01:21:56", "start": 4916.24, "text": "And on the sort of broader- Spam kind of issue. Where do you-- do you have any idea where that's gonna end out, or you don't really know? It kinda depends on what people are saying." }, { "speaker": "stephan", "time": "01:22:08", "start": 4928.99, "text": "So on the, on the issue of broader unwanted usage of the chain, my main comment, and I think it's, it's something that is common to many problematic in Bitcoin today, is just that unfortunately There's not a lot of demand for using Bitcoin at all, like not a lot of people want to use Bitcoin. If we had more usage of Bitcoin, it would make it significantly more expensive for people like Stamps, for instance, who try to spam the UTXO set to do it. and maybe it would bring a cost enough, like a high enough cost to disincentivize their, their meme behind it. for inscriptions, same, inscriptions are extremely large, so raising the, the fee rate at which they need to be to be included will have an effect, raising it from one to six sat per vbyte, for instance, as done by SleepStream, is not going to do anything. But if there is active demand for Bitcoin's block, block space and the next block fee rate is constantly a hundred sat per vbyte or two hundred sat, it's going to make them think once or twice before storing their JPEGs. So I think that's my broader take. I also think that it's a fade, it's a hype, we've seen it. it's going to, it's going to fade away. Well, I'm afraid that it's, it's taking back on now because of all the drama from the filter people around my proposal that is entirely unrelated to inscription, be-because they made it to be about inscriptions. Now the inscription people are All over it again, they, they, they, they, they're making JPEGs of my, of my tweets and whatever bullshit. So it just revi-revive them if we, if we just ignore them and stop trying to revive them and making it bigger than it is, it's just going to die off, it's just a fade." }, { "speaker": "antoine_poinsot", "time": "01:24:22", "start": 5062.57, "text": "Yeah. Okay. Well, yeah, thanks for joining. I know you've gotta run, but I guess if I had to summarize a few of the key points here, it's understanding the difference between the OP_RETURN specific proposal on this PR and the mailing list discussion versus the broader inscriptions and broader spam filter conversation, and also understanding the difference between Bitcoin, the protocol, and Bitcoin Core, the- Admittedly dominant reference client of Bitcoin, but it's not the only client. and I guess one other question around implementations, right? Because there's Bitcoin Core, there's Not, there's Libbitcoin, there's b t c d, Floresta, I think Bitcoin JS, maybe there's a few others out there that I, you know, I can't think of right now. What do you think happens there? Do you think there will be, you know, disgruntled users who will go to not, but most of the network will stay on core? Do you have a view on that?" }, { "speaker": "stephan", "time": "01:25:13", "start": 5113.86, "text": "I don't know I don't think that LibBitcoin has any published binaries, so I don't think it's an option for people. I'm not sure about Bitcoin GS, JS. I'm not sure about the state of the project there. I know that BTCd works. I know that it has a lot less eyes on it, and it's a complete reimplementation of the protocol. I would advise against using it. if people want to use something, at least use Nuts. Or Libra Relay, I would advise against using either of those, for different reason, but at least they're very, very likely to be consensus compatible with Bitcoin" }, { "speaker": "antoine_poinsot", "time": "01:25:56", "start": 5156.43, "text": "Alright, well, thanks for joining and thanks for, helping explain your view. I'm sure this is not the end of this conversation, I'm sure there's gonna be a lot of back and forth, but nevertheless, thank you anyway, and, well, I'll see you in, Vegas for Bitcoin 2025." }, { "speaker": "stephan", "time": "01:26:11", "start": 5171.44, "text": "Thanks for having me. Until next time." } ] }