Episode 85: Bitcoin Core 26.0 (And F2Pool’s OFAC Compliant Mining Policy)

Aaron van Wirdum Live from Utrecht, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum Hello, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum Welcome back.

Sjors Provoost Thank you.

Aaron van Wirdum You've been back for... Do you even live in this country still?

Sjors Provoost I certainly do, yes.

Aaron van Wirdum You were gone for like two months?

Sjors Provoost No, one month.

Aaron van Wirdum One month, a couple of conferences. Where did you go?

Sjors Provoost Too many conferences, in fact. Bitcoin Indonesia, Nostrasia in Tokyo.

Aaron van Wirdum Well, but the thing is, before that, you were in the States for a while, you were in Portugal.

Sjors Provoost I was, but I was home for a few weeks in between.

Aaron van Wirdum All right. Well, you were gone for so long that there's a new Bitcoin Core release.

Sjors Provoost That's right.

Aaron van Wirdum Bitcoin Core 26, but... Before we get into, so that's what this episode is going to be about. Sjors, we're going to discuss Bitcoin Core 26.

Sjors Provoost Cool.

Aaron van Wirdum But there's been some recent developments that you suggest that we briefly touch on before we get there.

Sjors Provoost Yeah, I think so. So remember, dear listeners, if you listen to episode 37 back in 2021, we talked about MARA Pool, which at the time was making blocks that they said were OFAC compliant. As far as we know, they did not actually do any filtering. But this triggered a developer, which we will call 0xB10C, to write a tool that monitors the blockchain for said censorship, just in case that would ever happen.

Aaron van Wirdum Yeah, so just to reiterate what this all means. There is an OFAC list, and this means there are entities on there that you're not allowed to transact with, and that's the US government sanctioned list. Is that the right way to think about it?

Sjors Provoost Yes, correct.

Aaron van Wirdum So these would include... people that the US government does not like, essentially.

Sjors Provoost Yes, these are only people that the US government does not like.

Aaron van Wirdum Right, and there are Bitcoin addresses on this list?

Sjors Provoost Yeah, so I think the general idea is that they say, hey, this guy and this guy, you should not do business with them, and this is how you recognize them, and they'll spell out their name in like five different ways, and give maybe some known addresses, and they might also give some known Bitcoin addresses that are associated with this person.

Aaron van Wirdum Right, so there are Bitcoin addresses on this list, and if you want to send Bitcoin to or from these addresses, then, so what Marathon Pool was doing was they would essentially filter these transactions, not include these transactions into a block. That's how they would comply with this list, right?

Sjors Provoost Yeah, but they didn't actually do that. I think they were thinking about doing that. And they put some [unclear] message in the block. But we explained that back in that episode, because as far as I know, they didn't actually do any filtering, but it caused quite a lot of consternations and they backed out of that idea. I think they even replaced their CEO, though that may have been completely unrelated. But anyway, it was enough motivation for him to write this tool. And what this tool does is it basically runs a Bitcoin Core full node and a Bitcoin Core full node will propose a block. Basically, it just every 10 seconds creates what it thinks would be a correct block. It doesn't do the proof of work. It just constructs the block. And then when a real block appears, it compares it. It looks at which transactions are missing that were expected to be in the block and which transactions are not missing. And then for the transactions that are missing, it would run it against a bunch of heuristics of why it might be missing. Usually it's completely innocent. So for example, a block transaction might be very new. Maybe your node has heard about it one second ago. Then it's very likely that other nodes have not heard about it yet. So it's not surprising that it's in a block, that it's not in a block. Something else that tends to happen, especially these days, is that miners will have an accelerator service where they will prioritize transactions that... If you look at their Bitcoin fees, they should not be in the block, but they are in the block because they've paid through credit card or some other way to be included in the block. And so basically some of the tools automatically filter some of these things and other times you basically wrote a blog post about it, doing it manually, just checking out what's going on here.

Aaron van Wirdum Okay, so what is going on here? Why are we discussing this?

Sjors Provoost Well, what seems to be going on here is that there are four transactions by F2Pool. which...

Aaron van Wirdum Transactions by F2Pool?

Sjors Provoost Well, transactions not by F2Pool.

Aaron van Wirdum Transactions not included in a block by F2Pool.

Sjors Provoost Exactly.

Aaron van Wirdum Right.

Sjors Provoost Four of them. And if you look at each four of them, I believe two or three of those, there's not a good explanation of why they're not in a block. Could still be innocuous, but they're not recent transactions. They're not pushed out because other transactions were prioritized. etc. And then the explanation that will remain is that they were filtered because they were on that list.

Aaron van Wirdum So they are on that list.

Sjors Provoost They definitely are on that list. Yeah, that's not the problem.

Aaron van Wirdum Okay, got it. So censorship is upon us.

Sjors Provoost Well, yes, but we didn't know for sure, I guess. We could just do the analysis, but then there was a tweet by, I guess, the person in control of F2Pool. [unclear]? Yes, Who says, uh will disable the TX filtering patch for now until the community reaches a more comprehensive consensus on this topic.

Aaron van Wirdum So, basically there's a confirmation that he was in fact filtering out OFAC transactions in breach of the OFAC list.

Sjors Provoost Yes, or at least some of them because it's not clear if he was filtering all of them… um

Aaron van Wirdum But where does this patch even come from? Like, is this a patch?

Sjors Provoost [unclear].

Aaron van Wirdum Can I download this patch? Okay.

Sjors Provoost No, you'd have to write it yourself. You'd have to do something like, if this transaction arrives...

Aaron van Wirdum Bitcoin Core does not offer this patch?

Sjors Provoost No, but I guess you can write a patch that keeps things from going into your mempool. I don't know if we have a way to get things out of your mempool once it's in there.

Aaron van Wirdum Anyways, so Wang Chun F2Pool was using a patch. Maybe self-written maybe not to filter these blocks out, no, these transactions out of blocks.

Sjors Provoost Yes.

Aaron van Wirdum To comply with the OFAC list. And now he's...

Sjors Provoost Well, we don't know if it was to comply with the OFAC list, but the transactions were on the...

Aaron van Wirdum [unclear] hedging everything so much? It's pretty obvious at this point, right? You did the analysis.

Sjors Provoost No, because there are some unconfirmed tweets that suggest that...

Aaron van Wirdum And he confirms it on Twitter.

Sjors Provoost Yeah, but there are some other unconfirmed screenshots of tweets that suggest that motive may have been slightly different. But in any case, we know that these transactions were deliberately filtered.

Aaron van Wirdum But what's the alternative motivation?

Sjors Provoost Well, it might be that he just doesn't like those particular people.

Aaron van Wirdum He just doesn't like the same people that the US government doesn't like.

Sjors Provoost Yeah, exactly.

Aaron van Wirdum Okay, but then still he's filtering transactions.

Sjors Provoost Yes.

Aaron van Wirdum Like there's still some form of censorship happening, right?

Sjors Provoost Exactly. But there could be two different reasons for censorship, right? One is you're afraid of some government, like the US government, making your life difficult. And the other could be, well, you think the US government is actually right.

Aaron van Wirdum Okay.

Sjors Provoost But we have no idea which of those two is the true motivation. I'm just saying... Either is possible.

Aaron van Wirdum Sure.

Sjors Provoost Either is problematic.

Aaron van Wirdum Are we talking about this because we should be worried about this? Is your opinion that we should be worried about this?

Sjors Provoost I think we talked about that in the earlier episode, that I am worried about this in the long run. Now, in the short run, it's absolutely not a problem because these transactions were just mined by another miner, the next block.

Aaron van Wirdum Yeah.

Sjors Provoost Ironically, by a US miner.

Aaron van Wirdum Yeah. Maybe it's a bit much to go over this whole thing again. Again, we discussed it in episode 37, you said?

Sjors Provoost Yes.

Aaron van Wirdum Yeah so that's what we discuss I guess in depth how worried we are about it. Anyways, um short term. So now it's turned off. I guess the other thing maybe worth mentioning is so this is something that…

Sjors Provoost So the fact that we were able to detect this at all is because you know of all this tooling it's it's not that obvious normally because transactions you know sometimes they appear in a block sometimes they don't. So that's pretty cool that we have the tech to detect it.

Aaron van Wirdum The impact is pretty minor. Another relevant episode perhaps to listen to in this context is the episode we did on Stratum V2 because Stratum V2 is kind of a solution for this problem if we consider it a problem, right?

Sjors Provoost Yeah, what Stratum V2 does that's relevant here is that it delegates the responsibility of putting things into a block, not to the mining pool, which tends to be quite large. You know, there's two pools that are 51% roughly of all the hash power, but it delegates it to individual miners. So, and that's far more of them.

Aaron van Wirdum Yeah, so we discussed that in episode 80. Okay, this was a long intro. I guess the reason this is worth bringing up is because, I mean, it seems... This is kind of the thing that Bitcoin developers and journalists maybe as well sometimes have been like talking about and warning about for many years. And this is sort of the first time it's actually happening. So there's actually a reason now.

Sjors Provoost If you go through, you know, this, if you just assume a slippery slope, which is always a problematic type of argument. But if you do, then the ultimate outcome of this is you're back to PayPal because all transactions have to be KYC'd and permissioned before they go into a block. Now, we're nowhere near that. But does this make sense to worry about this?

Aaron van Wirdum Right. It is sort of a first step in that direction. And it's interesting to see how things will play out, I guess. So the first step we now saw is that Wang Chun disabled his patch. But yeah, it's an event in that sense. Like it's a... beginning of something that could go in a very wrong direction even though it's only a very small step right now right is this are we done with this This was this was the intro to our Bitcoin Core 27— Wait, Where are we? 26 episode. Okay, let's talk about Bitcoin Core 26 then.

Sjors Provoost Yes.

Aaron van Wirdum First of all, I think everyone knows this by now. Actually, I'm not even going to ask you about this anymore. I'll just preface this. So the way it works, Bitcoin Core releases a new version of the software every six months. And that means that every new feature that was done within these six months is in Bitcoin Core. And that means that's a new release. There is not a new release because there is a new feature. There's just a new release and whatever is new is new.

Sjors Provoost That's right. Yes, exactly. So yeah, so there are no like things that must be finished before the deadline uh whatever is ready is ready.

Aaron van Wirdum Right, so the last release was about half a year ago apparently. Right at this point where are we in the release process?

Sjors Provoost There have been two release candidates as far as I know. The second candidate does not have many problems so maybe it's the last one. Maybe there'll be another one… um

Aaron van Wirdum Right, so potentially the new Bitcoin Core release could be announced released any day now.

Sjors Provoost Exactly.

Aaron van Wirdum Okay.

Sjors Provoost Or maybe a few weeks. Um, what's interesting perhaps is that there is a testing guide now every release there is always a testing guide but this one apparently has had some extra love and attention so if you've ever wanted to test a release you should look for the uh I think if you google Bitcoin Core 26 release testing guide you'll find it and hopefully it'll be in our show notes.

Aaron van Wirdum Who is this for? This is for developers, I would assume.

Sjors Provoost I would say a little bit lower barrier to entry than being a developer. Anybody who can download a piece of software and carefully follow up instructions.

Aaron van Wirdum So what are you testing?

Sjors Provoost You're testing things that have changed. So there's all the features that we're talking about, but there's also lots of smaller changes and the testing guide will basically take you through some of the changes and how you might go about testing them. Of course, you should also test things in a way that's not in the guide.

Aaron van Wirdum How would you go about testing them? Like, what what can you give an example of what we're talking about here?

Sjors Provoost Yeah well I guess we can do that when we cover the the actual changes.

Aaron van Wirdum Okay, sure. Do you want to get into the actual changes?

Sjors Provoost Sure.

Aaron van Wirdum Okay, so the actual change so what we did. Well, mostly Sjors to be honest, is you picked out a couple of features in this new release that are noteworthy Even more like you picked out the most noteworthy of the most noteworthy changes right?

Sjors Provoost Uh I just picked the ones that I thought were cool.

Aaron van Wirdum Okay, so the first one oh yeah and we mentioned some of them in our previous episode actually because in the previous episode which I guess by now is two months ago we did mention some new inclusions in Bitcoin Core or you did already so we'll sort of repeat these for whoever missed that episode or just to give a complete picture. So the first one is peer-to-peer transport encryption.

Sjors Provoost That's right.

Aaron van Wirdum What's the BIP number for that again? Do you remember? Do you know?

Sjors Provoost No.

Aaron van Wirdum It's not BIP-151, right? That one was replaced?

Sjors Provoost No, it's a new one. It's peer-to-peer encryption. So we did a whole episode on this, episode 77. That really explains why you want to do this. But the short version is that nodes will encrypt their traffic between each other. So that especially internet providers cannot simply just listen to what you're doing. This is actually very easy to test. It's also something that's not on by default. But as part of testing you might want to turn that on. So roughly the way you would test this is you download Bitcoin Core, the new version. You turn this feature on by changing the configuration setting. And then your friend also downloads Bitcoin Core, also turns this feature on. And now you try to connect to them. So in Bitcoin Core normally it automatically finds peers, but you can manually say, hey, please connect to this IP address. And then you can actually get something called a session ID. That's probably, it should be in the instructions. But basically you'll be able to see a number just like with Signal. A long number. And if you compare that long number with what your friend sees as a long number, then you know that you are directly connected to them. There's not a man in the middle. So that's the kind of thing you can test. And it'd be very worrying if the number was different. That would indicate a bug.

Aaron van Wirdum Right.

Sjors Provoost Or somebody spying on you. But probably a bug.

Aaron van Wirdum Okay, well, let's linger here a little bit because now you spoke about testing and we did discuss it in previous episodes, but still. So right now, Bitcoin Core nodes. They're part of the peer-to-peer network, so they communicate with each other, which specifically means they send transactions and blocks to each other. And right now they do that over an unencrypted channel. It's just plain text. It's just plain information, right? So that means that internet service providers can see exactly which transactions and blocks you're sending. And I guess the main problem is that this would allow ISPs… to sort of see where transactions originate.

Sjors Provoost Yeah I'd say that's one problem. And the other is it makes censorship easier because if it's very easy to detect that it's a Bitcoin node it's also very easy to block it now that's still easy with this encryption in place for other reasons but having encryption it makes it one step easier to to get around censorship.

Aaron van Wirdum Okay, that… Yeah that's that's basically it right? That covers this. Okay so this is now in Bitcoin Core but it's optional.

Sjors Provoost Yes.

Aaron van Wirdum So you can switch it on and it's a preferential or did you just explain it is the preferential seeking of other nodes that do the same thing?

Sjors Provoost Yes, no, it's not preferential, but if if it happens to connect to another node and it knows that it has this feature it will use it. But it's not preferential.

Aaron van Wirdum Okay, so it still connects to other nodes randomly, but they will first sort of try, hey, are you using encryption?

Sjors Provoost No, they will only try if they think the other side can use it.

Aaron van Wirdum Oh, so how would my node think that your node is using encryption?

Sjors Provoost So we talked about, I think in episode two or three, we talked about how nodes bootstrap and learn about other nodes. So they learn about nodes by having a list of IP addresses to connect to. But in addition to those IP addresses, there's also some metadata of which features these nodes support. So in your long address book of potential nodes to connect to is information like, is this a prune node or a full node? Does it have specific bloom filters or whatever filters you want? And as of now, it also tracks whether the node supports V2 transport. So if your address book says that this other node supports that new feature, which could be a lie, but at least that information would be there. Then it'll try that first. And if it fails, just tries the V1 connection. Now, I guess in the future, we might turn that around and just always try the V2 and then fall back to V1 if it doesn't work.

Aaron van Wirdum Yeah, why wouldn't you just always try it? Just because it's extra data to communicate? Like this extra try? Like, why wouldn't you just by default first try encrypted?

Sjors Provoost Because if you first try encrypted... and the other side does not support it, the other side will hang up on you. So you have to connect again, which is not the end of the world, but right now the majority of the network doesn't support it, so that means all of your connections would fail and you'd retry.

Aaron van Wirdum I see.

Sjors Provoost But I don't know if that's a big enough deal in the long run. So it might be turned around. Just try it.

Aaron van Wirdum Yeah, I would assume eventually the goal is that everyone would use this, right? Are there any downsides to using this?

Sjors Provoost Well, there is now because it's too new. So if something goes wrong, your node might simply fail to connect or get hung up on by all of its peers and you don't get the latest blocks, right? So right now it's not safe yet. But in the long run, I don't think there's any downside. It was designed to not have downsides, in the sense that it's actually even a little bit faster than the original protocol. You'd think it'd be slower because it's encrypted, but the original protocol uses checksums to make sure that the messages are correct, and those checksums use SHA-256, which is very slow, and the new algorithm uses a quicker checksum. So it's better in, hopefully in every way, if it's not broken.

Aaron van Wirdum Right. So how, if I download Bitcoin Core 26, how do I switch this on?

Sjors Provoost You go into your bitcoin.conf settings file, and then you turn on, I think you enter v2transport=1. But it'll be in there, either the release notes or the testing guide.

Aaron van Wirdum Right. All right, moving on to the next point. AssumeUTXO was implemented for signet, testnet? Not mainnet, right?

Sjors Provoost That's right.

Aaron van Wirdum Okay, so what is AssumeUTXO again?

Sjors Provoost Well, we covered that in episode 14. So that's quite a while ago. It's basically the short version of it is that instead of starting at the Genesis block when you start your node and going all the way to the most recent block, which takes a long time, you start at a snapshot. And you assume that it's valid. And then you go from the snapshot, which might be a few months ago, to the present, to the tip. And then once you've done that, you start from the Genesis block. And in the background, you check all the blocks. And you make sure that you indeed arrive at this snapshot that you assumed initially.

Aaron van Wirdum So the benefit here would be that you can start using the Bitcoin Core node before fully syncing?

Sjors Provoost Yes. You would basically sync only the last 10% of the blockchain. And you would be immediately able to use a wallet, receive coins, send coins. But there's still some chance that your starting point was wrong. And what could go wrong then is, let's say there's some malicious developers and they just create fake coins. Well, now you think you've received coins, but these coins don't actually exist. Now that's a really, really expensive attack, right? Because somebody still has to make a block with enough proof of work. That is wrong according to all the other nodes, but only correct according to you or the list of victims that they have. So I don't think that attack is super realistic, but we still want to...

Aaron van Wirdum Plus the developers need to be corrupt, obviously.

Sjors Provoost Yeah, so this depends on the distribution mechanism. Right now the idea is that the correct block is hard-coded into the source code, so you would indeed have to compromise the developers. You could, we could still change that approach. I don't know if it'll be changed. But the approach could be that, no, you can just use any block and the developers do not bless any of the blocks. Because it's, the downside of the developers blessing the blocks is that, well, now if you compromise the developers, you're screwed.

Aaron van Wirdum How would you use any block?

Sjors Provoost You basically, Bitcoin Core wouldn't care. Like you would just give it a block, say, assume this one is correct. You just download that from somebody on the internet that you trust. And then you'll find out if it was right or not, but it'll take a while.

Aaron van Wirdum Right. I see. And obviously, so...

Sjors Provoost So that means there's no centralized group of people to pressure or to corrupt.

Aaron van Wirdum Yep.

Sjors Provoost But the downside is you will get scammed left and right because everybody can just make their own fake one.

Aaron van Wirdum Yeah. okay interesting so wait which so which version is implemented in Bitcoin Core right now the the blessed one okay the developers have blessed it yeah okay uh so yeah you mentioned

Sjors Provoost And for testnet and signet obviously that's fine right but it's also not there's also no theft risk there right?

Aaron van Wirdum It's only on testnet now and signet which is a version of testnet. um so yeah so you mentioned even if it would be on mainnet the the attack would be expensive because you need to create a fake block and you need to at least in the current version corrupt the developers plus it would only work temporarily because it's all it's kind of a stop gap until you've actually synced from

Sjors Provoost Yeah, basically once you've synced from the Genesis block, the node would crash.

Aaron van Wirdum It's kind of a, yeah, right. It's sort of a solution until, in the meantime. And therefore it's obviously also optional. You can just opt to actually wait until it's fully synced before you receive any transaction.

Sjors Provoost Although in that case, you should just not use the feature.

Aaron van Wirdum Yes, well, that's what I'm saying. The feature is basically optional.

Sjors Provoost That's true in general, yes. So if you wanted to test this, again, you download Bitcoin Core, then you obtain the signet or the Testnet snapshot. There's some links to torrents, I believe. And then you just run one command and you'll see it in action.

Aaron van Wirdum Okay, so that's also new in Bitcoin Core 26. On to the third point. The third hand-picked selection by Sjors is... Network diversity. There's a new upgrade in updated network diversity tools. What's going on, Sjors?

Sjors Provoost Yeah, so I believe if I understand this feature correctly, and I did not read it up in detail, it's been a while, but here's the thing. Bitcoin Core will connect to about eight nodes, will make connections outbound to about 8 nodes.

Aaron van Wirdum That's the default? 8 is the default?

Sjors Provoost Yes, it might be 9 now. And then other nodes might connect to you, but if you're behind a router, etc., then that won't happen. Now those 8 nodes, by default, would just be on plain internet. IPv4, IPv6. But if you want to, you can also connect to Tor nodes. If you turn Tor on. Now, if you don't do anything, you may or may not have a connection to a Tor node. And if you have one and you lose that connection because they hang up on you or something goes wrong, then you're just going to connect to a new node and maybe it's a Tor node, maybe not.

Aaron van Wirdum Wait, if I'm using Bitcoin Core, which I am. But I haven't explicitly made any sort of change to connect through Tor. Can I still connect to other Tor nodes? No, right?

Sjors Provoost No, you have to turn something on to do that.

Aaron van Wirdum Okay, got it. Okay, go on.

Sjors Provoost But once you have turned it on, but you let the Bitcoin Core node automatically handle what it connects to, you may or may not have a connection to another Tor node. And if you have a connection to another Tor node and you hang up on that one, or they hang up on you... maybe you won't have it again.

Aaron van Wirdum Right, so what you're saying is I'm connected to eight nodes. One of them is a Tor node because I switched the ping on that allows me to connect to Tor nodes. Now this guy's internet, Wi-Fi fails, whatever, I'm disconnected with him. So now I'm going to reconnect randomly to another node, which may or may not be a Tor node. So it's possible that I'm connecting to not a Tor node and now I'm not connecting to any Tor node.

Sjors Provoost Yeah, so basically the Tor feature so far just... does not guarantee that you actually connect to a Tor node. You may or may not. And so this new change, make sure that you do. It makes sure that at least, I don't know what the percentage is, but let's say at least one connection will go to Tor if you have Tor on. And it will basically, if that connection disappears, it'll make another one.

Aaron van Wirdum And so the way I would do this, again, is I go into the config file and I say...

Sjors Provoost No, this just works.

Aaron van Wirdum This just works. Out of the box.

Sjors Provoost If you have Tor on, yes, this just works. Tor does not work out of the box.

Aaron van Wirdum Sure. Okay, so this will basically guarantee that I'm going to connect to a Tor node if I want that.

Sjors Provoost Well, assuming there is one that you can connect to at all, but it will try, yeah.

Aaron van Wirdum Yeah. What's the benefit?

Sjors Provoost This solves a problem known as eclipse attacks, and we have done previous episodes too about eclipse attacks.

Aaron van Wirdum Also probably very early on, I think.

Sjors Provoost Yes, I forgot to write down the numbers, but you'll find them. Basically, in Eclipse attack, the idea is that some evil person makes sure that your node only connects to them. So you think you're connected to eight different peers, but you're not, you're connected to the same person, because they have eight different IP addresses and tricked you into connecting to them. We'll explain all that. Now, if you also connect through Tor, this attack becomes more difficult, because they might be able to trick you into connecting to them through normal IP addresses. but they may not be able to trick you into connecting to them through Tor. Or if they're making the connections to you, they might not know your Onion address that they're connecting to. They only know your normal IP address.

Aaron van Wirdum Yeah.

Sjors Provoost So that's why this helps.

Aaron van Wirdum It's kind of a safeguard. Like Eclipse attacks themselves are kind of unlikely to happen. There are more tools against that, right, in Bitcoin Core?

Sjors Provoost Yeah, I would also say Eclipse attacks, you know, again, Eclipse attacks are getting more and more difficult. And if you want to do them, you probably want to have a motive. Like you want to be able to scam somebody into accepting your payment and then double spending them and working with miners. All that stuff. They're not easy attacks, but we like to make them impossible or harder.

Aaron van Wirdum So Tor is kind of a lifeline to still get the latest blocks in case they're being censored in some sort of Eclipse attack scheme.

Sjors Provoost Exactly.

Aaron van Wirdum Makes it more difficult. So this is also new in Bitcoin Core. The network diversity is embedded more and more thoroughly. Then I'm seeing you selected, there's a Taproot Miniscript upgrade.

Sjors Provoost Yes, so we covered Miniscript in episode 4. A very long time ago.

Aaron van Wirdum Really?

Sjors Provoost Yep. One of the first things we did. So, what's the TL;DR Miniscript? It is a subset of script, you could say, so not all of Bitcoin script, but a part of Bitcoin script that has been handpicked by super wizards like Andrew Poelstra and sipa to make sure that you don't shoot yourself in the foot.

Aaron van Wirdum Yeah.

Sjors Provoost And that you can combine pieces of script, like two pieces of script and you put and in between it, et cetera.

Aaron van Wirdum Yeah.

Sjors Provoost So these allow you to do complicated, fancy wallets with like, okay, I want two signatures, but after one year, I only want one signature, et cetera. And this worked. This has been added to Bitcoin Core a year ago or so in various steps, which we've covered in earlier episodes. And the latest step is that you can now also use Miniscript with Taproot.

Aaron van Wirdum Right. And what is the benefit?

Sjors Provoost So the benefit of Taproot in general...

Aaron van Wirdum Maybe should I first, for those that didn't follow that, so yeah, Bitcoin transactions use scripts, so it's basically programming language for Bitcoin, allows you to lock Bitcoins up in all sorts of creative ways, time locks, multisig, whatever. A Miniscript is a way to sort of simplify that. It's really for developers, right? Like, I'm not going to use it. It's for people like you, and...

Sjors Provoost It's for developers or for wallets that have been written by very small developers and that do it for you in the background.

Aaron van Wirdum Right. But with regular scripts, it's kind of easy to make mistakes and lose coins. And with Miniscript, kind of the most common ways to make these mistakes are just... ejected like you can't use this only the simple stuff is left and because of that you can actually make fairly complex things relatively simply and safely yeah okay so this was already available in Bitcoin Core so what this means specifically is I think you can you connect wallets that use this to Bitcoin Core and probably I don't think I'm saying that right. Well, that's…

Sjors Provoost That's true. Yeah, so um well the Bitcoin Core wallet supports Miniscript right but there's no like graphical way or anything in the interface where you can do that you'd have to manually type these pieces of Miniscript. But there are wallets out there that will connect to Bitcoin Core using the RPC, for example. And they might use the Bitcoin Core wallet for the key storage, etc. But they would have some graphical user interface and they would construct a Miniscript.

Aaron van Wirdum So where... I think I'm skipping ahead.

Sjors Provoost So where Taproot comes in...

Aaron van Wirdum No, I don't want to go there yet. Where is this? I don't know how else to ask. Is this in the Bitcoin Core wallet or is this in the Bitcoin Core... like node software so where where do I find whatever we're talking about?

Sjors Provoost Well the Miniscript lives in the Bitcoin Core wallet.

Aaron van Wirdum Yes. So this… Okay, so we're talking about the Taproot upgrade let's go there then. Yeah, so now this has been this has been made available in Taproot. So is this an upgrade in the Bitcoin Core wallet?

Sjors Provoost Yes.

Aaron van Wirdum Okay, got it. So what's the upgrade?

Sjors Provoost So the upgrade is that you can now use this Miniscript so these safe pieces of script, not just in SegWit, in regular SegWit, which used to be the only thing, but you can now also use it in Taproot scripts. And remember what's nice about Taproot scripts is you can have all these multiple ways that you can spend a coin. You can now hide all the ways that you're not using by putting them in different leaves. Your wallet would basically know that, okay, there are five different subscripts, essentially, that are possible and the user will tell me which one of these five to use when I want to spend this coin and we'll hide the other ones. And there were some like there's some subtle changes between the scripts in Taproot and the scripts in SegWit before some limits were dropped but that's not that important.

Aaron van Wirdum Right. It's just, it's basically just the benefits of Taproot are now available in combination with Miniscript in a Bitcoin Core wallet.

Sjors Provoost Yes, but either you will have to write your little Taproot Miniscript yourself and put it in the wallet. Once you've put it in the wallet, by the way, it just works, right? You just click on receive new, make new address. It'll show an address, looks like any other address and you'll be able to spend from it and it'll just work. But you generally do not want to type Miniscript yourself, even though it's safer than regular script. Probably want to use some other tool that does that for you. Right.

Aaron van Wirdum So this is available in Bitcoin Core now. Bitcoin Core 26. Well, I say now at the time of recording we're still in… yeah

Sjors Provoost I don't know if this is in the testing guide, maybe there maybe it is. That would be pretty cool.

Aaron van Wirdum Um, who's gonna benefit from this? What are there any wallets that use this right now or that want to use this?

Sjors Provoost I think Liana wallet wants to because they're trying all sorts of fancy multisig uh… Yeah, multistage, multisig things, right?

Aaron van Wirdum What's it called?

Sjors Provoost Multisig.

Aaron van Wirdum No, the wallet.

Sjors Provoost Liana.

Aaron van Wirdum Liana. Have I heard of this? I don't think so.

Sjors Provoost Wizard Sardine is the company.

Aaron van Wirdum Oh, yeah, yeah, yeah. Okay, Kevin.

Sjors Provoost Yeah, and they do a lot of work on Miniscript in general to contribute back.

Aaron van Wirdum Yep, that's true.

Sjors Provoost But hopefully, and I know, for example, that there's other wallets that support Miniscript already, but the hard part is the setup part, I would say. So many wallets might be able to sign Miniscript, even hardware wallets, but they will not... Once you've put it in there, it's not that easy to make these wallets in the first place.

Aaron van Wirdum Right.

Sjors Provoost Okay.

Aaron van Wirdum Last point, I think. We're going to the last point. The last mentionable upgrade in Bitcoin Core 26. submitpackage RPC you wrote down.

Sjors Provoost Yeah, I believe in previous episodes we have talked about the idea of package relay for transactions. So then the simplest example is I have a Lightning channel. I want to force close that Lightning channel. My partner of the Lightning channel or no longer partner of the Lightning channel is offline. So all I have is the last time we co-signed a transaction, and this was before ordinals were invented, and fees were super low. And so I try to broadcast that transaction, but it simply does not even go into the mempool of my peers.

Aaron van Wirdum We have a solution for that, though. You can use child pays for parent, Sjors.

Sjors Provoost That's right. The only problem is that the child...

Aaron van Wirdum Hang on, let me explain the solution. So the solution is I'm going to spend the money from this transaction to myself with a higher fee. So now the miner will see that if he wants to confirm the high fee transaction, he'll also have to confirm the low fee transaction and I'll get the money and the problem is solved, right?

Sjors Provoost Correct, yes. And the miners already do this as far as I know. The problem is getting it to the miner. Because this is where the bureaucrats come in. You basically go to your peers in the network and you say, here's the transaction, but hold on one second, I've got another transaction. But no, no, no. Your peers say, no, this transaction is too low of a fee. But wait, I have this other transaction. Here's the other transaction. Well, that has a really high fee, thank you. But it's spending a transaction that I've never heard about.

Aaron van Wirdum Yeah, hang on. You got to emphasize. So when they say this has a... This has not enough fee. The fee is too low. What they even mean is the fee is too low for the mempool. They're not even going to include it in the mempool. So yes, it would not fit in the block. Now that's fine because it usually goes into the mempool and then you can use the child pays for [unclear] that I explained. But in this case, the transaction, because of all these ordinals, isn't even going to fit into the mempool and therefore it's not going to be seen by anyone and therefore the higher fee transaction is not going to be seen by anyone either, because it's not spending funds from a transaction that anyone is seeing.

Sjors Provoost Yeah, because mempools only process transactions one by one, and if the first one doesn't pay enough fee, it's not going in there.

Aaron van Wirdum Right.

Sjors Provoost So, what is the solution? Is you need a way to send two transactions at the same time to your peers.

Aaron van Wirdum Yeah, so peers and miners will consider them in tandem right from the get-go, before it even goes in the mempool, essentially.

Sjors Provoost Yeah, and this thing is called package relay, and work is in progress to do that. It's not easy. And we've discussed some baby steps in that direction. One of the first baby steps was the RPC called submitpackage. And the idea was to send transactions to your own mempool. So not to your peers, just to your own mempool. And I think half a year ago or so we covered how that worked. You would give this RPC two transactions. And it would just basically reject it. Because it would use the same logic as always. It would process them one by one. So why was that added? Well, because the next step makes it more useful. Now, with the 26.0 release, it will actually consider both of them and therefore include it in its own mempool.

Aaron van Wirdum Right.

Sjors Provoost But not [unclear].

Aaron van Wirdum So this upgrade only applies to... So if I make two transactions, one of them is a low fee, one of them is a high fee... I can now send this transaction over RPC to my own node, but that's it, right?

Sjors Provoost Yeah, and you could imagine maybe there would be a website of a miner where you can send it directly to the miner this way, and they would use their own RPC. That's not the future, obviously, but... You could see some use even of this primitive feature.

Aaron van Wirdum Right. So there's now something in Bitcoin Core. It's a baby step. It's a step towards package relay, right? Exactly. That's just a way to think about it.

Sjors Provoost Yeah.

Aaron van Wirdum It's actually kind of useless in itself. Or is there, you just speculated about a potential maybe?

Sjors Provoost Yeah, and the other is like, at least it would be in your mempool. And so maybe once the fees go down, you know, it's a bit easier to rebroadcast it or something. But rebroadcasting is also not automatic. So yeah, no, it's... So there you go.

Aaron van Wirdum It's basically useless, but it is a step towards package relay, which itself is a useful and important upgrade one day, hopefully.

Sjors Provoost Yes.

Aaron van Wirdum Okay, great. So these are, we've now discussed six, five of the most important upgrades in Bitcoin Core. That's the episode actually, right?

Sjors Provoost That's right. That's a wrap.

Aaron van Wirdum Okay.

Sjors Provoost Thank you for listening to Bitcoin.

Aaron van Wirdum Explained.