Glozow rejoins me to talk about updates coming to Bitcoin’s transactions and mempool policy. We talk about how these will be essential to keep bitcoin use efficient and safe, especially for layer 2 protocols such as Lightning. We chat:

• Current state with transacting
• RBF and CPFP
• Problems right now
• L2 security
• Pinning vectors
• What is package relay? 
• What is v3 transactions? 
• What are ephemeral anchors? 
• Policy vs consensus

Links:

• Glozow on X
• Waiting for confirmation – blog series on Bitcoin Optech
• v3 and Package RBF Bitcoin Core Review club
• Bitcoin Optech v3 transaction relay 
• Glozow slides for BTC++ talk: v3 and ephemeral anchors

Previous Episodes:

• SLP404 Gloria Zhao – What Do Bitcoin Core Maintainers Do?
• SLP216 Gloria Zhao Learning Bitcoin Core Contribution & Hosting PR Review Club

Sponsors:

• Pacific Bitcoin Festival (code LIVERA)
• CoinKite.com (code LIVERA)
• Mempool.space

Stephan Livera links:

• Follow me on Twitter @stephanlivera
• Subscribe to the podcast

Podcast Transcriptions:

Stephan:
Gloria aka Glozow. Welcome back to the show.

Glozow:
Thank you for having me again. It’s

Stephan:
So,

Glozow:
a pleasure to be here.

Stephan:
yeah, I always enjoy talking with you and I know you’re obviously very focused on Mempool and some of these things and we’re gonna get into some of this stuff today. I think there have been some updates and I just think it would be interesting for listeners to understand and maybe for some of them to get a refresher, obviously, because many of them might have listened to the prior episodes you did. But also there’s probably new things for them to learn and understand because the conversation shifts over time as well. So, yeah, so today we’re mainly talking about V3 transactions, package relay, all these, you know, associated ideas, transaction pinning. But do you mind giving us a bit of an overview? What’s our current state of play? Why are there still, let’s say, quote unquote, problems with

Glozow:
Mm-hmm.

Stephan:
transactions and the mempool in terms of how it applies today?

Glozow:
Sure, yeah, I think a lot of people are maybe experiencing fluctuating levels of fee market conditions these days. So maybe all the way from the beginning, we have limited block space, each block can only have a certain amount of transactions by weight in them. And we try to have a kind of fee market way of deciding what gets confirmed and what isn’t. And so the way that you might communicate to miners that your transaction is more urgent is by putting a high fee rate on it. And miners are hopefully incentivized by the fees and not who’s their buddy and who’s not. And so they put the highest fee rate transactions, the most profitable ones into their blocks when they mine them. And so you are actually not tied to just the fee rate of the transaction that you broadcast first. we have ways of bumping our fees. Let’s say you undershot it or you want it to confirm faster, or your fee estimator is not very good and you’re trying to minimize for fees. So you start from a very low fee rate and then you can bump that over time until it confirms. That’s a great strategy. And you have two ways of doing that today. One is RBF, which stands for Replace by Fee. in which you create a new transaction which conflicts with your original payment, if you’re familiar with the UTXO based design of Bitcoin transactions. So it’s impossible for them both to confirm. By consensus, they’re incompatible. They’re double spends. And an intelligent mempool policy, such as one that implements the BIP 125 replaced by fee policy, will kind of intelligently see like, okay, this one pays higher fees. So I should probably replace the one that I have now with this new one. And so thereby they’ve accepted your new transaction and you’ve bumped the fee of your transaction. The second method is CPFP, child pays for parent, where again, with the UTXO based model, you spend one of the outputs, for example, the change or your received payment if you’re the recipient. in a child transaction with a really high fee rate. And again, we have these kinds of intelligent algorithms to detect, hey, if I mine this low fee rate transaction, I get the really high fee rate one, that’s its child. And so you’ve effectively changed the effective fee rate of this two transaction package.

Stephan:
Yeah.

Glozow:
Yeah, those

Stephan:
And when

Glozow:
are

Stephan:
it comes

Glozow:
the two.

Stephan:
to that, right. And so as you mentioned, there’s RBF and child pays for parent today. We’re going to get into some of the problems later, but can you give people just a rough idea how much more they need to pay? So as an example, let’s say I’m sending a transaction to you and I absentmindedly set it at one Satoshi per V byte, per virtual byte. And then

Glozow:
Mm-hmm.

Stephan:
I’m like, oh no, it’s not confirming, you know, how much more do I need to make that to get it to you?

Glozow:
So the absolute bare minimum is probably a 1SAT per VBITE increase in the fee rate. We’re talking about RBF here, are we? So there are rules. So I want to shift away from RBF being something that users do, and it’s more something that nodes do. It’s like this algorithm that we use to determine, OK, this is more incentive compatible. a DOS component. So we want to avoid a situation where you can do thousands and thousands of replacements where you add one Satoshi each. And from the node’s perspective, that costs bandwidth because you have to download it and then you go and upload it to other peers and then they also broadcast it to theirs. There’s a bandwidth component and there’s a validation computational component because you have to relook at all these signatures. and revalidate the transaction, recalculate any ancestors that might have an update that you’re mempool to account for this new transaction. There’s a cost to each node to do this replacement. And so there is a certain amount of extra Satoshis that you need to pay. So there’s that kind of bare minimum is the cost, the size of the new transaction at one Satoshis per V byte is the increased amount of absolute fees that you need to pay. You have to have new fees, essentially, to pay for the new bandwidth usage. But for a user, I think if you’re going from one sat per VBite and you go to five sats per VBite, that’s usually pretty fair. Or if you go from five to 10 or whatever, that’s, I think, how it usually works in

Stephan:
Right,

Glozow:
wallets.

Stephan:
yeah.

Glozow:
Yeah.

Stephan:
And as you rightly say, because there’s a difference between what the user sees and what we’re talking about here is also what’s happening at the node to node level. And what we’re talking about here is how nodes relay transactions to each other, right? Because as you were saying, you know, of course we wanna have a free market, but there are certain rules about, as you said, DOS, meaning denial of service. So

Glozow:
Yes.

Stephan:
I guess how I’m understanding that, just to explain it in simple terms, is this idea that If I was malicious and I was just kind of spamming it out there, I can sort of push a lot of cost to other people, because if I just put these little transactions,

Glozow:
Exactly.

Stephan:
every other node has to now look at that transaction and then look at the ancestors, as in the ones that came before, and then sort of recompute, oh, okay, what other transactions are being touched on here and what are the other signatures involved? And then I can very quickly maliciously… create a burden on other people. And that’s why there are certain rules that currently restrict what exactly you’re allowed to do. And that’s where RBF, like rule three and rule, I think it’s rule five, are probably the important ones. So could you just explain a little bit about those rules?

Glozow:
Yeah, so it’s rule three and four. I touched on it a little bit. But yeah, essentially, it’s exactly what you said, where you’re trying to protect your nodes resources. And then there’s like DDoS, or Distributed Denial of Service, because there is a kind of magnified component, where not only are you doing work, but you’re having every single person in the network also download and broadcast and validate and whatnot. And so rule three. So OK, maybe we can just go through the replacement rules They’re not that difficult. One is we have this BIP 125 signaling rule. So today, a lot of nodes will respect, like if your n sequence numbers are set to a certain amount, we don’t do replacements. That’s rule number one. Rule number two is you can’t have new unconfirmed outputs. We can just gloss over that one. It doesn’t really do anything anymore. And then rule three and four are you have to increase the absolute fees of the transaction. So you have your replaced transaction and your replacement transaction. Your replaced transaction can have descendants. So if it was CPFP or somebody spent a change output from it, for example, all of those need to be evicted because those depend on a transaction that’s not going to exist anymore. We take the collective fees of all of those transactions and you need to beat that. And I’m not talking about fee rate here. I’m talking about absolute fees. And you consider those as paid at some point in the past. And you have to pay essentially new fees. So you have to have that absolute fee amount plus more. And the additional, this is rule four, has to cover the new transaction at one sap per V byte. And you can think of it as you pretend you’ve already quote unquote, paid the fees that you did before, you have to pay new fees in order to pay for the bandwidth of this new replacement transaction. And that is the DOSing. So if you increased one Sat-Pro-V by, sorry, if you increased one Satoshi, for example, then you would have that DDoS problem. Does that make sense? Yeah.

Stephan:
Yeah, I think I’ve got you so far. And so then in terms of our approaches for dealing with some of these things, and I think commonly this will, in the years to come, that will probably apply a lot in things like Lightning. And as you have spoken about in one of your talks, and I mean, Lightning developers talk about this idea is when you open that channel, we’re having to presign. the commitment transaction, which is the transaction that closes the Lightning transaction. And we’re having to sort of guess what we think the fee will be, but actually the fee could really change. And so there are some issues created by having to do this, right? Because we either have to guess, and that means maybe we overshoot or undershoot. And so then, you know, that brings in and necessitates further tweaks and fixes. As I understand, a lot of Lightning developers are looking at things like anchor outputs. which is like another way to be able to change the fee afterwards. So if you could just elaborate a little bit about that process and some of the issues associated.

Glozow:
Yeah, so a lot of people know me for working on package relay, which is kind of the solution to essentially a big set of problems that I like to think about. And it largely centers around fee management, where it is a security issue. So I guess the security of smart contracting protocols, or L2, as relates to mempool and fee management. So we talked about fee management as a kind of like nice thing where you can tell minors, can you please confirm this faster? But there’s a certain set of conditions where it becomes a security problem. And that being like smart contracts and L2s. So with smart contracts, I’m defining that as you and some untrusted party or some other set of parties. are entering into a contract where you create a transaction together or you create a UTXO that is shared with you and other people, where you enumerate all of the spending paths. And that is embedded in the script in order to spend this UTXO. And that’s your contract. So for example, in Lightning, you’re saying, hey, we share this UTXO. And we can pay each other such that within this certain amount we can both collaborate to withdraw these funds or pass this certain time lock, then you’ll be able to withdraw these funds. But then, oh, if I can prove that you’re cheating and you’re claiming funds that don’t belong to you, we can revoke that. Like we’ve enumerated all the ways that we can spend this money together. And like you said, the one big characteristic of that is that your signing time might be very, very different from your broadcast time. And because there’s time locks involved, You have a time window in order to get something confirmed, otherwise a new spending path opens. So it’s not just, do I get paid faster? But it’s like, do I get my money at all? Or the other person gets to cheat

Stephan:
Right.

Glozow:
me.

Stephan:
And so this could be in the scenario of one person cheating. It could be, or potentially even in the scenario where somebody’s gone offline or maybe

Glozow:
Yeah.

Stephan:
somebody has restored from a backup and maybe their connectivity is really bad. So there’s all kinds of issues that can come here. And I guess the worst, maybe worst case scenario is if the, if the fees that we agreed to at the start were very low, but

Glozow:
Mm-hmm.

Stephan:
then one of us has gone offline and the fees have gone really high,

Glozow:
Exactly.

Stephan:
then the other, the other guy or the other person in that channel in that example could be up the proverbial creek without a paddle, right?

Glozow:
Yeah, exactly. So right now, we’re in this like, it’s great, because it’s actually illustrating what I’ve been talking about for years, is we’re in this era of no 1 sat per v byte transactions propagating. Or maybe they do. But for default mempools of size 300 megabytes, there’s high enough traffic today that anything lower than I think it’s like 6 sats per v byte. is getting evicted because you keep the most incentive compatible transactions because they’re more likely to mine. So if we went into a Lightning channel today, or sorry, not today, but like ages ago, and we signed our transactions at one sat per VBite because that was fine at the time, and we had anchor outputs like you said. So with Lightning commitment transactions, they’ll have anchor output. So that’s an output that is specifically for the purpose of CPFPing. It doesn’t actually pay anybody. It usually has, I don’t know, 300 something Satoshis in it. Each Lightning Commitment Transaction will have two, one for each participant so that they can each CPFP any transaction belonging to their channel that they see in the mempool. Let’s say it was once I pervibite and they added anchor outputs. Today, if we broadcast one of those commitment transactions, it wouldn’t. it wouldn’t go very far. I think there’s like the mempool space like submitter and they have they’re connected to miners and electron servers that have really big mempools so maybe you’ll be fine. But all the default mempools and their smaller ones as well will just like throw that

Stephan:
We’ll

Glozow:
away

Stephan:
drop you

Glozow:
immediately

Stephan:
out. Yeah, you’ll be,

Glozow:
or they won’t

Stephan:
yeah.

Glozow:
ask you to send them through fee filters they’ll be like hey I’m not taking anything below 10 sats per vbyte or 7 sats per vbyte so don’t even bother announcing that to me. we’d be really, we’d be in trouble being able to get something confirmed. And

Stephan:
I

Glozow:
we

Stephan:
say

Glozow:
wouldn’t

Stephan:
yeah.

Glozow:
be able to sign something new, sorry, just to

Stephan:
Yeah, go on.

Glozow:
like highlight the conditions. It’s the time lock, the broadcast and signing time are different. But also most importantly, is you’re not able to sign a new transaction with each other. So we talked about RBF, like you can see PFP, but we talked about RBF as one of the solutions. available to most users. That’s not available when your channel party is offline or trying to cheat you. They’re not going to agree to sign a new transaction with you. So RBF is often not an option. Although what I’m trying to work on as part of package relay and the validation things is to add a policy where you can have package RBF. So even if you have to, sorry, so if you have a that you’re trying to replace. Hopefully you can add a child to one of the anchor outputs and the child’s fees will also count for replacing the conflicts of the parent. So you’re not just locked in to the fees that you put on that commitment transaction or that transaction that you signed

Stephan:
I see.

Glozow:
ahead of time.

Stephan:
And just to be clear, what we’re talking about here is also in the case of unconfirmed transactions, correct? Right?

Glozow:
Yeah,

Stephan:
So

Glozow:
yeah, yeah.

Stephan:
what we’re talking about here is not just transactions that have actually been confirmed into a block. It’s that there are transactions, you know, in quote unquote, the mempool or in all of the nodes mempools and giving nodes the ability to safely look at the unconfirmed transaction and the child of that transaction in a kind of safe way. So I guess

Glozow:
Mm-hmm.

Stephan:
we’re sort of like, I guess In an analogy, an analogy might be you’re trying to thread the needle here of trying to allow nodes to look at descendant transactions without being DOS is

Glozow:
Yes,

Stephan:
kind

Glozow:
exactly.

Stephan:
of the that’s kind of we’re trying to thread this needle here of allowing this but not allowing the bad side of it. Is that

Glozow:
Exactly.

Stephan:
kind of a fair summary? Yeah.

Glozow:
There are so many pinning. There are so many problems that are essentially this trade-off between, OK, when we’re designing mempool policy like RBF or Package Reader or whatever, we’re trying to be really protective of the node resources. But then on the other side, there’s what users need. And we have to find some trade-off in the middle that’s like, sorry, you can’t have the twi- the- the 30th descendant of this transaction, or you can’t make a cluster, you can’t make thousands of transactions that depend on each other. And a user might be like, oh, I just wanna keep CPFing or something, but we have to make a trade off. And sometimes the trade off that we choose is harmful for. like user usability because we’ll always try to be conservative with DOS. Like it wouldn’t really be OK if we were like, oh, we just make this trade off. It’s OK if the node stall for like 30 seconds. That’s that’s never going to be OK. So we’re quite conservative and we lean towards the anti-DOS side.

Stephan:
Okay, gotcha. And so can we then talk a little bit about, I guess, so we’ve been touching on this, the transaction pinning, as you mentioned, there’s rule three pinning and rule

Glozow:
Mm-hmm.

Stephan:
five pinning. I think some of the, I mean, there are different pinning

Glozow:
Mm-hmm,

Stephan:
vectors, but I think those

Glozow:
yeah.

Stephan:
are probably the main two ones that people are thinking about. Could you just explain a little bit about that and how it would work in a transaction pinning attack? Yeah.

Glozow:
Yeah, so we already explained what rule three is. Oh, we forgot to go through all the RVF rules. So rule five, real quick, is you can’t replace more than 100 transactions at a time. So like I said, you will conflict with a transaction. You have to actually get rid of all of its descendants as well. And it might have, let’s say, 20 descendants. And maybe you’re conflicting with actually five transactions because you’re double spending all of them. If it exceeds 100, then we don’t do the replacement because we’re just evicting so much of our mempool that it’s worrisome what we can do to thrash people’s caches. A mempool is a cache, essentially. And then there’s rule six, which is not in the, it was added later, is the new transactions fee rate has to be higher than the previous, which I think

Stephan:
Pretty obvious.

Glozow:
it’s not impossible to do without. breaking one of the other rules, but it is possible to have a lower fee rate transaction that meets the absolute fee requirements. So back to pinning. I think rule five is really easy to explain. So let’s say you were potentially trying to, you were trying to replace a bunch of things either. I think with Lightning this would only occur if you’re trying to do a batched package RBF. So you wouldn’t really hit this today. So it’s not really a concern. And you were trying to replace, let’s say, five commitment transactions. And each of those commitment transactions had a conflict in the mempool because they’re all the same Mallory person who’s trying to steal from you. represents a different state from your channel. And of course, all commitment transactions conflict with each other because they all spend from the same funding UTXO that you and your counterparty locked yourselves into. And so you go to broadcast those transactions, and they all conflict with something. And let’s say in addition to kind of pre-broadcasting these conflicting commitment transactions, those parties also attached a bunch of descendants to it. So. from their anchor output, they added a child, and then they spent another child, and then they spent another, da, da. And so suddenly, there’s like more than 100 transactions out there that you would potentially have to replace. And you’ll hit that rule five limit, and then most nodes will be like, sorry, that’s too much. I’m not gonna do this replacement.

Stephan:
I see. So the malicious example of that would be, you know, we have a lightning channel together, but I’m malicious and I do this rule five pinning by just kind of maliciously adding new and new descendant, new descendant, new descendant until I’ve got over

Glozow:
Yep.

Stephan:
a hundred. And then

Glozow:
Yes.

Stephan:
you’re basically stuck at that point because you can out, you can’t fee bump anymore and you’re just kind of stuck. And in that scenario where, you know, like it is today, if you, if, if it’s all effective fee rate of one set per V by, but the prevailing rate to get in confirmed is like five or six sets. That’s the point where in that case, if I’m malicious, I’m stealing from you and I’m getting away with it, right?

Glozow:
Yeah, yeah, a lot of it is kind of this, like, in a lot of scenarios today, if, like, the problem arises when you are like, oh, I need to go and broadcast a close, but then there’s already someone there, you might not know that, right? Because there’s no such thing as the mempool. There,

Stephan:
I see.

Glozow:
like,

Stephan:
It’s

Glozow:
it

Stephan:
possible

Glozow:
might be…

Stephan:
that you don’t see all the transactions.

Glozow:
Yeah, you haven’t seen it, but like, you know, minors already have the first version because Mallory, you know, got ahead of you and you weren’t, you didn’t have like a bird’s eye view of every single person’s mempool. So you didn’t realize that she had already broadcast something. And that’s really annoying. Like what we would love to have is, of course, you don’t, is to not have a bird’s eye view of mempool. And what you do is you broadcast what you have with a fee bump to today’s medium. priority, and then you keep bumping. And you can assume that one of these is going to confirm. Whereas today, you’re like, well, there might be something in somebody’s mempool that you can’t replace. So it’s more of what do you need to do in order to be secure? I think there’s definitely ways to skirt around all of the, or most of the problems today. all kinds of monitors going and you try to watch mempools and whatnot. And I think there’s a lot of businesses that outsource this to a third party that has many block explorers and feeler connections and is seeing what is announced and who has what. That shouldn’t be a requirement for you to have a secure mining node. Ideally, you don’t have to be watching all these things and you’re just like, all right, we’re going to broadcast and we’ll let the free market do its thing where it’s going to take, you know, the highest fee rate stuff because we’re willing to pay the fees. So, you know, hopefully it’s somewhat efficient and doesn’t require us to look around every corner. Yeah. And then rule three pinning is again with this idea of you broadcast your commitment transaction. There’s one that you conflict with. This is a world where we have package RBF. And instead of attaching a bunch of descendants to it, they just attach one big descendant that pays a lot of fees, but is pretty low fee rate. So for example, you can attach up to 100. You can have a descendant package of up to 101 kilovertual bytes, which is way larger than the normal transaction. You can attach one and have it pay, let’s say, one sap per V byte. And that’s 100,000. Satoshi’s that you’re paying right, which is which is pretty high. I think that’s like twenty five dollars today. And that means that like they’re not fee bumping any. Like it’s just one sat per VBI. It’s not a CPFP. But if you want to replace that commitment transaction, you have to pay at least one hundred thousand Satoshi’s in addition because of rule three, because, you know, we have this rule that says. if you want to do replacement, you have to pay all of the original fees plus some extra. And that’s maybe not fair in this situation because this transaction wasn’t doing anything. It’s clear that you’re trying to do a replacement that pays way more. But if we were to get rid of this rule three, then we might have a DOS issue.

Stephan:
Gotcha. And so then, yeah, that’s where some of these solutions are coming in. And so you’re known for obviously talking about this idea of package relay, but there’s also other elements here. So there’s package CPFP, package RBF, and v3 transaction. So could you just explain how these pieces fit together for us?

Glozow:
Yeah, so we did kind of skip ahead a little bit. So package relay and package RBF. So today, you wouldn’t be able to replace something that because you’re only you’re doing one transaction versus one transaction. And you don’t get to use the child to pay for replacement. But that’s something that we want to fix. And obviously, we also talked about the kind of mempool minimum fee rate being higher than one sap per V byte. So if you have a one step per V byte transaction, that has to make it into the mempool first before you can bump it. But package relay is like, OK, why don’t we relay transactions as a package and we evaluate them as a package so we can immediately see, OK, this is low fee rate, but it comes with this child. So I’ll look at them together and submit them together. Oh, cool, they meet the fee rate requirements. And the hope is that, for example, this like parent could be zero stats per V by in the future. So that for a contracting protocol like lightning or DLCs or vaults or whatever, you could just kind of rely on there being like you’ll add fees later and then you never have to like overshoot because today you have to overshoot. Like you have to sign everything with the idea that, oh, the minimum rate, the minimum fee rate could rise. So we have to put it at like 20 stats per V by for example. and potentially overpay. And so that’ll hopefully save people money and also get rid of some of these limitations. So that’s package relay and package RBF and all of the kind of policies that go along with it that are supposed to emulate what you can do with CPFP today, but without the limitation that they go one at a time. And so while I was working on package relay, I was kind of interested in all these problems with pinning attacks. So I think it was like almost a year and a half ago, or maybe almost two years ago, I essentially went around and I was talking to Lightning developers, and I was looking at RBF, and I came with a list of issues and grievances and pinning attacks. that everybody was running into, and I posted that to the mailing list. And I said, like, okay, like we have these problems. There’s kind of a range of solutions that we could go for. So package relay is the type of thing where we’re kind of like fundamentally re-architecting something, or like we’re making very invasive changes because like instead of doing one at a time, we have this like more generic package idea. We’re re-architecting a lot of things. And there’s like even more invasive changes that we can do that some people are working on to like fundamentally re-architect mempool so that, you know, the complexity of doing such an operation. I’m going to simplify this. So like the complexity of certain operations are more complex, but it means that we can do these other things in a computationally simple way, like we’re caching more things or we’re doing other things more lazy like Sorry, I’m speaking to the software engineering listener here. We’re changing the way that this data structure is designed. And so there were those kinds of solutions. There were like, let’s just change the RBF policy. A lot of people were like, let’s get rid of rule three. And I think today we’re sitting here and we’re saying, yeah, there’s just no way because there’s no other way to kind of guarantee this bandwidth DDoS is prevented. And then there was one idea which is like, well, there’s this problem essentially today where people are entering into smart contracting agreements. They’re saying, hey, we have this transaction with this very specific use case. And our current kind of ancestor descendant allowances in our mempool policy. are just way too permissive. Like the fact that you can attach 25 descendants to a commitment transaction doesn’t make any sense. Like nobody wants that. Like there are no lightning use cases where after you broadcast your commitment transaction, you then add 25 things chaining off of it. And it would be so much simpler if we just allowed one parent, one child, or like end parents and one child. Cause all we want to do, like the only thing we would ever want to do with unconfirmed lightning commitment transactions is bump them so that they confirm, right? And so I think it was Blue Mat and a couple others were like, well, why don’t we just restrict the descendant limit? And so there was some exploration of like, can we do that for all transactions? That would be great. Can, and you know, that doesn’t work because there’s definitely use cases out there where you might want. multiple

Stephan:
Right,

Glozow:
descendants.

Stephan:
maybe as an example, so I guess maybe in a joking way, this is Bitcoin’s single child policy.

Glozow:
Hahaha!

Stephan:
But anyway, putting that aside, as I understand, there are some uses where exchanges, for example, doing batch payouts, I think they sometimes use this kind of thing where, you know, let’s say they’re doing a payout to 10 users and in that same time they’ve seen, oh, another five users want to get a payout, attach another descendant to that

Glozow:
Mm-hmm.

Stephan:
transaction. So does that screw them over or are they still able to do this case?

Glozow:
Yeah, so with my kind of philosophy for policy changes is to only like reduce restrictions instead of adding new restrictions because anytime you add new restrictions, you have to basically go and talk to like every user of Bitcoin and be like, is this okay? And that’s very difficult. But luckily, we have a lot of kind of things that are non standard that we can use to add new rules without like restricting anybody. So anything with version 3 and version is a field in transactions. Anything 3 and above is currently non-standard. So they wouldn’t be relayed by the vast majority of nodes unless they have some custom policy.

Stephan:
Right, so I guess we can say it’s like an opt-in scheme here that you’re creating.

Glozow:
Yes,

Stephan:
And

Glozow:
yes.

Stephan:
in the future, the hope is that more and more people just opt into a V3 environment and we’re all just in a V3 world. So then we can think of it like one parent, one child that simplifies things.

Glozow:
Exactly, exactly. And it’s hopeful, like it’s only really meant for smart contract, L2 contracting protocol kind of thing. So it’s opt in. Everybody else can just continue using V2 and, you know, get pinned and whatnot. But for most people, like it doesn’t even matter, right? Like you’re never going to have descendants. Like you’re not sharing this transaction with anybody. You’re just trying to pay someone. But for these kinds of ideas where, sorry, these kinds of protocols where you have an untrusted party and you can agree, you can sign everything V3 to start with, you’re like, hey, is it okay if we agree to not add more than one descendant to this commitment transaction should it ever end up in mempools or when we broadcast it unconfirmed? And it’s like, well, yeah, sounds good. And it’s so simple, it simplifies so many things. So like, there’s many, many pinning attacks. I can link my mailing list post or whatever. And some of them, like I said, it’s just like not solvable unless you’re willing to expose yourself to like checking every single transaction in the mempool to assess, like to calculate a score for this transaction. And we can talk about why that is. I’ve talked about this in other places as well. because of just like the sheer amount of possibilities for ancestors and descendant relationships in transactions and mempools. And but with one parent and one child, there’s, this is very simple. You just like, you just take the minimum of two

Stephan:
Yeah.

Glozow:
scores.

Stephan:
And so just a quick question on that. So in that, so let’s say we’re in a V3 world and

Glozow:
Mm-hmm.

Stephan:
you know, people are doing lightning. Let’s say somebody tries to broadcast an old state, the other,

Glozow:
Mm-hmm.

Stephan:
and so that they’ve created a new child, I guess what I’m trying to get at is can you only fee bump at once or is the second or third fee bumps just replacing that child? That is that you get what I’m

Glozow:
Ah,

Stephan:
saying?

Glozow:
yes, so it depends on what the transactions look like. So today, you’ll each have an anchor output. Oh, sorry, in a proposed view. OK, yeah, so we would change kind of how commitment transactions are constructed for Lightning as well. So the way that Ellen Penalty works is you have a commitment transaction that’s your version of the state and your counterparty has a mirrored. version. And right now they each have two anchor outputs, but in this case you would just have one because you can always replace the other one with your commitment transaction, with your output. So yeah, you would attach a child to it that pays fees and then if you want to bump it again, you just RBF that child.

Stephan:
Yeah, I

Glozow:
Correct.

Stephan:
see. So it’s not new

Glozow:
Yeah.

Stephan:
descendants, you’re actually just RBFing

Glozow:
Yes.

Stephan:
that same child transaction, just so I’m

Glozow:
Exactly.

Stephan:
getting it right. Okay.

Glozow:
Yeah.

Stephan:
Okay, there’s one other area, one other concept I noticed, this ephemeral anchors

Glozow:
Yes.

Stephan:
thing. So can you just, can we talk about that? What is an ephemeral anchor?

Glozow:
Yeah, it has a way cooler name than V3, and I wish I thought of something cooler. So the way we talked a bit about how anchors work today. So today, you have two anchors, and then in this hypothetical V3 future, you’d have one anchor per commitment transaction. There’s a few kind of limitations with that as well. So one is because we. don’t want to hit descendant limits. Everything on a commitment transaction other than the anchor output actually has a one block relative time lock in order to spend it. So like usually a commitment transaction you’ll have your anchor, but you’ll also have like, oh, Bob has this much in their channel balance, Alice has this much, and then you can redeem those after the transaction confirms. And there’s a one block. So this transaction has to confirm, the commitment has to confirm before you can broadcast a spend of redeeming your coins from that transaction. And there’s no purpose for that other than the fact that we don’t want unconfirmed descendants spending from anything other than the anchor output. Because we have a descendant limit and. For example, if your counterparty were to attach 25 descendants to all their outputs, suddenly you can’t even use your anchor output anymore. So that’s one problem with the way just lightning works today is you can’t redeem anything before the one block expires. And that’s just how it works right now. We have this carve out thing in mempool policy where you get like one extra one. but that is super ugly. It’s like always the bug when something fails. And it doesn’t make any sense. It’s just complexity for no reason. CPFP carve out, I can link the PR and the mailing list post for that. You need one for each participant. Of course that goes away with the V3 thing. And you have to allocate part of the channel balance to put in the anchor output. So we have a dust threshold in our policy where you can’t have like two Satoshis in an output because it’s very likely that nobody would ever want to spend this UTXO because it would cost

Stephan:
It would cost

Glozow:
more

Stephan:
more than, yeah.

Glozow:
to spend it. Yeah, then it’s worth. So the dust threshold specifies that you can’t really be below, I think it’s like 300 something or whatever, Satoshis. And so that comes out of the channel balance. And that is a blocker for L2 or L in symmetry, which is something that Greg Sanders has spent a long time prototyping and kind of figuring out all of the security and the pinning problems with it. And because the way that, we don’t have to get into it, but it’s a blocker to be shaving channel balance because then at every update, you have to like shave off 300 Satoshis from. from your balance. So you’re like leaking value as your blinding channel like goes on, which just doesn’t work. That’s not the case today because you’re making conflicting. Anyway,

Stephan:
Yeah, gotcha.

Glozow:
so these are all kind of the limitations with anchor outputs. With V3, we get rid of the, I think we can get rid of carve out and we can get rid of one per participant, just one anchor per commitment transaction. But you still kind of have this problem of like having to put 300 Satoshi’s into it. and the one block relative time lock. And so, ephemeral anchors, it’s taking me a while to get here, solves these problems by just kind of changing the way that the transactions are signed again. So, ephemeral anchors gets rid of the dust threshold rule for a very specific type of package. So,

Stephan:
Okay.

Glozow:
if the commitment transact or the parent is zero SATs per V byte, as in we can guess that it would never confirm on its own, and it has an anchor output, we guess that it would definitely be spent because it has to be V bumped by something, right? And so that anchor, that ephemeral anchor, is supposed to only exist while you’re validating a block. Like it’s never going to hit the UTXO set. It’s going to appear once in your UTXO set while you’re validating this block and then immediately be spent by a fee bumping transaction. And this is like a V3 package. So it’s only ever gonna be one parent and one child. This child’s not gonna pay for anybody else. This parent’s not gonna have any other children paying for it or spending from it. So it has to be this one. parent one child package and it has an anchor that is definitely going to be spent because the parent is zero sats per V byte. So ephemeral anchor says like, okay, well, why, let’s get rid of the dust threshold because we can be reasonably certain that this UTXO is ephemeral. It’s

Stephan:
Okay.

Glozow:
never going to actually appear in any chain state. It’s going to get spent in the same block.

Stephan:
Okay, so is it sort of like having a zero SAT anchor output,

Glozow:
Yes,

Stephan:
and

Glozow:
yes.

Stephan:
we can sort of use it programmatically as part of our layer two contracting protocol in an opt-in sense? And so this is kind

Glozow:
Yes.

Stephan:
of like, eventually the goal is to, as you were saying, have all of these pieces, like these pieces of the different pieces of the puzzle together, right? Whether that’s package relay, package RBF, package CPFP, V3 transactions, and

Glozow:
I’m all

Stephan:
anchor

Glozow:
like this.

Stephan:
outputs. Oh, sorry, ephemeral anchors, sorry. You

Glozow:
Yeah.

Stephan:
get all of these pieces together. And then we are making layer two protocols more secure, right?

Glozow:
Yes, exactly. It’s things will be more secure. Ellen symmetry will be possible because you won’t have this leaky thing happening. And yeah, that’s kind of the future that we’re aiming for. There was a lot of work that went into it. And I mean, all these PRs have been open for quite a long time and they all build off of each other. So,

Stephan:
Yeah.

Glozow:
you know, it’s going to take a while. But it’s really cool to have. all of this kind of written out. Like we could have a, we could live in a world where we don’t have to worry about pinning, where you don’t have to put any fees on your commitment transaction. You just pay exactly what you need in order to get something confirmed when you broadcast it. You don’t have CBFB car value. You don’t have these one block relative time locks. You can redeem stuff directly into vaults. Like there’s, you know, all these amazing things that can happen if, you know, we get all five of these proposals

Stephan:
Yeah,

Glozow:
in.

Stephan:
okay. And so basically all of these are still, I guess, in progress to be clear.

Glozow:
Yes, everything’s

Stephan:
Yeah.

Glozow:
in progress. Everything’s been open for a while.

Stephan:
But yeah,

Glozow:
Yeah.

Stephan:
but it’s good for just people to understand these things. And I guess, you know, just to confirm for listeners, it’s not a soft fork, right? Like this is just

Glozow:
Exactly.

Stephan:
upgrades or updates into Bitcoin core. Right.

Glozow:
Yeah, yeah. So all of this is non consensus. I have this like kind of thing where I think consensus is like, a bit overrated. It’s like very talked about in podcasts and

Stephan:
Right.

Glozow:
on stage at conferences and stuff. But we can do a lot just with just changing the peer to peer protocol.

Stephan:
Right.

Glozow:
Like changing

Stephan:
Yeah.

Glozow:
the protocol like There are other protocols that make up Bitcoin, including the peer-to-peer protocol. And policy is not consensus, but we can still achieve quite a bit by creating a policy that makes sense for everybody to use and everybody to run that give us the benefits of DOS resistance and things that users can use

Stephan:
Yeah.

Glozow:
and security and all these things.

Stephan:
While we’re here, do you mind just explaining for us what’s the difference between policy and consensus? Just

Glozow:
Sure.

Stephan:
to explain that.

Glozow:
Yeah. Oh, by the way, if you don’t mind me shilling, I recently wrote a 10 week series of blog posts with Bitcoin Optech called Waiting for Confirmation. And

Stephan:
Yeah, sure. We can

Glozow:
it

Stephan:
put that

Glozow:
does,

Stephan:
in the show notes. Yeah.

Glozow:
yeah, awesome. And it talks about fees and fee estimation and fee bumping and it explains policy. I go through, I think, 27 examples of policy, which is pretty much all of them. in Bitcoin Core, the standard rules and whatnot, and explain why they exist and the design goals that we’re going for. Anyway, so we know what consensus is. It’s the rules that everybody’s agreed on, on how money can be spent in Bitcoin. And those validation rules are applied to every transaction and every block. But of course, before transactions end up They’re also broadcast on this awesome decentralized transaction relay network that is the Bitcoin P2P network. And that offers decentralization and privacy and lots of nice censorship resistance, lots of nice things. But from an individual node standpoint, we don’t just apply consensus rules because mostly DOS reasons. So for example, you can imagine a consensus valid transaction that literally takes 30 seconds to validate. And this has happened in the past. It was a combination of a really big transaction and the quadratic caching problem prior to SegWit where a block took a really, really long time to validate. And while you’re doing that, you can’t do anything else, right? Like you, you know, you’re using your resources to validate this transaction. You can’t accept new blocks. You can’t be working on a new block template because you haven’t processed whatever blocks have been announced to you. You’re stuck doing this for 30 seconds or more or something of this sort. And so consensus is not sufficient to protect a node from being attacked

Stephan:
attacked.

Glozow:
in this kind of manner. Because you can also imagine. that you validate this transaction, it ends up being invalid.

Stephan:
Right.

Glozow:
It’s not

Stephan:
So it’s kind

Glozow:
even…

Stephan:
of like a spamming vector. Yeah.

Glozow:
Yeah, you’re like validating hundreds and hundreds of signatures and the last one’s invalid. I had to throw this away. And so we have to have something, in my opinion, we have to have something in addition to consensus in order to have to make it reasonable to ask people to run nodes. And Bitcoin only really function, like this whole decentralized network only functions if people voluntarily run notes because otherwise we’ll have like five notes

Stephan:
Yeah, gotcha.

Glozow:
and it won’t be decentralized anymore.

Stephan:
And so I guess just to make that example clearer,

Glozow:
Hmm.

Stephan:
it’s possible to have things that are like, let’s say you could send a transaction that was not in line with one, but in line with the other. So, I mean, maybe an example would be if you have a transaction that doesn’t meet most nodes policies, but it still meets the consensus

Glozow:
Yes.

Stephan:
that’s theoretically possible. Right?

Glozow:
Yes, that’s possible. So sorry, I haven’t defined policy yet, but it’s a set of validation rules just for unconfirmed transactions. And it’s in addition to consensus. So you can’t have something that’s policy valid, but not consensus valid. It’s

Stephan:
Right.

Glozow:
an additional

Stephan:
Like one’s

Glozow:
restriction.

Stephan:
a subset. Yeah.

Glozow:
Yeah. Yeah, exactly. So we have seen, particularly in the past few months with the inscriptions. that are much, much larger than a standard transaction, which cannot be more than 400,000 weight units. I think we saw like a 4 million one or so, or just below 4 million.

Stephan:
Right. And so I think in that

Glozow:
Yeah.

Stephan:
example, it was actually a mining pool. I believe it was Luxor who just kind

Glozow:
Yes,

Stephan:
of

Glozow:
I think so.

Stephan:
they might have specially crafted it. And I guess it’s that example, like we were saying, most nodes would not have received and forwarded that transaction because it

Glozow:
Yeah.

Stephan:
didn’t meet their policy. However,

Glozow:
Yes.

Stephan:
it did meet the Bitcoin networks consensus rules. So therefore that block was allowed to be a four megabyte block

Glozow:
Yes,

Stephan:
or whatever,

Glozow:
yeah.

Stephan:
which was basically one whole inscription.

Glozow:
Yeah, exactly. I think there’s been a lot of talk about removing a lot of standardness rules, because every time something like that is mined, you get no benefits from compact block relay. So for those that don’t know, with kind of our decentralized transaction relay network, there’s tons of benefits to that. And the biggest one is that it makes blocks relay faster, because we’re not going to be able to do that. If you’ve already received all the transactions, you don’t have to download and validate

Stephan:
That’s

Glozow:
them

Stephan:
true.

Glozow:
again. You already have their signature cached, like you don’t have to download them again. You have their UTXOs loaded from disk, which can take a really long time. So usually, like vast majority of the time, you already have everything. So they just send you the header and the short IDs, which is like very, very small, like many orders of magnitude smaller than the full block. And you just like… everything just propagates extremely quickly. But anytime you have something like that, really, really big non-standard transaction, nobody’s heard of it yet. And then so at each hop in the network, everybody has to be like, hey, could you send me that transaction? And I’m gonna go and validate it, blah, blah. And then I forward it onto the next peer. So the latency, you know, like,

Stephan:
There’s

Glozow:
it’s

Stephan:
a

Glozow:
at

Stephan:
knock-on

Glozow:
every

Stephan:
effect,

Glozow:
single hop

Stephan:
yeah.

Glozow:
on the network.

Stephan:
Gotcha.

Glozow:
So

Stephan:
Okay.

Glozow:
yeah.

Stephan:
Yeah. Okay. Yeah. So I guess we covered then that that’s the difference between policy and consensus.

Glozow:
Mm-hmm.

Stephan:
And yeah, as you were saying before, it’s kind of interesting because obviously controversy online. I mean, there’s always controversy about whatever, but people are always talking about, let’s say, soft forks. But there are serious things that need to be updated and fixed

Glozow:
Yeah.

Stephan:
in Bitcoin that are not related to soft forks at all. As we’re sort of talking about now, right? Mimple and v3, it’s not a soft fork. And yet, it’s serious in the sense that, you know, If the developers are not careful, something gets screwed up, like that could stop the way nodes talk to each other, which could also be very catastrophic

Glozow:
Yeah,

Stephan:
to the network.

Glozow:
yeah. I have a colleague at Brink, Nicholas, who is essentially working on testing a lot of our peer to peer protocol stuff. And it’s extremely important because you can imagine, this is also what makes like mempool validation so scary, is you can imagine there being a bug where, I don’t know, you like. try to dereference a null pointer. These are very basic coding problems. But for a Bitcoin node listening on the peer-to-peer network, that might look like you’re able to crash nodes just by sending them a specially crafted transaction. Or you’re able to split the network because there’s a slight difference. Let’s say there’s a slight difference in the way that. V25 Bitcoin Core and V24 Bitcoin Core do things and one of them would disconnect due to some difference. Suddenly

Stephan:
Yeah.

Glozow:
you’re able to split the network based on what version that they’re using. These are obviously not problems that hopefully there’s not problems that exist today. But these are the kinds of fish

Stephan:
It’s possible,

Glozow:
that these are

Stephan:
yeah.

Glozow:
the big fish we’re talking about

Stephan:
Yeah,

Glozow:
when

Stephan:
yeah.

Glozow:
we’re talking about peer-to-peer stuff.

Stephan:
I can’t remember who told me this, but I remember there used to be an old opcode called opver, and it literally would cause a hard fork if there were different versions.

Glozow:
Exactly.

Stephan:
And now it’s disabled,

Glozow:
Yeah.

Stephan:
right? But that’s just an example of that.

Glozow:
Yeah.

Stephan:
So one other area, we touched on LN symmetry. Obviously, in order to get LN symmetry, we need APO, any prevout, or at least something

Glozow:
Yes.

Stephan:
that offers a similar function. to that. So I’m curious if you could offer any comments on the interaction of APO and you know these things like V3, ephemeral output, sorry ephemeral anchors and all of this.

Glozow:
Yeah, so Greg Sanders has spent a really long time kind of prototyping. I think he’s already written, again, implemented this beautiful new future where we have all these things. Yeah, APOs of soft work. I think, I mean, a thermal anchors can benefit from a soft work, like making those rules of soft work in addition to policy, but it doesn’t require it. But it’s a long list of things that we need to do in order to make this future a reality. I have not personally spent any time reviewing the APO code, but yeah, it’s one of the many dependencies of LN symmetry. We, you know, in Bitcoin Core, like we said, there’s a lot of things beyond the Covenant proposals that people talk about on Twitter. Everybody has a number of proposals, like, I have these and other things that I’m working on. And it’s just completely impossible to review all of them. There’s very few reviewers and not enough time. And so I think there’s this myth that people are scared of consensus or people refuse to work on consensus. I think it’s just more that people have other things that they deem more important and more interesting, to be quite frank. And Yeah, this release we’re trying a new kind of project management experiment where we’ve kind of picked four high priority projects that people voted were their priorities. And we’re every week having a meeting where we talk about what the status of that is. And we’ve made a lot of really good progress on like BIP 324, which is one of our high priority projects. But this isn’t like, you know, the maintainers have decided that these are the priorities and we’re forcing people to review. It’s like, first of all, it’s impossible, but it’s more like, hey, like you said that this was your top priority for this release process. And so, hey, can you review it? Or like, hey, we’re not gonna merge this yet because it conflicts with this thing. Or like, we’re just going to like leave this. nitpick or this like unimportant thing that someone was trying to tack on because we are focused on or we said you know it’s not like we you know top-down decision making but like there’s an effort to try to um organize and coordinate

Stephan:
Okay,

Glozow:
review

Stephan:
yeah.

Glozow:
and stuff

Stephan:
So

Glozow:
and

Stephan:
this

Glozow:
unfortunately

Stephan:
is more around

Glozow:
none of

Stephan:
how

Glozow:
those

Stephan:
you

Glozow:
projects

Stephan:
prioritize, yeah.

Glozow:
yeah none of those projects are the are the are ctv or api or you know the

Stephan:
Of course, yeah. Yeah,

Glozow:
consensus

Stephan:
of course, and

Glozow:
ones

Stephan:
I think it’s also important that people move slowly and that support is built for these things and it needs to, you know, I think that’s fair. But I guess looking out longer term, and as you’ve mentioned, right, in the future with V3 and ephemeral anchors and package relay and the package RBF and all of these things, the hope then is that people can more appropriately or accurately manage their… layer two protocols and their fee rates to keep it secure and sustainable. Uh, and I guess maybe there’s a little bit of like fee optimizing that goes into that as well. Uh,

Glozow:
Yeah.

Stephan:
is that sort of the high level goal? That’s the high level push here.

Glozow:
Yeah, yeah, exactly. There’s so if you if you read like James O’Byrne’s op vault proposal, for example, or just a lot of protocols, or like, use cases built with, you know, the covenant proposals, they all depend on package relay. Because they’re all you know, the smart contracts where there’s a time lock. and there’s multiple parties and you sign now and you broadcast later and things can change and you need some way of managing fees. I think we’re in this space where we’re building layer two we’re building more on top where we’re hopefully able to get more privacy and scalability and more expressivity, more features, don’t know how to say that word. that are off chain and make Bitcoin more useful with the same security guarantees because we’ve already enumerated all of the things that can happen when we try to settle on chain. But that security requirement nowadays includes being able to fee bump. And so we’re just trying to like close those gaps. Like this security assumption, which is not quite safe today, we can make that much stronger. you know, the world is your oyster. You can build as many layers as you want because you’re always gonna be able to confirm,

Stephan:
Gotcha.

Glozow:
you’re always able

Stephan:
And I

Glozow:
to

Stephan:
guess

Glozow:
settle on

Stephan:
one

Glozow:
change.

Stephan:
other point to clarify, would you say it’s fair that because some people do criticize this idea that oh, you’re changing Bitcoin just to kind of help layer twos and I just only care about layer one and Bitcoin, you know, but I think would you say it’s also fair to say that all this stuff we’ve mentioned in this episode also helps just layer one users, even if you don’t care about layer two.

Glozow:
Yeah, yeah, exactly. I mean, it’s exactly. So I mean, even today, if you received a payment, actually, I heard a lot of people say this when Mempool min fee rate started rising, that they would receive some kind of payment at one sat per VBITE. And then it would disappear from Mempools because it got evicted. And they’re essentially like, hey, can you send it again, but with a new fee rate? And a lot of like wallets were breaking and people were having trouble RBFing things because it fell out of mempool but then like how do you treat that? Is that is that a deleted transaction? Like does it still exist? You know, like a lot of people were experiencing problems.

Stephan:
And at that point, just out of curiosity, you should treat it like it could get broadcast. So if you

Glozow:
Exactly.

Stephan:
just resend the new transaction, you might be out money double because you already

Glozow:
Yeah.

Stephan:
paid once and now you’ve just paid again. So it’s kind of like, it’s a really awkward limbo situation there until we get package relay.

Glozow:
Yeah. Well, I mean, part of it is maybe fix your wallets. There’s so

Stephan:
Right.

Glozow:
much low-hanging fruit with respect to how we can make the fee thing a much more user-friendly interface for all users. And a lot of that is, I mean, there’s a lot of wallets that don’t even do RBF, right? Or a lot of wallets struggle to receive replacements because they’re like, where did it go? Or like, you know? And yeah, there’s a whole list of things that we can do. One of which is package relay, which should eliminate a lot of things. Because yeah, you could just see PFP that thing that just fell out of your mempool.

Stephan:
Gotcha. I guess while we’re here also, Mempool full RBF, do you have any thoughts on that or anything to add in

Glozow:
haha

Stephan:
terms of where that’s at or is it just sort of, the option is there and you’re just happy for people to enable it or disable it however they choose.

Glozow:
Yeah, so we talked a lot about the kind of RBF limitations today and it’s kind of top of mind for me always. And I think I would really love to fix a lot of these things before we subject every transaction to these rules. Like today, if it doesn’t signal BIP 125, you’re just not going to bother. Yeah, there’s a lot of issues that. we could we should fix before we like intentionally would want

Stephan:
Gotcha.

Glozow:
to sorry when I say we I’m not saying like Bitcoin Core is like about to about to merge it or whatever

Stephan:
Right.

Glozow:
I think this is my personal opinion um if I you know were to decide um if there was a timeline if I could make a timeline it would be fix RBF and then and then consider doing full RBF. I think the other reason that you’d wanna switch it is if everybody’s doing it. I think there’s evidence to show that there is some adoption. I don’t think there’s widespread adoption. I think there’s a lot of kind of false positives that people tout as full RBF replacements. So the best example I can, like, so for example, we just talked about transactions falling out of mempools, right? So if that transaction that didn’t signal RBF fell out of mempools and then you made an RBF, there was a lot of block explorers and full RBF detectors that will mark that as a full RBF, even though there was no replacement at all. Like, it’s just one of them fell out and then you put in a new one. That’s not a full RBF replacement. And that is, I think, by far the most common… mistake that people make when they talk about adoption of full rbf is they don’t account for like these extremely high false positive um likelihoods um but i think like basically for me personally i spend a lot of time looking at like full rbf um explorers and monitors because it’s essentially like if all the miners are mining full rbf and a lot of the nodes are doing it too, then it becomes unsafe to not do full RBF on your node because you’re kind of like plugging your ears to transactions that are probably gonna get confirmed. But prior to that, I don’t have any personal desire to turn it on simply because of all the issues with the existing RBF rules. Please don’t yell at me on Twitter.

Stephan:
Right, yeah. Yeah, no,

Glozow:
Yeah,

Stephan:
that’s totally

Glozow:
this is

Stephan:
fair.

Glozow:
my personal opinion.

Stephan:
Yeah, gotcha. So yeah, I think that’s a good spot to finish up. I think, well, I don’t know if you have any, I guess, last things you want to mention, you know, if there was like one key takeaway, what should people take away?

Glozow:
Policy is really important and it’s really cool and there’s a lot of really exciting things that are being built in Bitcoin Core despite what some people like to say.

Stephan:
Okay great well I’ll make sure to include the stuff in the show notes. You’ve done a review club on this. I’ve got

Glozow:
Yes.

Stephan:
your Bitcoin Optech series which

Glozow:
Mm.

Stephan:
we’ll also include in the show notes and thanks for joining me GloZell.

Glozow:
Thank you so much for having me.