Episode 81: Bitcoin Core 25.0

Aaron van Wirdum Live from Utrecht, this is Bitcoin Explained. It's Sjors.

Sjors Provoost We're back.

Aaron van Wirdum We're back in beautiful, sunny Utrecht after I spent some time in Miami and Prague and you spent some time in Prague and more Prague. Is that right?

Sjors Provoost Mostly Prague.

Aaron van Wirdum You were in Prague for a while. That's where we recorded the previous episode. Of course, about Stratum V2. And now we're back in Utrecht. And we're going to talk about Bitcoin Core 25, which is the latest Bitcoin Core release. But it came out a couple of weeks ago. Because we were traveling, we didn't have time to record this episode yet. But dear listener, we won't disappoint you. Here we are with our episode on Bitcoin Core 25. Before we get there.

Sjors Provoost It's time for the critical part of the show.

Aaron van Wirdum I will be honest with you, Sjors. I am starting to regret doing the jingle myself. I do feel like I painted myself in the corner with this one.

Sjors Provoost But [unclear]…

Aaron van Wirdum Here we go. Sjors stacks sats. Sjors stacks sats. Sjors stacks sats.

Sjors Provoost Yay. Okay, I guess I'll read one. We have 250 sats from a unit of Ack, which I would probably read as Proost, as in cheers, because it's two beer glasses. And then there's another one from Michael Matulev, Sjors stacks sats, without a music jingle. Um and MRMR 1750 sats.

Aaron van Wirdum How do you know that was without the music jingle, Sjors?

Sjors Provoost Because it doesn't have the music emoji. The last one did.

Aaron van Wirdum Oh it actually did and you still didn't sing it?

Sjors Provoost Yeah this one doesn't.

Aaron van Wirdum Okay well what was the third one?

Sjors Provoost Whatever let's move on.

Aaron van Wirdum Sjors, do you still like this part of the episode? Because I don't think I've heard a single interesting message so far.

Sjors Provoost Well, we could make the criteria a bit stricter that the message should actually be interesting before we do the segment.

Aaron van Wirdum All right. Sjors stacks sats. Sjors, Bitcoin Core 25. Or 25.0.

Sjors Provoost Speaking of not very interesting.

Aaron van Wirdum Right I was just gonna say this doesn't strike me as a particular particularly spectacular release maybe as always I guess at this point most listeners will know but just For context, what does it mean that there is a new Bitcoin Core release?

Sjors Provoost It means about six months went by since the last Bitcoin Core release.

Aaron van Wirdum Right.

Sjors Provoost So it's basically whatever makes it in by some date is what goes in. And then there's some time, maybe a month or two spent on fixing bugs, not changing anything, just fixing bugs. And then it's released.

Aaron van Wirdum Right. So that's in contrast with some other types of software that will release a new version once they've included some kind of important new upgrade. Instead of that, Bitcoin Core just releases a new version every six months. So sometimes it's very interesting and sometimes not much happens in six months. That's really worth... talking about but we're still going to talk about it is that right?

Sjors Provoost It also depends on your interest because if you look at the actual you know list of all the little commits that go in there there's a lot of stuff that's under the hood so if you find that stuff interesting um then there might actually be much more for you there.

Aaron van Wirdum Sure I'm just approaching it from a podcast host perspective and what a average listener might find interesting I think this is not going to be the most spectacular episode but we're still going to do it Sjors.

Sjors Provoost That's right.

Aaron van Wirdum Okay so we highlighted a couple of upgrades that are at least kind of worth talking about and we're just going to do them in um in order of us having written them down in our own show notes. They're not in order of importance or in order of anything else right? I think that's right. Okay so number one: there is some kind of performance improvement when it comes to huge transaction loads and it has something to do with BRC-20 is that right?

Sjors Provoost Yeah that's right. So what in more in general what we've seen in the last few months is the um the the inscriptions the Ordinals and then the BRC-20 hypes and also the Stamps hy— hype that we uh we talked about in earlier episodes it

Aaron van Wirdum just yeah hang on so yeah we spoke about inscriptions Ordinals in a previous episode as well as Stamps. We have not spoken about BRC-20.

Sjors Provoost No, BRC-20 is based on inscriptions. They are inscriptions. They're just inscriptions with a piece of JSON in it. And they are supposed to be smart contracts. I'm saying that with a very cynical face and scare quotes. They are not smarts and they're also not contracts.

Aaron van Wirdum So this is also what I thought. But you're sure about it? They are just using inscriptions, right?

Sjors Provoost Yeah.

Aaron van Wirdum And then they do... It's kind of it's kind of like how Counterparty reinvented is that sort of?

Sjors Provoost Yes.

Aaron van Wirdum Because that's how it sounds it's just Counterparty reinvented more or less.

Sjors Provoost Yes.

Aaron van Wirdum Okay. Yep. Okay. And there's some kind of performance improvement in Bitcoin Core that has something to do with this.

Sjors Provoost Yeah. So, I mean, generally speaking, what you see is people start using Bitcoin in very different ways. So the transactions look a little bit different than what you're used to. For example, you know, in the last episode or a few episodes ago, we talked about how invalid blocks were produced because people were putting multiple signatures in. Now, that wasn't a problem with Bitcoin Core. That was just a problem with the miner software. But software just gets stressed out and starts hitting weird corners. And so similarly, these BRC-20 transactions, they are atypically small. That's sort of one thing you would see about them. They're not the typical two-input-two-output transaction that you see normally. They're smaller.

Aaron van Wirdum Why? What do they look like or what's the deal?

Sjors Provoost I think, and I haven't looked at them in detail, they're probably just one input, one output, a lot of them. Because a lot of time what you do is you update the state of your smart contract. So you're saying, okay, my little fluffy image of a dolphin is now for sale. And that is just one JSON picture that you're uploading or one piece of JSON that you're uploading to the blockchain. You're not sending your coins anywhere. So you just probably just send the same coin to yourself. With this extra node on it right.

Aaron van Wirdum So that so we don't have to re-explain how inscriptions work but you just put this data in the witness and most nodes wouldn't even look at it I guess. yeah and they're very small like you said because not much else is happening with the transaction. Yeah but this is the idea. Okay go on.

Sjors Provoost But it does mean they're a little smaller than expected and then if you really look at how Bitcoin Core deals with things like the mempool how transactions are relayed to other nodes before they go in a block. There were some assumptions in there that were assuming that was happening at about seven transactions per second and you know with SegWit that increased a bit and for this type of usage it should be slightly higher too. Basically the new release contains some improvements to to handle these these higher numbers but I'm being very vague here so we should do another episode where we try to explain that in more detail.

Aaron van Wirdum I mean probably when I understand it. Because it doesn't sound super interesting but basically what it comes down to if I understand you correctly is the Bitcoin Core software the Bitcoin Core code is sort of calibrated with certain assumptions in it of how Bitcoin would usually be used and then that software sort of knows, yeah, it's optimized for that situation. And now that situation kind of changed because of BRC-20 and inscriptions and all of that. And this new Bitcoin Core release kind of takes this new way of using Bitcoin into account with its assumptions in its code.

Sjors Provoost Yeah, and I guess the bigger picture here is that, you know, in blocks, we have a very hard limit. You know, there's only so many megabytes that go into a block. So it's much easier to reason about sort of the worst case. But for the mempool, there are not really any rules. Because it's not really consensus, right? So it's a little bit more complicated to make code that handles all mempool scenarios ideally.

Aaron van Wirdum Right, okay. Now let's make this as practical as we can make this. So I'm a casual Bitcoin Core user. What's the benefit for me when I download Bitcoin Core 25? How does it help me?

Sjors Provoost Probably when there's another storm of these super small BRC-20 transactions, your node will be happier. And by happier, I just mean it's probably going to make your computer less hot, use less memory, stuff like that.

Aaron van Wirdum Require less resources.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, I like my computer cooler, so that's good. Next point, right?

Sjors Provoost Yeah.

Aaron van Wirdum Okay, so there's some update with Miniscripts. We've done a whole episode on Miniscripts. Do you remember what episode that was?

Sjors Provoost I do not.

Aaron van Wirdum Look it up. And then I think in a previous Bitcoin Core release episode, we also mentioned that something... Miniscript related was implemented but it wasn't quite there and it sounds like a new step has been made right?

Sjors Provoost Yeah so when we described Miniscript several years ago I think it was one of the first episodes where Miniscript is just a way it's not a consensus change it's not a soft fork, it's just a way to write scripts in a in a sane way because writing scripts Bitcoin script by hand is a the best way to lose your money and using Miniscript basically allows you to write scripts in a safe way now Bitcoin Core added support for making a watch-only wallet. So that's a wallet that you can see your balance. You can create addresses. So you can use Miniscript and you can receive coins, but you couldn't spend it. So that's not ideal for most people. And so this new release does let you spend it. I'd still say it's pretty experimental. And there are some edge cases where you can actually not spend it.

Aaron van Wirdum Okay, so maybe as a very... brief recap of Miniscript actually. So the thing here is that the Bitcoin protocol allows certain kind of basic smart contract functionalities. So it allows multisig, it allows time locks, it allows I don't know hash pre-images, it allows a bunch of things. And with Miniscript, it's actually very easy to implement these things in the smart contract way. So you can receive coins in a certain way. So for example, you can have a board of directors and a company and they can say... Three out of five have to agree or two out of five after a year, whatever. You can do that kind of stuff. And with Miniscript, you can implement that easily. Now with Bitcoin Core, okay, now is where I'm getting kind of lost. Because this is what the Bitcoin protocol allows.

Sjors Provoost Yeah, nothing changed in the Bitcoin protocol for Miniscript.

Aaron van Wirdum Right, so what is Bitcoin Core actually?

Sjors Provoost Well, Bitcoin Core is really multiple things. So Bitcoin Core is the node, the thing that checks the blocks for validity. Nothing changed there. But Bitcoin Core is also a software package that has a wallet built into it. Now, anybody's free to build a wallet, there's nothing special about the Bitcoin Core wallet. In fact, it's probably not one of the most user-friendly wallets, but it is quite powerful. At least it's becoming quite powerful. I think that's a better way to say it, thanks to Miniscript. So this wallet is able to use Miniscript.

Aaron van Wirdum But when you say, okay, you say use Miniscript.

Sjors Provoost It means you can give it a piece of Miniscript and it understands how to create addresses, how to sign transactions using it, etc.

Aaron van Wirdum Okay, but Miniscript is literally script. It's not—it's still something you code as a programmer, right?

Sjors Provoost Yeah.

Aaron van Wirdum So you give that code to the Bitcoin Core wallet. Okay, we're not talking about the GUI then. You have to go into the command line and you paste a piece of code there. And this is what Bitcoin Core will understand.

Sjors Provoost Yeah, but basically, I mean, some people may have been used to pasting xpubs around. So it's basically Miniscript. The way it works in practice is just an xpub with a bunch of extra script around it saying what to do with the xpub.

Aaron van Wirdum Okay, this is what you paste.

Sjors Provoost Yeah, you paste it in the command line, but there's no reason this could not— this could be added to the user interface too. It's just that you'll have to paste something magical that you probably don't understand. So it's a bit dangerous.

Aaron van Wirdum Okay. And so far, Bitcoin Core could understand it and you could receive the coins, but then they were just sitting there in your wallet and you couldn't actually spend them.

Sjors Provoost Yeah.

Aaron van Wirdum Yeah, it sounds like being able to spend them is a pretty good upgrade.

Sjors Provoost It's one of the nicer features of Bitcoin, although it's good for inflation if people don't, you know.

Aaron van Wirdum Okay, so I guess... Wait, but this is still sort of limited. It doesn't...

Sjors Provoost Yeah, I think for the most cases that you've described it will work. You can create a PSBT because there's now two, I believe, two hardware models or maybe three. So the Ledger was first and then I believe it was COLDCARD or BitBox, one of those two, added support for Miniscript, which means you can make like a multisig wallet with three physically different devices with each having their own trade-offs. And in order to do that, you need PSBTs generally to move between these devices. But there are some limits to what you can do there. So there may be some obscure scripts that you can write them, you can receive coins on it, but you will not be able to send them to the hardware wallets using a PSBT. Some like edge case that if you know Miniscript, you'll probably understand the edge case. I don't.

Aaron van Wirdum And also, it doesn't work with Taproot yet.

Sjors Provoost Yeah, that's a bigger drawback, I would say. Miniscript was designed quite a while ago before Taproot. And it is initially designed for the use with SegWit, basically SegWit script. Actually, I think there's also a Miniscript standard for pre-SegWit script, I think. But at least it was designed for SegWit script. And so there has now been a recent modification to that proposal that also makes it work for Taproot script. Because most of the script is the same between SegWit and Taproot. Most are the same opcodes, so you can make signatures, etc. But there's a few subtle changes in Taproot. So that changes a few things about Miniscript.

Aaron van Wirdum So is that... So that would be an upgrade in the future, potentially, I would assume.

Sjors Provoost Yeah. And that's, again, that's one step at a time. So the first step would be that you can write Miniscript and then it'll generate, you know, a leaf, a script leaf in Taproot because you can put your individual scripts and individual leaves in the tree. But there's no way yet to decide how to most efficiently, you know, distribute your... your scripts between all the leaves so if you have like five different conditions do you want to make five leaves in Taproot or do you want to make one leaf that does two of them that sort of stuff there's nothing no tooling for that yet.

Aaron van Wirdum Right okay. so

Sjors Provoost Soon tm.

Aaron van Wirdum Two weeks. So we've mentioned two improvements so far which had one was the transaction loads BRC-20 and then we now mentioned Miniscript and now we're getting to the third one and that's actually the last one already.

Sjors Provoost Fast wallet rescan.

Aaron van Wirdum Fast wallet rescan. Sjors, explain.

Sjors Provoost So Bitcoin Core again has a wallet built into it. And let's say you first used that in 2012 and you received some Bitcoin. And then you were like, okay. Let me put this wallet on a USB stick put it in a vault somewhere physically so the whole wallet not just a backup codes just the actual file and remove it from my computer because I'm traveling around with it now your node just keeps updating keep syncing, keep syncing, keep syncing, and then now you come back and you you put the USB stick back into your computer maybe that's a bad idea if there's a lot of money on it but let's say you do and use Well, then your wallet is behind, in a sense, because the new transactions that happened since 2012 would not be in that wallet file because it was in your vault. And your node doesn't know, it doesn't really track them either, not specifically. It just has all the blocks. So there's something called a rescan, which basically the wallet file...

Aaron van Wirdum Wait, wait, wait, wait. So, because this is confusing. I think what you mean to say is you received coins on one wallet. And now after that, you started using a new wallet, right? When you say syncing, syncing, syncing, your node is not syncing based on that wallet anymore.

Sjors Provoost Yeah, your node is still syncing. It's just storing all the blocks and checking the validity. But it's not keeping track of how that matters for your wallet.

Aaron van Wirdum Right. So you basically reinstalled Bitcoin Core or something like that. You got a new computer, something like that, right?

Sjors Provoost No, you can basically unload a wallet and then load it again.

Aaron van Wirdum But in most—

Sjors Provoost But I guess another scenario would be yes so so you are restoring you're reinstalling Bitcoin Core and you you're recovering your wallet and you're trying to see if there's any coins in that wallet and find the transactions and the only way to do that is to go through all the blocks and check for every block if there's something useful in that block and that just takes a long time could be several hours.

Aaron van Wirdum That's not so bad.

Sjors Provoost Computer. Okay it depends on your patience.

Aaron van Wirdum I guess I guess we can do better than that.

Sjors Provoost Yes, we can.

Aaron van Wirdum So how do we do better?

Sjors Provoost Yeah, so basically this is using the Neutrino filters that we did an earlier episode about, the compact block filters. Forgot the episode. Look for Bitcoin Explained Neutrino and you'll find it. But the idea there is that light wallets can use these filters to figure out which blocks they need to download. So instead of downloading all the blocks, a mobile wallet can say, okay, it can figure out by itself without revealing any private information to the outside world. Which blocks it it should download and in order to do that it needs to download something called these filters these filters are much smaller than normal blocks and so Bitcoin Core can create these filters and Now the wallet will take advantage of that because rather than scanning every block From the history from the last time you checked your wallet it now knows which blocks it needs to scan And so it'll scan fewer blocks, which is faster.

Aaron van Wirdum Yes. Wait. So if I have a wallet.dat file on a USB stick, as we discussed, that's the example we're using. And I buy a new computer tomorrow and I sync Bitcoin Core and now I get the wallet.dat file. Somehow Bitcoin Core would know which blocks to download based on the wallet.

Sjors Provoost So the wallet.dat contains the addresses that belong to your wallet. And so depending on how old it is, that's going to be somewhere between 2,000 and 8,000 because it basically creates a cache of addresses. It knows these addresses. And yet using these filters, which Bitcoin Core will also have created, it's able to know which blocks are relevant and which blocks are not because these filters are like a compressed summary of the blocks. So then it looks at the filters and it says, okay, do my addresses, if I run my addresses to this filter, does it say yes or no? And if it says yes, I'm going to download the block and I'm going to check everything. Filters are not accurate. So it's possible that you might download 10 times more blocks than you really need, but you're not downloading them all. And in the case of Bitcoin Core, it's not even about downloading them. It's just about checking them.

Aaron van Wirdum Well... Yes, so it doesn't work with a pruned node, right? You do need to have all the blocks available.

Sjors Provoost Correct. At the moment, it does not work with a pruned node, but if you had these filters on your computer, but pruned blocks, you would be able to know which blocks to download again, which currently you can only do with some manual magic. So it is possible, actually, with a pruned node, but then you need a script. And basically, I've tried this myself, just to experiment with it. You can scan. I don't know if I tried this myself. I may not. No, I think I'm lying here. But in theory, it's possible to download all the blocks that you're missing and then scan it. But the wallet will [unclear] be very confused.

Aaron van Wirdum Okay. Well, I don't understand how this works, but that's probably because I forgot how Neutrino works. So if I want to understand that, I would have to go back to our own episode and listen to that.

Sjors Provoost Sounds good.

Aaron van Wirdum Unless, Sjors, you want to try explaining this right now?

Sjors Provoost You forgot how an Arduino works.

Aaron van Wirdum I mean, I don't remember.

Sjors Provoost I just told you.

Aaron van Wirdum I mean, I understand the idea. I just don't understand why it works. I don't understand.

Sjors Provoost It's magical math.

Aaron van Wirdum Yes, exactly. Well, I feel that at some point I kind of understood it more than just magical math, but not right now.

Sjors Provoost No, the magical math basically says that you've done some calculations before to make a filter from a block. And then you can check against the filter. You say, do these addresses belong to this block or not?

Aaron van Wirdum Do you want to just leave it there?

Sjors Provoost Yeah, because that's about as well as I can explain it.

Aaron van Wirdum Okay, we'll leave it there. If you want to know more, I think we go a little bit more in depth in our actual Neutrino episode.

Sjors Provoost We missed the topic.

Aaron van Wirdum Well, I wasn't done, Sjors. I think you're going to bring up the RBF, the full RBF.

Sjors Provoost No, no, no, no. Wait, there's 65-byte transactions.

Aaron van Wirdum Oh, you're right. Oh, we missed a topic. That's a big one. You're so sharp today. Luckily, because I'm apparently not. Okay, so yes, there's something going on with the minimum size of transactions.

Sjors Provoost Yeah, we added more freedom to the mempool.

Aaron van Wirdum Is that so?

Sjors Provoost Yes.

Aaron van Wirdum Okay, explain.

Sjors Provoost So remember there is consensus, which is what the rules for the blocks, and there's standardness, which is rules for the mempool. And generally the standardness rules are stricter than the consensus rules. In fact, that's always the case. In other words, there are some transactions that are perfectly fine in a block, but they are not fine in the mempool. And this usually has to do with preventing DoS, denial of service attacks, on your node. In this case, though, it's not really that. There is a minimum size. I believe it was 84 bytes. So any transaction that's less than 84 bytes would not be relayed by nodes. If it's in a block, it's fine.

Aaron van Wirdum Is there a minimum size to be in blocks at all?

Sjors Provoost I don't think so. There's probably a minimum practical size because you have to point to a previous transaction, etc.

Aaron van Wirdum Yeah, there's an actual minimum size that a transaction can be, but there's no consensus rule for it.

Sjors Provoost Yeah, I guess you'd say there's an inherent minimum size. It follows from what has to be in a transaction, but other than that, I don't think there's a number.

Aaron van Wirdum Okay, but there is a minimum size for the mempool policy.

Sjors Provoost Yeah, and I think it was something like 82 or 84, some number, and this number has been decreased. Now it's 65.

Aaron van Wirdum Okay, why?

Sjors Provoost Well, so why... I mean, there's some use for it. So I think the idea is it makes it a little bit easier to burn coins if you need to.

Aaron van Wirdum To burn coins?

Sjors Provoost Yeah, if you have some dust that you want to get rid of, you want to remove it from the UTXO set.

Aaron van Wirdum Okay.

Sjors Provoost I think it's easier to do that with smaller transactions. But the...

Aaron van Wirdum Wait, what? Why would you want to do that?

Sjors Provoost Because you want to clean up the UTXO set.

Aaron van Wirdum But you literally just want to... throw away coins?

Sjors Provoost Well you throw away coins that are not economical right?

Aaron van Wirdum So why not just leave it alone?

Sjors Provoost Because then it's sitting in people's memory and using up resources. Be a good citizen clean up your UTXOs

Aaron van Wirdum I guess I guess okay yeah go on.

Sjors Provoost There may also be uh things I mean I think this was proposed by instagibbs, [unclear] Sanders and he's working on ephemeral anchors which are ways to combine two transactions that are paying a zero fee and then one is bumping the other so maybe those transactions are actually smaller than and maybe that's why he needs it I haven't looked at the reasoning in any case it's possible so it's done um the original reason is kind of funny um the original limit was made this weird number like 82 or 84 because if they had made it 65 then the bad people would have understood why it was done and they might have been able to exploit something before the fix was released. So this is a case of you have a vulnerability. You know that if people make 64-byte transactions, they can cause problems. You don't want to give that away too, obviously. So you say, we're not going to make the limit 65. We're going to make it like 84 and then make up some excuse why 84 is a good number. Because nobody needed it.

Aaron van Wirdum This is super confusing. Luckily, I know what you're talking about.

Sjors Provoost All right. Well, maybe you can explain it.

Aaron van Wirdum Yes. So you mentioned the original number, and you said that was 82. So that's the confusing part. No. The original number was 64. That was a minimum of 64.

Sjors Provoost Yeah.

Aaron van Wirdum And then it was increased?

Sjors Provoost No, no. There was no minimum. But it had to be increased above 64.

Aaron van Wirdum Oh, so it was not 64?

Sjors Provoost No, I think it was…

Aaron van Wirdum So there was no minimum.

Sjors Provoost Yeah.

Aaron van Wirdum Okay. Okay. So there was no minimum. And then a minimum was imposed. When was this?

Sjors Provoost I think it was 2017.

Aaron van Wirdum Oh, a while ago.

Sjors Provoost Yeah. Might have been done even earlier.

Aaron van Wirdum Okay. Then a minimum was imposed and that minimum was 84?

Sjors Provoost Something like that.

Aaron van Wirdum Okay. And now that has been decreased to 65.

Sjors Provoost Exactly.

Aaron van Wirdum What you're saying is... the reason that 84 was picked originally is because they didn't like originally 65 would have been ideal but I didn't want to do that because it would reveal something so then they picked 84 which was a little bit more off to the side And then hopefully attackers wouldn't notice it.

Sjors Provoost That's right.

Aaron van Wirdum Right? Okay. So what was wrong with... So why is 64 a magical number?

Sjors Provoost Yeah. And in fact, the strict rule that you really need is not 64. So it could be smaller than 64. It can be bigger than 64. But you don't want 64.

Aaron van Wirdum Okay.

Sjors Provoost And the reason has to do with Merkle trees. And we've talked about Merkle trees in earlier episodes. We've even tried to explain Merkle trees in earlier episodes. I think we should not try that again.

Aaron van Wirdum Probably multiple times.

Sjors Provoost Yeah. But the idea of a Merkle tree is like...

Aaron van Wirdum To no avail.

Sjors Provoost What it looks like... Right. What it looks like is you take two transactions side by side and then you hash... No. So you take two transactions, you hash each of them, and then you put the hash of the first transaction on the left, the hash of the second transaction on the right. And the hash of a transaction is how many bytes?

Aaron van Wirdum 64.

Sjors Provoost No.

Aaron van Wirdum Oh.

Sjors Provoost The hash of a transaction is...

Aaron van Wirdum I don't know.

Sjors Provoost Well, it's called SHA—

Aaron van Wirdum Should I know?

Sjors Provoost Yes, it's called SHA-256. The 256 stands for the number of bits. 256 divided by 8 is 32.

Aaron van Wirdum Okay.

Sjors Provoost So the hash is 32 bytes. You put two of the next to each other. That is 64.

Aaron van Wirdum Right.

Sjors Provoost And then this tree goes up and up and up. You keep combining two. What?

Aaron van Wirdum This is not how a Merkle tree works. What?

Sjors Provoost This is exactly how a Merkle tree works, at least how it works in Bitcoin. Yeah, you start with transactions at the bottom, you pair them, and then you basically hash each of them, and you put the hashes next to each other, so 32 bytes next to 32 bytes, and that's 64 bytes in total.

Aaron van Wirdum Right, and you hash these together, right?

Sjors Provoost Yeah, exactly.

Aaron van Wirdum Okay, yeah, yeah.

Sjors Provoost So you hash each of these. And so the problem there is that if you implemented this well, a Merkle tree, then it would be very clear how many leaves there would be. So you would basically say this is a Merkle tree and has so many leaves. And then somebody who looks at the Merkle tree can extract it and see these are all transaction hashes. Problem is in Bitcoin, it's done unsafely and this has caused problems in the past. But basically anything that's 64 bytes can be either a transaction of 64 bytes or it can be one of these points inside the Merkle tree.

Aaron van Wirdum Yeah okay they look the same I just want to clarify

Sjors Provoost They look the same and that is that is where multiple attacks have come from including much older ones that where you could create blocks that were like you would pretend that you that the block is invalid and then you'd send the same thing again you all sorts of nasty things

Aaron van Wirdum I just want to clarify we're getting really into the weeds with weird niche but kind of interesting attacks here so yeah okay the transaction hash is 32 bytes. I already, I'm not going to try to re-explain this one even. But I was kind of following you.

Sjors Provoost 32 bytes. You put two of them next to each other and now you have 64 bytes.

Aaron van Wirdum Yes.

Sjors Provoost So what does that mean? Well, I think it's Sergio who...

Aaron van Wirdum Sergio, yeah, Demian Lerner, yeah.

Sjors Provoost Yeah, who wrote a blog post in 2017 explaining exactly what you can do to attack a user of an SPV wallet.

Aaron van Wirdum I'll add the link to the article in the show notes.

Sjors Provoost Yeah, you definitely want to read it. I'll try to explain it at some high level, but it... I find it confusing.

Aaron van Wirdum Yeah, go for it.

Sjors Provoost What is important to know is that this attack, so it's an attack on SPV wallets. So these are wallets that do not download full blocks but only get a summary. And they get something called an SPV proof, which is saying, hey, this transaction exists. It's inside a block. It's here. It's inside this block. And then you give it all the block headers. So the SPV wallet knows, okay, there's some proof of work on top of this transaction. I can't check all the consensus rules, but at least I know some miner paid a lot of money to make this thing. So that's a kind of wallet user that's not very common anymore because there's all sorts of problems with it, including the one we're about to describe. And then if you have a few million dollars in budget, you can perform this attack. And this was in 2017. I think you also need to have a pretty substantial amount of Bitcoin to do that, which was cheaper back then. What you do is you start creating transactions. You basically create a 64-byte transaction. and you pretend that it is part of this Merkle tree or the other way around. See, this is where I even get confused. But the idea here is because the transaction is hashed into 32 bytes and there's two of them next to each other, that means that you can basically start making a... How do you say this? There's certain parts of the transactions that can be whatever you want. And so you don't have to actually find a SHA-256 pre-image. You have to find far fewer. You have to try far fewer random transactions to be able to craft a transaction that looks like this. And one of the tricks he does is like he's saying, okay, I don't care about the amount in advance. So how many amounts can there be? There's just several bytes worth of what the amounts can be. So you basically keep looking for transactions with random different amounts. And then once you find the right hash, you use it. And then you send money to yourself. Anyway, you should read the blog post. But the attack is quite expensive.

Aaron van Wirdum Yeah, can I summarize this? Here's the summary. SPV wallets are not secure if you want to accept millions of dollars worth of Bitcoin.

Sjors Provoost Yeah, assuming his calculation is correct, it would cost at the time several million to do this attack. And so if you are receiving more than a few million, you should absolutely run a full node.

Aaron van Wirdum Yeah, there are just some weird quirks in the Bitcoin protocol and miner incentives. And SPV is not secure for that.

Sjors Provoost No, and this attack also requires collaboration from a miner. So if you have collaboration from a miner anyway, you might as well just do a normal double spend.

Aaron van Wirdum Right.

Sjors Provoost But I think the target audience for this attack was automated systems that use SPV proofs. And I think at the time, Liquid had some components and RSK had some components that were fully automated and would use these SPV proofs and would have lots of money in them.

Aaron van Wirdum Okay. And now I want to ask you, so Bitcoin Core made this change? Or apparently they made the change a couple of years ago, actually. And now it's only now, I guess the developer figured most people have now upgraded. So now we can stop pretending that 84 was...

Sjors Provoost No, the pretending stopped earlier. So I think it was changed in 2017 without any explanation. Although this blog post from him was around the same time. And then in 2019, there were comments added to the source code saying, actually, this is nonsense, but this is the reason. And then only now somebody bothered to actually change the limit, which is because nobody needed it.

Aaron van Wirdum Yeah. So why is it needed now?

Sjors Provoost Well, I don't know. I mean, that's what we speculated on earlier. Maybe it's easier to burn money or maybe it has something to do with these ephemeral anchors. I didn't study it in enough detail.

Aaron van Wirdum Okay. Uh anyway so now the limit is 65 however even now that's only a policy change

Sjors Provoost Yeah so the irony is this never prevented the attack because the attack as described actually requires being a miner or at least working with a miner so it's kind of ironic because a miner doesn't care about standardness rules so it was a step it was like okay but you know there's something called defense in depth where you say okay We think only a miner can do this, but maybe somebody else figures out a way to do it without the help of a miner. So it still helps to make it more difficult to relay these things. And there is a software proposal, which is called the Great Consensus Cleanup, which Matt Corallo proposed in 2017.

Aaron van Wirdum We may have done an episode on that or no?

Sjors Provoost Yep. And one of the parts of that proposal was to make the minimum transaction size 65 bytes. And that would be consensus change.

Aaron van Wirdum Right.

Sjors Provoost Which is precisely for this reason.

Aaron van Wirdum Right. Okay. But that's not what this is. So that's one. I feel we're getting really into the weeds with this Bitcoin Core 25 episode Sjors. I think this is like a very niche upgrade, but it's an upgrade. So we've now covered four topics. We're done with this one, right?

Sjors Provoost I think we've covered. Yeah, we covered four of them.

Aaron van Wirdum Good. Are we done with the episode?

Sjors Provoost I think so.

Aaron van Wirdum I mean, that was this other thing you wanted to mention, maybe something about the full RBF release.

Sjors Provoost Yeah, so there's an alternative implementation, which you can download at your own risk. Make sure to check all the signatures, et cetera.

Aaron van Wirdum This is Peter Todd's implementation?

Sjors Provoost Yeah, it's Peter Todd, I think, together with Antoine Riard. They're lobbying the full RBF thing, which we've done plenty of episodes about. It's essentially Bitcoin Core 25 plus the full RBF stuff. And the one thing that's... I think interesting about it is that when you just turn on full RBF, you're able to replace transactions without setting the RBF signal. But the problem is if you're sending it to your peers, none of those peers might relay it. And so what you want to do is you want to find other nodes out there in the network that also support this feature. And there's something called service flags in which nodes can communicate that they have this feature and deliberately connect to them. So this patch does that. But I should warn you that changing peer-to-peer code is always very scary. So if just one or two people are doing that, I don't know, it's up to you.

Aaron van Wirdum And anyways, this is not Bitcoin Core really. And we were talking about Bitcoin Core. So that's the episode then, Sjors?

Sjors Provoost That's right.

Aaron van Wirdum Bitcoin Core 25 is released. Where can people find it?

Sjors Provoost BitcoinCore.org.

Aaron van Wirdum There you go.

Sjors Provoost So thank you for listening to Bitcoin

Aaron van Wirdum Explained.