Episode 24: Bitcoin Core 0.21.0

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Episode 24.

Sjors Provoost That's right.

Aaron van Wirdum And in episode 24, Sjors, we're going to discuss Bitcoin Core 21.

Sjors Provoost Hooray! Well, 0.21. We're still in the age of the 0.0 releases.

Aaron van Wirdum Yes, which is ending now.

Sjors Provoost Probably, yes.

Aaron van Wirdum That's what I understand. The next one, the 22 will actually be Bitcoin Core 22.

Sjors Provoost That's what it says in the master branch right now. But until there's a release, somebody could come out and change it back.

Aaron van Wirdum All right, well, anyways. I guess it's going to be, yeah, 22 will be the next version. Yeah, so this one is still called Bitcoin Core 0.21. And it was released... when was it exactly a week ago when we're recording no less than a week ago anyways last week and we're gonna discuss this new release and the new features in this new release

Sjors Provoost yeah there's some very cool features in there

Aaron van Wirdum it's a big release there's a lot of new stuff in here

Sjors Provoost yeah and we're gonna refer back to some earlier episodes where we talk about either the specific feature or at least sort of the general area that this feature touches

Aaron van Wirdum yeah we already discussed some of it So what we're going to do for this episode is we're just going to take the release notes and kind of discuss each new feature, each notable new feature point by point for the most interesting ones.

Sjors Provoost That's right. And in the show notes, you can find the full release notes, which are very long.

Aaron van Wirdum Let's start. Are you ready?

Sjors Provoost I'm ready.

Aaron van Wirdum Let's go. So first points.

Sjors Provoost Yeah. So the first change, the mempool, right? It used to be that when you have a Bitcoin Core wallet, you would be broadcasting transactions from your wallet. And then after 15 seconds or so, you would be broadcasting transactions from the wallet. And you would just keep broadcasting it to your peers nearby.

Aaron van Wirdum Isn't it 15 minutes?

Sjors Provoost Yeah, 15 minutes. Yeah. So it would very frequently broadcast its own transactions because the wallet really wants to make sure that the rest of the world hears about its transactions. The problem with that...

Aaron van Wirdum Until it's included in a block, of course.

Sjors Provoost Exactly. The problem with that is it's not very good for privacy. Because if you can pinpoint which node is constantly repeating a transaction, then that suggests that that's the node that created it.

Aaron van Wirdum Yeah, it makes it very obvious which addresses, which inputs... originate from which node which is bad for privacy because a node can be tied to an IP address and an IP address to an identity and so forth.

Sjors Provoost Exactly. So the long-term goal here, which has not been achieved in this specific change, but we always do little micro steps, the long-term goal is to get to a place where the node will just treat its own transactions, its own wallet transactions, just like it would transactions from another peer. So it will not prioritize its own transactions. And there's some downside to that because you have to keep your wallet open probably a little bit longer. to make sure that it does get broadcast. But yeah, then it would be indistinguishable. So I think one of the long-term goals is to say, we're going to wait until the wallet transaction fee is close to what it would be for the next block, right? Because you can order transactions by fee.

Aaron van Wirdum Yeah, I think what you're trying to say is that right now, this rebroadcasting is done blindly, while in the future, the plan is to actually see if the transaction should have been included in a block by now. based on the fees. And only if that's not the case, will it rebroadcast the transaction. And it will do so for any transaction the node has seen, not just for its own transactions.

Sjors Provoost Exactly. And this also creates a better separation between, because the Bitcoin Core is a node, which has a mempool, and it's a wallet. And this dealing with mempools should be done by the node. and it shouldn't be done by the wallet. So there's a lot of process separation going on under the hood there.

Aaron van Wirdum Yeah, but this, what we're describing right now, is actually not included in Bitcoin Core 21 right now. We've seen one microstep towards this in Bitcoin Core 21.

Sjors Provoost Yeah.

Aaron van Wirdum So what is this microstep?

Sjors Provoost If I understand correctly, the microstep is that it's going to broadcast it once a day instead of every 15 minutes.

Aaron van Wirdum I think that's right. It just does it less often. there's a bigger chance it will have been included in a block by then, which means it's never going to rebroadcast.

Sjors Provoost And you need to spy on a node a lot longer.

Aaron van Wirdum Yeah, exactly. So it's a benefit for privacy.

Sjors Provoost Yeah, I would say so.

Aaron van Wirdum And it's a small step towards a bigger plan. Yeah. Okay, next one. Tor version 3 support. Oh, we should mention, as far as the mempool stuff, we've discussed this in episode 19 in more detail. For listeners who want to go back a couple of episodes and hear more about this.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, next point is Tor version 3 support.

Sjors Provoost Yeah, which we talked about in episode 13.

Aaron van Wirdum Correct.

Sjors Provoost In quite a bit of detail.

Aaron van Wirdum Yeah.

Sjors Provoost So the quick version is Tor, you know, has been improved as a version 3. Bitcoin Core now uses that.

Aaron van Wirdum That's the very short version.

Sjors Provoost Yes.

Aaron van Wirdum And I think that's good enough for now. So yeah, episode 13 for anyone who wants to hear more.

Sjors Provoost Right, because this also includes a new way to gossip addresses. So that's actually a bigger change.

Aaron van Wirdum Yeah. I mean, the important thing is that I think a year from now, if I'm recalling correctly, if you want to use Tor... in a year from now, you actually do need to have this version 3 support, right?

Sjors Provoost That's also my understanding, yeah. Because Tor is still centralized. So there's somebody in charge who can say, okay, next year you can no longer use version 2.

Aaron van Wirdum Right. So now Bitcoin Core supports version 3, which means it's compatible with Tor even a year from now.

Sjors Provoost That's right.

Aaron van Wirdum Okay, point 3.

Sjors Provoost Anchors. It's a new file, but more importantly, we talked in episodes 17 and 18 about eclipse attacks, how a node can be sort of isolated from the rest of the network. And one of the countermeasures that we talked about back then is that when the node restarts, it should remember at least some of the nodes it was previously connected to. And that's what these anchor connections are. So before your node shuts down, it saves, or I guess it regularly saves, two of the nodes that it's connected to currently, namely nodes that it's only exchanging blocks with, so very low bandwidth. And then when it starts up, it's going to read that file and it's going to connect to them again. And we explain a lot more about that in those episodes.

Aaron van Wirdum Yeah, I think especially episode 17. Yeah, but both 17 and 18, I think most of it, most of this specific change was in episode 17. So anyway, so this was included in Bitcoin Core 21 as well. So Eclipse attacks are now harder to pull off against Bitcoin Core 21 nodes.

Sjors Provoost Yes.

Aaron van Wirdum Nice. All right. Next point.

Sjors Provoost The next point is BIP-157. also known as neutrino filters. We have not talked about that yet, so we can briefly explain it. There are lots of mobile wallets out there, especially for Lightning, that don't want to download the entire blockchain.

Aaron van Wirdum Yeah, or just light wallets in general. They don't have to be mobile, just something that doesn't download and verify the entire blockchain.

Sjors Provoost Yeah, though I think the number of excuses you have to run a light wallet outside of a mobile situation are...

Aaron van Wirdum I mean, a lot of people don't feel like waiting for two days for the whole thing to sync.

Sjors Provoost Yeah, that's true, for the initial experience. I mean,

Aaron van Wirdum it's a bad idea or definitely not preferable, but that would be the reason.

Sjors Provoost Yeah. So what these filters do is instead of downloading every block, you download these filters, which are much smaller than a block, and then you can take your own list of addresses and run your own list of addresses against that filter. and the filter will tell you whether or not there's something in the block. pertaining to your addresses.

Aaron van Wirdum Yeah, or at least possibly.

Sjors Provoost Yeah, there can be some false positives. So you might get a list of 1,000 blocks that you need to download, and maybe of those 1,000 blocks, only 100 actually contain your transactions. But that's better than downloading all 666,666 plus blocks.

Aaron van Wirdum Yes. Yeah, we made that milestone this week.

Sjors Provoost Yeah, exactly.

Aaron van Wirdum That's why you remember the exact number.

Sjors Provoost Precisely. It's very hard to remember. There are lots of trade-offs when it comes to these filters, so I think we should go into that for another episode. It's not enforced by consensus, so you're kind of trusting that the list is real. Although, you know, if you, let's say the list gives you a bunch of nonsense results and you start downloading those blocks and you don't see what you're expecting, well then you know that whoever gave you those filters was lying to you, but it gets a little complicated. So we'll talk about that some other time. But it's there, and it was already used in the wild a lot, especially by the mobile Lightning wallets. So, so far there was only specialized nodes that would serve that, usually running BTCD. And now every Bitcoin Core wallet can do it if you turn it on.

Aaron van Wirdum Right, yeah. So just to be clear, the thing that's new in this Bitcoin Core 21 release, I'm just going to call it Bitcoin Core 21, not Bitcoin Core 0.21. Anyways, what's new here is that I think previous Bitcoin Core release could already create the filter. And now in this Bitcoin Core release, it can share it over, I guess, the peer-to-peer network, right?

Sjors Provoost That's correct, yes.

Aaron van Wirdum That's what's new.

Sjors Provoost Yeah, the filter has been... around there so as usual you know you have this filter but you can't really use it and now you can use it next one

Aaron van Wirdum yeah so we'll we'll get back to this in another episode i think this is the short version of it next point Signet

Sjors Provoost Signet which we discussed in episode 10

Aaron van Wirdum correct

Sjors Provoost in great detail but the very short version is it is like testnet but heavily centralized and everybody can make their own if you want to and it's awesome

Aaron van Wirdum yeah what it does is it it creates a bitcoin blockchain in a way just like testnet is just sort of a copy of the bitcoin blockchain same rules and same things apply it's just it's just there for developers to test new stuff on to test new you know software on without the risk of losing coins if there are bugs and these kinds of things the problem with the testnet is that because it's so similar to the bitcoin blockchain it it depends on hash power but without any economic incentives to actually keep the [unclear] secure or stable in any way the testnet can be very insecure or no not insecure. Well, insecure and more importantly unstable

Sjors Provoost yeah unstable especially because there might not be any blocks and then After 20 minutes, there's like lots of blocks.

Aaron van Wirdum Yeah.

Sjors Provoost It's just a mess. You can have very large reorgs. It's not fun to develop against it. And although when you develop software, you should make it very robust, you have to deal with edge cases that really make no sense on the real Bitcoin network. So you're kind of wasting your time.

Aaron van Wirdum Right. So yeah, Signet is like a testnet, except that... Bitcoin blocks need a valid signature from whoever is running the signet. And that person is making sure that the test network is somewhat stable. So it's completely insecure. This is not how you want to design actual Bitcoin because it depends on the trusted third party. But because it's just for testing anyways, it's fine.

Sjors Provoost Yeah. And although there's just two people who can sign it. That doesn't really matter because everybody can make their own Signet with their own rules. And you can have a 15 out of 15 multisig or you can make it, everybody can sign it. It's probably a bad idea. But, you know, the centralization part is solved by just having as many as you want and it's worth nothing.

Aaron van Wirdum So this was included in Bitcoin Core 21. What does that mean exactly to have it included in Bitcoin Core 21?

Sjors Provoost Well, it means that you can start Bitcoin Core with the dash Signet. just like you can start it with dash testnet and your icon will have a nice different color. And there's a faucet out there that you can go to and you can get signet coins, which you get by the dozen, I think. So it's nice. Yeah, you can use it. And we'll go back to it again in the, well, I guess we can skip to that item now because it makes sense. Because the other thing that's included is taproot.

Aaron van Wirdum Right. Yeah. Okay.

Sjors Provoost And Taproot is active on Signet.

Aaron van Wirdum Yeah. So we now have Taproot on Signet.

Sjors Provoost That's right.

Aaron van Wirdum Obviously, this is meaningless for regular users. This is just for developers, just for testing their software.

Sjors Provoost Exactly. The main plan was to have the Taproot code inside of Bitcoin Core, unactivated, but just there so people can find bugs in it and can play with it.

Aaron van Wirdum Which is also the case. It's in there now.

Sjors Provoost Exactly. So it's nice because normally you would have the code of a software in there and you could theoretically play with it, but it's not very clear how you would do that. But now it's very clear because you can use it on Signet. And the nice thing about Signet is that the rules can be changed anytime because there's two miners that can centralize, decide to just enforce different taproot rules if the taproot spec is changed.

Aaron van Wirdum Right.

Sjors Provoost Because it's not final. until it's live.

Aaron van Wirdum Yeah, well, it's kind of final, right? The idea is that from here on out, it shouldn't be changed anymore, I think. That's why it's included in the code in the first place.

Sjors Provoost Yeah, I think you'd see it as a release candidate.

Aaron van Wirdum Right.

Sjors Provoost Because even if Taproot activates on mainnet in the future with a new version of Bitcoin Core, this old version of Bitcoin Core won't do anything with that.

Aaron van Wirdum Right. Yeah.

Sjors Provoost So even if the rules change now, there's no problem with your 0.21 node. It will not get confused if Taproot changes. Of course, hopefully it doesn't.

Aaron van Wirdum Yeah. Sure. But about that, so yeah, the Taproot code is included in Bitcoin Core 21. This also means that probably the next minor version of Bitcoin Core, which would be Bitcoin Core 21.1, well, Bitcoin Core 0.21.1, will have the actual activation logic for Taproot.

Sjors Provoost Hopefully, yeah, if all goes well.

Aaron van Wirdum That's kind of the plan, right?

Sjors Provoost I mean... Yeah, I think that's the tradition. But, you know, there's no centralized management team that decides what the plan is. So it is what may happen. But yeah, let's just say that's the plan. That's the thing with an anarchistic system, right? It's what we did the last time, but nobody can force any of the volunteers and developers to do it again until it's been done.

Aaron van Wirdum Is it time for you to take charge Sjors?

Sjors Provoost No.

Aaron van Wirdum I'm assuming that there will be a minor release, which has Taproot activation in it. It's just going to be my assumption.

Sjors Provoost I'm optimistic, but I have not followed any of the...

Aaron van Wirdum We discussed Taproot activation possibilities in Episode 3, I believe, and Taproot itself in Episode 2, or the other way around.

Sjors Provoost Right, yep. and I have not followed the news since then when it comes to activation, so I guess I'll just see when it activates.

Aaron van Wirdum Yeah, more on that discussion indeed in Episode 3 and Taproot itself in Episode 2. All right, next point.

Sjors Provoost Yeah, so we'll jump back in our little queue to BIP339 Witness Transaction ID Relay, or WTXID. So here's the thing. A long, long time ago, before there was SegWit, transactions had a hash. And this hash represented the entire transaction. But...

Aaron van Wirdum It was a transaction ID.

Sjors Provoost Exactly.

Aaron van Wirdum Yeah.

Sjors Provoost But then we created SegWit. And SegWit added data to the transaction. But the identifiers that we use for transactions are still based on what is in the transaction minus all the SegWit stuff. This is because old nodes don't see the SegWit stuff.

Aaron van Wirdum Yeah, this was kind of why SegWit worked. to solve malleability.

Sjors Provoost Exactly.

Aaron van Wirdum Because previously, a transaction, before SegWit, a transaction had all the transaction details, how many bitcoins are involved, where are they going, plus the signature, and this was all hashed, and this hash was a transaction ID. However, it turned out that slightly different signatures could all be valid. And therefore, a signature could be changed in flight, for example. You send the transaction to the network. Someone on that network slightly changes the signature. The transaction is still valid. But all of a sudden, the transaction ID changed because the hash changed because the signature changed. So to solve that, this was a problem for things like lightning. So to solve this, SegWit separated the transaction details from the signature. the transaction details were still hashed to create the transaction ID, and the signature was put in a separate part of a block, segwit part of the block, and therefore malleability was solved.

Sjors Provoost That's right.

Aaron van Wirdum But this meant that the signature was not part of the transaction ID at all.

Sjors Provoost That's right, and that makes a lot of sense when you, for example, have something like Lightning or any sort of escrow system where you pre-sign a transaction to release coins. You want to make sure that the transactions go in. And so the transaction that releases the coins refers to the transaction that puts the coins in there. So you don't want somebody to be able to change that transaction that goes in. Because then you suddenly don't have a release transaction anymore and your coins are held hostage.

Aaron van Wirdum So what's this change now?

Sjors Provoost So what this change is not about how the consensus works, but it's how transactions are relayed between nodes. So when a node... talks to another node that says, hey, here's a bunch of transaction IDs. Would you like the whole transaction for this thing? And that's still referring to this pre-SegWit transaction hash, also the on-chain transaction hash. But this new change lets you gossip these transactions using the witness transaction ID, which does include the signature, I believe. Now, I don't know why that's useful, to be honest, but because I haven't read up on what exactly the BIP is saying. I'm just saying that... you can now gossip transactions based on including the witness, which I guess could have some benefit.

Aaron van Wirdum Does this have something to do with potentially sharing a transaction with an invalid signature and therefore...

Sjors Provoost That's my theory because I should have read it, but my guess is that indeed you would send another node a transaction hash and they would ask for the transaction and you would give it a fake transaction because you would just add your own signature to it and it would just be nonsense. And then the other node would say, okay, this transaction is dumb. I'm just going to ignore that moving forward. And then another node would give the real one, but this node is now rejecting it because it's already seen it and it thought it was fake. So you want to prevent that.

Aaron van Wirdum Right. And that's what this new change might solve is your speculation, but neither of us is actually sure because we didn't read the BIP.

Sjors Provoost That's right.

Aaron van Wirdum Read the BIP fellows.

Sjors Provoost I also know this was done.

Aaron van Wirdum And it's BIP, which one is it?

Sjors Provoost 339. Yes. I also know this was done before Taproot because it has some sort of utility there too.

Aaron van Wirdum Right.

Sjors Provoost All right, next item.

Aaron van Wirdum Next item is Taproot, which we've already covered. So then the next item is a bunch of RPC changes.

Sjors Provoost That's right. If you look at the release notes, a lot of changes are about the RPC, and we're not going to mention them because they're not that interesting.

Aaron van Wirdum RPC stands for Remote Procedure Call.

Sjors Provoost Yes.

Aaron van Wirdum What does that mean actually, Sjors?

Sjors Provoost It basically means if you're running a Bitcoin node, then you can issue commands to it. And if you're a desktop user, you would just click on buttons. But if you're in the command line, well, you would type Bitcoin client, then some command. But if you are on the network, you probably want to send some JSON to it and get some JSON back from it over the network. And that's what these RPC calls are for. So you can send the commands over the network and get a response back.

Aaron van Wirdum Right.

Sjors Provoost And if you've built some sort of complicated server, you want to make sure nothing breaks. And Bitcoin Core is always very careful. It tries not to make breaking changes in that RPC. So, for example, a situation you might be in is you run a block explorer of some sort and you have one little server machine that has a Bitcoin full node on it. And we'll get to that actually with the ZMQ explanation, but I guess we'll transition to that. So you'll have one node that runs Bitcoin Core on it and another that runs a database and another that runs the website because usually, you know, they try to split all these things up. So the web server might ask the node questions like, what is the current block height? Or, you know, what's in your mempool? That's done via RPC. Or it might say, send a transaction to this person. That's also done via RPC. So that's all scripts and code. So you want to make sure that your code is still doing what you think it's doing when you upgrade the node. But which brings us to the next point, ZeroMQ feature improvement. So you can read in, if you find this interesting, you can read in the release notes exactly what.

Aaron van Wirdum Is that one of the RPC changes?

Sjors Provoost Well, ZeroMQ is not actually RPC, but it's also a way to communicate.

Aaron van Wirdum Okay.

Sjors Provoost So with RPC, you have the Bitcoin node is listening. and you send a command to it and you get a response back. That's how RPC works. But ZeroMQ is push -based. So what you're doing is the Bitcoin node is constantly broadcasting and you can listen to that broadcast through a channel. And so the broadcast could be every new block. So then you're listening to a certain channel and you get the block as soon as the node sees it. Or you can listen to transactions. Or I believe you can even listen to transactions at a certain address. This might be useful if you have a block explorer with a live page where you're looking at an address and then the node sees a new transaction on that address. It sends a message to your ZMQ. to the web server, and the web server sends a WebSocket message to the browser so your browser updates without having to hit the refresh button. Something like that.

Aaron van Wirdum Okay.

Sjors Provoost So that's nice for people who care about that. Next item.

Aaron van Wirdum Okay. Yep.

Sjors Provoost There is a new SendRPC by yours truly, which is cool. Basically, if you want to send coins through the command line, you can do it with the graphical interface, but if the cool kids want to do it with the command line, it's very tedious. When the first version of Bitcoin Core came out, when it wasn't even Bitcoin Core, I think you just had a command called send to address, and you gave it an address and an amount, and that was it. And that's still out there. But the problem is that command got expanded, but it doesn't have all the features you may want. And at the same time, there were commands to create PSBTs that we talked about in an earlier episode.

Aaron van Wirdum Partially signed Bitcoin transactions.

Sjors Provoost Exactly. And those were very powerful. You could do all sorts of cool things to your transaction, including coin selection, for example, through the command line. But it was very tedious because if you want to make a PSBT, then you have to... make it and then sign it and then finalize it and do a bunch of things. So the problem was you had a very simple way to send coins with the very old Satoshi Time RPC methods, just sent to an address, but you couldn't configure it. Or you had a super powerful method that was extremely hard to use. And so the new SendRPC is... easier to use, and powerful.

Aaron van Wirdum And you made this?

Sjors Provoost Yes, and it's been improved since.

Aaron van Wirdum Thank you, Sjors.

Sjors Provoost Hopefully you're welcome. It's marked experimental, so if you...

Aaron van Wirdum I'm not one of the cool kids anyways, I just used GUI.

Sjors Provoost Well, it's especially useful if you're experimenting with newer features like hardware wallet integration and stuff. Then you want to experiment on the command line and then hopefully later do it in the GUI.

Aaron van Wirdum How is that going to take a side path? What's going on with hardware integration, hardware wallet integration?

Sjors Provoost It's very slow. Yeah. So I think I gave a presentation in 2019 or something.

Aaron van Wirdum In London.

Sjors Provoost Yeah, and Andrew Chow has done it as well. Yeah. And I mean, the final picture we thought would be here now, or at least I was hoping for, but it's not. But a lot of things have been done. So part of the hardware wallet project was to get PSBT support. Well, that's pretty much done. Part of it was descriptor wallets, which we'll get to next. So that's been done. And the thing I've been working on as a work in progress is an expansion of this send command in RPC that will let you talk to a hardware wallet. directly from the command line. And the second one is a graphical interface around that.

Aaron van Wirdum Right.

Sjors Provoost And those pull requests exist. They get a little bit of review, but they're not moving forward very quickly. Eventually it might happen.

Aaron van Wirdum But it's still moving.

Sjors Provoost It's still moving. And also there are great other solutions out there. So there's the Specter open source project, which just runs a little web server on your own computer. And then it magically talks to the RPC again with these RPC calls that we talked about. And it creates wallets. And it's very, very nice, very slick. We wouldn't be able to get it that slick.

Aaron van Wirdum Right. But if you can get more support inside of Bitcoin Core, it means fewer software that you need to download from places that you then need to trust.

Sjors Provoost Exactly.

Aaron van Wirdum So there is something to be said for continuing this. All right. Next point.

Sjors Provoost The next point is called experimental descriptor wallets and SQLite support.

Aaron van Wirdum Right.

Sjors Provoost Two things. So descriptor wallets, I don't think we've talked about that.

Aaron van Wirdum I don't think so.

Sjors Provoost So the general idea is that when Bitcoin Core started, it was just a single address type, pay to public key.

Aaron van Wirdum I think we did discuss that.

Sjors Provoost And then there was a new address format, pay to public key hash. And so that was added to the wallet. And then Segwit came along and pay to script hash came along. And now the wallet is just a giant mess of backwards compatible things. Right. Code that nobody understands. And while Andrew Chow has been at work at cleaning that up. And one of the things that was added was the idea of the descriptor wallet. The descriptor is something invented by sipa. And the idea there is that you, well, describe what is in the wallet. So you literally just write out, you start with this master key, and then you take the first derivation, you know, within BIP 42. and you take the second derivation or whatever, and then it's slash star. And then if you write down just those descriptors, you can recover your addresses.

Aaron van Wirdum Yeah, so this could be, for example, you have a bunch of multisig addresses, and these are described as multisig addresses, and then your hardware wallet addresses, and then your playing addresses or whatever. And these are sort of categorized. You can easily categorize your different UTXOs, your different coins.

Sjors Provoost Yeah, so for a hardware wallet, it's a nice example. Usually a hardware wallet will give you an XPUB. You know, if you plug it in, it can spit out an XPUB, and an XPUB is a way to derive multiple addresses. And so a multisig address would be...

Aaron van Wirdum We did discuss that in, I think, one of the first episodes. I don't have a number in front of me. XPUBs.

Sjors Provoost Yeah, could be. And basically... You can say, okay, here's a multisig address consisting of these three XPUBs, and then what you need to do to these XPUBs to get the individual addresses. So you can describe very complicated wallets. And if we add Miniscript support in the future, you can describe even more wildly complicated wallets that way.

Aaron van Wirdum Right. So what's up with SQLite?

Sjors Provoost SQLite is a new database format. So the wallet itself is just a bunch of records, essentially. And right now it's sitting in Berkeley DB version 4, which is a 10-year-old unmaintained piece of software, which, you know, it's 10 years old and unmaintained. So that's a problem. And SQLite is a bit more modern. It's still being maintained. It's very short, so the total code for SQLite is not that large to review. And it is designed to be backwards and forwards compatible in sane ways. So if a new version of SQLite comes out, you have pretty strong guarantees that it's still going to work. And that if you save something in the new wallet, it's also going to work in an old version.

Aaron van Wirdum Yeah, I was just going to ask that. So if you upgrade to Bitcoin Core 21, nothing happens. Nothing interesting happens. Nothing worrisome happens.

Sjors Provoost No, if you already have a wallet, it is not converted to descriptor wallets. It is not converted to SQLite. Nothing happens. There are manual commands that if you like to, you can do that. But we still consider both of these things somewhat experimental. Right. So you probably don't want to do that. But the goal in the future is that new wallets will be descriptor wallets and will be stored using the SQLite database. And then, you know, more far into the future, there'll be an automatic migration tool or like at least some button that says, you know, you probably want to migrate this. And then even further into the future, when you start it up, it'll say, okay, I'm not going to start up. Please migrate the wallet first using this tool or something. And then later on, it's like, please download an older version. I guess there'll always be a conversion tool because, you know, you want to be...

Aaron van Wirdum I like my backwards compatibility. Please keep that for me.

Sjors Provoost Yeah, I guess it depends on how horrendous it is to keep all that old code around. But I guess one thing we might end up doing is write just the code that's necessary to read one of those old Berkeley databases, no longer to be able to write it. So you wouldn't need the whole library. We talked about libraries. We would just need enough to be able to read it. Right. Yeah, but that's years and years probably.

Aaron van Wirdum I think we've made it to our last point.

Sjors Provoost Yes.

Aaron van Wirdum So it's a small one.

Sjors Provoost Yeah. At the RPC level, you can now specify your fee in Satoshi per byte.

Aaron van Wirdum Finally.

Sjors Provoost Yes. It used to be Satoshi per kilobyte. or BTC per kilobyte, some weird unit.

Aaron van Wirdum Something no one else used.

Sjors Provoost Yeah, exactly. Because now all the websites will use Satoshi per byte. And yeah, the annoying thing about the standard that it was using before is if you type one, because you intended one Satoshi per byte, you're actually saying, I don't know, a thousand Satoshi per byte.

Aaron van Wirdum Right.

Sjors Provoost Or some really obscene number that would be very expensive if you don't know what you're doing. Yeah. There is actually protection against that since a few years.

Aaron van Wirdum So that's changed to make it more consistent with the rest of the Bitcoin ecosystem.

Sjors Provoost Yeah. And that's not yet in the graphical interface, but that's typically the next step.

Aaron van Wirdum Right. So yeah, I noticed there were like 140 contributors to this release, something like that.

Sjors Provoost Quite possible.

Aaron van Wirdum Maybe 130, 140, something around that number.

Sjors Provoost Because we talked about the highlights, but if you look at the actual release notes and then at the bottom, there are so many super small changes. That could be an individual contributor that just comes by.

Aaron van Wirdum Yeah, I just wanted to mention thank you to all these 130 or 40 or whatever it was contributors. Thanks to everyone. Thanks to you as well, Sjors.

Sjors Provoost Thank you.

Aaron van Wirdum You're one of them. What else? How do people upgrade? What do people do?

Sjors Provoost Go to BitcoinCore.org and download it and then do all the checks to make sure that you've got the real thing.

Aaron van Wirdum Yeah, like the signature verification stuff and these kind of... Well, I guess that's the main thing.

Sjors Provoost Yes. Yeah, I think that's it.

Aaron van Wirdum Yeah, and nothing else, right? So like we mentioned, this Berkeley DB to SQLite, that's unnecessary. You don't need to redownload blocks or anything like that.

Sjors Provoost Yeah, as a user, you just download the new version and life continues.

Aaron van Wirdum Nice. I like that.

Sjors Provoost All right.

Aaron van Wirdum I like life to continue. All right, then. Thank you for listening to the Van Wirdum Sjorsnado.

Sjors Provoost There you go.