Replace By Fee (RBF) — NADO 26

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

Sjors Provoost Hello.

Aaron van Wirdum Sjors, I heard Bitcoin is broken.

Sjors Provoost It is.

Aaron van Wirdum Again.

Sjors Provoost Yeah, it was absolutely terrible.

Aaron van Wirdum A double spend happened.

Sjors Provoost Yep, ruined.

Aaron van Wirdum And this is because a fatal flaw in the Bitcoin protocol.

Sjors Provoost Yep.

Aaron van Wirdum That's how it was reported, I think, in Bloomberg.

Sjors Provoost Yeah, I couldn't find the original report by Bloomberg. I think Cointelegraph reported it more or less in that way, and then Bloomberg referred to it.

Aaron van Wirdum Oh, yeah, I think that's what happened.

Sjors Provoost But at least more recent articles I saw from Bloomberg were saying, oh, noobs thought it was broken, and they were all Googling double spends.

Aaron van Wirdum Oh, they corrected it?

Sjors Provoost I wouldn't say corrected it. They were more like, you know, going meta on it.

Aaron van Wirdum On their own mistake.

Sjors Provoost So I don't know if it was their own mistake because I've only seen the haters basically saying that they made that mistake.

Aaron van Wirdum Fair enough. Okay. So to be clear, Bitcoin is not actually broken.

Sjors Provoost Nope. It's working as expected.

Aaron van Wirdum It's working exactly as expected. Now we could get into a discussion on whether or not the double spend happened or not. And that gets into the definition of double spend, but we're not going to do that. Sjors.

Sjors Provoost No.

Aaron van Wirdum Instead, we're going to explain what was sort of this alleged. fatal flaw in the protocol which was replace by fee RBF

Sjors Provoost yes

Aaron van Wirdum that was sort of why this alleged double spend could have happened

Sjors Provoost Yeah, it could have happened even without that.

Aaron van Wirdum Sure, yeah. And I guess that's the sort of stuff we're going to discuss in this great podcast today.

Sjors Provoost Exactly. So stay with us and you'll learn more.

Aaron van Wirdum Okay, first of all, this thing is called replace by fee. Just in brief terms, what does it mean? What is replace by fee?

Sjors Provoost So it means you have a transaction that might be going from A to B and you're paying a fee to the miners and you decide it's taking too long because miners... We'll mine the biggest fee first, generally. And so you can send the new transaction with the same origin, same destination, if you like, and you increase the fee. And then that gets propagated to your peers.

Aaron van Wirdum Yeah, well, now you've already sort of described the use case. If we want to put it in more abstract terms, it basically means that if there are conflicting transactions, the miner will pick the highest one, right?

Sjors Provoost Exactly. So conflicting transactions means spending the same input.

Aaron van Wirdum I said highest one. I mean the transaction with the highest transaction fee.

Sjors Provoost Yes, that's right.

Aaron van Wirdum Yeah. So you just described one use case. You're sending a transaction and it's taking too long to confirm. So you send a new transaction with a higher fee.

Sjors Provoost Yeah. And that's a very reasonable use case. You're sending a transaction with maybe one Satoshi per byte because you're not in a hurry. But then after a couple of days, you're like, okay, this is ridiculous. And you bump it to 100 Satoshi per byte, and it goes in the next block.

Aaron van Wirdum Yeah, or after a month.

Sjors Provoost Right now we have transactions in the mempool that have been there for a month that pay one satoshi. This is the first time ever I think this has happened.

Aaron van Wirdum Okay. So fee market is working, which is the next point I want to make. This is another argument in favor of replace by fee. Is that it actually allows for more effective fee markets to happen?

Sjors Provoost Yeah, that's right. Because in 2017, what we saw is that because people did not use replace by fee. They saw the mempool was quite full. They thought, okay, currently the fees might be 50 satoshi per byte, but I can't change it anymore. So I'm just going to be safe and I'm going to set it to 100 satoshi per byte. And then the next person would say, oh, well, that looks really expensive. Let's make it 200 satoshi per byte. So people were really bidding up against each other much more than was necessary.

Aaron van Wirdum Exactly. With replace by fee, they could have instead paid, say, one satoshi. And then keep an eye on the mempool maybe and see, okay, you know what? It looks like my one Satoshi transaction isn't going to confirm in the next block. So you know what? I'm going to bump it to five. And then sort of keep an eye on the mempool or wait, you know, half an hour, however much in a hurry they are. And in that way, sort of make sure that transaction confirms fast enough, but not overpay to make sure.

Sjors Provoost exactly yeah

Aaron van Wirdum so we've got two benefits already one of the benefits is your transaction gets stuck you want to get it unstuck the second benefit is it allows for better fee markets yeah there's a third interesting benefit and I think there are more if we want to get into the into the details but what one pretty obvious one is that with replace by fee you can make more efficient use of the Bitcoin blockchain so for example I'm paying you, Sjors, and then next I'm paying Ruben, who's not here today, but I'm also paying Ruben. And the way I could do that with Replace by Fee is I send you one transaction first, and after that I decide that I want to send Ruben a transaction. So now I create a transaction that pays you both. and then include a good fee in that. So now instead of using two different transactions, I can use one transaction, which is more efficient block space-wise.

Sjors Provoost Yeah, and exchanges can do this at a much larger scale, right? So they have lots of customers that they need to pay out, and so they create one transaction. And that's going to be in a mempool for a while. And so every time another user withdraws coins, they just expand that transaction. And then whichever gets in the block gets in the block and the rest will just make a new transaction.

Aaron van Wirdum Exactly. They can sort of keep updating this transaction by including more and more recipients.

Sjors Provoost Yeah, which also, again, means more efficient use of the blockchain. So you get more value for your vbytes.

Aaron van Wirdum So there are three pretty good benefits. One of them is getting transactions unstuck. The second one is allowing for a more effective fee market. And the third one is more block space efficiency.

Sjors Provoost Yeah, and I can mention a fourth one that will actually create a nice bridge to the downside. Which is, let's say you make a one Satoshi per byte transaction to an exchange, and that exchange is called Mt. Gox. And you read on Twitter that this is maybe not a very good exchange. So you're like, okay, maybe I don't want to do this anymore. And so you can cancel a transaction because you can create a transaction with a higher fee that just goes back to you.

Aaron van Wirdum Right, yeah. So you're describing it as a benefit now. But like you said, this is what critics of Replace by Fee would consider a detriment. And it is, of course. In a way, there aren't that many critics of RBF anymore, I think. But yeah, the detriment, the downside is that it allows for double spending if the recipient isn't going to wait for confirmations. So it's easier to double spend unconfirmed transactions with RBF.

Sjors Provoost Yeah, and this was, of course, a big discussion, say, in 2015, 2016, when this, what we're going to talk about was introduced. You know, a lot of merchant applications would... like to be able to just have an instant confirmation essentially but it wouldn't be confirmed so that's that's inherently risky but as I guess we'll explain by default if everybody played reasonably nice it wasn't very risky but of course in Bitcoin we think long term and we don't want to rely on something that just requires too much kumbaya

Aaron van Wirdum yeah so that was indeed a big discussion on whether or not we should allow RBF in the Protocol, I'm saying protocol, but to be clear, either way, it's not actually a consensus rule.

Sjors Provoost Yeah, so there's a difference between consensus as in what is allowed inside of a block. So if you see a block with something in it that's not consensus compatible, you will not accept the block. And so the miners won't get their reward and it's really bad.

Aaron van Wirdum It's just an invalid transaction, invalid block.

Sjors Provoost Yeah, but there's all sorts of rules that pertain to how the network works. Things that... which transactions a node will relay or which ones it will reject and those rules are you know they're written in the code so if you run the code as it comes it'll do that but there's not really any enforcement other than that you can change the code or change the setting and it will behave differently.

Aaron van Wirdum Yeah, these are like peer-to-peer layer rules.

Sjors Provoost Yeah.

Aaron van Wirdum And importantly, this is also for miners. This is how they decide which transactions they include in blocks.

Sjors Provoost Yeah, but there it's even more important to realize that miners, of course, are very conscious of their revenue. So they will probably change something if the code does something that's not favorable for them economically and they can get away with it, they will do it.

Aaron van Wirdum right presumably if it's like not some edge case yeah so the reason it was sort of controversial at all in the first place is because it was going to be the discussion was on whether or not RBF replace by fee was to be included in Bitcoin Core and most Bitcoin nodes on the network are Bitcoin Core so if all Bitcoin Core nodes would for example reject replace by fee transactions, then it would actually be very hard to get your replace by fee transaction to a miner because nodes wouldn't relay it over the network.

Sjors Provoost Right, so you'd have to know who the miner is or there'd have to be some nodes that would relay it anyway.

Aaron van Wirdum Yeah, or you'd have to be a miner or something like that, yeah. So by including replace by fee in Bitcoin Core, by including it, that's how it would become a bit more easy to make an unconfirmed double spend.

Sjors Provoost Yes.

Aaron van Wirdum Okay, so that's sort of the argument against replace by fee. Now let's debunk that argument, Sjors. Can we?

Sjors Provoost Go ahead.

Aaron van Wirdum Well, I will first mention,

Sjors Provoost did we? Well, we at least brought up the point that we don't want to rely on people being nice and people using default settings.

Aaron van Wirdum Sure, that's the most obvious argument that it's possible whether you like it or not. But like I said, whether it's included in Bitcoin Core kind of makes a difference on how easy it's going to be.

Sjors Provoost Yeah.

Aaron van Wirdum Okay. Well, I will mention, first of all, there's a thing called first seen safe replace by fee, which people were discussing back in like 2015, 16.

Sjors Provoost Okay, how does that work?

Aaron van Wirdum The idea behind first seen safe replace by fee is that you can only replace transactions if the outputs, if the recipients get at least the same amount of money. So that way, even an unconfirmed transaction is relatively safe under this context what we're talking about. Because the transaction can be replaced, but only by adding even more recipients.

Sjors Provoost Yeah, but there's a huge problem with that, which is that the, Blockchain has no idea who the change address is. So normally what happens is...

Aaron van Wirdum Well, there's no change address at all.

Sjors Provoost Well, yeah, but that's already a problem with replace by fee. But let's say I'm sending you 0.1 Bitcoin and I use a coin worth 0.2 Bitcoin.

Aaron van Wirdum Oh, sorry. There is a change address. There isn't a fee address. I was confused.

Sjors Provoost Exactly. So yeah, so that's good to remind the listener. There is no fee address. There is just how much I'm sending you and then how much I'm sending myself as change. And the difference between that is the fee.

Aaron van Wirdum Right.

Sjors Provoost The problem is, if I sent you 0.1 using a 0.2 coin, the change is going to be 0 .1. And then if I want to raise the fee, well, normally what I would do is I would just lower the change amount. But with this rule that you just explained, you can't lower the change amount because the blockchain doesn't know. They might think I'm actually cheating the intended recipient rather than myself.

Aaron van Wirdum Right, that's a good point.

Sjors Provoost So that means you have to add another input. every time you want to bump the transaction fee. But that actually uses more block space, so it gets really expensive really fast.

Aaron van Wirdum Well, it could still work in the situation we described where an exchange adds new recipients in the payout address, for example.

Sjors Provoost No, they would have the same problem. Every time they add a new recipient, they would have to add a new input.

Aaron van Wirdum But that's fine.

Sjors Provoost Well, they'd have to have like a Sahara Desert of Dust to be able to keep doing that. Because if they want to pay a thousand people, they need a thousand inputs.

Aaron van Wirdum I guess you're right. So it does not sound very practical.

Sjors Provoost I've never seen this proposal myself. I was not very active in the... I was not active at all in Bitcoin Core when this played out. So maybe this argument has been mentioned, maybe not.

Aaron van Wirdum Maybe I hadn't heard it actually, but you're right. Then there is opt-in replace by fee. Okay. This is what's actually in Bitcoin Core, right?

Sjors Provoost That's right.

Aaron van Wirdum So opt-in replace by fee is replace by fee. Well, what it means is the only way Bitcoin Core nodes will replace a transaction, if it includes a higher fee, is if the first transaction includes a special flag. So a sign. that tells these nodes it's fine to replace this transaction if it has a higher fee.

Sjors Provoost Right. And so this is still a way to be nice, basically. But if you're a merchant and you're relying on this zero confirmation, if you see this flag, you know that this thing might disappear from under you. And Bitcoin Core nodes won't try to stop that.

Aaron van Wirdum Yeah, so the most practical sort of use case for this is if you are a merchant like BitKassa in the Netherlands, I think they will accept an unconfirmed transaction. So if you're at a bar and you're buying a beer, they have a payment terminal and they will accept unconfirmed transactions unless it has a RBF flag. Because in that case, they're just going to say, we're not sure enough that this transaction is not going to be replaced. This is a rejection from us.

Sjors Provoost Yeah, and they have to do that in addition to checking the fee. Because if you're sending a transaction with a very low fee, then it might also never get confirmed and you have a lot of time to try and replace it. So it's still a can of worms, I think, as a merchant to do this. It's fine for small amounts, I guess. But then if it's fine for small amounts, why worry about RBF? But also, I guess the discussion now is... Not as critical as it was then because now we have Lightning and we have pretty user-friendly wallets to the point where if you really want to accept something fast, Lightning is just much safer and better privacy too. so definitely back then that wasn't ready yet right so

Aaron van Wirdum yeah there are still some proponents of full RBF as well I think Peter Todd is an obvious example and i'm sure there are more I probably would consider myself one

Sjors Provoost I I vaguely remember a mailing list post maybe a year ago where somebody suggested just turning on full RBF

Aaron van Wirdum right

Sjors Provoost at some point in the future I think that didn't end up happening.

Aaron van Wirdum Right, yeah. His arguments, Peter Todd's arguments from... I don't know if these arguments have changed because it's been a couple of years since I wrote this article and spoke with him about this. But his argument was that the way these types of merchants... can be relatively sure that a double spend isn't going to happen with an unconfirmed transaction is monitoring the network. So checking, you know, having nodes on different parts of the network and see if there are any conflicting transactions going on. And this is in itself a problem that they feel the need to do this because for one, it's bad for privacy, arguably. Well, that's his argument anyways, because these nodes now have a better idea of where transactions originated. And two, it's requiring resources from nodes on the network because, you know, these spying nodes or whatever you want to call them, these double spend checking nodes, they have to get blocks and transactions from different nodes on network. So, you know, they're sort of wasting resources.

Sjors Provoost Yeah.

Aaron van Wirdum So it would be better, Peter Todd would argue, to just go for full RBF to make this kind of practices useless.

Sjors Provoost Yeah, but then those practices don't seem to be happening at a scale that's problematic. As far as I know, So I don't know whether you want to change it or not. The other thing is now that everybody's running Lightning nodes, those nodes will have pretty much all of the same problems that you just described. They have to make sure that... you know nobody's trying to close the channel on them etc does anything fancy so I think we're already at the place where you really need to pay attention to what's happening in the mempool

Aaron van Wirdum right okay so there is now a version of opt-in RBF in Bitcoin Core

Sjors Provoost yep

Aaron van Wirdum and by the way mentioning Peter Todd I think he still maintains like a bunch of nodes that do full RBF

Sjors Provoost Yeah, he used to have a separate release that was full RBF. And if you were sure that he wasn't trying to hack you, then I don't know if he released binaries or just code. It's just a one line change.

Aaron van Wirdum Right. And the idea was there that people could still use full RBF if they want to. And I'm pretty sure that some miners actually do use full RBF.

Sjors Provoost Yeah.

Aaron van Wirdum Which makes sense because it's incentive compatible for them to do so. They make the most money if they do so. So anyways, but in Bitcoin Core, there is the opt -in RBF version. And I think you have some more details about what it actually does.

Sjors Provoost Yeah, so I guess it's fun to describe it in a little bit more detail. So given a transaction, like I said, I sent you money and I have some change back to myself. There are five rules that Bitcoin Core will check if I want to replace that transaction. And this has been the case since 0.12. So it's quite a while.

Aaron van Wirdum Like five years ago?

Sjors Provoost Something like that. Yeah,

Aaron van Wirdum 2016.

Sjors Provoost So if a transaction spends one or more of the same inputs, that's the first condition. Remember that.

Aaron van Wirdum That's what makes it RBF in the first place.

Sjors Provoost Yeah, because I can spend twice. That's a bad idea. I could send you 0 .1 Bitcoin and have a fee and then create a new transaction that uses different inputs. Then, of course, the blockchain will just mine both of them and I have a problem. So I have to replace the input. And if I do that, then first of all, I have to opt into this thing with the flag that we talked about. That's rule number one. And then the rule is the replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions, which is a kind of a roundabout way of saying the opposite. I can add new inputs to this new transaction because maybe I want to increase the fee, so I need some extra inputs or I want to add other people. But this input has to be confirmed if it's a new one. And my guess is that this is just to prevent a can of worms where I have a transaction that is unconfirmed and I'm sending it across all the nodes and it doesn't depend on any unconfirmed inputs. And now I bump it, but now it does depend on all sorts of unconfirmed inputs. And now I'm forcing everybody to figure out where those unconfirmed inputs are and maybe they have a super low fee and I guess it's too complicated to implement.

Aaron van Wirdum Right, yeah. I can see that.

Sjors Provoost Because, you know, think about what this code looks like on the Bitcoin Core end. You have to write, you see this new transaction and what are you going to do? Oh, now some of these dependencies are unconfirmed. I have to traverse that whole tree. I don't want to think about that. I only want to think about my descendants.

Aaron van Wirdum Yeah, it would basically allow for types of denial of service attacks, I guess, where you just...

Sjors Provoost Yeah, I think it's... My guess is it's both for denial of service, but also just to make the code easier to implement for anybody who writes this kind of node software. Then rule number three, the replacement transaction pays an absolute fee of at least the sum of the original transactions. Because you can replace one transaction plus a bunch of its descendants, the things spending from that. But the absolute fee has to be the same. So if I paid...

Aaron van Wirdum Or higher.

Sjors Provoost Yeah, the same or higher. Exactly. Which also means that if I paid you and then you paid somebody else and I want to replace my transaction, The transaction that you paid to somebody else, I have to at least pay the same fee that was in there. It's kind of a disincentive for me to reorg from under you. Because that's one of the annoying things with RBF, right? I'm paying you, you're paying somebody else. Now I bump the fee. Oh, oops. The transaction you paid to somebody else is now gone.

Aaron van Wirdum Right.

Sjors Provoost And, well, I would have to really deliberately do that because I would have to increase the fee on my own transaction by enough that it also covers that transaction of yours that I just destroyed. So in practice, this wouldn't happen. We would either both agree to send a new transaction and somehow package them or not.

Aaron van Wirdum Yeah, there are probably very little, if any, sort of real-world examples where an RBF transaction would have a lower fee. So it's just to prevent weird attacks and complications.

Sjors Provoost It is an annoying rule, and maybe we'll get to it, but it's probably necessary. And then the fourth rule is it has to increase the fee rate. by the minimum relay fee

Aaron van Wirdum sure

Sjors Provoost so usually at least one satoshi per byte but if a mempool is full then the minimum relay fee is going to be higher So if the mempools are very full, then you cannot bump by just one satoshi per byte. You may have to bump by 10 satoshi per byte.

Aaron van Wirdum Right. This could differ from node to node. If they have different mempools for whatever reason, then they might have a different idea of what the minimum relay fee is. So it might make its way through parts of the network, but not others.

Sjors Provoost It's possible. Yeah, this is a tricky bit, right? Because you know from your own node how much is in the mempool. And so you have to estimate what the minimum fee rate is that still goes into your mempool. But if you just start your node after stopping it, the mempool might be incomplete. And so you might be more optimistic about how low the fee increment can be. So it's kind of annoying. But it does make sense that you don't want people to spam the network and you want to keep.

Aaron van Wirdum Yep.

Sjors Provoost So, and the fifth rule is the number of original transactions to be replaced and their transcendent transactions will be evicted from mempool must not exceed a total of 100 transactions. So I guess a simple way to say is that if you do something convoluted that touches more than 100 transactions, it's not going to work. And another caveat that I don't think is in these rules, but it is there, is that if you replace a transaction, it has to opt into it. Every one of its inputs has to opt into allowing this fee bump. But also for all the descendants, this has to be true. So if I... send a transaction to you and you send to somebody else, but your transaction does not opt into RBF, then I can't replace my own.

Aaron van Wirdum Right.

Sjors Provoost And also I can opt out of RBF. I can bump the fee once and then I can say, now it's final. So I opt out in the last bump.

Aaron van Wirdum Oh, that's actually possible?

Sjors Provoost Yeah.

Aaron van Wirdum Right.

Sjors Provoost And this is probably also why there's so many problems because we could talk about problems.

Aaron van Wirdum Oh, there are problems?

Sjors Provoost There are problems. [unclear]. Especially... Well, let's start with a simple problem that I don't think I've seen a solution for. Let's say I'm sending you a transaction, but I'm also sending Ruben a transaction. I think we mentioned that example. And those are two separate transactions. But now I think, oh my God, what if I combine those transactions? Because that would be more efficient.

Aaron van Wirdum It would be.

Sjors Provoost Yeah. But because maybe I can use fewer inputs in particular. Because I have one input. that goes to you. And I have one input that goes to Ruben. And if I combine them, then they go to both of you. So that saves me a number of bytes. But we talked about rule number three. So I don't think we can do that.

Aaron van Wirdum Oh, because it has a lower absolute fee in that case?

Sjors Provoost Yeah.

Aaron van Wirdum Right. So there actually is a normal example where it would be handy.

Sjors Provoost Yeah, exactly. So because I've increased the fee rate, right? Because I have to increase the fee rate. But unless I double the fee rate, or I don't know what the factor is, because I've made the transaction smaller, the absolute fee is going to be lower. So generally merging two transactions is not, yeah, it's not going to work.

Aaron van Wirdum Right.

Sjors Provoost The current RBF rules.

Aaron van Wirdum So yeah, the way to go then would be my solution to just make, not make two separate transactions, but the second one would have already, needs to already be the RBF one.

Sjors Provoost The downside of that one.

Aaron van Wirdum Needs to already combine the two.

Sjors Provoost Yeah. The downside of that is it needs to, you need to track a little bit more things of what's going on. Because in the example I gave you is either, if one of them confirms, so if the one, If the one with the combined one, if it confirms, then you're done. If one of the original two confirms, then the combined one won't happen. So it's more clear which one you need to bump. But if you start combining things, you need to track, I guess, because one of those versions will confirm you need to remember which ones to add. But you probably have to do something like that anyway. And a wallet can automate it. Yeah. And this is not really a consumer use case that often because, you know, you might send more than one transaction per unit of time, but usually it'll probably be confirmed before you get to the next one.

Aaron van Wirdum Sure.

Sjors Provoost But for exchanges, this is relevant, but for exchanges, they can build the automatic tracking software.

Aaron van Wirdum Exactly.

Sjors Provoost So maybe this is a non-issue, but I just wanted to bring it up to illustrate the rule. And then there is transaction pinning, which is a problem with Lightning. And here, I think the simplest way to say is with Lightning, you have two parties that craft a transaction together, but they have to decide in advance what the fee is going to be. That's annoying because fees can go all over the place. So when two Lightning nodes are connected, they are constantly sort of renegotiating those transactions and creating new ones. just because they want to take into account the fee weather.

Aaron van Wirdum Yeah, well, what you mean, I think is, so yeah, to be clear, in Lightning, you need to create a transaction with your channel partner, but then sometimes you'll only broadcast that transaction months later. While at the time of negotiating the transaction, that's when you're deciding on what the fee is going to be. While months later, maybe that fee is not going to be enough. That's the problem.

Sjors Provoost Yeah, but as your Lightning node is running, it's talking to the other side and it will renegotiate. So it's not too bad.

Aaron van Wirdum Okay.

Sjors Provoost Regardless, yeah, if the channel closes, you know, maybe you don't reach each other and it might be very unfavorable fee. So the idea here would be, wouldn't it be nice if you can agree on a very low fee, but you can RBF it yourself later. And so there was some complicated thing done with these Lightning transactions, as well as a rule in Bitcoin Core that would let you add extra outputs to it. And then each of the parties could RBF that if they wanted to. But the weakness in that story is that if I'm evil, I could basically add a transaction to RBF it and it would say opt out of RBF and the fee would be very low. Because we talked about this rule that all of the descendants have to opt into RBF. Does that make sense?

Aaron van Wirdum Can you repeat the last part?

Sjors Provoost So I'm doing this RBF transaction, but I'm opting out of it in that RBF transaction. I'm using a very low fee. So now you want to bump that.

Aaron van Wirdum Oh, right. Got it.

Sjors Provoost You can't even add your own RBF anymore because one of the descendants is now opting out. And there's various shenanigans like that. You could add a chain of 99 transactions to it. So you violate the 100 maximum rule. You know, you add 99 transactions with a super low fee. Now the other side cannot add number 100 or 101.

Aaron van Wirdum Right.

Sjors Provoost And all sorts of annoying shenanigans that if you go to a Lightning developer mailing list, it is full of this sort of pure headache. And I don't think that just going for a full RBF would really solve that because the other problem we talked about in another episode is just package relay in general. Like, what do you do with these if somebody wants to replace a chain of 100 transactions? Yeah, that kind of worm, I'm just going to leave it open. Just saying that this is every now and then on the mailing list, you'll see threads and people proposing different solutions and then people explaining why that doesn't work.

Aaron van Wirdum Yeah. Okay, well, that was getting very into the weeds. Let's get back to the beginning. What actually happened with this double spend concretely?

Sjors Provoost Back to our amazing adventure that made it all the way to Bloomberg and crashed the market by 7%.

Aaron van Wirdum Allegedly, maybe.

Sjors Provoost No, I don't actually believe in astrology. So basically what happened is forkmonitor.info is a site that I also work on by BitMEX Research detected... two blocks at the same height. It's called a stale block, or at least one of them is going to be stale.

Aaron van Wirdum One of them is definitely going to be stale because, well, for obvious reasons.

Sjors Provoost Yeah, because other miners will see two blocks, and then there's some heuristics, like just build on the first one you saw, for example. Also, nodes will do that. If all things equal, they'll pick the first one they saw. And at some point, miners will build on one side or the other, and that's going to be the final blockchain. But now what happens if in one of those blocks is a transaction that sends money to you, and in the other block is the same input, but it goes to me? Now that will be a double spend.

Aaron van Wirdum Right.

Sjors Provoost Now in this case, what seemed to be happening is that somebody did an RBF fee bump, basically. But the... winning, like the higher fee ended up in the shortest chain and the lower fee ended up in the longest chain. And this probably wasn't any nefarious thing. It's just that those transactions and the fee bumps are moving around the mempools all over the Bitcoin network. And you find a block just before you see the increased fee and you miss it.

Aaron van Wirdum Yeah. So that's probably what happened is that there was one fee and then there was a replacement fee. And while the replacement fee was still making its way over the network and reached one miner that mined the block, it hadn't yet reached another miner that also mined the block at the same time. So now there were conflicting transactions in the two blocks.

Sjors Provoost Right. And if I remember correctly, this particular transaction also had an OP_RETURN script. So it was probably some sort of protocol that's doing some sort of token thing. And the OP_RETURN script was also changing. So that's why it was marked as a double spend and not as a fee bump, because I wrote the detection code for that. And one of the rules was like, if the fee changes by a little bit, I'll consider it a fee bump with or without the RBF flag, because maybe people use it or they don't. But if something weird changes, then it just says, just manually investigate, this might be double spend. And that, you know. crashed the market.

Aaron van Wirdum Right. But yeah, there was nothing going on. Yeah, it resolved exactly like you would expect it to resolve exactly like how Bitcoin is designed. All right. Anything else then?

Sjors Provoost No.

Aaron van Wirdum All right. Thank you for listening to the Van Wirdum Sjorsnado.

Sjors Provoost There you go.