Episode 99: Bitcoin Core 30

Aaron van Wirdum Live from the internet, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum How are you, Sjors?

Sjors Provoost Hello, how are you?

Aaron van Wirdum It's been a while.

Sjors Provoost It's been a few days.

Aaron van Wirdum Yeah, we haven't made an episode because we always committed to only making episodes live in person. There were some exceptions, but I think neither of us really liked that, so we kind of made it a rule. But I haven't been in the Netherlands for a while now, never mind in Utrecht, so we couldn't do it. We decided to pick up where we left anyways.

Sjors Provoost Yeah, especially because this is a topic that really nobody talks about, and I think we should.

Aaron van Wirdum Yeah, there's apparently a very obscure new software release called Bitcoin Core 30, and we thought maybe it's time that someone brings it under the attention of the people out there. On that point, I do want to start with that a little bit because I think this has been the most...

Sjors Provoost Do we want to thank our sponsor?

Aaron van Wirdum Yes. Thank you, CoinKite. Thanks for being our sponsor. Thanks for making the brilliant COLDCARD and all the other magical devices you put out there. What's the... Sjors, help remind me. What's the little USB thingy called?

Sjors Provoost I think it was the coin... The COLDPOWER.

Aaron van Wirdum No. But it's like a...

Sjors Provoost Oh, you mean the OPENDIME.

Aaron van Wirdum The OPENDIME.

Sjors Provoost The legend.

Aaron van Wirdum Yeah. Yes. Legendary. Legendary CoinKite. Thanks for sponsoring us. Oh, my God.

Sjors Provoost I think the OPENDIME still doesn't support Taproot because I opened a pull request once to make it use Taproot and they closed it because it wasn't cockroach enough. Anywho.

Aaron van Wirdum Anyways.

Sjors Provoost Let's talk about this obscure piece of software.

Aaron van Wirdum Oh, yeah. So I wanted to ask you, you know, okay, we're mostly going to be making a drama-free episode here. You know, we're going to discuss what's actually new in Bitcoin Core 30. Like I said, it does seem like this has been probably the most controversial Bitcoin Core release ever. Social media community has been sort of ablaze over all of this. I don't think I've seen it this bad since the block size wars and in some ways even worse than the block size wars. And I'm just sort of wondering, you as a Bitcoin Core developer, I know you're not on Twitter, you're not on X. How much are you seeing of this or how much does it affect you and maybe others? Can you give some sort of estimation of that?

Sjors Provoost Yeah, I guess compared to the block size wars, because the community was smaller too, this is probably actually smaller in relative terms. But it's just more money to be made and more attention to be had on social media. Maybe social media is just worse than it was 10 years ago. Yeah, like I said, I try to just ignore things as much as possible other than the actual facts. because just arguing with people on Twitter or even Nostr is just a huge energy drain. We did record a whole episode on probably the most controversial part of it. That's our previous episode, The Return of the OP_RETURN, so people can listen to that. And I don't think anything has changed, although I think we'll address a couple of very minor things here. in the release notes

Aaron van Wirdum yeah yeah but yeah i mean that's a good uh sort of non-spoiler warning maybe we're not gonna spend half an hour discussing this change because we made a whole episode about it anyone who wants to know how Sjors thinks about that or me i can go to the previous episodes uh previous episodes and that's where we really discussed the you know the OP_RETURN limit change

Sjors Provoost well now i would say uh if you look at um say the github repo and you know 99 percent of the work on Bitcoin Core is completely unrelated to these controversial changes. And that work just continues as before. It's interesting how, you know, there's like 350 open pull requests on the GitHub repo and they're almost all like silos. So one pull request can be super crowded and noisy and the other one is completely deserted and nobody's even looking at it.

Aaron van Wirdum Yeah.

Sjors Provoost I think I've made the analogy before that the Bitcoin Core project sometimes feels like you have a very large brutalist office building and everybody has a little cubicle. And if you're in that cubicle, your pull request is like a cubicle. You might be in multiple cubicles, I guess. But if nobody comes by, then nobody can hear you.

Aaron van Wirdum Yeah. Okay, well, regardless, let's actually kick off with that specific topic just to get it out of the way. So the OP_RETURN policy limit has been lifted basically entirely, right? Again, I think we've said enough about that. Anyone who wants to know the details about that can go to the previous episode. However, there is also another related change that's close to it, but that we did not discuss in the previous episode. I think there's also a policy... policy rule is that it's now also possible besides bigger OP_RETURNs to include multiple OP_RETURNs in one transaction, right? We did not cover that last time.

Sjors Provoost I'm not sure if we did, but we can just repeat it. Yes. So you can either make one OP_RETURN that is the maximum size of a transaction or less, or you can make multiple ones, which, you know, can ultimately add up to the same size.

Aaron van Wirdum Yeah, that's important to note.

Sjors Provoost I would say that's mostly a simplification.

Aaron van Wirdum Well, it's important to note because, you know, in this entire shitstorm, it has been brought up as well as like another supposedly bad thing that Bitcoin Core developers have done. But as you point out, even if there are multiple OP_RETURNs in a transaction, the total size of these OP_RETURN, are still bound to whatever the limit is and this limit even in Bitcoin Core is still configurable right uh

Sjors Provoost yeah so we kind of went back and forth on that the initial idea was to completely drop it because it's essentially a placebo but you know there was a lot of drama so eventually i think now the default has been changed like there's no limit but if you do set a limit the only difference between now and before is that the limit applies to the total for transactions so Let's say you set the limit to 83 bytes. That was, I think, the previous default. Then somebody could make, I guess, you know, 20 OP_RETURNs of two bytes each if they somehow wanted to. Now, that'd be pretty expensive for them because every output has an overhead.

Aaron van Wirdum Yeah, I'm pointing it out because there was a point of critique, as I mentioned, that, okay, you can change the default setting now. You can change it back to where it was. But the critique was, but now you can still include multiple OP_RETURNs in a transaction. However, the point is that if you do change it back to, let's say, 83 bytes, then if you then put multiple OP_RETURNs in a transaction, then their combined size can still only be 83 bytes. So even if you change it... If you do change the defaults for whatever reason you may think you want to do that, then that is still the actual limit for OP_RETURNs. Yeah, you can split it up in two different OP_RETURNs, but it's still 83 bytes in that case, right?

Sjors Provoost Mm-hmm.

Aaron van Wirdum Yeah, okay. So then why you said the change was made, and I'm talking again specifically about the fact that you can include multiple OP_RETURNs, that was made as a simplification?

Sjors Provoost Yeah, I mean, it depends on how you look at it, I guess. But the idea was there can only be one, so that restriction is dropped. Now it doesn't matter how many outputs are OP_RETURNs. So the rules are simplified. Whether that actually is simpler in the code, that's debatable, right? Now you have to check the total against multiple outputs. As long as the option is there at all, there's some complexity. As long as you remove the option, it becomes simpler because you're just not counting it at all. But now, you know, it has to count, like look at the first output, look at the second output, look at the third output, and then complain when something goes over it.

Aaron van Wirdum And because, you know, because we're talking about a policy rule, you know, just to repeat this point, it does not apply to the consensus rules. If your node receives a block with a transaction in it that has... you know, bigger OP_RETURNs than whatever setting you're switching it to, then you'll still accept that.

Sjors Provoost Yeah, in fact, you know, a block could contain a four megabyte OP_RETURN in a single transaction, right? Which would not be even possible with the new Bitcoin Core over the mempool.

Aaron van Wirdum Yeah.

Sjors Provoost Each transaction is limited to 100 kilobyte in general.

Aaron van Wirdum Yeah, so what is technically new in this specific instance is that there can now be multiple OP_RETURNs in a transaction on whatever size you want to put that setting. And then if it's within that size, you will accept it in your mempool and relay it to other nodes, correct?

Sjors Provoost Yes. And so just a little bit more background on why, you know, such as, I mean, first of all, if the setting was entirely removed, which was the initial idea, it's actually a simplification. But because the setting is still there, we still need to look at the total. So you could argue it's not really a simplification, but it is in the long run. But another reason to do this is because if somebody has a need to have multiple OP_RETURNs, and I don't know if anybody does at the moment, but if they do, and we still have this limit of one OP_RETURN output per transaction, then there is another incentive for people to go outside the mempool. And you use accelerators, which creates the centralization pressure that we tried to solve in the first place.

Aaron van Wirdum Yeah. And on that point, what I also find interesting to sort of highlight here is that your reasoning... So you said... We don't know if there's a use case for it. Maybe there isn't. That in itself has drawn a lot of ire. There seem to be a lot of people that feel that unless you can prove that there is a use case for it, you shouldn't make any changes. While you, and I agree with you, see it more as, well, if there's no harm, then what's the problem? If there's no harm and you simplify the code, then that seems like an improvement.

Sjors Provoost Yeah, I guess in this case, where the confusion comes from is, or potentially comes from, is that initially the idea was to drop the setting entirely. And because we haven't dropped it entirely now, the simplicity argument isn't as strong. But yeah, the problem with these alternative use cases is if you wait until they're actually fully deployed... and they go around the mempool because, you know, they're already deployed. Now you lift the limit and, well, they're already going around the mempool. So, you know, why would they change anything? So you might be too late if you keep chasing these things and Bitcoin Core only releases once every six months. And we'll have another topic on the list where something similar happens where it was a response to actual behavior. So we were a little bit late at this time, I guess.

Aaron van Wirdum Yeah, yeah. So if you're being reactive on these things, you're actually too late. And then if there's no harm in doing it, then it's better to just do it now in case someone might need it.

Sjors Provoost Especially because the total amount doesn't change, right? Like you said, you can spread it over multiple outputs.

Aaron van Wirdum Yeah. Yeah, okay, let's move on from that point. Anyone who was listening specifically to hear more about the OP_RETURN drama can now switch off because we're going to talk about other interesting, notable improvements in Bitcoin Core 30, right? Or was there anything else you wanted to say about this?

Sjors Provoost Yes, but I was just changing the sequence of items on our to-do list. All right, let's talk about the minimum relay fee then. Because that's sort of in the same area of changes. And then we'll move on to completely different changes.

Aaron van Wirdum Okay. It was very important to adjust that in the Google Doc that no one else will see besides you and me. Good thing that you did that. Exactly. Okay. So yeah, so this is another policy change, which, okay, so that's the minimum fee that is included in the transaction, can now be lower before Bitcoin Core node will accept it in the mempool and relay it to other nodes, right?

Sjors Provoost Yeah, so it used to be one satoshi per vbyte, now it's a 0.1 satoshi per vbyte. And this is a case of people start doing things and Bitcoin Core has to follow. Otherwise, everybody will go around the mempool. So what started happening is because the fee market is such an amazing success. Yeah, people wanted to pay less fees. And well, like I said, I'm not on social media myself at the moment. But what my understanding is that there was sort of a Twitter movement to... for people to individually configure their relay fee to go lower by factor 10.

Aaron van Wirdum Yeah, and that was...

Sjors Provoost Somebody just followed that example.

Aaron van Wirdum And so that was... Sure, that was always possible with Bitcoin Core. Any individual user could already lower the min relay fee.

Sjors Provoost Yeah, it's a matter of changing a setting. Now, keep in mind, everything is possible with Bitcoin Core if you recompile it yourself. But in this case, it's just a matter of changing a setting. So you can already lower it to one thousandth of a satoshi per vbyte. Not lower, because the amounts internally are processed at that resolution. So you'd have to do some more changes if you want to go even lower than that. But I guess, yeah, people settled on about 10x lower. And some miners followed, and that means these things get mined. But that means if you don't change your default setting, now you're kind of surprised about what gets into blocks. And that surprise hurts compact block relay, among other things. So we talked about compact block relay in our previous episode. But generally the idea is that if you're sending a block to the next person down the line, to one of your peers, If you know what's in their mempool, you really only need to send the header of the block and a summary of the transactions, like a list of the transaction IDs, rather than the full block with all its contents. But if you don't know what's in somebody else's mempool because they changed some setting, now you have to send the whole block over. And so this delays propagation network-wide.

Aaron van Wirdum Yeah, it's better for the health of the network if blocks find their way across the entire network as fast as possible. And that requires... that mempools closely reflect the actual blocks that are being mined. So if for whatever reason, the blocks start to look different, in this case, because very low fee transactions start to make their way to miners, then it's actually better for the health of the network that everyone adapts the same behavior. So in this case, Bitcoin... in this case, and also very relevant to the OP_RETURN issue, but in this case as well, Bitcoin Core has decided to allow lower fee transactions in the mempool and relay it to other nodes in order to better reflect the mempool with blocks that are being found. Good summary.

Sjors Provoost Yes, and so this has been a general theme now over a few different topics. We've seen with RBF, full RBF, the changes. We've seen it with OP_RETURN. Now we're seeing it with the fee rate. And the response has been slightly different in different cases. So in the case of full RBF, you had somebody basically promoting that concept, releasing an alternative client, and then Bitcoin Core did not follow. until at some point, you know, all the miners or at least a large chunk of the miners were doing this and compact block relay was broken. And so then Bitcoin Core said, okay, let's turn RBF on. So arguably that was too late. But because we already had broken compact block relay and, you know, the longer you let that sort of centralization risk exist, you know, maybe at some point the damage is irreversible. Probably not in this case. Okay, so then we had the OP_RETURN stuff, where Bitcoin Core developers saw that a use case was imminent and tried to preempt it. That caused an enormous amount of drama. And now it's kind of in between, like this spontaneous change in policy by users, and Bitcoin Core follows it just a month or two later. Yeah, I don't think there's really consensus on how to best deal with this. Like these three options, you can either be too early or too late or right on time. And at some point, there might be a deviation from... from in policy that is simply not acceptable, as in it would just be unsafe, cause a DoS problem. And at that point, there's nothing Bitcoin Core can do other than propose a consensus change or just accept that nodes are slow or vulnerable or something bad like that. So it's not a healthy development, I think, but people do what they do, right? It's an open source, open system.

Aaron van Wirdum Yeah, and I think that's an important point to emphasize here, because this says a lot about how the Bitcoin Core project sort of operates, is that... you know you guys you know you are one of the Bitcoin Core developers you don't see yourselves as authorities that decide how other people can or even should use the network it's not in your control how people what kind of transactions people send or what kind of transactions miners mine Bitcoin Core can only you know adjust to that so and then like you said there are like a couple of ways to do that which is either sort of you know do it in advance when you see it coming or only do it when it's kind of too late and that's sort of the difficult aspect here to balance

Sjors Provoost or worse like you can't do it at all Because there might be some trade-off that's really unacceptable.

Aaron van Wirdum Yeah. So this is a good example of that as well. Users were already starting to relay very low fee transactions. Miners were already starting to mine that. So then Bitcoin Core in this release said, okay, we're going to lower the fee minimum in order to better.

Sjors Provoost And this change, I don't think this change is particularly bad because, you know, the last time this limit was lowered, I think it was 10 sats per vbyte in the past or maybe five, and the price has gone up 10,000x. So if you look at this, you're going to have to look at it as a DoS, a denial of service protection. If the minimum relay is too low, then somebody can just cheaply cause you to use a lot of bandwidth, everyone to use a lot of bandwidth. And so I think the initial calculation years ago was done on like, okay, if somebody spins up a bunch of Amazon nodes and just starts flooding us with random data, how much does it cost them versus how much does it cost the ecosystem? How much cost does the attacker have and how much resources of the community are they wasting if you add up everybody's node costs? And so I think we're still quite on the safe side of that equation. It's really expensive. For the attacker, they need to spend quite a lot of sats to cause people to use bandwidth.

Aaron van Wirdum Yeah, okay. One last note on this point, because I noticed that in the GUI, that change, yeah, so in the user interface, that change does not apply. Like the minimum fee if you want to send the transaction is still the same as it ever was, right?

Sjors Provoost Technically, it's the wallet that's unaffected. So the wallet can be used from the command line. You'd be surprised some people use it from the command line and they like it. But yeah, as far as I know, the wallet still has one sat per vbyte as a minimum. I think you can manually set it lower. But my guess is the wallet will follow in a later release. You kind of want to make sure that the network actually relays your transaction, because let's say we change the wallet now to use this 0 .1 sat per vbyte, and you start your GUI, and you have maybe five peers, and none of them have this custom setting. Because, you know, a lot of people do, but not everybody does. So you might not be connected to anyone who does. So you sent your 0.1 sats per vbyte transaction and it just gets rejected by your peers. And they don't tell you it's rejected. So you just, you send it, you close your wallet, you go to sleep and the next morning you're like, why isn't this confirmed yet? It's because it never went anywhere because you only had your node open for five minutes and none of your peers accepted your transaction. So you kind of want to be a bit conservative when it comes to the wallet. But I think you can just do it manually if you want to.

Aaron van Wirdum Right, so in that sense, Bitcoin Core actually also adjusts to the situation on the network. It will only be implemented in the wallet once there's a good enough likelihood that it will actually make its way through the network.

Sjors Provoost Yeah, and of course there's also a bottleneck of just the very small number of people that work on the wallet in general in Bitcoin Core. I don't think we've adjusted the new RBF... I don't think we've adjusted to the new RBF reality yet, for example. And there's some...

Aaron van Wirdum How so? You can use RBF with Bitcoin Core, right?

Sjors Provoost Yeah, well, Bitcoin Core wallet has been setting the RBF flag for wallet transactions for many years. We don't have to anymore because it's gone.

Aaron van Wirdum But there's also no harm in doing it, I guess.

Sjors Provoost No, and well, there's actually harm in turning it off.

Aaron van Wirdum Privacy?

Sjors Provoost Yeah, you can see who upgraded if we change this. And maybe something similar applies to fee rates. If we suddenly drop it, then you can see who is upgraded. So I'm not sure what the right path is there.

Aaron van Wirdum Right. Okay, let's move on to the next point.

Sjors Provoost Cool.

Aaron van Wirdum Actually, I think this is also, there's another policy issue. There's a new policy rule, just correct me if I'm saying anything wrong, but there's a new policy rule that restricts the number of signature operations, sigops. Per transaction? Or no, per output, right?

Sjors Provoost Yeah. So we did a whole episode, 93, about the great consensus cleanup restoration soft fork proposal, which deals with time warp attacks. And one of the attacks that soft fork, proposed soft fork, is trying to deal with is... preventing somebody from making a transaction that takes like an hour and a half on a Raspberry Pi. Oh, sorry, to create a block that takes an hour and a half on a Raspberry Pi to validate. And maybe several minutes on a modern computer. Because if a malicious miner produces such a block, they can stall their competition and maybe get a head start out of that. And the way that was fixed involves that particular rule. So there's 2,500 sigops limit per, I think it's per transaction.

Aaron van Wirdum Okay, but just explain what it is. It means basically, if I understand correctly, you can make a transaction or an output with what? So you're not sure which of the two it is? It's either a transaction or an output?

Sjors Provoost I think it's... It's per transaction, but what you're counting is you're counting sigops in the inputs and in the outputs.

Aaron van Wirdum Okay, so there can be a maximum of 2,500 signatures, basically, in a transaction then, right? That's what it means.

Sjors Provoost Yeah, signature operations is slightly different. So, for example, a legacy multisig or bare multisig, as we called it, I think it counts as 20. Something like that. I'm a little fuzzy on the details here, but basically it's a limit in the number of signature operations. No sane transaction would actually go over those limits. Like there’s no...

Aaron van Wirdum Because it's thousands, yeah.

Sjors Provoost Yeah, exactly. You'd need a very, very insane kind of multisig. So the only people who would be making such a transaction are people trying to DoS the network or people doing experiments. I think there were some historical examples of these actually violating them.

Aaron van Wirdum Okay, so right now, if you make a transaction with 3,000 sigops, it can still be mined in a block. It is still consensus valid, correct?

Sjors Provoost Yeah, and that doesn't change, right? This is a policy change. The only thing changes is you can't relay it anymore.

Aaron van Wirdum Right. So if someone sends a transaction like that to you and you're running Bitcoin Core 30, then you're going to not include that in your mempool and not relay it to other nodes. But if it's in a block, again, then that's still fine.

Sjors Provoost Yeah. And this is there to protect future miners. It's not really there to protect the network because I don't think they're that terrible. A future miner, when and if, or if and when this becomes a soft fork, then it is consensus. And we don't want a miner to accidentally mine this thing. And so that's one of the reasons, one of the goals of policy rules is to prevent accidentally mining something. Because the miner doesn't accept it as a standard transaction, they'll never see it, they'll never mine it.

Aaron van Wirdum Right, so it's kind of in anticipation of hopefully, potentially a future soft fork to already sort of, you know, push network behavior kind of in that direction so that when the soft fork happens, then it's a relatively small change that can't really cause too much problems essentially, right?

Sjors Provoost Yeah, exactly. You want soft forks to be as safe as possible for users, but also for miners.

Aaron van Wirdum Yeah, and I think also, so that ties in with, I guess, another point. We do apparently keep getting back a little bit to the OP_RETURN issue. As a general sort of direction, I think the goal of the Bitcoin Core project is to essentially... you know, as much as possible, just get rid of policy rules and make what nodes accept and relay as close as possible to the actual consensus rules. Is that correct?

Sjors Provoost There is a philosophy that says that policy and consensus should converge.

Aaron van Wirdum Yeah, exactly.

Sjors Provoost I don't know if that's realistic, but... And one of the reasons is that one of the use cases for policy is upgrades, upgrade hooks. Upgrade hooks means that, say, SegWit version 2 or 3 or 4 currently is not standard, so it will not be relayed. But it is consensus valid. It's just that if you mine it, it has no meaning. So that's a case where we don't want them to be the same because you would simply never be able to upgrade.

Aaron van Wirdum Sure, yeah.

Sjors Provoost So I get the philosophy of like, you don't want to have these pedantic limits, as some people would call them, like the OP_RETURN size or RBF things. But it's not, I don't think it's true that... consensus and policy cannot be identical because you would never be able to upgrade Bitcoin anymore.

Aaron van Wirdum Yeah, you still got to leave the room for...

Sjors Provoost Or you'd make it, depending on how, you could also say, well, you'd make it completely unsafe. So you could also say, well, let's just allow SegWit version 3 relay and not worry about it. But then people can shoot themselves in the foot and give away their money because you would get a bc1f address. which might be some future SegWit version. I don't know what the letter F maps do. And you would just send to it and that money would just disappear and it wouldn't even go to anyone.

Aaron van Wirdum Okay. Just to give our listeners a sort of rough idea, because so now the limit is 2,500. Like you mentioned, that is probably far beyond anything that anyone would ever use for any real reason, essentially. What kind of impact does this actually have on a node? Let's say this limit is touched. There is a transaction that actually has 2,500 sigops. Are we talking about a transaction that's going to stall your node with a second or not even that? What sort of ballpark do you think about?

Sjors Provoost I haven't looked at the exact numbers, but my guess is it's negligible. This is very safe for individual transactions. One of the reasons is that... The policy, there's another policy limit which limits transactions to 100 ,000 kilobytes. And so my guess would be that the combination of these high numbers of sigops and a very large transaction are what really is more dangerous. You've got to keep in mind that we have this quadratic phenomena in Bitcoin. So quadratic hashing, that's what's solved with SegWit, but legacy transactions still... If you simplify it, if two transactions of one kilobyte have like one bad each, it adds up to two bad. But if you make it a two kilobyte transaction, it might be four bad.

Aaron van Wirdum It's bad times bad.

Sjors Provoost Yes. So if it's one big transaction, it's much worse than several small transactions quadratically. And so... That's probably why an individual transaction violating this policy limit is not going to be a problem, but a miner could include a bigger one.

Aaron van Wirdum Right. But in any case, to summarize this, a transaction that has 2,500 sigops is both... very implausible to be used for any real reason, while at the same time also still well within sort of safety limits. So that's why, at least as a ballpark, that number was picked.

Sjors Provoost Well, yeah, and in general, the idea of this consensus cleanup thing is to mitigate the worst case scenario without confiscating any legitimate use case or getting anywhere near legitimate use cases.

Aaron van Wirdum Yeah.

Sjors Provoost So there is a trade-off. You might not. be able to solve like there might still be blocks that are slow to validate but not as slow like you can't make it you can't have a perfect solution because then you're going to start risking that you confiscate somebody's very obscure but still potentially real setup

Aaron van Wirdum yeah Okay, let's move to the next point. An other improvement is one parent, one child orphanage, or there's something improved in that sense. Can you remind me what it is?

Sjors Provoost Yeah, we have covered this in previous episodes. But a quick recap is that one parent, one child transactions packages are useful for especially tools like Lightning. So in the Lightning Network, when two people have a channel, they need to agree on a forced close transaction or a penalty transaction. Basically, the transaction that you can unilaterally close the channel with. So if you and I have a channel and one of us is offline, we both have a transaction to... close the transaction without talking to the other side but we have to decide how much fees go into that transaction and we don't know how much fees the future is going to hold so that's always been a bit of a complexity in lightning and the general solution to that is anchors where you like allow yourself to add a transaction later a child's transaction later And there were different mechanisms to do that, and a lot of them suffered from pinning attacks where you would add a transaction, but somebody else would add another one, and you wouldn't be able to bump it, and it would never get confirmed, and you'd be too late, and people cry. But then people came up with the concept of ephemeral dust, which is not the Finnish metal band, which basically lets you make a transaction with a zero-fee, zero-amount output. And then the child spends that zero fee zero transaction output and pays whatever fee is necessary and can decide that at the last moment.

Aaron van Wirdum Yeah, and to do that, you of course have to add some of your own coins then. And basically what you're doing is you spend that zero amount output to yourself in combination with some real money Bitcoin sats that you're sending to yourself. And you include a fee in that new transaction. And if that, you know, now because this is a new transaction, you basically know exactly how much fees you're supposed to include for it to confirm within a reasonable time.

Sjors Provoost Yes, and you can replace it. if fees go up immediately. So that's a nice solution. Normally, you're not allowed to relay a transaction that has a zero fee, zero, that has no fees. In general, of course, that's not going to relay. having an output with a zero amount is also not going to relay because we have a dust limit there. The idea is that you can relay them as a package, a one child, one parent transaction. So it's ephemeral dust because the dust exists, but it's immediately spent and it always goes as a pair in the same block. So the block never creates any dust, only the transaction does.

Aaron van Wirdum Yeah, the zero sat transaction is immediately, or output is immediately spent in the same block. It's just, it's immediately gone, right? That's the point.

Sjors Provoost Yeah.

Aaron van Wirdum So what's the improvement in Bitcoin Core 30?

Sjors Provoost The improvement is that this mechanism under the hood relied on something called the orphanage. And the orphanage is a way for Bitcoin Core to see, hey, I just got a new transaction, but I don't know what the parent is. So I'm just going to keep it for a little bit and then ask the peer for the parent.

Aaron van Wirdum Okay, so the orphanage is specifically for transactions that do make it to you over the peer-to-peer network, but you don't see basically where it's coming from on the blockchain.

Sjors Provoost Yeah, it's not spending anything you know. So you're like, tell me what the parent is, and the peer sends it to you.

Aaron van Wirdum Right, right.

Sjors Provoost That mechanism has been around now for, I think, since version 29. The problem with that mechanism is that it's very easy to attack. So you can flood the orphanage basically with infinite child transactions. That can just be complete garbage transactions because the node has no way to know that a child is a real transaction. So it's essentially free to, you know, if you know what peer you want to influence, you just, you know, just flood them with orphans basically. And it's a first in first out system. So once a hundred orphans are there, you just replace all 100 of them and there's no orphans anymore. And so this relay mechanism doesn't work. So I guess in the lightning scenario, if you are trying to attack your counterparty and you roughly know what peers they're connected to, maybe you can blast their orphanages out and your peer will not be able to get their penalty transaction out. Something like that. That would be the risk. So version 30 makes the orphanage a lot stronger. It basically, well, I don't understand the full mechanism, but it boils down to if one of your, let's say you have 10 peers and one of your peers starts misbehaving by sending you tons and tons of orphans, you're not just going to flush them all. If another peer also sends you that orphan, you're going to hold on to it. So there's just a better accounting system that makes it more difficult to attack the orphanage.

Aaron van Wirdum Bitcoin Core is protecting the kids.

Sjors Provoost Exactly, yeah, yeah. Protect the children.

Aaron van Wirdum Okay, so the orphanage is more robust now. Next point.

Sjors Provoost Yes, there's a Bitcoin command, but I think that was a bit too nerdy. I don't know if you cared about it.

Aaron van Wirdum Oh yeah, no, no, go for it though, yeah.

Sjors Provoost There's one command to rule them all. So there used to be bitcoind, bitcoin-qt, Bitcoin... Well, bitcoind and bitcoin-qt, basically. And then there's some other changes coming up that would add bitcoin-node and bitcoin-gui. And, you know, other developers are like, OK, this is becoming a confused mess. Somebody downloads Bitcoin and they see like 15 commands that start with bitcoin. What to do now? And so the solution is to add another command, which is just called bitcoin. And you call that command and you tell it what else to call. So it has a documentation. You call bitcoin space node. It starts bitcoind.

Aaron van Wirdum There are 15 standards. That's too many standards. We need a standard to rule them all. Now there are 16 standards. Yeah, exactly. So this is for nerds that use the command line, which, as you said, a command line doesn't exist for me. If it's not in the GUI, sure, I'm not aware of its existence. I don't care about it, but this is for those people like yourself that for some reason prefer to use that, right?

Sjors Provoost Yes.

Aaron van Wirdum Okay.

Sjors Provoost Well, one such user might be a miner.

Aaron van Wirdum Sure, I mean, I'm sure there's a lot of people that use it.

Sjors Provoost That was a bridge to the next topic.

Aaron van Wirdum Oh, so you're clever.

Sjors Provoost IPC mining interface.

Aaron van Wirdum Yeah, I don't remember what this was. Tell me.

Sjors Provoost Yeah, so we talked about Stratum v2 a couple episodes ago. Well, we did. I think in multiple episodes. There has been the idea of, well, decentralizing mining. Stratum V2 is one way to do that. It adds encryption, for one thing, and it also adds the ability for individual miners to create their own block templates. To kind of separate, you know. And...

Aaron van Wirdum I mean, it's basically a way to decentralize mining pools, right? Miners on a pool can, for themselves, decide what they put in blocks.

Sjors Provoost Yeah, and this mostly exists outside of Bitcoin Core. There's a project called the Stratum Reference Implementation, SRI. They make all sorts of software tools to run your own pool, to convert between Stratum v1 and Stratum v2, to make your own block templates, etc. But they do need Bitcoin Core for one thing, which is to make the block templates. And also to send the solution if you find a block. And this part is called the template provider. And so the original idea was for when the spec was written was for Bitcoin Core to be the template provider.

Aaron van Wirdum Just to be very clear about this, templates basically just means everything that goes into a block.

Sjors Provoost Except the solution for it. Yeah, except the nonce.

Aaron van Wirdum Except the hash, yeah, sure.

Sjors Provoost And the payout stuff. Yeah, so Bitcoin Core is good at making templates, but the problem was that in order for Bitcoin Core to do this, it would have to speak the Stratum v2 protocol. So it would have to support the same encryption standards and new messages. And so this was implemented by me and a few others, and there was some resistance to adding, basically to adding all this extra complexity, adding these extra cryptographic methods. listening to ports and processing messages, etc. So then a compromise was reached, which is that, well, we'll have Bitcoin Core listen on a protocol we call IPC, Interprocess Communication. And it's not directly supporting Stratum v2, but it does support the messages that Stratum v2 needs, or it can give the information Stratum v2 needs. So it can give a block template, it can push a block template, etc. And so... That's what's in version 30 of Bitcoin Core. And then you can use a separate application to connect to Bitcoin Core and actually basically translate this to the actual Stratum V2 language.

Aaron van Wirdum Right. So let me repeat this back to you and see if I get it. So Stratum V2 is basically a different project. It's a mining specific project. It's like it said, a way for... mining pools to decentralize part of their operations, namely individual hashers, users of the pool, miners, they can decide what goes into a block, which transactions go into a block. But for that, they would actually use Bitcoin Core to hear what transactions are on the network, et cetera, and use this to construct essentially the block. And then... now there's kind of a bridge, a way to connect with the Stratum v2 protocol in order to make it all work. Is that a good enough summary?

Sjors Provoost Yeah, exactly. So there's a bridge between Bitcoin Core and the rest of the Stratum v2 ecosystem, and it uses this new IPC system.

Aaron van Wirdum Right.

Sjors Provoost Which initially was intended for something completely different, namely the separation of processes. So it was designed to split the node from the wallet and from the GUI so that if one of them crashes, the other doesn't crash. And we might still do that, but for now, we basically repurposed this tool.

Aaron van Wirdum Right. So right now, the only mining pool that I'm aware of that uses Stratum v2 is DEMAND pool, but they're kind of still in startup phase, I think.

Sjors Provoost And Braiins as well.

Aaron van Wirdum Do they use it?

Sjors Provoost Yes, but I don't think they do their own. I don't think they offer custom templates. They just support the new technology. But that's already an improvement, because if you're... If you run your ASIC farm and you connect to any Stratum v1 pool now, your router or your internet provider or anyone can just steal your hash rate.

Aaron van Wirdum Yeah, yeah, yeah. That's no good, Sjors. But Braiins does not, or at least not yet, allow individual miners to construct their blocks.

Sjors Provoost I don't believe so. And DEMAND pool does plan to do that, but I don't think they've actually launched this yet. So there was a bit of a chicken egg.

Aaron van Wirdum I happen to know that they're getting close to sort of launching for real, basically.

Sjors Provoost Well, that's good news. It has been a bit of a chicken egg problem on the Bitcoin Core side because shipping this new, even this new IPC interface was also controversial, partially because nobody was using it yet. And so there's some people that say, well, we should first thoroughly test it with the pools and et cetera to make sure it's right and then ship it. Whereas the counter argument to that is, well, the pools are not going to test it if it's not already shipped in Bitcoin Core because it's too much of a pain for them to compile some custom experimental version. And especially if they're not sure that it's actually going to be deployed, right? They need to have at least some confidence.

Aaron van Wirdum Yeah.

Sjors Provoost There was that chicken egg, but now it's in the release, but it's not completely final yet. So it might still make a few breaking changes in the next release.

Aaron van Wirdum Okay, so I was going to ask, is this completely good to go now, or is there still work to be done on the Bitcoin Core side?

Sjors Provoost No, there's still [unclear]... I mean, it's usable, but I think it can be improved.

Aaron van Wirdum Right, sure. Okay, any last thoughts on this topic before we move to the last one on our list?

Sjors Provoost No, let's move.

Aaron van Wirdum Okay, last one on our list is... You explain this to me.

Sjors Provoost NAT-PMP and Port Control Protocol, PCP. We have covered this in earlier episodes. It's a lonely world out there, especially if you run your node from a residential place. Typically, your router will block any connections to you. So your node can reach the outside world, but the outside world cannot reach you. And there's various methods that's often used.

Aaron van Wirdum It's a don't call us, we'll call you kind of logic.

Sjors Provoost Yes. And now, you know, in the world of gaming and torrents, et cetera, there have already been methods developed to change that so that you can actually listen to people connecting to you because there's some performance reasons that you want to do that and other reasons why you want to do that. And Bitcoin Core was using that from very early on, like 2012 or even earlier. But the method it was using back then was unsafe. It was called UPnP. And so it was kind of turned off by default. It's there. It's always been there, but it was off because there were too many vulnerabilities in the software. And as of recently, we have a brand new method. By brand new, I mean it's a 10-year-old standard probably, called PCP, Port Control Protocol. It's been implemented from scratch in Bitcoin Core itself. And as of version 30, it's on by default. So that means if you install your node freshly and if your router supports this protocol, which it may or may not, I think a lot of modern routers will support it, your node is listening, which means you're going to have a bit more connections and the network is going to be more robust.

Aaron van Wirdum Yeah, so... Basically, normally, if you start up a node, then you can connect to other nodes, but other nodes cannot connect to you, which means there is essentially a subsection or a sub-community, whatever you want to call it, of Bitcoin Core nodes that are providing more services or more connection to the rest of the network than others.

Sjors Provoost Yeah, they're going to be better connected, and also there's a demand on those nodes because... There's only a limited number of them and everybody wants to connect to them.

Aaron van Wirdum Yeah, so it's a slightly centralizing factor, actually, that everyone sort of initially...

Sjors Provoost I wouldn't say centralizing because there's plenty of them. But they could get overloaded. If the ratio becomes too asymmetrical, then the few nodes that are listening will get completely overwhelmed.

Aaron van Wirdum I didn't say centralized, but I would say that is a sort of centralizing aspect, right? It's better if all nodes are sort of equal in that sense and everyone helps each other rather than everyone relying on some subset.

Sjors Provoost It's better, but I don't think there was a risk of centralization here. But I do think there's just a risk of overloading these resources. And part of the problem is because we want to move away from... So Bitcoin nodes want to connect to a diverse set of peers, not in the woke sense of the word, but in as many places in the world, like different countries, different networks, so that it's harder to trick you for one network operator to trick you. There's a new project we talked about years ago in a podcast called ASMAP, where we try to map the internet and then try to connect it really to different countries, etc. And one of the side effects of that project is that we might start connecting to very obscure places. And a lot of nodes would start connecting to those very obscure places because they're trying to diversify a bit too much. And then those, like you run in some random place in South America. You have an internet provider with just one Bitcoin node in it, and thousands of nodes try to connect to you because you are very unique and special. And so if more nodes are listening, then hopefully on that obscure internet provider, there's also going to be more nodes listening. So not all the traffic just goes to that one listening node.

Aaron van Wirdum Yeah, okay. And this is... So what exactly is new in Bitcoin Core? Like this is now just a thing or?

Sjors Provoost So this feature has been in there since the last version, but it's now on by default. So if you upgrade and you didn't manually turn it on or manually turn it off, it will be on. Then if you turn it off, it's not going to be turned on.

Aaron van Wirdum Then it can be called by the outside world.

Sjors Provoost If your router supports it, yes.

Aaron van Wirdum Okay. Do routers generally support this or what's the if there?

Sjors Provoost I'm not sure. We'll find out. It should be pretty clear in the stats that the number of listening nodes would go up dramatically. Because at the moment, most of the listening nodes are on Tor because the way people set up their Tor nodes usually is such that they're also listening. So that's why some people are saying, oh, the majority of Bitcoin nodes is on Tor. Well, that's not true. The majority of listening Bitcoin nodes is on Tor. But that might no longer be true eventually.

Aaron van Wirdum Right, right. PCP is also a type of drugs.

Sjors Provoost That's not my expertise, but you tell me.

Aaron van Wirdum Coincidence?

Sjors Provoost I think every three-letter acronym probably is.

Aaron van Wirdum Okay. I think we made it through the list, Sjors.

Sjors Provoost We did. Well, in that case, unless you have anything to add?

Aaron van Wirdum No, where can people find this? Where can people find Bitcoin Core 30?

Sjors Provoost BitcoinCore.org.

Aaron van Wirdum Okay. Thanks, Sjors.

Sjors Provoost Thank you for listening to Bitcoin

Aaron van Wirdum Explained.