{ "episodeId": "SLP729", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "martin_habovstiak": { "name": "Martin Habovstiak", "role": "guest", "tag": "MARTIN" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.1, "text": "If you use the right techniques, now again, not endorsing spamming the chain, but above a certain size, if you are using some alternative opcode, so let's say hypothetically even if bip one ten were to be activated on the heaviest chain and it was, you know, everyone was using Bitcoin with bip one ten, spammers who want to economize on their cost could use an alternate inscription method and they would be only paying zero point four percent more. Do you believe that if someone is spamming the chain today, that you are going to- to deter that person by making them pay zero point four percent more. Hi, everyone, and welcome back to Stephan Livera podcast. Joining me on the show today is Martin Habovstiak. Martin and I actually first met, I believe, around twenty nineteen, around the Lightning conference. And I know, Martin is a Bitcoin developer and, had some interesting views to share. He-- Martin is the creator of the Not Lies dot com website, and so I thought it'd be interesting to elaborate on s-some of these views and have them Explain so people can hear a different view. So, Martin, welcome to the show, and, give us some of your, I guess, your rationale. People wanna hear why. Why did you want to create this website? Thank you." }, { "speaker": "martin_habovstiak", "time": "01:13", "start": 72.52, "text": "hello. Well, thing was like, you know, probably everyone heard about the BIP 110 discussion and, People were making various reviewed claims around it, and one of those claims, was that the data, in the transaction Like if it's contigous, then there could be legal issues stemming from it. And I thought that this is really weird argument, because like if you are some sort of criminal that splits your, your files into different chunks, then of course you wouldn't be deemed not guilty just because you split the files, it doesn't make any sense. So why, why would splitting the data help? But from very early, I knew that there are actually ways, like even if you've kinda tried to force the issue of splitting by basically chunking the data and putting some garbage between the chunks, garbage from the point of view of, of the format you are trying to, to put into the chain, of course, there are techniques to either like make it corrupt the file only a little bit So it doesn't matter, or even like make it so that the data don't get corrupted basically at all. And I knew it from the beginning and, and At the beginning of the discussion, I demonstrated, an image that had like, red dot every five hundred and twenty, pixels or something like that. Basically, it was red because, of the encoding of the- Length, so that's, like two hundred fifty three, and there is, whatever other number for blue, blue and green. So if you know, like, RGB, so red, green, blue. R, red is one byte, and it matched the encoding perfectly. So if you encode it, an image like that, where you would put a red dot Every f- five hundred and twenty pixels. It'll damage the image a little bit, but if there is illegal content, it's still visible the content, you know? Like, you won't hide the entire image, there is just bunch of dots on top of it. So, and I don't think it would make an image illegal just by putting dots on it, of course. And a- actually, I discussed this with a lawyer, and he confirmed that, this is basically bullshit, that, Even if you damage the image, still, still illegal. So that was my argument, but I only posted the image alone and described like, \"Okay, I did this.\" then someone objected to it that, but, you know, you can do it because you are technical, but others can't. He didn't know that I used L O M that spit it out correctly on the first try. But, anyway, I thought that, okay, the argument is debunked, and I moved on, but Months later, I still saw people making this claim about Contiguous Data, and I was like, \"What? Like, this was discussed to, to death on the mailing list?\" It was debunked, and I didn't hear any convincing counterargument that people are still saying this, and I, I got more and more fed up with this. And I was like, okay, I, I can see the problem. Like people are basically assuming, but some people or most people aren't actually reading the mailing list. That's the first The first issue, but the second issue is that even if they are on, they might assume that, \"Yeah, this is all theoretical,\" or, you know, like, \"It's very vague,\" like- It's hard to convince someone of something that, like, you know, in theory works, but if someone doesn't understand the theory, then it's really difficult to convince. So despite my real, like, distaste for spam and I really didn't want to put data on the chain, but I thought that doing just one transaction, just once. Just to prove the point, might be a reasonable and make sure that it's not super trivial to repeat, like not publish the code of course. So I, I wrote code actually to assemble the transaction for me because it would be pretty tricky to do it by hand. And, then I, I posted in, into the mention, but just before, I thought it would be nice to put some clear text into the transaction describing the project, especially because I actually had to put some garbage data into it. That's, that's the, like, funny thing. so The thing I did is actually make the entire transaction into an image. And it is, quite different from just putting an image somewhere in, let's say, witness data. So, but if you do these tricks, like trying to make the entire transaction into an image, it imposes some structure on it and specifically minimum size of something like sixty-five something kilobytes. So that's, why the transaction has Around sixty, sixty and something, because like also there, there are, some other reasons when the transaction starts getting even bigger, but you know, like it has to have this size. It's not like it- Had the size because of the image, encoding or something. It had to have this" }, { "speaker": "stephan", "time": "07:07", "start": 426.51, "text": "size. So, so just walking back a little bit, the point of this is that you crafted a Let's say a manual transaction or using an LLM, you crafted a transaction that creates a sixty-six kilobyte image, which is a TIFF file, that is now in the chain. And now, of course, there are different counterarguments here. On one hand, I think some of them were saying, \"Well, hang on, this transaction wouldn't be Bit One Ten compliant.\" And then the other big one would be that, \"Look, you still had to go out of band to a miner to do this,\" although I presume maybe if you had used Libra Relay or Or, that, TX Pigeon, you might have been able to do it through that also. But can you address the, I guess first of all, as I understand, you made a, a version that went, you know, on the current version of Bitcoin Core or just in general, and then you made a BIP one ten compliant version. So can you just explain a bit about those different versions?" }, { "speaker": "martin_habovstiak", "time": "08:00", "start": 480.34, "text": "Yeah, so basically the current version was made with current rules just to prove a point that despite the claims that the transaction contains some, non-contiguous chunks, like you cannot make it contiguous, I made like even the entire transaction contiguous, like, so It's, it's not true that just by putting some, like splitting the data apart, you can force spammers to not put contiguous data because there are file formats that can skip over these, these chunks. So, and even like to the extreme where the transaction itself can be an image. But, of course, like if anyone of you, tried, like ever look, look up how various files format work, they usually start, or probably always, with some specific bytes. Like they start, like, let's say, the .tiff files starts with, four nine in hex, four nine, which, is the same as The capital M letter, then there is a forty-two zero zero and there is some offset into the transaction. And if you think about it, like the Bitcoin transaction also starts with a version number. But the current standardness rules dictate that the ver- version number is standard only for, zero, one, and I think also two, if I remember correctly, I'm not sure about it. So that doesn't match up. So therefore, if you want to make the entire transaction, then you have to use some non-standard, standard relay, and even Libra relay still enforces the versioning thing. So which I think is okay because the Even the idea of like using weird version number is like complete insanity to be honest, so it was like mostly to make it more fun, you know? Like I could still make it contiguous, just start at, at some offset, but I didn't have to. I thought it would be more fun to make the entire transaction, because then, like You know, like people wouldn't need to make more effort to, like, figure out, like, where did I put the data inside the transaction and so on. But if I make the entire transaction contiguous and people already know that the entire transaction, like, supposedly isn't Then, then like, you know, the, the, the discrepancy is very obvious" }, { "speaker": "stephan", "time": "10:38", "start": 637.9, "text": "then. I see, yeah. And so just trying to reflect what I have heard and seen from the Noz camp. Now, I won't be able to perfectly reflect this, but it seems, from what I've seen, people like Mechanic have really made this kind of contiguous argument. He sort of really makes it about this contiguous argument, and people have been, kind of trolling him as well about, I think he was at a conference, on a panel on stage, saying something like, \"Uh That there's gonna be a virus somehow that, that's gonna be the vector for delivering malware, that, you know, Ethel is gonna be downloading the chain and searching, you know, this particular byte, which seems a bit odd. But I will say also in the Knots camp, Luke, Luke Dasher, seems to have a slightly different argument. His argument seems to be more like, well, given, you know, The way data is encoded, you could say almost anything is this illegal data, but what makes it different, in his view, is this idea that it's the so-called standard way to interpret this thing, right? So he, for some reason, he seems to say that, you know, Core v30 seems to be especially endorsing this kind of non-financial data, that it's the standard way to interpret. What do you make of these different arguments around the, the exact, you know, reason? It's gonna be wrong or illegal or cre- raising the risk of the state coming after Bitcoin node operators." }, { "speaker": "martin_habovstiak", "time": "12:01", "start": 721.29, "text": "But maybe the first question people should ask themselves is, what makes things standard? Why, why is obriturn supposed to be standard and inscriptions aren't? Because like if people start using them massively, how is it different from standard? So- Yeah. I mean, you're, you're" }, { "speaker": "stephan", "time": "12:21", "start": 740.91, "text": "telling me, yeah, and the other thing is even up to 400 kilobytes, even pre-V30, up to 400 kilobytes is standard. So yeah, I mean, it doesn't seem consistent to me." }, { "speaker": "martin_habovstiak", "time": "12:30", "start": 750.23, "text": "Standard in the, like, the stan- like the standardness rules. I mean, like, what he probably meant is standard way of interpreting bytes. So, yeah, he, he made some point that, like, nobody would think about saving a transaction as a TIFF file and trying to open it with an image viewer. Like, that sounds completely crazy, which is true. So far, but here's the thing, like it could at some point become not crazy, like it could happen potentially that some shitcoiners are already trying to rewrite the code that I made, they want to try, write their own version and try to spin off some NFT tokens out of this. And in that case, like, you know, like if there is like, I don't know, like a few thousands or tens of thousands of transactions made this way, then who's to say that it isn't standard, like it's just arbitrary definitions? On the flip side, he says that Obriton is a standard way, but that standard doesn't even have like defined way of distinguishing what kind of file format is there. So you have to like try to do some guess- Seeing a beach, ironically this transaction itself being both a transaction and an image, like basically if you try to guess what kind of While it is just from the data itself, you get ambiguous result because you can't tell if this is a Bitcoin transaction or an image, if, if you have no context. You and even, to" }, { "speaker": "stephan", "time": "14:10", "start": 850.41, "text": "be fair, even in your website, notslize dot com, you mention here, you know, you can verify yourself, you know, here's the transaction ID, and then you have this command xxd minus r minus p into tiff, like dot tiff, right? Because there are different image files, there's dot tiff, there's jpeg, png, webp, whatever, I mean, there's many others. So I guess The point is, this XXD command is, I, I guess, reversing the hex encoding, right? So I guess that's a, a transformation step, isn't it?" }, { "speaker": "martin_habovstiak", "time": "14:41", "start": 880.76, "text": "Yeah, but, the hex encoding is really some like internal detail. It's just ba-basically the only reason there is even the hex encoding to begin with is that Bitcoin daemon uses something called JSON-RPC, which has to encode all data as text. Which is super inefficient, but whatever, it is what it is. And because, like, you cannot encode arbitrary data as text ISO like you could have some weird characters that would end up as, like, I don't know, emojis or whatever, and it would be, or it just break your terminal because there would be control characters or like a carriage return or something crazy. So because of this, it has to encode it to hex. But this encoding is kind of like temporary, it's just for the transfer of data. It's not like the hex encoding isn't stored on the, on disk because it would be twice as large, which would be insane, and it's not, hex encoded, at the P2P network level. So the P2P network uses still binary encoding, it's just because of this JSON RPC interface that it has to be temporarily encoded when you are pulling it out. But you can, check for instance, the mempool space API provides, an endpoint that will give you just the unencoded raw data, and then you don't have to do any encoding or decoding, rather. So like other APIs are possible, like you could conceivably retrieve it via peer-to-peer idea, connect to Bitcoin D, as if you were a peer-to-peer node And ask for the transaction that way, and then you would get it, not hex encoded. So, so the hex encoding doesn't have anything to do with it. Not to mention that even the scripts themselves are hex encoded. So if someone tried to use this as an argument, like, \"Oh, yeah, you have to hex-decode,\" guess what? You have to hex-decode operator As well or anything basically like scripts, you either have to hex decode if, if you want to like han-hand parse them or, you can use the decode script command, which is still another command that you have to run, and even that command will not hex decode individual fields, it will only tell you the instructions, and if there is like push instruction that contains data, it would again tell you hex encode the data. So like this Can't be an argument." }, { "speaker": "stephan", "time": "17:15", "start": 1035.48, "text": "Okay. Now what about this argument around, now the not or one ten proponent could come back to you at this point and say, \"Well, the point is to make it harder. That the fact that you had to go out of band, you couldn't just send this out on the standard Bitcoin relay network, that's the point.\" From their perspective, they'll say, \"That's the point. The fact that you had to go out of band to a directly to a mining pool to get them to put this in, that's actually part of the reasoning.\" What would" }, { "speaker": "martin_habovstiak", "time": "17:45", "start": 1064.82, "text": "Well, that's, that's the issue. I, I made the transaction more funny, but maybe I made it more confusing in the process because, like It's because of the version number. I could just get rid of this, and actually the first iteration of this idea, the first program that I coded, it, it actually took just one day to write it. Although to be completely fair, it, it took a bit of time to think of a method to write it, like should I write it as, like by modifying the image encoder or by, like Maybe to put it differently, should I try to assemble it as transaction first and image as a secondary, or the other way around? So I had to figure out, so that is to, took a bit, but once I realized that just taking an existing image encoder and modifying it to my needs It will be easier than it took one day of coding, basically. And this was just-- so this, this was an image that started at some offset, it wasn't at the beginning of the transaction. So I had to like chop off the first bytes and then save it as a TIFF file, and it worked. and this," }, { "speaker": "martin_habovstiak", "time": "19:08", "start": 1148.01, "text": "this actually the first iteration, like, didn't follow all the standardized rules because I didn't know all of them by heart, but it would be, you know, like matter of, while to just look up all the magic constants and adjust them appropriate to it would be really great. So I guess what you're saying," }, { "speaker": "stephan", "time": "19:27", "start": 1167.0, "text": "just so I'm understanding you, you're saying theoretically you could try to grind it to a point where you found a way to make Make it standard while still showing as a contiguous image, if you had to put in more effort to sort of grind it out." }, { "speaker": "stephan", "time": "19:47", "start": 1186.55, "text": "Right. So that you would have to be in that same context of cutting off the first number, whatever number of bytes, because you're using a standard version number, and then you could have stuffed it into a transaction that way. Yeah. And it would still be contiguous." }, { "speaker": "martin_habovstiak", "time": "19:59", "start": 1199.04, "text": "Yeah. Like this was the first version of my code. Maybe it's a shame that I didn't think of saving it, I started immediately to work, like, working with the next one, because I, I could have made another transaction just to prove this point, but whatever." }, { "speaker": "stephan", "time": "20:15", "start": 1215.17, "text": "Yeah, okay. So I guess the broad point you're trying to get at, as I read you, is you are kind of talk, trying to talk to this idea that Filtering, is it going to-- I guess that's the question. Can filtering protect node operators from illegal content? Does it, you know, somehow? Yeah, that's the question." }, { "speaker": "martin_habovstiak", "time": "20:37", "start": 1236.62, "text": "There is no way it can do, do that. Like, there will always be many ways of doing it. It's funny because the first programming project for Bitcoin that I ever made that had anything to do with Bitcoin was specifically to steganographically put messages into the Bitcoin blockchain as a series of valid, and they aren't even fake, like completely valid addresses. That you have private keys to, so you can spend from them. So it's absolutely indistinguishable, and no, like without the knowledge where to find it, nobody can find it. so this was like my first, it was like toy project that I didn't actually put anything into the chain, it was just the idea of like generating the sequence of the addresses that encode some secret message that if you put this sequence back into the, decoder and put the password there, it's It will spit out the, the message." }, { "speaker": "stephan", "time": "21:33", "start": 1293.49, "text": "I see, yeah. so I guess the point, like, also it should sort of answer the point that people will be thinking is, are you trying to spam the chain or make it easy for people to spam the chain? Or I think what I'm reading you as is you're trying to make the point that If you try to filter it this way, you're just gonna create worse problems somewhere else." }, { "speaker": "martin_habovstiak", "time": "21:55", "start": 1315.09, "text": "Yeah. Exactly. And that's, that's the issue. Every single technique, used to bypass, these kinds of, restrictions ends up getting worse for the network too. So like if someone is rich and bored and wants to buy a monkey picture, they don't care if it costs twenty bucks or thirty or fifty or five, whatever, they'll buy it. If someone is rich, and if someone isn't rich, they will just buy, a cloud storage. Recently, I have calculated that the, the transaction I put into the Bitcoin chain costed me nine million times more than monthly subtri-subscription to, to a cloud service I, I pay for. Like a" }, { "speaker": "stephan", "time": "22:47", "start": 1366.68, "text": "Dropbox or a Google Drive kind of thing." }, { "speaker": "martin_habovstiak", "time": "22:49", "start": 1368.96, "text": "something different, but anyway." }, { "speaker": "stephan", "time": "22:52", "start": 1372.18, "text": "But similar to that, yeah." }, { "speaker": "martin_habovstiak", "time": "22:54", "start": 1373.7, "text": "Three, three, three something euros for a hundred gigabytes per month. And, yeah." }, { "speaker": "stephan", "time": "23:00", "start": 1379.95, "text": "Oh, sorry, you mean more like a VPS service, not like a Dropbox service. Is that what you mean?" }, { "speaker": "martin_habovstiak", "time": "23:05", "start": 1384.63, "text": "No, it's, it's just, and, and, it's something like Google Drive, but, just encrypted." }, { "speaker": "stephan", "time": "23:11", "start": 1390.59, "text": "Okay, gotcha. Yeah. So like Proton Drive, as an example. That's the" }, { "speaker": "martin_habovstiak", "time": "23:14", "start": 1393.91, "text": "one. Yeah. I, I don't-- That's the thing. Maybe Google Drive has even cheaper prices." }, { "speaker": "martin_habovstiak", "time": "23:22", "start": 1401.86, "text": "Fair price, I just was interested by comparing it to price of something I actually pay for and know the price. So it's like the factor was around nine, nine million times or more than monthly subscription. So it would be for, I don't know, how many thousands of years, sorry. So the, it would be like if, if my goal was just to store data And nothing to do with Bitcoin. I wouldn't use Bitcoin because it's like nine million times, oh, maybe not nine million, because, it's monthly subscription, but, you know, even if you like say like, \"Okay, I will live for a hundred years,\" then you can say like, \"Okay, twelve hundred months,\" it's still like thousands of times more. E-even if you make this assumption that I will live, live for a hundred years and I want to store it for a hundred years, it's still much more much more expensive, so it doesn't make sense. So therefore, whoever is putting stuff in Bitcoin is putting it there because they want to put stuff into Bitcoin That's because, like, they want to store data somewhere. And, like, so, so therefore making it harder only overloads the network itself because, because of these restrictions. For instance, if you compare the transactions, the first one and the second one, the second one is much larger, well, much, I think it's like ten kilobytes, which is pretty Pretty significant, I think, and it's, it ends up being like ten kilobytes larger just because I had to bypass the restrictions, which forced me to put more inputs there, which, finally, and have this method of making the entire transaction into a valid image. What it makes is the more inputs you have, the bigger it has to be, but not just because of the inputs, but, but there is some data that shifts more further and further away, and you have to add more like garbage in between, so basically We," }, { "speaker": "martin_habovstiak", "time": "25:20", "start": 1519.87, "text": "you can put more garbage or more, more text there or whatever you like. So that's the, that's the irony. So the filters made it much, bigger. And in some cases, this can be even like, extremely bad for the," }, { "speaker": "stephan", "time": "25:36", "start": 1535.81, "text": "yeah. Okay. So let's get to this. So there are different ways things can get-- and now again, I wanna be clear, I haven't never spammed the chain, I don't earn money out of this, I'm not invested in any company that, you know, is spamming or shitcoining. But just so people understand, there are different places that people can spam into the chain, right? There's fake pub keys, there's witness And then there's OpReturn. So can you just talk us through some of those different methods, just so people understand kind of the, the trade-offs and the costs of doing this so that people can at least be aware of this issue?" }, { "speaker": "martin_habovstiak", "time": "26:11", "start": 1570.66, "text": "Yeah, so the first one, the most popular maybe or most well known is the obiturn, and that, that one is actually interesting because it's not really financially viable to put large chunks of data into obiturn, because at some size it starts to make more sense to put it into the witness data, and the reason why it's like there is some cutoff. Is, if you want to put stuff into witness data, you must have, you must make another transaction. So you have more overhead from creating a second transaction. And so if, if your data is large enough That, the saving, covers the cost of making another transaction, then it works out. And someone even calculated the exact value, but I, I forgot what it was. I think it was like" }, { "speaker": "stephan", "time": "27:01", "start": 1620.98, "text": "160 bytes or some, I don't know, 140 bytes or something like this. It's like in that range. So I guess just, so I'll, let me just try and explain it in simple terms for the maybe less technical listeners. So, you know, in Bitcoin, you have inputs and outputs, and op return is an output, right? But the, the interesting thing about witness spamming is it's actually on the input side of the transaction. And another kind of piece of context that people should know is that in inscriptions, again, not endorsing this, but there's this thing called the Taproot inscription envelope, and it's like OP_FALSE, OP_IF, and then they stuff the data there, and then it's like, I think it's an AND IF or something like that. And as you mentioned, it's a two transaction scheme. It's called, I think it's called a commit-reveal scheme. So the idea is that Spammer is kind of first doing the commit stage, and then only on the reveal, he's showing actually the thing that is valid to spend this is this massive thing, and that's where they're stuffing in the data. So it's a two-stage process, but The thing is, that is one of the cheapest ways to spam the chain, right? So again, not endorsing, but just like just objectively speaking, above a certain size, which is probably like that hundred and forty bytes or whatever it is, basically anyone who wants to spam images into the chain, it's generally gonna be cheaper for them to use witness spamming. And so I think it's just important to people understand because, because of the SegWit discount, you get, it's a twenty-five percent the cost of putting something in operation, which you pay full, full fare." }, { "speaker": "martin_habovstiak", "time": "28:33", "start": 1712.63, "text": "Yep. So, but there is still, a weird edge case is like, what if you want to put like the data that is, let's say, bigger than eighty bytes and less than whatever the threshold is, let's say, one hundred and sixty, like what Citra is doing. If you need to do that, then, the most, the cheapest way of doing it. Is to put, put another output" }, { "speaker": "stephan", "time": "29:08", "start": 1747.69, "text": "fake" }, { "speaker": "martin_habovstiak", "time": "29:09", "start": 1749.13, "text": "public key and that is extremely harmful to the network because of returns. They, they can be proven to be unspendable simply by looking at the first transaction. If the first transaction is a return, you can be, certain, one hundred percent, that this never will be spent, and you don't even need to bother putting it into the UTXO set because this UTXO is as if it didn't exist. So in Bitcoin, the, the way it internally works is that spent bit, spent UTXO and not existing UTXO are the same thing. Basically, one spent- It is spent, it is d-d-d-deleted from the database as if it never existed. So basically, this same thing happens with oblivion. It immedi-- like, it skips even the storing into-- there isn't even, like, people talk about the oblivion being pruned, but it's not even stored in the first place in the UTXO set. It is still stored on disk if you don't have pruning enabled or at least for a while. If you have pruning enabled, it will get deleted after a few blocks. So, so that's the important part. If the data is like in between Then this is super harmful for network because the public key gets stored into the, to the Exocet, and this can never be pruned from the node ever, because like if someone did prune it that could become a huge, chain split or network split, so people would see different versions of transactions and like, this will be complete, completely catastrophic and kill Bitcoin basically, probably. So there is no way like this will ever get deleted. therefore, it is better if people, if they are going to spam Bitcoin. And here's the thing, again, what I said before, like, people who are putting the- Data in Bitcoin are doing it on purpose to have it on Bitcoin specifically, not because they like want to store data somewhere wherever and Bitcoin is the cheapest option, it's the, the operation on Bitcoin and they will pay whatever they want, whatever they have to get in. So they will do it. So if they are in the situation where they will do it regardless, then better let them do it in the original output and not in the fake public keys." }, { "speaker": "stephan", "time": "31:37", "start": 1897.41, "text": "I see. Yeah, and so just talking through the, yeah, as, as you mentioned, and there are even more harmful ways of spamming the chain. So stamps is kind of a well-known one of that, and there are some of the, some of the guys, some, there are guys out there who are working on some of these things already. Like, so it's not like they're just theoretical, like they do exist. They can, you know, and I think the citrair thing is like a very specific example because it's like- It's only this kind of edge case sort of, whereas most of the spam, actually, I think a lot of the spam is text, and it's already under eighty-three bytes anyway. And then the, the images, so they're less by the count, but more by the bytes. Those, a lot of those, there have been literally millions of images spammed into the chain using the inscription envelope. And so that's sort of the, the challenge of explaining some of these things, because people will then look They might look at, oh, here's the op-return, you know, chart showing you how many, how much, you know, large, how many large op-returns there have been, but actually, the spammers who wanna put images in, they're not spamming on op-return, they're spamming on the witness. It's like, it's just a diff- it's like a very niche- Kind of technical conversation that you, you have to be sort of really into the, the guts and the weeds of technical minutia of Bitcoin to sort of even grasp on these things. So I guess that brings us to your calculator. Let's talk about that because you have a calculator at the website notslights dot com slash calculator, calculator dot html. Links will be in the show notes for listeners. But, Martin, tell us about this calculator. What are you doing? What are you showing here? What are some of the, the key takeaways for people?" }, { "speaker": "martin_habovstiak", "time": "33:18", "start": 1998.16, "text": "Yeah, so after I posted all this stuff, people were, oh, like I noticed that many people were saying the basically the same thing, like, \"Yes, but it's, it, it's overhead for the spammer as well, so it will get more expensive, and therefore spammers will be detraughted from it.\" And I would say, like, \"Okay, that would be probably a fair argument if it costed the spammer like a hundred times more or something,\" but, you know, like, it's always good to get some real numbers, like how much it And I even decided like to try and measure mu-different techniques because I wasn't, wasn't even sure like which technique is even the best To begin with, and there was this, thing with, the, the, sp-spelling, rather, the meaning of, BIP110, that what they wrote it in a way that made, made it look like they will also restrict the script sizes, and that was the exact thing that made me unsure which technique. Like, if, if, if I knew from the beginning Beginning that this restriction is, not applied to the scripts, then I would have known from the immediately that, putting it into the Taproot, or Witness, version zero is, basically, the most efficient, rather to the script, not, not, to Witness. But, I still wanted to, like, show various techniques, why not? It wasn't too hard to code. So basically what this calculator does, it, it basically simulates, kind of like what- The attacker do. So in the code, what it does is it, it has these parameters that are on the, in the UI, like, what is the restriction for, like, chunk limit, for the push limit, what is the data size, a-and so on. And it takes these restrictions and based on them and the technique, it, virtually chops up the data. So there is no data at all, it, it just works with numbers. So it tries to, like, okay, so, we use technique that, puts stuff into witness, and we have, we have, two hundred and fifty-six byte limit. Okay, so whatever the number is divided by two hundred and fifty-six, and now we have, like, how many chunks we have. And then there is some processing to figure out Well, it, it even fits into the script itself because even scripts, can have some size limits and whatnot, and then it tries to process like, okay, do I need more inputs or more outputs in case of over- or whatever? And it tries to like do all this computation to make like, to compute like how much overhead there will be, and then it end-up, ends up all the sizes and whatnot. and, outputs the numbers. Then for convenience, there are like percentages shown. And this is where it gets to the point, like you can see that if you try different techniques, usually one of the techniques is super cheap, and especially for a lot of data, like if you put there like, ten thousand, you know, bytes of data, and you select, like, pushes in, in TapScript, you will see That's, just, di-differentiating slightly, will at the cost of like, point four percent. Like, if you think that, yeah." }, { "speaker": "stephan", "time": "36:56", "start": 2215.72, "text": "So look, we need to highlight that just for listeners. So if you use the right techniques, now again, not endorsing spamming the chain, but above a certain size, if you are using some alternative opcode, so let's say hypothetically, even if BIP one ten were to be activated on the heaviest chain, and it was, you know, everyone was using Bitcoin with BIP one ten Spammers who want to economise on their cost could use an alternate inscription method, and they would be only paying zero point four percent more. It's actually a bit less than that, but let's say zero point four percent, right? Listeners, think about that. Do you believe that if someone is spamming the chain today, that you are going to deter that person? By making them pay zero point four percent more." }, { "speaker": "martin_habovstiak", "time": "37:39", "start": 2259.16, "text": "Exactly." }, { "speaker": "stephan", "time": "37:40", "start": 2260.3, "text": "So I think that's the important point that people should learn and understand here, which is that, you know, it's a lot-- and I, you know, shout out to Moonsetala for this as well, because, he commented under my earlier episode with, Charlie talking about this and explaining, \"Look, basically the gist of it is, as long as we still have Bitcoin script and as long as we have the SegWit discount...\" This is more or less gonna be true, right? Like as long as we have these two things, more or less, that's kind of the situation we're in, right? So I understand, like, I certainly appreciate, you know, I understand the desire to not have spam in Bitcoin, but there's just some certain technical fundamental realities on the ground that unless we're willing to go back and unwind the SegWit discount, which, again, that would have its own problems, there are reasons we did the SegWit discount, and unless we're gonna unwind Bitcoin script There's not really a lot that you can do here. Like, I think that's just the fundamental point. So how do you see that? Do you agree or disagree, or how would you elaborate on that?" }, { "speaker": "martin_habovstiak", "time": "38:40", "start": 2320.38, "text": "That is a really funny thing, like, let's say, like, we were like, \"Okay, let's just go to get rid of the Bitcoin script so that, there is no, no more of this stuff.\" Entertain this idea. What happens if we remove Bitcoin Script?" }, { "speaker": "stephan", "time": "38:59", "start": 2338.63, "text": "I mean, multisig and Lightning and all these things are out the window at that point, right? And what" }, { "speaker": "martin_habovstiak", "time": "39:03", "start": 2343.0, "text": "happens if Lightning network breaks? All the copy transactions suddenly go to the chain. Suddenly you have like maybe thousand times, ten thousand times more spam in the chain from the transactions that would have otherwise been on Lightning. So like, you know, like the biggest optimization and the biggest anti- that's a funny thing, like, Lightning Network is the biggest anti-spam technology in Bitcoin. Because like, if you are putting stuff on, like if you are transacting over Lightning Network, it's so much cheaper that then it makes economic sense to pay higher fees on the channel opening and closing transactions, and those can then drive out the spam. But if you di- like if you destroy Lightning Network, then, like this, this stops working, and you, you get even worse spam. H- and here's another really funny, thing that if you look only at the cost of, like, running a full node A block full of Bitcoin tr-uh, transactions that actually transfer some value is more costly to validate than a block full of spam." }, { "speaker": "stephan", "time": "40:13", "start": 2413.41, "text": "I guess there's a bit of a nuance with that, isn't there? Because it, it is true, I mean, it- Because if we're talking about inscription, that's, I think that's true, but if it is a sp- let's say if we're talking about spam as BLC, then that creates a lot of small UTXOs, right? Because if you remember back in late '23, early '24, there were these guys doing this competitive mint, and that's why people got annoyed, right? Chris Guider and a bunch of these other people were really annoyed about the high fee. Now, to be fair, I was also annoyed about the high fees at that time too These guys are just like spending crazy because they're gambling. Now, okay, I understand there are people who don't want gambling in Bitcoin, but the pro-- but again, it comes back to how you're gonna stop it, right? And so with BRC20, there's probably a slight nuance there because if you're doing BRC20s, these people are creating a ton, a ton of UTXOs, and that was, that was when the UTXO set kind of blew out from maybe seventy million all the way up to maybe one, sixty million, something like that," }, { "speaker": "martin_habovstiak", "time": "41:20", "start": 2479.51, "text": "yeah, by spam I meant ma-mainly like, because like even those transactions are kind of like, if you, if you are measuring it in terms of bytes stored, they are inefficient, they are like paying four times more fees than they would have to, but if people are just using, witness and, either the Tapscript ML or basically any technique that I put there, then, it's, less costly for the network to validate, and the ver-it's a very simple reason That signature verification is much, much more costly than hashing or any other like cryptographic operation. It's very" }, { "speaker": "stephan", "time": "41:57", "start": 2516.55, "text": "computationally costly for the node, yeah." }, { "speaker": "martin_habovstiak", "time": "41:59", "start": 2519.29, "text": "It's orders of magnitude, more costly So like, the fa-funny thing is like, I think that the Tapscript envelope as used today might be one of the least costly ways, for the Foono to validate, because it can just skip over the instructions that are in the unexecuted branch, so it just skips over them, and it only needs to hash the entire script just once, so, there is just one, one hash. You are doing Other techniques, there, it might happen that, the node has to, like, maybe execute some instruction, maybe allocate some memory, it might need to, hash stuff because, like, one of the techni- actually is the technique that I use for my image is just putting the chunks into the witness and then, putting hash, hash verification into witness script. And it has much more overhead than the Taproot envelope. But, I wanted to prove a point that, you don't need Taproot and you don't need Op, and you don't need- Yeah. Yeah." }, { "speaker": "stephan", "time": "43:06", "start": 2585.92, "text": "And while we're here, I'll just quickly mention, 'cause this is also relevant for listeners, I think, Shesek ran the number. He actually ran the numbers. I've posted this, I've been sharing it as well for people. He ran the numbers on what difference did Taproot make? And that number is like twelve percent. Okay? So basically- Even without Taproot, you're paying twelve percent more, and even without the current inscription envelope, people are just gonna be paying point four percent more. So right, so even if we, like, let's say we took away Taproot, we took away OP, you're, you're forcing the spammers to pay twelve point four percent more. Is that really gonna move the needle? Are they really gonna stop? can you think of anyone, any spammer who's like, you know, when the price of Bitcoin and the fee market, the block space market can vary by more than that? Do you really, you know, listeners really think this through? Do you think twelve point four percent is enough to stop them? I don't think so, right? Now, yes, there's other kind of arguments people get into of like, \"Well, okay, you're forcing the spammers to change their inscription envelope.\" But even there, like, if you look at what Casey Rodama and some of those other guys have said, he's the creator of Audionals and the AUD, which isn't-- think of it as an indexer, and it's also the referen- the reference implementation for And then most of the rest of the spammer ecosystem, like the big exchanges and whatever else, the wallets who support all this ordinal spam stuff, they'd be updated within a few weeks. So really, the way I'm understanding this is it's basically more like a temporary inconvenience to spammers and not-- and, and like a big, big cost for us to do a consensus change. So I think it's important that people just sort of understand these different costs in terms of the, the asymmetry. There's a big asymmetry here. So that's, that's what I would say Do you wanna, do you agree or disagree or how do you see that?" }, { "speaker": "martin_habovstiak", "time": "44:53", "start": 2692.57, "text": "Yeah, I certainly, if there was like literally zero cost to doing this, then I would be like, okay, let's, let's make them pay twelve percent more, why not? Hypothetically, well, I wouldn't want to di-destroy Taproot, that's a other, other thing, like there is privacy gains and so on, but let's say we, we could maybe somehow magically create twelve percent overhead for the spammers without causing like any issues whatsoever, no risk, no chain speed Problems, if anything, and it's like something like super simple in the code that there requires almost no engineering or testing, I would be like, \"Okay, whatever, let's do it.\" But it isn't the case. Like there are real costs, there is risk of chain splits, there is risk of freezing some funds. There is more code complexity. And also like, even if it's temporary, the code that enforces the temporary, rules still has to be in the codebase until the end of time. You can't remove it afterwards because then someone could, after several, like, after many years, if mining gets progressively better, someone could, use it to for-fork the chain and create a like fake, fake chain, that, like violates those previous, previously activated rules. So like, this isn't like simple stuff. And like, we would also piss off legitimate users, we would, like, PiP one hundred and ten would also, like, force, protocols like Citra to use fake pub keys and whatnot. Basically, it, it- Yeah. I mean, to be clear," }, { "speaker": "stephan", "time": "46:36", "start": 2795.62, "text": "Citra already are going to use fake pub keys, but it's a- It's a bit of a nuanced thing. It's only for their challenged transaction that is unlikely to even hit the chain. Yeah. So the thing, 'cause that's also another big kind of point people saying, \"Oh, they changed for Satria,\" which is not true. Satria was an example, but it wasn't changed for Satria. And the way we know that is, Satria didn't change to do large op returns. They didn't bother changing their protocol 'cause they never asked for it, and they didn't bother changing for this. It was like just an" }, { "speaker": "martin_habovstiak", "time": "47:09", "start": 2829.28, "text": "From developers, please, it would you mind to change your code just to be nice to Bitcoin? Suddenly there is like a huge, huge, like this, revolution against it And then I, okay, so, so actually the BIP one, one one zero crowd probably already caused more spam on Bitcoin, well, aside from my transactions over the years, the thing I- I could totally imagine, I, I'm not sure what Citra is doing or not, but I could totally imagine like their CEO or Citra or whoever says like, \"Okay, there is this risk that if we change it to put it in the OpReturn\" We might need to change it back because the, those guys will just fork Bitcoin and for, for Softfork and, and it will stop working entirely, even Let's just not do that in the first place. And we are screwed. Well, screwed. Thankfully it's probably not that big of a deal if it's not supposed to get in the chain in the first place, but- it's worse, basically. So things will be worse just because people were, screaming about it. That's the issue." }, { "speaker": "stephan", "time": "48:26", "start": 2905.93, "text": "So I guess sort of wrapping things up then, do you have an alternate vision for realistic Bitcoin adoption? What would you say instead of bit one ten? What should people do?" }, { "speaker": "martin_habovstiak", "time": "48:37", "start": 2916.72, "text": "Well, if we want to decrease spam, then the only option is to decrease the block size. I wouldn't decrease the witness discount that some people proposed because the witness discount is still important to avoid people from making, too many outputs. It might make sense to reduce the segwit discount if, combined with something like cross-input signature aggregation or, or something else. there, there, there are some reasons to do that in that case, but only in that specific case, but other than that, I, I think just decreasing block size is much simpler and it doesn't involve, the, the thing is like, any of these changes probably makes, coding other, other libraries and software that works with Bitcoin in any way like much more difficult. Like, since I'm co-creator of RaspBitcoin, I can tell for RaspBitcoin Bitcoin, like I, I know the APIs, I know how it works, I can pretty well imagine what kind of changes would be needed to make this change. And here's the funny, funny thing, this is specific to Rust ecosystem, but maybe some other languages work like this, as well, is that like the Rust Bitcoin library is like the, like top most library that all other libraries use. the thing is like the, the if we break the API of this library, then every other library has to update, and they have to do it pretty much synchro-nously, like if some libraries are interacting between each other as well, then they, they have to like update, well, not strictly in a lockstep, but like kind of together, in that means to be kind of coordinated. And it is, this is a huge pain, and if there is any for- Work that creates this kind of problems, then it's, it's huge cause on, on the entire ecosystem, not just like all these like risks and, and, cost to the network and so on, but also to the engineers, to the developers, who instead of making new features on Bitcoin or maybe increasing the security or something, they have to now adjust the code because of some nonsensical, consensus change. So, even then I, I would be very careful about doing this adjustment, but, like just decreasing the block weight, the maximum block weight is the most, like, sen- the simplest, way of doing it, but it's not like super simple at all, like it still requires a bunch of work." }, { "speaker": "stephan", "time": "51:17", "start": 3076.78, "text": "Yeah, and I mean, look, for what it's worth, in 2017, if I could have gotten, hypothetically, if we, if I, if we could have gotten SegWit without a block size increase, I would have, I would have been in favor of that. I think, I think, chatting with Adam Back, I think he mentioned this idea of like, \"Oh, well, what if we just had like a 500 kilobyte base block size with, like, you know, a discount?\" But, I mean, at this point, it seems unlikely, right? Like, just being honest, it seems very unlikely that it's gonna happen. but, you know, if we could get consensus for it, I mean, I, I think, you know, maybe? But I just, yeah, it just seems unlikely. And even the Sizer idea, the compa-the cross input aggregate signatures, it doesn't-- I mean, from what I understand, it doesn't seem that anyone's actually working on that right now, so it's kind of, again, it's a bit of, like, or at least not right now. Well," }, { "speaker": "martin_habovstiak", "time": "52:00", "start": 3119.96, "text": "actually, there, there are people working on it to, to my knowledge. Oh, I didn't know that. Yeah, okay. I know that one person got a grant for it, but I don't know if" }, { "speaker": "stephan", "time": "52:12", "start": 3131.84, "text": "Yeah, 'cause from what I recall, I think Jonas Nick was doing some work on that and maybe Fabian as well." }, { "speaker": "martin_habovstiak", "time": "52:19", "start": 3138.55, "text": "Yeah." }, { "speaker": "stephan", "time": "52:20", "start": 3139.73, "text": "Yeah, but, it didn't seem that like there was like a big, that there's like a lot of people who are out trying to push it. I mean, hey, maybe, I'm not opposed to it also. So, anyway, I guess the point is There's not a lot of good ways to stop the spam that don't also hurt us in some other way monetarily, right? Whether it's harming our scripting, whether it's harming Lightning, whether it's harming, let's say, miniscript, Taproot miniscript, which is also a future pathway for maybe improving self custody for a lot of people, whether that's redundancy, inheritance, you know, just security in general. Like I think there's a lot of these, you know, the harder you try to clamp down on s-some of these possible ways of spamming the chain," }, { "speaker": "stephan", "time": "53:03", "start": 3182.93, "text": "Very use, and that's why for me, even though, you know, I've been Bitcoin only since twenty thirteen, I don't, you know, endorse spamming the chain at all. But I just, I think there are genuine risks and problems with Bip one ten. I think it is extremely unlikely to even happen, but it's at least, I think it's at least educational if people can understand, okay, it's, it's not as much about just sort of signaling how much you hate spam, it's about understanding the certain technical realities of how Bitcoin works and that we aren't meaningfully Increasing the cost for spammers with bit one ten. And so I think it's, it's just not, and it's, it's kind of also a, a bad premise, right? Like it's, it's like a false, fake emergency because it's inconsistent of, let's say Luke or other people in that camp to say that somehow, you know, what core has in the default mempool is somehow different to what both core and not accept as consensus valid already and have done so for a long time, like one megabyte op return has been cons- Consensus valid for a long time. Why are we now, and to kind of make a huge deal about this one hundred kilobyte op return when there are literally millions of image inscriptions and theoretically up to four hundred kilobytes, people could pre-V30 could even be relayed around the network as standard on most of the network. So it just, it-- to me, it just feels like a false narrative. So at least that's how I see it. Do you wanna take a few minutes, give us your closing thoughts, any key takeaways for listeners?" }, { "speaker": "martin_habovstiak", "time": "54:29", "start": 3269.07, "text": "Yeah, maybe there That isn't brought up very often, but I, I believe it's extremely important. What people need to understand is the reason Bitcoin's mining Is to make it resistant to the government influence. Because like if you, let's say, for instance, that you either trust a government or you at least trust a group of governments, like let's say you pick, United States, United Kingdom, France, whatever, Russia Who cares? And you issue a private key for each of these, these governments, and they do basically multi-stick of, of blocks. And basically they do the same thing that, Cygnet is using or Liquid, where they, they just sign blocks, there is no mining, and you just trust them. If you trust the government, this would be much more efficient because there would be no mining. The blocks could be much more frequent because, there are no syn-synchronization issues between fewer parties. The filters could be just implemented by the government. Why not? And if you trust the government, then this would be much more efficient system, much better than Bitcoin. So why does Bitcoin have mining if, if, why Satoshi didn't issue the keys? Because Satoshi doesn't want to involve governments in the first place obviously. And like, okay, but then people are like Saying stuff about legal and illegal content in the blockchain and so on. But here's the deal, like if, if you are willing to change your node because you fear that the government will persecute you for storing illegal content You will be willing to change your note because you are fearing government prosecuting you for enforcing twenty-one million bitcoins cap? If government says, \"Okay, whoever runs Bitcoin node which enforces the twenty-one million cap will be jailed,\" so either run, run our hard fork that removes the cap or go to the jail, what will you do? Based on, on current situation, the BIP one, one, one, zero, supporters will probably change their note. So there is no cap actually. So I think what's important is for people to realize that Bitcoin is absolutely nonsensical without this ability and without the willingness of the node runners To say no to the government and random notes cover to it so they cannot be prosecuted, because the government cannot like go door to door and seize every single computer and analyze the software on the computer to figure out if it is-- if it happens to store some version of, of Bitcoin Core that is enforcing the limit that, like, this is non-workable for the government. So basically, if you run your node in secret, which is how it's supposed to be, then the government can't know that you are running it, and can't even if they find out that you are running, they can't prove that you are running, like specific versions or something. And if this is the case, then you don't have to fear the government, jailing you for posting illegal content, in the Bitcoin blockchain because they don't know you actually do. So that's So kind of the point, and I think that it's what people don't realize is like, like even if all these arguments were kind of like valid in, in, in the sense that it would be real, like legal thing Then it would still be wrong to change Bitcoin for it, because like if, if people change Bitcoin because they fear government, then Bitcoin already failed." }, { "speaker": "stephan", "time": "58:16", "start": 3495.87, "text": "Alright, well I guess we'll leave it there. So listeners check out, Martin's website, it's over at notslies dot com, and you can follow him online k i x u n i l, and, Martin, thanks for joining me today." }, { "speaker": "martin_habovstiak", "time": "58:28", "start": 3507.68, "text": "Thank you too. Bye." } ] }