{ "episodeId": "SLP511", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "glozow": { "name": "glozow", "role": "guest", "tag": "GLOZOW" } }, "segments": [ { "speaker": "stephan", "time": "00:08", "start": 8.43, "text": "Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by Swann dot com. Have you wondered about Bitcoin transactions and the mempool? Well, Glozow rejoins me to talk about some updates coming to Bitcoin's transactions and mempool policy with v3 transactions, as well as package relay. We get into what are some of the current issues or- In this space and what can be done to improve these issues as well as make layer two security a little bit better, as well as potentially removing pinning vectors, and we, we get into this and explain some of the details around this, as well as talking about package relay, v3 transactions, and ephemeral anchors. Here's my discussion with Glozow. Gloria, aka Glozow, welcome back to the show." }, { "speaker": "glozow", "time": "00:53", "start": 52.99, "text": "Thank you for having me again. It's a pleasure to be here." }, { "speaker": "stephan", "time": "00:56", "start": 56.23, "text": "Yeah, I, 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'll 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." }, { "speaker": "stephan", "time": "01:20", "start": 79.67, "text": "And because the conversation shifts over time as well, so yeah, so today we're mainly talking about v3 transactions, package relay, all, all these, you know, associated ideas, transaction pinning, yeah, 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- Transactions and the mempool in terms of how it applies today." }, { "speaker": "glozow", "time": "01:45", "start": 104.86, "text": "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- A transaction is more urgent is by putting a high fee rate on it, and miners are hopefully incentivized by the fees and not, you know, 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's not very good and, you're trying to minimize your fees, so you start from a very low fee rate and then you can bump that over time until it confirms. That's, 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, of Bitcoin transactions. so it's impossible for them both to confirm, they're-- by consensus they, they're incompatible, they're double spends. and an intelligent mempool policy, such as one that implements the BIP one twenty-five, Replace-by-Fee policy, will kind of intelligently see, like, okay, this one pays higher- Fees, so I should probably replace the one that I, 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 base model, you spend one of the outputs, for example, the change, or your rec-received payment, if you're the recipient, in a child transaction with a really high fee rate and again- And we have these kinds of in-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 the, this two transaction package." }, { "speaker": "stephan", "time": "04:16", "start": 255.77, "text": "Yeah. Great. And so as you've mentioned, there's RBF and child pays for parent today, and we're, we're gonna 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 And I absentmindedly set it at one satoshi per vbyte, per virtual byte, and then 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?\"" }, { "speaker": "glozow", "time": "04:41", "start": 281.01, "text": "so the absolute bare minimum i-is probably a one sat per vbyte increase in the fee rate. there, you- we're talking about RBF here, are we? Yeah. so there are rules, so- I, I want to shift away from like RBF being something that users do, and it's, it, it's more something that nodes do. It's like this algorithm that we use to determine, okay, this is more incentive compatible, but there's also a DOS component. So you, we want to avoid a situation where you can do like thousands and thousands of replacements where you add one Satoshi each, a-and from the node's perspective, that costs bandwidth 'cause you have to download it and then you go and upload it. 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 it might have, and update your mempool to, to account for this new transaction. There's a cost to each node to do this replacement, and so there is a, a certain amount of extra satoshis that you need to pay, so there's that kind of bare minimum is the cost, the, the size of the new transaction, at one satoshis per VByte is the increased amount of absolute fees that you need to pay. you, you have to have new fees essentially to pay for the new, the bandwidth usage. but for a user, I think if you- just if you're going from like one sat per v byte and you go to like five sats per v byte, that's usually pretty fair, or if you go from five to ten or whatever, that's, I think what usually, how it usually works in, in wallets." }, { "speaker": "stephan", "time": "06:32", "start": 392.31, "text": "Yeah. And as you rightly say, 'cause 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- 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 I guess how I'm understanding that, just to ex-explain it in simple terms, is this idea that if I was malicious and I was just kind of spamming it out, spamming it out there, I can sort of push a lot of cost to other people because if I just put these little transactions, 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, a burden on other people. And that's why there are certain rules that, you know, currently restrict what exactly you're allowed to do. And that's where, you know, 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?" }, { "speaker": "glozow", "time": "07:41", "start": 461.2, "text": "Yeah, so it's rule three and four. I touched Bit, but yeah, essentially it's exactly what you said, where you're trying to protect your node's resources, and then there's like, so 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 okay, maybe we can just go through the replacement rules 'cause they're not that, they're not that difficult. One is we have this BIP one twenty Five signaling rule. So today, a lot of nodes will respect, like, if your end 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's, it's, 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 replace transaction can have descendants. So if it was CPFP'd 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 gonna exist anymore. you 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 like paid at some point in the, in the, in the past, and you have to Pay essentially new fees, so you have to have that, that absolute fee amount plus more, and the additional, this is rule four, has to cover the new transaction at one sat per vbyte. and you can think of it as you're, like, 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 increase one sat per v- if you, sorry, if you increased one satoshi, for example, then you would have that, that DDoS problem. Does that make sense?" }, { "speaker": "stephan", "time": "09:57", "start": 597.05, "text": "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, you know, in, 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 pre-sign the commitment transaction, which is the transaction that closes the light- The 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 on the, on the-- afterwards. So if you could just elaborate a little bit about that process and some of the issues, you know, associated." }, { "speaker": "glozow", "time": "11:00", "start": 660.23, "text": "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, 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 a-and fee management. So we talked about fee management as a kind of like nice thing where you can tell miners, \"Can you please confirm this faster?\" But there's a certain set of conditions where it becomes a, a security problem. that, and that being like smart contract, smart contracts and L2s. So with, 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, 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 of time, we can both collaborate to withdraw these funds. Or past this certain time lock, then you'll be able to withdraw these funds. But then, oh, if I can prove that you're, you're cheating and you're claiming funds that don't belong to you, we can revoke that. Like we've enumerated all the- The ways that we can spend this money together. and like you said, the, 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, or, or the other person gets to, gets to cheat." }, { "speaker": "stephan", "time": "12:59", "start": 778.99, "text": "Right. And so this could be in this and- Scenario of one person cheating, it could be, or even potentially even in the scenario where somebody's gone offline, or maybe somebody has restored from a backup, and, or maybe their connectivity is really bad. So there's all kinds of issues that can come here. And I, 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 then one of us has gone offline and the fees have gone really high, exactly, 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?" }, { "speaker": "glozow", "time": "13:33", "start": 813.05, "text": "Yeah, exactly. so right now we're in this like, it's, it's great because it's actually illustrating what I've been talking about for years, is we're in this era of like no one sat per v byte transactions propagating, or maybe they do, but, for default mempools of size three hundred megabytes, you know, there's high enough traffic today that anything lower than, I think it's like six sats per v byte is getting evicted. Because you keep the most incentive compatible transactions, 'cause 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 vbyte, because that was fine at the time, and we had anchor outputs, like you said, so with Lightning, commitment transactions, they'll have anchor outputs. 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, three hundred something satoshis in it. each lightning commitment transaction will have two, one for each participant, so that they can each see pfp any transaction belonging to their channel that they see in the mempool. Let's say it was one sat per byte and they added anchor outputs. Today, if we broadcast one of those commitment transactions, it wouldn't, it wouldn't go very far. I, I think there's like the, the mempool space, like submitter and, and they have, they're connected to miners and Electrum servers that have really- Big mempool, so maybe you'll be fine, but all of the default mempools and, and there's smaller ones as well, will just like throw that away immediately or, or they won't ask you to send them. through fee filters, they'll be like, \"Hey, I'm not taking anything below ten sat per byte or seven sat per byte, so don't even bother announcing that to me.\" we'd, we'd be really, we'd be in trouble, being able to, to get something confirmed. And we wouldn't be able to sign something new, sorry, just to 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 CPFP, but we talked about RBF as one of the, one of the solutions available to most users. That's not available when your part- 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 our RBF is often not an option, although what I'm trying to work on as part of package relay and the, and the validation things, is to add a policy where you can have package RBF. So even if you have two, sorry, so if you have a transaction that you conflict with, 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 into the fees that you put on that commitment transaction or that commit-- that transaction that you sign ahead of time. I" }, { "speaker": "stephan", "time": "16:36", "start": 996.19, "text": "see. A-and just to be clear, what we're talking about here is also in the case of unconfirmed transactions, correct? Right? Yeah, yeah. So what we're talking about here isn't 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 Unconfirmed transaction and the child of that transaction in a kind of safe way. So I guess we're sort of like, I guess in an al-- 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'd. Yes, exactly. This kind 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 kind of a fair summary? Yeah." }, { "speaker": "glozow", "time": "17:23", "start": 1043.36, "text": "Exactly. There are so many pinni- There's so many problems that are essentially this trade-off between, okay, when we're designing mempool policy like RBF or package relay or whatever, we're trying to be really protective of the node resources, but then on the other side, there's like what users need, and we have to find some trade-off in the middle that's like, sorry, you can't have the tw- the thirtieth descendant of this transaction, or you can't make a cluster, you can't make, you know, thousands of transactions that depend- depend on each other. And, you know, a user might be like, \"Oh, I just wanna keep CPFPing 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 okay if we were like, \"Ah, we just make this trade-off, it's okay if the node stalls for like thirty seconds. \" That's, that's never gonna be okay. So we're, we're quite conservative," }, { "speaker": "stephan", "time": "18:27", "start": 1106.87, "text": "Okay, gotcha. And so can we then talk a little bit about, I guess, so we've, we've, we've been touching on this, the transaction pinning, as, as you mentioned, there's rule three pinning and, rule five pinning, I think of some of the-- I mean, there are different pinning vectors, but I think those 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." }, { "speaker": "glozow", "time": "18:53", "start": 1133.34, "text": "Yeah. so we, 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 a hundred 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, twenty descendants, and maybe you're conflicting with actually five transactions because you're double spending all of them. if it exceeds a hundred Then we don't do the replacement because we're just evicting so much of our mempool that it's, it's worrisome, like what we can do to kind of thrash people's caches. A mempool is a cache, essentially. and then there's rule six, which isn't in the, it was added later, is the new transaction's fee rate has to be higher than the previous, which I think it's, it's not impossible to do, without breaking one of the other rules, but it is possible to have a lower fee rate transaction And 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," }, { "speaker": "glozow", "time": "20:09", "start": 1208.59, "text": "You were trying to replace a bunch of things, either-- I, 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, and they've already broadcast a commitment transaction that it represents a different state from your channel. and of course, all commitment transactions conflict with each other. Each other, 'cause 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 child, and so suddenly your- There's like more than a hundred transactions out there, that you would potentially have to replace, and you'll just-- you'll hit that rule five limit, and then most nodes will be like, \"Sorry, that's too much. I'm, I'm not gonna do this replacement.\"" }, { "speaker": "stephan", "time": "21:31", "start": 1291.37, "text": "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 descendants, new descendant, new descendant until I've got over a hundred, and then you're basically stuck at that point because you can now-- 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 it's all effective fee rate of one sat per vbyte, but the prevailing rate to get in confirmed is like five or six sats 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?" }, { "speaker": "glozow", "time": "22:06", "start": 1325.53, "text": "Yeah. yeah. A, 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, I see. Like, it might be- It's possible" }, { "speaker": "stephan", "time": "22:32", "start": 1352.15, "text": "that you don't see all the transactions. Yeah," }, { "speaker": "glozow", "time": "22:34", "start": 1353.87, "text": "you haven't seen it, but like, you know, miners 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, you keep bumping, and you can assume that like one of these is going to confirm, whereas today you're like Like, well, you know, there might be something in somebody's mempool that you can't replace. so it's, it's more of like, what do you, like, what do you need to do in order to be secure? Like, I think there's definitely ways to skirt around all of the, or most of the problems today if you have like all kinds of monitors going and, and you try to watch mempools and whatnot. and I think there's a lot of businesses that, you know- Outsource this to a third party that has many block explorers and, you know, feeler connections and is, is seeing like what, what is announced and who has what. that shouldn't be a requirement for you to have a secure lightning node, right? The, ideally you don't have to be watching all these things and you're just like, \"Alright, we're gonna broadcast and we'll let the, the free market do its thing where it's going to take, you know, the, the highest fee rate stuff because we're willing to pay the fees, so, you know, 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, this is a world where we have package RBF, and instead of attaching like a bunch of descendants to it, they just attach One big descendant that pays a lot of fees, but is like pretty low fee rate. So for example, you can attach up to a hundred, you can have a descendant package of up to a hundred and one kilo virtual bytes, which is way larger than the normal transaction. you can attach one and have it pay, let's say, one sat per vbyte, and that's a hundred thousand satoshis 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 anything, like, it's just one sat per byte, it's not a CPFP. But if you want to replace that commitment transaction, you have to pay at least a hundred thousand satoshis in addition because, of rule three, because, you know, we have this rule that says if you wanna do a replacement, you have to pay all of the original fees plus some extra. and, and that's maybe not fair in, in this situation, because, like- This transaction wasn't doing anything, like 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." }, { "speaker": "stephan", "time": "25:46", "start": 1546.13, "text": "Back to the show in a moment. Swann dot com is the lead sponsor of this show, and the team at Swann is organizing Pacific Bitcoin. Now, last year it was a conference, and this year it's even more. It's gonna be a festival celebrating Bitcoin, the lifestyle, and the community that is working to build a bright orange future together. I'm gonna be there. I'm really looking forward to seeing a bunch of you there. We have an awesome lineup of speakers coming: Max Kaiser, Stacey Herbert, Vijay Bojapati, Preston Pish, Greg Foss, Lynn sixth twenty twenty-three in LA at the Barker Hangar, so make sure you check your calendar and look up flights and hotels. Think about inviting some friends and family along. This is going to be a really accessible and awesome experience. I remember the vibe last year was so great because you had the opportunity to talk to all kinds of bitcoiners and make real connections, and I think it's a great opportunity to bring a new coinor along. This is a great opportunity for them to actually learn a bit more about Bitcoin and understand it's not just a bunch of us internet nerds, there's a real community So go and check out pacificbitcoin dot com, get your tickets using code livera for a discount. October fifth and sixth in LA, I'm looking forward to seeing you there over at pacificbitcoin dot com. Now, this episode is talking a lot about the mempool, but this show is also brought to you by the sponsor, mempool dot space. Mempool dot space is a Bitcoin and blockchain visualizer. You can see the mempool, you can see the blockchain, you can see second layer networks like the Lightning Network. You need mempool dot space every time you send a Bitcoin transaction You target your fee, whether you're looking at low, medium, or high priority. You can even scroll the blocks, you can click into those blocks, you can view transactions. It's got all kinds of features that help you do things like the block audit to see which transactions were included. You can do things like visualizing RBF and CPFP. You can even see which, which transactions relate to a Lightning channel open. There's just so many features that you can find over at mempool.space. And remember, if you are with an enterprise, you can even get in touch with the company and have instance with your company's branding, API limits, as well as specialized feature requests. So go to mempool.space/enterprise or otherwise just go to mempool.space. And now back to the show. Gotcha. So we're sort of, and so then, yeah, that's, 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 all the, also other elements here. So there's package CPFP, package RBF, and v3 transactions. So could you just sort of explain how these pieces fit together for us?" }, { "speaker": "glozow", "time": "28:16", "start": 1695.92, "text": "Yeah. So we, we did kind of skip ahead a little bit. So package relay and package RBF, so today, like, you wouldn't be able to replace something that One transaction versus one transaction, and you don't get to use the child to, 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 sat per vbyte. So if you have a one sat per vbyte transaction, that has to make it into the mempool first before you can bump it. but Package Relay is like, okay, why don't we relay transactions as a package and we evaluate them as a package so we can immediately see, like, okay, this is low fee rate, but like, it comes with this child, so I'll look at them together, a-and submit them together. Oh, cool, like, they requirements. And the hope is that, for example, this like parent could be zero sats per vbyte 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, 'cause 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 two twenty satz per vbyte, for example, and potentially overpay, and, and so that'll hopefully save people money and also get rid of some of these limitations. so that's package relay and, and package RBF and all 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, I was kind of interested in all these problems with, with, you know, 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, and I posted that. to the mailing list and I said like, okay, like we have these problems, there's kind of a, 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, we're making very invasive changes because, it, like instead of doing one at a time, we have this like more generic package idea where we're, 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 gonna simplify this, so like the complexity of certain operations are more complex, but it means that we can do these other things, in a, in, 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 like 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, there's just no way, because there's no other way to kind of guarantee this like bandwidth DDOS is prevented.\" and then there was one idea which is like, \"Well...\" Th-there's this problem essentially today where people are entering into smart contracting agreements, right? They're, they're saying, \"Hey, I, I'm-- 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 twenty-five descendants to a commitment transaction doesn't make any sense. Like, nobody wants that. Like, there, there are no lightning use cases where after you broadcast your commitment transaction, you then add twenty five things chaining off of it. and it would be so much simpler if we just allowed one parent, one child, or like n 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, is bump them so that they confirm, right? and so- I think it was BlueMat 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, there's definitely use cases out there where you might want multiple descendants. Right. Maybe" }, { "speaker": "stephan", "time": "33:23", "start": 2002.67, "text": "as, as an example, so I guess, maybe in a joking way, this is Bitcoin's single child policy. but, but, anyway, putting that aside, the, 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 ten users, and in that same time, they've seen, oh, another five users want to get a payout, we'll, we'll, we'll attach another descendant to that transaction. So does that screw them over, or are they still able to do this case?" }, { "speaker": "glozow", "time": "33:57", "start": 2037.17, "text": "Yeah, so w- 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, \"This is okay, \" and that's very difficult. but luckily we have a lot of kind of things that aren't standard that we can use, to, to add new rules. Without like restricting anybody. So, anything with version three and version is a field in transactions. Anything three and above is currently non-standard, so they wouldn't be relayed by the vast majority of nodes, unless they have some custom policy. Right." }, { "speaker": "stephan", "time": "34:41", "start": 2081.26, "text": "So, so I guess we can say it's like an opt-in scheme here that you're creating, and in the future, the, the hope is that more and more people just opt into a V3 environment, a world just in a V3 world, so then we can think of it like one parent, one child, that simplifies" }, { "speaker": "glozow", "time": "34:56", "start": 2095.79, "text": "Exactly. and it's hopeful, like it's only really meant for smart contract, L2 contracting protocol kind of thing. So it's, it's opt-in. Everybody else can just continue using V2, and, you know, get pinned and whatnot. But for, for most people, like it, it doesn't even matter, right? Like you're, you're never gonna have descendants. Like you, 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, end up in mempools or when, 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, many, pending attack. I can link my mailing list post or whatever. Yeah. and some of them, I, 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, for this transaction. And we can talk about why that is. I, I've talked about this in, in other places as well, because of just like the sheer amount of po- Possibilities for ancestor and descendant relationships in transactions and mempools. And but with one parent, with one parent and one child, there's, it's just very simple. You just" }, { "speaker": "stephan", "time": "36:35", "start": 2195.4, "text": "like," }, { "speaker": "glozow", "time": "36:36", "start": 2195.9, "text": "you just take the minimum of two scores." }, { "speaker": "stephan", "time": "36:38", "start": 2198.04, "text": "Yeah. And so just a quick question on that. So in that, so let's say we're in a V3 world And, you know, people are doing lightning. Let's say somebody tries to broadcast an old state, the other-- and so that, they've created a new child, so," }, { "speaker": "stephan", "time": "36:58", "start": 2217.84, "text": "I guess what I'm trying to get at is, can you only fee bump it once or is the, the second or third fee bump just replacing that child? That's, is that, you get what I'm saying?" }, { "speaker": "glozow", "time": "37:07", "start": 2227.45, "text": "yes. So it depends on what your, What the transactions look like. So today, you'll each have an anchor output. Oh, oh, sorry. In a proposed view, okay, 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 tran- with your commitment transaction with your output. So yeah, you would attach a, child to it that pays fees, and then if you wanna bump it again, you just rbf that child." }, { "speaker": "stephan", "time": "37:55", "start": 2275.13, "text": "Yeah, I see. So it's not new descendants, you're actually just rbfing that same child transaction, just, just so I'm getting it right? Okay." }, { "speaker": "stephan", "time": "38:05", "start": 2285.18, "text": "okay, there's one other area, one other concept I noticed, this ephemeral anchors thing. So can you just, can we talk about that? What is an ephemeral anchor?" }, { "speaker": "glozow", "time": "38:15", "start": 2295.0, "text": "Yeah, it, it has a way cooler name than, than V3, and I wish I thought of something cooler. So the way we, we talked a bit about how anchors work today. So today it's, you know, 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, 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 trans-the transaction confirms, and there's a one block time lock, so this transaction has to confirm the commitment transaction. hash to confirm before you can broadcast a spend of, like, redeeming your, 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 twenty-five descendants to all their outputs, suddenly you can't even use your anchor output anymore. so that's, 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's, it, it doesn't make any sense. It, it's just complexity for, for no reason. CPFP carve out, I can, I can link, the PR and the mailing list post for that. You need one for each participant, a- 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, 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 more to spend it, yeah, than it's worth. so the dust threshold specifies that you can't really be below, I think it's like three hundred something or whatever satoshis. and so that comes out of the channel balance, and that is a blocker for L2 or LN symmetry, which is something that Greg has spent, Greg Sanders has spent a, a long time, prototyping and kind of figuring out all of the- The security and the pinning problems with it. and because the way that, we don't have to get into it, but it, it's a blocker to be shaving channel balance because then at every update you have to like shave off three hundred satoshis from, from your balance, so you're like leaking value as your lightning channel like goes on, which just doesn't work. that's not the case today because you're making conflicting, anyway. Yeah, that's right. 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 three hundred satoshis into it, and the, the one block relative time lock. And so ephemeral anchors. It's taken 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 if the commitment transaction, the parent, is zero sats per vbyte, as in we can guess that it would never confirm on its own, and it has an anchor output We, we guess that it would definitely be spent, because it has to be fee 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 the, in your UTXO set while you're validating this block and then immediately be spent by a fee bumping transaction. a-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 vbyte. So ephemeral anger 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 never going to actually appear in any chain state. It's going to get spent in the same block." }, { "speaker": "stephan", "time": "43:51", "start": 2631.22, "text": "Okay, so is it sort of like having a zero sat anchor output? Yes. Yes. And we can sort of use it programmatically as part of our layer two contracting protocol. Yes. In an opt-in sense. And so this is kind 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 anchor outputs, oh sorry, ephemeral anchors, sorry. Yeah. You get all these pieces together and then we are making layer two protocols more secure, right?" }, { "speaker": "glozow", "time": "44:27", "start": 2666.71, "text": "Yes, e-exactly. It's things will be more secure, LN symmetry will be possible, because you won't have this leaky thing, happening. And, yeah, that's, 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, you know, it's, it's gonna take a while, but it's really cool to have all of this kind of written out. Like we could have, oh, 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 payment transaction, you In order to get something confirmed when you broadcast it, you don't have CPFP carve out, 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 in. Okay." }, { "speaker": "stephan", "time": "45:22", "start": 2722.33, "text": "So basically all of these are still, I guess, in progress to be clear." }, { "speaker": "glozow", "time": "45:25", "start": 2725.4, "text": "Yes, everything's in progress, everything's been open for a while." }, { "speaker": "stephan", "time": "45:31", "start": 2730.52, "text": "But yeah, but it's good for just for people to understand these things. And I guess, you know, just, just to confirm for, for listeners, it's not a soft fork, right? Like this is just upgrades or updates into Bitcoin, Bitcoin Core, right? Yeah," }, { "speaker": "glozow", "time": "45:43", "start": 2742.87, "text": "yeah. So all of this is non-consensus. I, I have this like kind of thing where I, I think consensus is like A, a bit overrated. It's like very talked about in podcasts and, right? And on stage at, at conferences and stuff. but we can do a lot just with, oh, just changing the peer-to-peer protocol, like changing the pro- like there are other protocols that make up Bitcoin, including the peer-to-peer protocol and, 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, can, can use and, and security and, you know, all these things. yeah." }, { "speaker": "stephan", "time": "46:31", "start": 2790.93, "text": "W-while we're here, do you mind just explaining for us what's the difference between policy and consensus? Just to explain that." }, { "speaker": "glozow", "time": "46:37", "start": 2797.45, "text": "Yeah. oh, by the way, if you don't mind me shilling, I recently wrote a ten-week series of blog posts with Bitcoin Optech, called \"Waiting for Confirmation,\" and it- Yeah, sure, we can put that in the show notes. Yeah. a-and it talks about fees and fee estimation and, fee bumping and poli-it explains policy. I go through, I think, twenty-seven examples of policy, which is pretty much all of them in Bitcoin Core, the standardness rules and whatnot, and explain like why they exist and kind of the design goals that we're going for. Anyway, so, we, we know what consensus is. It's, you know, the rules that everybody's agreed on on how money can be spent, right? i-in Bitcoin. a-and those validation rules are applied to every transaction, every block. But of course, before transactions end up in blocks, they're also broadcast on this awesome decentralized transaction relay network that is the Bitcoin P2P network, and that offers decentralization and privacy and, 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't imagine a consensus valid transaction that literally takes thirty 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, the- You're using your resources to validate this transaction. You can't accept new blocks, you can't be working on, like a new block template because you haven't processed, whatever blocks have been announced to you. Like, you're stuck doing this for thirty seconds or more or, you know, something of this sort, and so consensus isn't sufficient to protect a node from being attacked in this kind of manner. Because you can also imagine that you validate this transaction, it ends up being- Invalid. Like it's, it's not even- Right. So it's kind of" }, { "speaker": "stephan", "time": "48:53", "start": 2933.48, "text": "like a spamming vector, yeah? Yeah," }, { "speaker": "glozow", "time": "48:55", "start": 2935.1, "text": "yeah, you're like validating hundreds and hundreds of signatures and the last one's invalid, and you're like, \"Crap, I have" }, { "speaker": "stephan", "time": "48:59", "start": 2938.89, "text": "to" }, { "speaker": "glozow", "time": "48:59", "start": 2938.97, "text": "throw this away.\" Right? 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, right? And, and Bitcoin only really function-- like this whole decentralized network only functions if people voluntarily run nodes because, you know, otherwise we'll have like five nodes," }, { "speaker": "stephan", "time": "49:23", "start": 2963.21, "text": "and" }, { "speaker": "glozow", "time": "49:24", "start": 2963.71, "text": "it won't be decentralized anymore." }, { "speaker": "stephan", "time": "49:25", "start": 2965.11, "text": "So I guess just to make that example clearer, 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, that's theoretically possible, right? Yes," }, { "speaker": "glozow", "time": "49:44", "start": 2984.4, "text": "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, in addition to consensus. so you can't have something that's policy valid but not consensus valid. It's, it's an additional restriction. Like one of Yeah. yeah, exactly. So we have seen, particularly in the past few months, with like the, inscriptions that are much, much larger than a standard transaction, which can't be more than four hundred thousand weight units, For, I think we saw like a, a four million one or so, or just below four million." }, { "speaker": "stephan", "time": "50:26", "start": 3025.89, "text": "Back to the show in a moment. CoinKite dot com are the leaders in Bitcoin hardware security. You can go to CoinKite dot com and get a range of gear, most notably the Coldcard, which is a ultra secure hardware device or hardware signing device that you can use to generate the private keys for your Bitcoin and also sign Bitcoin transactions. Now, the really cool part is you can do this in an airgapped way, meaning you don't even have to directly connect your Coldcard With your computer, although if you're a beginner, you can do that just with a USB-C cable. But if you're intermediate or advanced, you can use it in airgapped mode, meaning you can use a micro SD card to move things back and forth between the computer and your cold card. If you are in a different situation where you can use NFC, that is also a possibility with the Mark IV. There are all kinds of features, and you can actually learn a lot about Bitcoin by using a cold card, and it's easy to use with software such as Specter Desktop or Sparrow Wallet or They even have different color Mark IV devices, so if you want it in red or black or glow in the dark, there's all kinds of options there for you. So go to CoinKite dot com, get your coins, get them off the exchanges, use a hardware device, get a cold card using code Livera at CoinKite dot com. And now back to the show. Right. And so I think in that example, it was actually a mining pool, I believe it was Luxor, who just kind of-- Yes, I think so. They might have specially crafted it. And, I guess it's that example, like we were saying, most nodes wouldn't have received and forwarded that transaction because it didn't meet their policy. Yeah. However, it did meet the Bitcoin network's consensus rules, so therefore that block was allowed to be a four-megabyte block or whatever, which was basically one whole inscription." }, { "speaker": "glozow", "time": "52:02", "start": 3122.06, "text": "Yeah, exactly. I, I This rules because e-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 if you've already received all the transactions, you don't have to download and validate them again. You already have their signature cached, like you, you have, you don't have to download them again. you have their UTXOs loaded From disk, which can take a really long time, so usually ni- 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 every- 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 then I forward it onto the next peer. So the latency, you know, like, i-it's at every single hop on, on the network. So gotcha, okay. Yeah. Okay," }, { "speaker": "stephan", "time": "53:20", "start": 3199.93, "text": "yeah. So I guess we covered then that, that's the difference between policy and consensus. 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 in Bitcoin Soft forks at all, as, as we're sort of talking about now, right? Mempool and V3, it's not a soft fork, and yet it's, it's serious in the sense that, you know, if the developers aren't careful, something gets screwed up, like that could stop the way nodes talk to each other, which could also be very catastrophic" }, { "speaker": "glozow", "time": "53:55", "start": 3234.67, "text": "to" }, { "speaker": "stephan", "time": "53:55", "start": 3234.79, "text": "the network." }, { "speaker": "glozow", "time": "53:55", "start": 3235.33, "text": "Yeah. 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 or like, these are like kind of 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, you know, there's a slight dif- like, let's say there's a slight difference in the way that v twenty five Bitcoin Core and v twenty four Bitcoin Core do things, and one of them, like, would disconnect due to some difference, like suddenly you're able to split the network based on what version that they're using. these are obviously like not problems that, you know, hopefully, hopefully there's no- Problems that exist today. but these are the kinds of fish that-- These are the big fish we're talking about when we're talking about" }, { "speaker": "stephan", "time": "55:16", "start": 3315.61, "text": "peer-to-peer stuff. I, I can't remember who told me this, but I remember there was a-- There used to be an old op code, op code called OP_VER, and it literally would cause a hard fork if there were different versions. Exactly, exactly. You know, and, and now it's disabled, right? But, that's just an example of that. so one other area, we touched on LN That offers a similar function to that. So I'm curious if you could offer any comment on the interaction of APO and, you know, these things like V3, ephemeral output, sorry, ephemeral anchors and all of this. Yeah," }, { "speaker": "glozow", "time": "55:50", "start": 3350.31, "text": "so, yeah," }, { "speaker": "glozow", "time": "55:53", "start": 3353.27, "text": "like Greg Sanders has spent a really long time kind of prototype. I think he's already written, like, again, like, implemented this like beautiful new future where we have all these, all these things. yeah, APO is a soft fork. I think, I mean, ephemeral anchors can benefit from a soft- Soft fork, like making those rules a soft fork in addition to policy, but it doesn't require it. but it's, it's, you know, it's a long list of things that we need to do in order to make this, this future a reality. I haven't personally spent any time reviewing the APO code, but yeah, it's, 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, and, and other things that I'm working on, and it's just completely impossible to review all of them, right? There's very few reviewers and not enough time. and so- I, I think it's, like, 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 think more important and, and more interesting to be, to be quite frank. And, yeah, we're, we're, this release, we're trying a new kind of project management like experiment where we've kind of picked four high priority projects that, you know, people voted, were their priorities, and we're, we're, 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 three twenty-four, which is one of our high priority projects, But, you know, it's-- this isn't like, you know, the maintainers have decided that these are the priorities and we're forcing people to review. It's, first of all, that'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- This, 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, there's an effort to try to, organize and coordinate review and stuff. Okay. And unfortunately, none of those projects, yeah, none of those projects are, are the, are the, are CTV or APO or, you know, the, of" }, { "speaker": "stephan", "time": "58:43", "start": 3522.85, "text": "course, yeah, the consensus one. Yes, and I think, it's, also people move slowly and the, the support is built for these things, and it needs to, you know, I, I think that's, that's fair. but I, I guess looking out longer term, and as you've mentioned, right, in the future with V3 and ephemeral, you know, 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. and I guess maybe there's a little bit of like fee optimizing that goes into that as well. Yeah. is that sort of the high level goal, that's the high level push here?" }, { "speaker": "glozow", "time": "59:28", "start": 3568.0, "text": "Yeah, yeah, exactly. there's, so if you, if you read, Like James Oburn's of, Vault proposal, for example, or, just a lot of protocols w- or like use cases built with, you know, the Covenant, Covenant proposals, they all depend on Package Relay, because they're all, you know, these smart contracts where there's a time lock and there's, you know, multiple parties and you sign now and you broadcast later and things can change and you, you need some way of, of managing fees, I, I think we're, we're in this like space where, you know, we're building layer two, like we're building more on top, where we're hopefully able to get more privacy and scalability and more expressivity, more features. I 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 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, this security assumption which isn't quite safe today, we can, we can make that much stronger. And then, 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 for, you're always able to settle on chain. And I guess one" }, { "speaker": "stephan", "time": "01:01:00", "start": 3660.27, "text": "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 of this stuff we've mentioned in this episode also helps just layer one users, even if you don't care about layer two?" }, { "speaker": "glozow", "time": "01:01:22", "start": 3682.59, "text": "Yeah, yeah, exactly. I, I mean, it's ex-exactly. So, I mean, even today, if you received a payment, actually a lot of, I, I, I heard a lot of people say this when, you know, mempool and fee rates started rising, that they would receive some kind of payment at one sat And then it would disappear from mempools 'cause it got evicted, and they're essentially like, \"Hey, can you send it again, but with like a new fee rate? \" and a lot of like wallets were like 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. and" }, { "speaker": "stephan", "time": "01:02:10", "start": 3730.0, "text": "at that point- Just, just I guess curio- out of curiosity, you should treat it like it ha- it could, it could get broadcast. If you just reset the new transaction, you might be out money double because you already paid once and now you just paid again. So it's kind of like, it's a really awkward limbo situation there until we get package relay, right?" }, { "speaker": "glozow", "time": "01:02:26", "start": 3746.43, "text": "Yeah. well, I mean, part of it is like maybe fix your wallets. There's like so much low-hanging fruit with respect to how we can make the, like, the fee thing like a, a much 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 the, where'd it go?\" Or like, you know? and yeah, there's, there's a whole list of things that we can do One of which is Package Relay, which should, eliminate a lot of things, 'cause yeah, you could just see PFP that thing that just fell out of your mempool." }, { "speaker": "stephan", "time": "01:03:06", "start": 3786.67, "text": "Gotcha. I guess while we're here also, mempool full RBF, do you have any thoughts on that or anything to add in terms of where that's at, or is it just sort of that the option is there and you're just happy for people to- Enable it or disable it, however they choose." }, { "speaker": "glozow", "time": "01:03:22", "start": 3802.19, "text": "Yeah, so," }, { "speaker": "glozow", "time": "01:03:25", "start": 3805.7, "text": "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 one twenty-five, you're just not gonna bother. the-- Yeah, there's, there's a lot of issues that we could, we should fix before we like intentionally would want to fix. Gotcha. Sorry, when I say we, I'm not saying like Bitcoin Core is like about to, about to- Merge it or whatever. Right. I, I, I think, this is my personal opinion, if, if I, you know, were to decide, I, I, 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, I think the other reason that we'd, 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 is a lot of, block explorers and full RBF like 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 like, 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, like Habits, but I, I think like basically for me personally, I, I spend a lot of time looking at like full RBF, 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, 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. Right. Yeah. Yeah, no, that's my personal opinion." }, { "speaker": "stephan", "time": "01:06:17", "start": 3977.78, "text": "Yeah, gotcha. so yeah, I think, 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 wanna mention, you know, if there was like one key takeaway, what should people take away?" }, { "speaker": "glozow", "time": "01:06:30", "start": 3990.43, "text": "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." }, { "speaker": "stephan", "time": "01:06:45", "start": 4005.31, "text": "Okay, great. Well, I'll make sure to include, the stuff in the show notes. you've done a review club on this. I'll, I've got, your Bitcoin Optech series, which we'll also include in the show notes. And, thanks for joining me, Glozow." }, { "speaker": "glozow", "time": "01:06:58", "start": 4018.05, "text": "Thank you so much for having me." }, { "speaker": "stephan", "time": "01:07:00", "start": 4020.13, "text": "As always, I hope you found the show educational and informative. Make sure to share the show with family and friends so that they too can learn about Bitcoin and stay informed about changes and updates that are happening in terms of Bitcoin transactions and package relay. You can find the show notes for my show over at stephanlivera.com/511. Thanks for listening, and I will see you in the citadels." } ] }