Episode 95: Bitcoin Core 28

Aaron van Wirdum Live from Utrecht, this is Bitcoin, Explained. Hey, Sjors.

Sjors Provoost Hello.

Aaron van Wirdum How have you been?

Sjors Provoost Not bad. It's only been three months.

Aaron van Wirdum Was our last episode also a Bitcoin Core release episode, perhaps?

Sjors Provoost No, no, no. We talked about silent payments.

Aaron van Wirdum Oh, that's right. Yes, that is right. Well, this time we're going to discuss the new Bitcoin Core release because there is one.

Sjors Provoost Version 28.0.

Aaron van Wirdum First, here's a message from our sponsor, Coinkite. [unclear] put a bunch of presents here for me to look at.

Sjors Provoost That's right.

Aaron van Wirdum This looks like a battery.

Sjors Provoost Yeah, this is a 9-volt battery. You know, the square-shaped battery for people who don't know what they look like.

Aaron van Wirdum A Duracell battery.

Sjors Provoost And then there's a little device next to it. Um, that is I believe called COLDPOWER which you can connect to the nine volt battery and then it can power any USB device, but you know probably the USB device you want to power with it is the COLDCARD

Aaron van Wirdum Um, I yes, wait, so this is a Coinkite product that I'm holding right now?

Sjors Provoost Yes.

Aaron van Wirdum And oh, I see. I can… Wait, I have to maybe so what? Okay, yes. It's very unfortunate in moments like these that we don't have any video with our podcast. Okay, so I'm now attaching this little USB device.

Sjors Provoost You should do it closer to the mic and then we can play the game that they do in Qmusic called Het Geluid, the sound, and then you have to guess what sound it is.

Aaron van Wirdum This is a very Dutch in-joke. Okay, so now I connected the battery to the thingy, and now what? Now it's charging?

Sjors Provoost No, no, that's just a USB port. Now you can connect a USB cable to that and then the COLDCARD to it, and then you have your hardware wallet getting power. Not so much charging, because I don't think it has a battery, but just it has power, so you can turn it on and you can move your files from the hardware wallet to the computer without... having this device connected to a USB port of the computer.

Aaron van Wirdum I have absolutely no idea what's going on here. But I also don't want to linger on it for 10 minutes. They're not paying us enough for that. It's a very cool device, though. It's called the COLDPOWER.

Sjors Provoost But I think they primarily want to sell more COLDCARDs, their hardware wallets.

Aaron van Wirdum Okay, COLDCARDs. Wait, but I got something else as well. Here is the TAPSIGNER. What is this, Sjors?

Sjors Provoost You can tap it and then it signs things. I think it's just kind of like an extra key.

Aaron van Wirdum It just has your private key on it?

Sjors Provoost Yeah, that wouldn't be your savings private key, obviously. It could be just one of many keys.

Aaron van Wirdum And this is another Coinkite product. Coinkite's making all sorts of stuff nowadays, Sjors. I remember when they were just making hardware wallets.

Sjors Provoost They're the Opendimes.

Aaron van Wirdum Yeah. I mean, they've been at it for a long time, actually. Rodolfo was at the 2014 conference in Amsterdam.

Sjors Provoost Oh, that's 10 years ago.

Aaron van Wirdum Yeah, I don't remember what he was like. He was already selling stuff and building thingies and gadgets and who knows what. I don't think it was hardware wallets. Maybe it was actually back then. I don't know. And then here we got the calculator looking. Hardware Wallet as well.

Sjors Provoost The Q.

Aaron van Wirdum The Q. Okay. This is way more than they paid for. Let's get to the actual episode here.

Sjors Provoost Well, there's another fun news, which is that how do I say this? Aaron stacks sats. Aaron stacks sats.

Aaron van Wirdum Aaron stacks sats.

Sjors Provoost Because we have connected you in Fountain so that the sats that are streamed now also go to you. So you didn't have to set up your own node.

Aaron van Wirdum I think we need to make more episodes for that to actually return some dividends. I haven't seen anything come in, I think.

Sjors Provoost No, because we haven't done an episode since.

Aaron van Wirdum Okay, there we go.

Sjors Provoost And they're not a sponsor.

Aaron van Wirdum Apparently people aren't paying us for doing nothing.

Sjors Provoost The podcasting 2.0 stuff.

Aaron van Wirdum So let's get to the actual episode here, Sjors.

Sjors Provoost Yes, sir.

Aaron van Wirdum Bitcoin Core 28. We've mentioned in basically every other Bitcoin Core new release episode that there is a new Bitcoin Core release every half year. People know that by now, which means that whatever is done... at a certain time goes in. If it's not done yet, then it doesn't go in. You know, this is kind of different with some other software products: you will release a new version when some sort of new feature is done. Bitcoin Core, nope, every half year, there's just whatever is done is in there. So we're going to discuss what's in there this time. There is, uh, there are some at least slightly interesting things in there.

Sjors Provoost Yes.

Aaron van Wirdum I would say.

Sjors Provoost I'd say it's quite a lot of interesting things.

Aaron van Wirdum Yeah, it's like an actual upgrade. Sometimes it seems sort of like a maintenance upgrade. Now there's some actual new stuff here. We'll start off with what is, at least in my personal opinion, the least interesting one. I don't know why we're even discussing this.

Sjors Provoost I think it's one of my favorites.

Aaron van Wirdum The testnet one.

Sjors Provoost Testnet 4. That's right, ladies and gentlemen.

Aaron van Wirdum Why are we talking about Testnet? Testnet is not Bitcoin. Anyway, so there's a new Testnet. Sjors wants to talk about the new Testnet. What's new with the new Testnet?

Sjors Provoost Well, there's two things in there. One is there were recently block storms, also known as the Lopocalypse. It's hard to pronounce, actually. It's easier to write.

Aaron van Wirdum That is harder to pronounce than you would think.

Sjors Provoost Jameson Lopp was just trolling everyone with just a single laptop producing hundreds of thousands of blocks, making Testnet 3 unusable for people with bad software, but also generally not easy to use. And it was exploiting a bunch of well-known vulnerabilities in Testnet 3 specifically. The problem with Testnet fundamentally, and we'll never be able to fix that, is that it cannot fully rely on proof of work the way Bitcoin does because all the proof of work is on Bitcoin. And if it was the same as Bitcoin, it would be a shitcoin and it would be attacked.

Aaron van Wirdum I mean, the problem, of course, is that performing proof of work actually costs, requires you to perform proof of work. There's actual energy you have to expend. And the reason miners do that on Bitcoin is because they get paid for it in Bitcoin. While testnet, which is designed to not be worth anything, and if it does get worth, you know, if people start valuing it, they reset it, you know, they being the developer. So it's like designed to not have any value, so therefore there's actually no... incentive to perform proof of work.

Sjors Provoost Yeah, and even if there was, which indeed, you know, sort of the rule is that if that happens, if people start valuing testnet coins, then it gets reset. There's just a new testnet, which is what's happening, and part of the reason is because people started selling testnet 3 coins. But it was also just becoming harder and harder to use, and one of the weaknesses in the testnet 3, so in order to deal with this lack of incentives, Testnet has a few extra rules that keep it somewhat workable in the face of miners messing with the network. In particular, what could happen without these rules is a miner decides to put a giant ASIC farm on Testnet 3, increase the difficulty to some really, really high difficulty, and then disappear. And then if you're just at home trying to test something with your CPU, you just cannot mine a block anymore. And so Testnet had a rule that after 20 minutes, you could do it anyway at a very low difficulty. And it was a bunch of these rules. And they were such that they were creating a mess because it was too easy to mine hundreds of thousands of blocks very quickly. And Testnet 4 fixes that. At least fixes it somewhat because fundamentally you can't really fix it.

Aaron van Wirdum Yeah, okay. So how does testnet4 fix it?

Sjors Provoost I don't know. I forgot. It basically adds a few more constraints to the timestamp. I think one of the problems was that you would... So after 20 minutes, you were able to mine a block at difficulty 1, which is the lowest difficulty. And then what you would do is the last block in the difficulty period would also be 1. And then... you would keep doing that, then the difficulty would permanently be 1. So it wouldn't be temporary for 20 minutes, it would just be permanent. And so I think the new rule is that the block at the edge of the difficulty period has to be the normal difficulty. So the downside is that if some ASIC drives up the difficulty, you can mine blocks. after 20 minutes, but not the first block of the difficulty period. So some ASIC will have to come around once every two weeks to produce one block if this happens, but they can't then lower the difficulty permanently.

Aaron van Wirdum Okay.

Sjors Provoost Because the problem is once the difficulty...

Aaron van Wirdum I hope you can excuse me for kind of not being very interested in all the adversarial ways that testnet can be abused. I want to just move on to actual Bitcoin here.

Sjors Provoost Yeah. This is fundamental.

Aaron van Wirdum I mean, if you think there's something to add for our listener that might find this interesting, go ahead. But I'm done with the testnet stuff, Sjors.

Sjors Provoost Well, then you want to talk about the time warp fix?

Aaron van Wirdum Yes, let's go to the... Oh, no, that is still testnet.

Sjors Provoost Yeah. But it’s a bit [unclear]…

Aaron van Wirdum Okay, I thought we were already there. Go for it.

Sjors Provoost Well, the time warp fix is something we talked about in the great consensus cleanup episode.

Aaron van Wirdum Yes.

Sjors Provoost So it's useful to try that on testnet, simply because maybe one day we want to use it on mainnet, but that's not the immediate plan here. And one practical reason why it's being deployed on testnet is because the time warp attack is another way to very quickly mine all the coins, like mine the whole subsidy. So you want to prevent that. We definitely want to prevent that on mainnet, because that's just bad. But on testnet, it's also important to prevent it, because otherwise someone's going to mine all 21 million coins on testnet, and then we have to make another testnet.

Aaron van Wirdum Which is totally fine.

Sjors Provoost For you, yeah, but it's a pain in the butt to make a new testnet. There's actual work involved.

Aaron van Wirdum Okay. So there is a time warp fix that is part of the Great Consensus Cleanup, which we discussed just two episodes ago. So everyone still has that fresh in their memory. Exactly. You know, January 2022 or whenever the last episode was.

Sjors Provoost Two weeks ago.

Aaron van Wirdum But that has been rolled out on testnet. So in a way, it's also being tested now, I guess. You can sort of see it that way.

Sjors Provoost Yeah, and it already led to some discussion. Some people argued that this fix is not good enough, not even for mainnet. And so it's good to have this code out there. When code is actually out there, people are more likely to look at it and critique it.

Aaron van Wirdum Good.

Sjors Provoost But one thing that's important to point out, I already kind of said it, but oftentimes when there's a software proposal, people hash out the whole software proposal, then they agree, then they deploy it on testnet, then they deploy it on mainnet. That's not what's happening here. This is just a test on testnet. It's not like the test that we're about to do this on mainnet.

Aaron van Wirdum Yeah, there's actually a practical reason to use this on testnet right now. That's the reason it's on testnet right now, not to test it for mainnet.

Sjors Provoost Well, it's there to test in case we want it for mainnet, but it's not like the typical software test on testnet is really like, okay, we think this is completely ready. Whereas in this case, we don't think that.

Aaron van Wirdum Right. Okay. Done with testnet?

Sjors Provoost Yes.

Aaron van Wirdum Awesome. Let's go to Bitcoin.

Sjors Provoost Talk about the mempool.

Aaron van Wirdum Yeah, so there's an actual...

Sjors Provoost Well, the mempool isn't really the blockchain either. So do you care? Are you going to fall asleep again?

Aaron van Wirdum Mempool definitely counts. Mempool counts as Bitcoin.

Sjors Provoost Okay.

Aaron van Wirdum Mempool is sort of...

Sjors Provoost You heard it here first.

Aaron van Wirdum I count it. I count it. I care about the mempool for reasons that we're going to explain right now. So there has been sort of a package of upgrades, which also includes a package. It's true, though. So the problem in a nutshell and the reason that this is needed, I think, correct me if I'm wrong. So in case there are any listeners that don't know this, every Bitcoin node has a mempool, and the mempool collects transactions that are then included in blocks. So there's sort of like a waiting room for transactions until they're actually included in the blockchain. So if you are a miner, then you're actually mining from the mempool of your node, essentially.

Sjors Provoost Yeah. There's no one mempool. Everybody has their own mempool, but all the mempools... tend to be very similar, especially the top of the mempool, the thing that's probably going to be mined next.

Aaron van Wirdum Right. But there is a problem, namely that mempools are also limited in size. It depends per person or per node how big that size is exactly, but ultimately a mempool also has a size, in the same way that a Bitcoin block has a maximum size. So if your transaction doesn't have enough fee, then it will actually drop out of people's mempools.

Sjors Provoost Yeah.

Aaron van Wirdum Now, this is a real problem, especially for second-layer protocols like Lightning, where sometimes you need to get a transaction that is sort of pre-made, pre-signed. You need to get it into a block, but first of all, you need to get it into a mempool to get it into a block. Now, if the fee is too low to get it into a block, but it at least gets into the mempool, you can fix that with this trick called... Child pays for parent

Sjors Provoost Or with replace by fee depending on the type of transaction.

Aaron van Wirdum Right, but in this case we're talking about child pays for parent mostly right? for the fix we're going to discuss right now.

Sjors Provoost Yeah, because if you're talking about Lightning what often happens is that you and your channel partner agree about a transaction. You pre-sign it, and so at the moment you sign it you don't know what the mempool fees are going to be in the future. And so the only way to, if there's some conflict or you can't find the other side, the only way to get your transaction then included to get it in the mempool at all is that it must have enough fees to make it in the mempool period. And to bump it, you cannot replace it because you don't have the, yeah, you can't RBF a transaction because the other side has to do the same thing. And so child pays for parent is then the only way to get it included in the next block or to even get it in the mempool.

Aaron van Wirdum Yeah, so in other words, if I want to get my money out of a Lightning payment channel then I can do that uh and then if the transaction fee of me doing that is not high enough because this was all like pre-done then what I can do is okay you know what, I'll just spend that money that I'm sending to myself, anyways and I'll spend it in a new transaction also to myself, and I'll include a higher fee, and then you know, nodes will figure out that okay if we include both of these transactions in a block then we get both of these fees. So that usually works unless if that first transaction where I'm originally getting my money out of this Lightning payment channel, if that transaction doesn't even have enough fee to fit in people's mempools, then I also can't claim it with this child pays for parent trick because now this child that I'm using, the child payment that I'm using to claim the money, isn't referring to something that other nodes know about because the parent transaction... The first transaction already fell out of their mempool. So the idea to fix that is that I should be able to tell other nodes on the network, hey, I want to pay for this transaction as well. So please consider both of these transactions. I know that the first transaction doesn't have enough fee for your mempool. I know that. But look, I got another transaction. Please consider them both.

Sjors Provoost Yeah, and a nice thing…

Aaron van Wirdum That's what we're trying to accomplish here.

Sjors Provoost Yeah, and if you can do that, then... One benefit is that when you open a Lightning channel, you can use a very low fee by default because you know you can just add whatever fees are needed later. And you don't have to think about the absolute worst case inscription-type mempool situation. Yeah, just assume an easy mempool. So it would be nice if this was possible, but currently it isn't.

Aaron van Wirdum Yeah, I'll repeat this one more time to make it very simple, hopefully, in case there's still someone out there doesn't understand. So when it comes to including transactions into blocks, transactions are potentially considered... in combinations. Like if one transaction spends from another, then the fees are sort of added up and a miner will figure, okay, if I include them all, then I get enough fees.

Sjors Provoost Yeah, and the miner has an incentive to do that, of course.

Aaron van Wirdum Yeah, so the goal is to accomplish a similar logic for the mempool. So nodes will also see, okay, we're going to consider these transactions as a combination of transactions rather than each individually. Okay, so that's what we're trying to achieve here. You know, I'm saying we... that's what Bitcoin Core developers are trying to achieve.

Sjors Provoost Yeah, some Bitcoin Core developers, not me per se, but I try to understand what they're doing.

Aaron van Wirdum Right, and now in Bitcoin Core 28, there's been some actual good progress on this goal.

Sjors Provoost Yeah, we've got four buzzwords basically, and we'll try to explain them.

Aaron van Wirdum So the first one you wrote down is one parent, one child packages.

Sjors Provoost Yes.

Aaron van Wirdum Yeah, go on.

Sjors Provoost Yeah, so the most simple example, which is the example you gave, is you have one parent, for example, this Lightning close thing, and one child, which is your fee bump. And that is a special case of a package, the simplest possible package. So basically support has been added to Bitcoin Core to handle that very specific case using, under the hood, something called the orphanage. As far as I understand it.

Aaron van Wirdum So there is actually a part of the Bitcoin Core code that is called the orphanage.

Sjors Provoost Yes. And remember when Roger Ver said that Bitcoin Core kills babies? Well, it turns out Bitcoin Core kills a lot of them because the orphanage doesn't really work.

Aaron van Wirdum It was actually true. Okay. So what is the orphanage and how does it work? How does it not work?

Sjors Provoost I'm a little vague on this, so if you really, truly, deeply want to understand this, you should look at everything Gloria Zhao has been writing on various mailing lists and other places,

Aaron van Wirdum which explains in more detail.

Sjors Provoost But roughly the idea is this. So you and I are exchanging transactions. You want to close your channel. You want to send me those transactions, right? And so the first thing you do is you tell me, hey, I have some new transactions. Namely, and then you don't give me the full transaction. You just give me some identifier of them. So you give me a list and I look at that list and I say, well, okay, send them to me. So then you're sending me the full transactions. But... And so this would be the Lightning close transaction that you want to send me and the child that you want to send me. However, before we did any of that, I told you, like, I'm not interested in transactions that are paying a very low fee. And so the Lightning action transaction, let's say, is below that level, but your child is above it.

Aaron van Wirdum So you're, for example, saying, I only want transactions that at least pay three sats per byte.

Sjors Provoost And so you being very nice, you don't send me the... The thing that you actually want to include, you just sent me the child. And that child then goes into the orphanage, into my orphanage, because I recognize that this transaction looks interesting, seems to pay a lot of fees, but I don't know the parent. So then a while later, probably a fraction of a second later, I ask you... could you please give me this parent? And you say, sure. You didn't send it before because the fee rate, but now because I'm asking you, if I'm asking you, you're going to send it to me regardless. And so I look at it and say, well, this doesn't pay enough fees and I just throw it away.

Aaron van Wirdum Sure.

Sjors Provoost And then later on, the child is also thrown out of the orphanage. That's how it used to work.

Aaron van Wirdum That's rough.

Sjors Provoost You know, life on the blockchain is rough and life in the mempool is even rougher.

Aaron van Wirdum Oh my god. So you request the parent of that poor child and I send you the parent and you still throw them both away?

Sjors Provoost Yes.

Aaron van Wirdum Do you at least throw them away together?

Sjors Provoost No, probably separately. So anyway, so that is, as far as I understand, really the thing that is being fixed. So you could say it's a bit of a hack. It doesn't really scale towards more complicated groups of transactions. But this one child, one parent use case is very useful already, for the example we just discussed. So I believe the main thing that this release changes is that... And when you're sending this parent, this time it will look at it and say, oh, look at that. If I combine this parent with this child that I have here in the orphanage, it does pay enough. Let me accept that and let me forward it to peers the same way, who then repeat the same process, if they're all upgraded. So as long as there is a bunch of upgraded nodes between you and the miner, they will finally get both of them.

Aaron van Wirdum This is a very wholesome upgrade then.

Sjors Provoost Yes.

Aaron van Wirdum I'm very happy with this one.

Sjors Provoost But it is also a bit of a duct tape solution.

Aaron van Wirdum Why?

Sjors Provoost Well, the orphanage is not really designed to handle the generic case of thousands of packages, etc. And you can quite easily overwhelm it. So if you send, let's say, instead of...

Aaron van Wirdum It's a small orphanage.

Sjors Provoost It's a very small orphanage. So if you're sending a thousand children, then the orphanage is going to throw away all but the last five. Right, so

Aaron van Wirdum it's a hard knock life.

Sjors Provoost It's a hard life on the mempool, even harder than on the blockchain.

Aaron van Wirdum So basically what you're saying is the adversarial you know person in the Bitcoin network can intentionally create all kinds of transactions that don't even have a parent or a child.

Sjors Provoost Well, they might have it, but you're just, yeah, you're never going to ask for it because there's too many orphans at the same time. Stuff like that. So, as far as I understand it, there needs to be a better mechanism to really deal with this problem of one parent, one child, and multiple parents, multiple children. But this, you know... Hopefully it's good enough that under most circumstances you will get your Lightning close transactions to a miner.

Aaron van Wirdum But there might be a better solution. Tomorrow. Tomorrow.

Sjors Provoost I don't know.

Aaron van Wirdum I'm making Annie references, Sjors.

Sjors Provoost Okay.

Aaron van Wirdum Orphanage. Never mind. We're moving on to the next point. There are V3 transactions.

Sjors Provoost Yeah, and so...

Aaron van Wirdum Version three transactions.

Sjors Provoost Yeah, and so that's just a field in the transaction that says number three, where it currently usually says number two. So you may wonder...

Aaron van Wirdum So the transactions are the same, now they just are version three. Okay, what does it mean?

Sjors Provoost Yeah, and that doesn't apply to all transactions, it applies to special transactions that care about the following. TRUC. And so... TRUC stands for, was it again, topologically constrained until confirmation. Topologically constrained until confirmation. So in other words, there are topologies, so how transactions relate to each other. There are rules for that in the mempool, not in the blockchain. So it's until confirmation. And you may wonder what rules? Well, roughly, it needs to be a one child, one parent pair. Exactly that special case that we just talked about. And then the other rule, I believe, is that the child cannot be more than 10 kilobytes or 10 kilo-vbytes. And this just means that if you opt into this version number, there are a lot of shenanigans that somebody trying to keep you out of the mempool or keep you from bumping the fees, etc., because we didn't really talk about that scenario, can be prevented. So it's not really interesting to the scenario you started with, which is you're not in the mempool, you want to be in the mempool. But it's the more complicated thing called pinning attacks that we would need a Lightning expert to completely explain. But it comes down to like you are in the mempool, but you want to be higher in the mempool. Because if you stay at the bottom of the mempool, then you'll just never get confirmed. And that's not good because there might be a deadline for your Lightning transaction that you want to close it.

Aaron van Wirdum Hang on. So, okay, I'm sending a transaction, right? So then I decide if that's going to be a V2 or V3 or V1 transaction. It can be whatever I want. But if I make it a V3 transaction, then it cannot have any grandchildren, you know, it cannot have any children of children in the mempool.

Sjors Provoost Exactly.

Aaron van Wirdum It can only have grandkids when it is included in the blockchain.

Sjors Provoost That's right.

Aaron van Wirdum And there is a benefit to this, which has something to do with pinning attacks and Lightning, which I don't understand. You also can't quite explain.

Sjors Provoost No, exactly. But generally in Lightning, you are coordinating a transaction together with somebody else. And so that transaction, you may want to have it in the mempool because the situation is to your benefit to get it included, or they might want it in the mempool because it's in their benefit to get it in the mempool. And you may have a conflict there where the other side may want to stop you from getting it into the mempool. And you can do all sorts of shenanigans where you attach lots and lots of small transactions or very large transactions with too low fees to this Lightning close transaction so that it doesn't get into the mempool or it doesn't get high enough into the mempool and you can't bump it anymore because the RBF rules are complicated. And so all that goes away with V3 because there can only be one child. And, you know, you may still have to race for paying higher fees, but it's somewhat limited.

Aaron van Wirdum It's a bit, of course, one child policy.

Sjors Provoost Yes. I'm sure that will make people happy.

Aaron van Wirdum The connotations here are less than optimal, Sjors, but I will remind the listener it's an opt-in thing. You don't have to. You can have as many childs as you want.

Sjors Provoost Yeah, exactly. You don't have to use those V3 transactions.

Aaron van Wirdum Okay. So that's a new thing. I don't quite understand the ban. Well, I kind of... Let's just move to the next thing.

Sjors Provoost It removes all the stuff that we don't understand.

Aaron van Wirdum Right. Got it.

Sjors Provoost So we don't have to explain how pinning works because it's less of a problem.

Aaron van Wirdum Got it. And then there's one... Okay. There's one more thing to the whole mempool upgrade.

Sjors Provoost Yes. The last buzzword.

Aaron van Wirdum Yes. And then we'll... then we're done with the mempool upgrades so we had the one parent one child packages kind of with orphanages and then we were just discussing the version three one child only policy and now… and that's called the the TRUC what TRUC stands for?

Sjors Provoost Topologically restrained. Sorry. Yeah, I think topologically restricted until confirmation.

Aaron van Wirdum Okay. Yes, you can only have grandchilds when you're in the blockchain as a transaction. Being a transaction. Anyways. Okay. And then there's something called P2A.

Sjors Provoost Yes.

Aaron van Wirdum What is P2A?

Sjors Provoost Pay to anchor. And so we talked about this situation where you want to make a child to pay for the parent. Now, the question is, what does that child look like? It can be anything. It doesn't really matter as long as it pays a lot of fees. But you want it to be small because you don't have to pay just the fees for your parent. You also have to pay your own fees. So you want the child to be as small as possible. And pay to anchor is like a new standardness rule that lets you make a very, very small transaction to do just that. And the funny thing about it is that on the blockchain, the address will look like something like 1 fees or BC1P fees. And that's done with a special, very small script that just happens to represent the word fees. But it's really just a way to make it easier to make these children. It doesn't have any special meaning otherwise. But the change is that these are now standard, so they will actually get relayed.

Aaron van Wirdum Okay, so it was already possible according to the consensus rules to create this, but so far Bitcoin Core wouldn't relay them.

Sjors Provoost Yeah, and if I understand correctly, it wouldn't relay spending them. So you could send money to that address, but you couldn't spend from it.

Aaron van Wirdum Okay, so this is specifically intended to also benefit these other things we just discussed with the orphanage and the one-child policy, etc.

Sjors Provoost Yeah, because the child is now spending from that address, essentially. And you can do that, or anybody else can do it, too. So maybe you want to outsource it to Watchtower or something like that.

Aaron van Wirdum Long story short, now with Bitcoin Core 28, mempool policy has improved to the point where it makes Lightning a bit more... Usable, reliable.

Sjors Provoost When they start using it, and that might be another year.

Aaron van Wirdum Of course, right. At least Bitcoin Core has now facilitated Lightning to become more usable, cheaper.

Sjors Provoost Yeah, hopefully.

Aaron van Wirdum That sort of stuff. Okay.

Sjors Provoost And I mean, when we say Lightning, we mean anything that has the same concerns as Lightning.

Aaron van Wirdum Right, yeah. A lot of Layer 2 protocols actually have these kinds of issues, of course. Okay, we're just discussing... relay policy with the anchor stuff. Speaking of relay policy, Bitcoin Core, so next topic, we're done with the mempool stuff.

Sjors Provoost Here's more mempool stuff.

Aaron van Wirdum Here's more mempool stuff for you. Full RBF is now the default.

Sjors Provoost Yeah, so we've done multiple episodes about full RBF. If you look for the term in our show notes or in our history, you will find it.

Aaron van Wirdum Replaced by fee.

Sjors Provoost Yes, well, full RBF. You know says, like it's fully replacing but anyway, it doesn't really matter, it it the only thing it does is it turns the flag off, so or it ignores the flag, so it used to be that you had something called opt-in RBF where you would signal that your transaction could be replaced and if you didn't signal that then nodes if they were nice would not replace it if they were not nice they would replace it so unconfirmed transactions were always safe, unsafe for that reason because it's just a mempool rule so um, but… Then this new setting came in that lets your node basically ignore this flag and say, I'm going to just anything that pays a higher fee and meets all these other conditions will get relayed now. You don't need the flag anymore.

Aaron van Wirdum There was a setting in Bitcoin Core.

Sjors Provoost Yeah, that was off by default because it was a new thing. But now it turns out that most miners appear to be also using that. And so when miners are using a certain mempool policy, it is better for full nodes to also use that policy so that... their mempool reflects the next block accurately. And this helps with things like compact block relay, where you relay not the whole block to your peers when you see it, but you relay a very short summary. And that short summary relies on the fact that the person you're sending it to has the same mempool as you do. And so we'll recognize. You don't need to send all the transactions to your peers. You just send the header and a few other details. That doesn't work. And that started to, you could measure that it was working less well. So basically block relay was getting slower because too many people were using full RBF, but too many people were not. And now hopefully it'll speed up again because everybody will be using full RBF or most people.

Aaron van Wirdum Right. Yeah, I mean, this has obviously been a pretty controversial topic for over 10 years now. RBF in itself, some people would argue that it makes unconfirmed transactions less reliable, whereas previously they were still pretty reliable. If you got a transaction, even if it was unconfirmed, you would probably just receive it. And now that's been... You know, it's a lot less obvious now that it won't get replaced by a completely different transaction.

Sjors Provoost I'm not sure if it matters that much in practice. You'd have to ask merchants who still use it. There's not that many of them. They probably use all sorts of other risk scoring techniques that are completely unrelated to the use of this flag, but this flag would make it more difficult to perform the attack.

Aaron van Wirdum Yeah. Well, anyways, we've discussed RBF at length in different episodes, so let's just keep it at that. In any case, Bitcoin Core 28 now has full RBF on by default.

Sjors Provoost Yeah, and then for later on, we need to figure out, do we want to get rid of this flag? Do we deprecate BIP 125 or that part of it? Because that's the privacy…

Aaron van Wirdum The flag seems pretty useless now, right?

Sjors Provoost It's useless, yes, but if Bitcoin Core turns it off... But everybody else doesn't. Now you know which wallets are using Bitcoin Core. So there's still the question of what to do with the flag. And maybe we should just say, like, it should just be there. That just doesn't mean anything anymore.

Aaron van Wirdum I don't know. I say remove it. Get rid of it. Just a full RBF is the new reality. Okay. AssumeUTXO is available on Mainnet.

Sjors Provoost Yes. We talked about AssumeUTXO in episode number 14 in 2020. And it's ready. Well, you still need some command line magic, but you can basically, how you use it is you download a torrent.

Aaron van Wirdum What is it? What are we talking about?

Sjors Provoost That's what I'm explaining.

Aaron van Wirdum Okay, remind our listener. Oh, you are explaining it? Okay, good, good, good.

Sjors Provoost So you download a torrent, about 10 gigabytes, which represents the UTXO set during the halving block. So it represents who owns what coin. who owned what coin at block 8,400, sorry, 840,000. Then your node loads that snapshot and it checks it based on the hash that the developers put in. It doesn't trust it, it just assumes it, hence it's called AssumeUTXO. Then it goes to the tip, which is quick because it's only six months worth of blocks.

Aaron van Wirdum From now, yeah.

Sjors Provoost And from that point on, you can use your node pretty much normally. You can create a wallet, you can receive coins, you can send coins, you have a mempool, all that stuff works. Meanwhile, in the background, it starts at the Genesis block, goes all the way to block 840,000, makes sure that the UTXO set from Genesis actually matches what you assumed. And the moment it confirms that, it's happy. And if not, it crashes.

Aaron van Wirdum Right. So for a limited amount of time, you are kind of trusting the developers.

Sjors Provoost Yes.

Aaron van Wirdum You know, potentially the developers could have... I mean, you attribute coins to themselves that weren't really theirs, to name an extreme example.

Sjors Provoost Yeah.

Aaron van Wirdum But your node is still, you know, it's a temporary thing. It's like, okay, it's a stopgap until the node is really fully synced.

Sjors Provoost And the other thing is, any kind of fraud would be trivial to detect, right? Because anybody can take their own node, make this snapshot themselves, compare the hash, and look at the code and say, hey, the hash in the code does not actually match what I found, so... It's not just new people using it that would be surprised by this. Everybody would be saying, hey, why is Bitcoin Core putting an invalid snapshot in the source code? But it does actually check against this assumption. So you cannot get a snapshot from a random...

Aaron van Wirdum Why is all my money gone? Why is Sjors so rich all of a sudden?

Sjors Provoost Something like that, yeah. So it's not the case that you can just download a snapshot from a random person on the internet and they could pull that thing on you because Bitcoin Core is expecting a specific one. But maybe in the future that might change. It depends on what people want and what risks you're worried about.

Aaron van Wirdum Right.

Sjors Provoost But you still have to do, like, you have to find the torrent, you have to download it, you have to enter a command. So the next steps would be to make that process easier.

Aaron van Wirdum Right. Okay, so that's included in Bitcoin Core 28 as well?

Sjors Provoost Yep.

Aaron van Wirdum Next point, it's now easier to migrate your wallet from your legacy wallet to the new descriptor wallet format?

Sjors Provoost Yeah, so basically a couple of years ago already, the Bitcoin Core wallet was changed in two important ways. One is it uses a more modern way to organize keys using descriptors. We probably talked about that a little bit along with Miniscript.

Aaron van Wirdum We've definitely spoken about this in one of our episodes.

Sjors Provoost Basically, the wallet used to be just a bag of keys and some scripts and some logic to make sure that it's presenting sane addresses. And this has been made much more elegant in a way that's also easier to import your wallet, export your wallet, that sort of stuff. The other thing that changed is the database backend, which is a bit boring, but we used to have wallets. The wallet used to use Berkeley DB, which is a very, very old piece of software that we use a 10-year-old version of from like 2014 or even older, I think, maybe 2010. And the new modern wallets use SQLite 3, which is a modern database thing. And so those two things were combined. So it's the nicer organized scripts and the more modern database backend. And now the goal is to get rid of that old database backend. But of course, you know, there's a lot of money in these old wallets, so we don't want people to lose anything. And so there's a migration tool that has already been there for a while, but you need the command line, and I believe now you can do it from the GUI. And this tool is going to get more and more insistent that you use it, because the goal is to get rid of the old database format. But there is a way that we can still read those old wallets. So we will get rid of the software dependency, but there will still be code in Bitcoin Core that can read the old wallet and then upgrade it, but you cannot use it anymore.

Aaron van Wirdum So let's say I have a Bitcoin Core wallet that's still a legacy wallet. What's the incentive for me to upgrade? What's the benefit for me, if any?

Sjors Provoost Sanity. But in the future, you don't have a choice.

Aaron van Wirdum Okay.

Sjors Provoost It will basically say like, hey, you need to upgrade this wallet, otherwise you can't use it. You keep a backup of the old thing. So if there is a problem, please file a bug report.

Aaron van Wirdum Right.

Sjors Provoost But yeah.

Aaron van Wirdum Okay, so that's now a bit upgrading or migrating, I should say, is now a bit easier.

Sjors Provoost Yeah.

Aaron van Wirdum You can actually see what you're doing if you're not a developer.

Sjors Provoost I think it's just press a button, yeah.

Aaron van Wirdum Yeah, I like buttons. Final point, last point of this episode. Sure.

Sjors Provoost Yeah, there's plenty more in the release, but this is what we're going to cover.

Aaron van Wirdum Yeah.

Sjors Provoost This is the most exciting feature, I think, of the release.

Aaron van Wirdum Is that sarcasm?

Sjors Provoost Yes.

Aaron van Wirdum Block files are, no, I'm not sure how to pronounce this. XOR?

Sjors Provoost Yeah.

Aaron van Wirdum Yeah, block file XOR. What is a block file XOR?

Sjors Provoost Well, the goal is, the problem here is that there are virus scanners out there and they, historically already, they would look at your mempool and they would look at your blocks. And then if something was, especially back then in the mempool, that looked like a virus, like a transaction that just has, you know, an OP_RETURN, which doesn't do anything, but the OP_RETURN is followed by a well-known worm or a well-known virus, then the virus scanner... doesn't know that it's just an OP_RETURN and doesn't do anything. It just sees the pattern of the virus. It puts your whole Bitcoin Core node into quarantine. Or worse, it puts some files in quarantine, breaking the node, basically.

Aaron van Wirdum We did discuss this at some point in some context.

Sjors Provoost Yeah, I think so too. And from what I remember is it was first added to the mempool, the solution that we're about to discuss. And that same solution is now also applied to the blockchain files on your disk.

Aaron van Wirdum Right. Okay. So the problem indeed is, so you're storing all kinds of data in your mempool, in your blockchain, and this data can also be generated, well, is usually generated by other people on the internet.

Sjors Provoost Yeah.

Aaron van Wirdum And it can be generated in such a way, like you said, people can just put data in an OP_RETURN, for example, that just looks a lot like a virus. And then your virus scanner will say, hey, that doesn't look good to me. I'm just going to lock this entire program over here, which in that case is Bitcoin, so you can't use Bitcoin anymore. So there was a solution for this for the mempool already. I'm pretty sure we discussed that. And now the same solution has been applied to the blockchain itself. So what's the solution?

Sjors Provoost Yeah, the solution is called XOR, which basically... It scrambles it, obviously, but it scrambles it in a symmetrical way. So you use one key

Aaron van Wirdum from the blockchain in this case.

Sjors Provoost Yeah, on disk. It uses a key, a very simple key, and it just encrypts everything with that key. And with the same key, it can decrypt it. And this operation is extremely fast on most computers. So it can be done easily. It's not meant to be a secure form of encryption. Like any five-year-old can decrypt it because the encryption key is literally... stored next to it. So it's like, here's the encryption key. Like, please go decrypt it. It's just enough to trick the virus scanner.

Aaron van Wirdum Right, just to hide it from the virus scanner.

Sjors Provoost Yeah, and so if the virus scanner tries to be really smart and says, well, I think that's the decryption key. Let me decrypt it and then it's game over. But hopefully, because viruses, of course, use this trick too to hide some of their own code. So they might start with some code that is just enough to extract the real code. And so virus scanners will look at code that, you know, decrypt bad code, etc. So hopefully this won't be a cat and mouse game, but there it is.

Aaron van Wirdum Okay. Okay. Well, that covers it. Well, as we mentioned, there's, of course, a whole bunch of new, you know, upgrades, maintenance, all kinds of stuff happening with Bitcoin Core. But these were some of the most notable changes in Bitcoin Core 28.

Sjors Provoost That's right.

Aaron van Wirdum Where can people find Bitcoin Core 28?

Sjors Provoost Bitcoincore.org.

Aaron van Wirdum Great.

Sjors Provoost Or they can go on Nostr and follow me or Wladimir van der Laan, who, you know, the former lead maintainer. And there you can actually get a torrent directly that doesn't even take you to GitHub. But you should just probably just go to BitcoinCore.org.

Aaron van Wirdum Sounds good.

Sjors Provoost Yep. All right, then. Thank you for listening to Bitcoin,

Aaron van Wirdum Explained.