Episode 1: Explaining New PSBT and RBF Attacks

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

Sjors Provoost Hello.

Aaron van Wirdum [imitates tornado warning] That's my impression of a tornado warning.

Sjors Provoost Oh, okay.

Aaron van Wirdum That's probably how they sound, right?

Sjors Provoost I don't know, I've never heard one.

Aaron van Wirdum Me neither. Sjors, we're going to make a podcast.

Sjors Provoost Yes.

Aaron van Wirdum I suggest, since this is our first episode, we first introduce ourselves.

Sjors Provoost Sure.

Aaron van Wirdum Who are you, Sjors?

Sjors Provoost I'm Sjors. I work on Bitcoin Core and other hobbies. I live in Utrecht, as do you.

Aaron van Wirdum Yep, I'm Aaron van Wirdum. I'm the technical editor at Bitcoin Magazine. And what we're going to do basically is discuss technical news, technical stuff, Bitcoin -related technical stuff.

Sjors Provoost Yes.

Aaron van Wirdum Correct?

Sjors Provoost Sounds right.

Aaron van Wirdum I think we can just start then.

Sjors Provoost All right.

Aaron van Wirdum So we got two topics this episode. See how that goes. First topic is the... Well, there wasn't apparently an official name for it or if there was we couldn't find it but the Fee Burning Bug?

Sjors Provoost Yeah, we call it the Fee Burning Bug.

Aaron van Wirdum That's how we're calling it, right? So that was a big issue with hardware wallets in particular. It is a bit windy here which is fitting for our name.

Sjors Provoost Exactly. I'm trying to keep the wind from the microphone.

Aaron van Wirdum So there was a big issue which related to hardware wallets specifically, I think, a new bug, or at least sort of new, and the problem was that an unknowing victim could overpay in fees and therefore lose money, right?

Sjors Provoost That's the synopsis of it.

Aaron van Wirdum Okay, so let's start from the beginning. What is this bug? How does it happen?

Sjors Provoost Well, we can go back a little bit further in history to talk about a similar bug, which people thought was completely fixed, but it wasn't. So if you have a Bitcoin transaction, it has... a bunch of inputs that you're spending from, and it has a bunch of outputs that you're spending to.

Aaron van Wirdum Yeah, so the inputs are basically the addresses, your addresses that you're sending the coins from, and the outputs refer to the addresses that you're going to, right?

Sjors Provoost Yeah, assuming Luke Dashjr isn't listening to that first part, what you said, but basically.

Aaron van Wirdum Right. I'm simplifying a bit. That's sort of my job, right?

Sjors Provoost But one thing that, you know, if you use a wallet, you'll see in a transaction is a fee. But actually, if you look at the transaction on the blockchain, there's no such thing as a fee in the transaction. It's just a difference between the inputs and the outputs.

Aaron van Wirdum Yeah, so there's more coins going into the transaction than coming out of the transaction, essentially. And that difference is something the miner can claim as a fee.

Sjors Provoost And the other thing is that a transaction output will say the amount. So the transaction output might say, here's one BTC, but an input does not. An input just says, take this previous transaction and spend it. And it's up to you, again, to figure out how much that was, because it would be a waste of space to put the amount in the blockchain twice. Here's the problem.

Aaron van Wirdum The amount was already in the blockchain from the previous transaction. You're just spending the coins from that transaction, and the only thing you really need to know is the new amount, because then the difference, you know, you can just look at a previous transaction, usually at least.

Sjors Provoost Yeah, and so when you make a new transaction, when you have a wallet, say the Bitcoin Core wallet, you enter a destination and an amount, and then what it's going to do is it's going to look for coins, those are inputs basically, that add up to at least the amount you need to spend, and then it adds a change to go back to you. And that's fine because you're doing all the work and your wallet can check it. But now let's say you want to be safe and you want to put your private keys not on your computer, but you want to put them on a hardware wallet. So then what happens is your computer produces a transaction without a signature, gives it to the hardware wallet and says, go and sign this thing, please. Now, the hardware wallet will look at it and say, okay, these are the outputs. I can read that. But what about those inputs? I know nothing about them.

Aaron van Wirdum The hardware wallet has no idea about the inputs because the hardware wallet has no idea about the blockchain overall.

Sjors Provoost Exactly, unless you tell it about it.

Aaron van Wirdum Right.

Sjors Provoost So let's say you just lie to the hardware wallet and say, look, you're spending these two inputs. They're just half a Bitcoin. And, you know, there's almost no fee on this thing. Now, the hardware wallet, there's no way to check that. It used to have no way to check that. And so it would just sign the transaction. And then, oops, turns out you spent one Bitcoin in fees. That's quite annoying. And maybe some malware on your computer was doing that to you. So the solution to that is that you give the hardware wallet everything it needs to check. And so you give it...

Aaron van Wirdum The reason, to hold on one second, the reason you would overpay in fees in that scenario is because there would actually be more coins in your inputs than you're telling your hardware wallet.

Sjors Provoost Exactly. So you might think you're spending half a Bitcoin, but actually the coins that you're spending are worth one Bitcoin.

Aaron van Wirdum Right. And the hardware wallet just didn't know that because you lied to the hardware wallet.

Sjors Provoost The hardware wallet can't tell the difference, so we'll just sign whatever.

Aaron van Wirdum So that's a problem.

Sjors Provoost Yes.

Aaron van Wirdum You don't want that.

Sjors Provoost But the signature describes... So you're signing a message, essentially, and the message is the transaction. And the transaction, or part of the transaction, and the transaction contains the inputs that you're spending, namely the transaction hash and the position in that previous transaction. And so now you could give the hardware wallet the actual transaction that you're spending from.

Aaron van Wirdum The previous transaction.

Sjors Provoost Yes, exactly. And that previous transaction, you can look at it and you can check the hash. and you can check that the hash matches what's in the input, and you can see what the output amounts are. So now you know that you're probably spending an actual transaction that wasn't messed with, and you can check the amount yourself. So that's basically how it worked. So you would just give the hardware wallet all the inputs, and that's fine if it's small, but maybe you're spending from a giant exchange payout. multiple kilobyte transaction and you maybe you don't have a USB connection

Aaron van Wirdum but you are sending it through a QR code so space could be an issue. A hardware wallet is basically a very weak computer and then you have to load all that information into the very weak computer and it's a hassle and it can take a lot of time if it's a big transaction or a lot of them so that's not ideal for hardware wallets.

Sjors Provoost Yeah some of them are really really slow. They're using chips that were designed in the dark ages, basically.

Aaron van Wirdum It's not really made for this type of stuff.

Sjors Provoost No, absolutely not. Anyhow, so in came SegWit, and the idea was to say, okay, let's have the signature of the transaction not just cover what coin you're spending, so not just the transaction hash and the input number, but also the amount that you're spending. And then the idea is that if you sign something, you actually add the amount before you sign it. And then if somebody lied about the amount, well, then your transaction is just going to be invalid on the blockchain.

Aaron van Wirdum Right.

Sjors Provoost So the hardware wallet will just sign it because it just sees an amount and it says, okay, whatever. I haven't checked that amount because I haven't looked at the previous transaction. But I'm going to sign it anyway because if the amount is wrong, it's going to be invalid. So I don't really care.

Aaron van Wirdum Right.

Sjors Provoost And that's where the attack comes in that was discussed. And it wasn't unknown. It just was considered a little bit contrived. But here's what happened. Let's say you give... Well, a transaction has two inputs. And one of them is half a Bitcoin and the other is half a Bitcoin. But you're actually going to lie. your computer is going to lie to your hardware wallet, and it's going to say, well, the first one is half a Bitcoin, and the second one is just 0.01 Bitcoin, don't worry about it.

Aaron van Wirdum Yeah, so to be clear, the reason your computer would be lying to your hardware wallet is because your computer was compromised.

Sjors Provoost Yes.

Aaron van Wirdum So, right, the idea behind hardware wallets sort of is that even if your computer is compromised, you should be fine, but in this case...

Sjors Provoost Well, that's one way to look at hardware wallets, yeah.

Aaron van Wirdum There's some... There are still some attack factors of which is one and there are others.

Sjors Provoost If your computer is compromised, you have a very serious problem. But let's say somehow the problem is limited to just this little thing that's going to happen now.

Aaron van Wirdum Right, so then your computer is lying to your hardware wallet. So what's the lie?

Sjors Provoost The lie is, here's a transaction with two inputs, and I'm going to tell you the truth about the first input, and I'm going to lie about the second one. And then you're going to sign it, and you're going to sign both inputs, and you're going to trust the amounts that you get from the computer. And now, if you were to broadcast that transaction, it would be invalid. Because the blockchain would look at the first input and it would say, yeah, that's valid. And it would look at the second input and say, no, no, no, that's not 0.01 Bitcoin, that's 0.5 Bitcoin. So I'm not going to do anything with the transaction. But here's the problem. What if you send the hardware wallet another transaction, which is the opposite, where the first input is a lie. And the second input is actually true. And now the hardware wallet will diligently sign that one. And now you can actually combine the first and the second transaction, because you can just combine, take the input from one, put it on to the other.

Aaron van Wirdum Yeah, so there's two transactions with two inputs. Both are really yours. However, your computer is lying to your hardware wallet twice, telling you only one of them is yours.

Sjors Provoost Exactly.

Aaron van Wirdum The opposite one in both cases.

Sjors Provoost Yeah.

Aaron van Wirdum Both times the outcome is an invalid transaction, because the input you're being lied about doesn't match what's happening on the blockchain. However, with the two invalid transactions, you can both times take the valid one, an attacker can both times take the valid half, combine these, and then all of a sudden have a valid transaction.

Sjors Provoost Yes. So that's how you're circumventing the amount restriction. Yeah, and now the question is, how would this lying take place? Well, it would just tell you... After you sign the first one, it would say, hey, there's a problem, please try again. And it would show the other one. And so that's a very mean trick. So then the question is, how do you solve that problem? Well, you go back to basically what we had before. You just give it the inputs. Because now the hardware wallet sees the actual input transactions and can calculate the hash and say, hey, the amounts are...

Aaron van Wirdum Just to be clear about the problem before we move on to the new solution. The problem here is that in theory at least because we used a very simplified example here with two transactions and half both times but essentially if you really pull this attack to the limits you can drain someone's hardware wallet completely just with one transaction right?

Sjors Provoost Yeah, I guess you could do it three times.

Aaron van Wirdum and just just all inputs are just become a huge fee, and it's all paid as a huge fee, and yeah you know it kind of disappears into the blockchain to the miners somewhere.

Sjors Provoost Yeah.

Aaron van Wirdum So the only way to benefit from this attack is if you are a miner, correct? Like you need to be a miner because that's the only way you can get the fee.

Sjors Provoost Maybe, or maybe you can blackmail somebody in saying like, okay, now I have this transaction.

Aaron van Wirdum Right.

Sjors Provoost But I won't send it to the blockchain just yet.

Aaron van Wirdum You better pay me X amount or I'll broadcast this to the network and you'll lose your money.

Sjors Provoost Yeah, exactly. Something like that. So you never know. In general, there's something called defense in depth. So just because you cannot think of a way that this could go wrong, you still want to deal with it.

Aaron van Wirdum Yeah, it's a weakness you want to take care of.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, so the solution.

Sjors Provoost Well, the solution is we're back to the old story where you have to give all the inputs. all the input transactions so you can perform

Aaron van Wirdum you have to you have to provide the previous transactions like before

Sjors Provoost yeah so now there is a difference between this in the past in the past before SegWit you could fool a wallet with just a single attempt there was no need to to ask would you like to try again because you could just lie about the entire transaction and right now you have to do this weird trick where you tell the user oh something went wrong please sign again right and and so you know things weren't as bad as they were before but with this you know the way most hardware wallets have fixed this or at least some have fixed this we're kind of back in the old situation where you just need to give it the inputs

Aaron van Wirdum yeah so we solved the problem but then it turned out it wasn't really solved it was just made a little bit harder to abuse and then to solve it again we're sort of back to the original situation

Sjors Provoost yes

Aaron van Wirdum all right so now there was some I don't know if controversy is the right word, but there was some...

Sjors Provoost We can first talk about the even better solution.

Aaron van Wirdum Okay, go on.

Sjors Provoost So there is a new proposal called Taproot, which I'm sure we'll talk about in another episode. And part of what Taproot will do is, for every input, you have to sign the amount, not just of that input, but also of all the other inputs. And so, yeah, you can't lie about one input but not lie about the other input.

Aaron van Wirdum I see.

Sjors Provoost And I think it's not just the amount. It's a whole bunch of things you're signing for about that previous transaction. So you really don't have to provide it anymore.

Aaron van Wirdum So with that approach, you'd sign way more information about this transaction in general.

Sjors Provoost I mean, in general, with transaction signing, it's kind of a weird concept because the signature is in the transaction. So how does that work? You can't sign before you have the signature. So what you do before you sign the transaction is where the signature goes, you put a dotted line, so to speak, and you sign everything or you sign some parts of it. And you can change that scheme a little bit, add a little bit more to it or move things from it. So that's what Taproot plans to do.

Aaron van Wirdum But right now, I guess we're sort of drifting in a different topic now, but that's fine by me. So right now you indicate which part of the transaction you're going to sign, right? With the SIGHASH flag?

Sjors Provoost Yes.

Aaron van Wirdum So would Taproot actually make that less flexible then?

Sjors Provoost No, I think it just changes the meaning. So SIGHASH_ALL is what most transactions use, which is pretty much signing everything about the transaction. And I think, so what SegWit added is you're not just signing the content of your own transaction, you're also signing something about the inputs, namely the amount. And so what Taproot changes would be to sign not just the amount of the previous transaction, but a bunch of other things. Probably the script as well. I haven't read it.

Aaron van Wirdum And was this done to solve this specific problem, or are there other problems it solves?

Sjors Provoost Maybe. So that comes into why did this thing become an issue again, because this was known since 2017. And so I'm not sure. This problem was brought up again on the mailing list. And this Taproot solution was brought up on the mailing list. My theory is that bringing up the solution for Taproot reminded people of the original problem, made other people look at that original problem and not agree that it's innocent. They would feel more strongly about it.

Aaron van Wirdum Yeah, because this issue isn't new in itself. Like you said, it was around for years. And you think it was just rediscovered?

Sjors Provoost Yeah, it was either rediscovered or it was... like somebody proposes this solution, and you think, hey, what are you actually solving? Oh, I didn't know about that problem. So something like that might have happened. But I'm sure you can look it up in the archives. Now, it should be noted that if you can trick a user to sign twice, you can also just make them send different funds. So even with this fix... If I can trick the hardware wallet into signing again, I can just make them sign as many transactions as I want. But I can't lie about the amounts of each of those transactions. But you can still drain somebody's wallet. It's like, try again. Why don't you try again? And then you cannot rack up the fees. You would just have them pay you twice or pay somebody else twice. So perhaps that's less useful as an attack. If you can't lie about anything... then you're sending money to an exchange, and now you're sending it to the exchange twice. Well, if it's not the exchange that's trying to scam you, but some random malware, the malware doesn't really have any benefit from you sending to the exchange twice.

Aaron van Wirdum Right.

Sjors Provoost So it's perhaps a less useful attack.

Aaron van Wirdum Right. But it would be sending different coins still.

Sjors Provoost Yes. You would just have a brand new transaction. New inputs. different change address maybe even. But your hardware wallet only says, would you like to send this much to this address? And if it says that twice, you might just click OK twice. You don't even think about it.

Aaron van Wirdum Yeah, yeah. Right, I see. So there was some incompatibility with some wallets after this upgrade, right?

Sjors Provoost Especially BTCPay Server. They have a way to receive money on hardware wallets. That's not affected. But they also have a way to then send money from your hardware wallet using BTCPay Server. And the problem is, if you need to provide the actual input transactions, you need to still have those input transactions. And BTCPay Server doesn't have them. So it would have to... Basically, those transactions are sitting somewhere in the blockchain, and BTCPay Server at the moment doesn't have a way to just go in and get an arbitrary transaction from the blockchain.

Aaron van Wirdum Right.

Sjors Provoost But not all wallets have that problem. For example, the Bitcoin Core wallet, I believe it keeps the transactions that it cares about inside the wallet itself.

Aaron van Wirdum Even if it's pruned.

Sjors Provoost Even if it's pruned.

Aaron van Wirdum Right.

Sjors Provoost Exactly. And web-based wallets, they will just ask the server to please give that transaction, so that's not a problem either.

Aaron van Wirdum So it's mainly a problem for pruned types of wallets, because they need previous transactions, which they don't have in order.

Sjors Provoost Yeah, I would say it's a problem for not wallets, basically, so they aren't used to holding on to information. They just try to serve the wallet, sign things on the fly. They're key managers, but they don't hold on to transactions, maybe. It's not fundamentally unsolvable, but I can imagine it's painful.

Aaron van Wirdum It's unsolved, at least.

Sjors Provoost Yeah, I mean... At least for BTCPay Server.

Aaron van Wirdum There's no solution ready yet.

Sjors Provoost At least not for BTCPay Server.

Aaron van Wirdum Right.

Sjors Provoost But in principle it could be fixable because if BTCPay Server uses Bitcoin Core indirectly and Bitcoin Core has a transaction index turned on, it'll just work. Or if you store the block height, that also helps.

Aaron van Wirdum So do you think the fix was worth it? What's your opinion, Sjors?

Sjors Provoost The problem is slightly overrated, but it's other people's money too. And so... The problem, of course, is if you're using a hardware wallet and you don't like this choice, but you've upgraded the hardware wallet, you're kind of screwed. But not really, because at least with Trezor, you can downgrade it. If you don't like the solution, of course, you don't get any of the other fixes. In fact, it's open source, so you can even just take their latest firmware release and undo that one change. And maybe they could add a setting where you can turn it off if you want to.

Aaron van Wirdum Or you can just not upgrade, of course.

Sjors Provoost But if you were using Trezor with Bitcoin Core and HWI, that's all still experimental. But that would break until the new version of Bitcoin Core, which compensates for this change. So it's not the end of the world.

Aaron van Wirdum The upcoming version for Bitcoin Core will have a fix for this included.

Sjors Provoost Yes. At least if it gets merged, but I think so. So that's either 0.21, which comes out November-ish, or 0.20.1, which just comes out randomly.

Aaron van Wirdum Yeah. All right, anything else on this topic?

Sjors Provoost There's one other way that you could deal with this problem as a hardware wallet, which is to remember the inputs you've already signed and warn the user, hey, wait a minute, I've seen this input before, but that requires a fair memory on the device. But maybe if you only remember the last 10 inputs that you signed, maybe it's not too bad. It depends on how much memory the device has. Some have very little.

Aaron van Wirdum Yeah, you mean the hardware wallets, right? So hardware would have to remember transactions then.

Sjors Provoost Would have to remember some of the recent inputs they've signed and say, hey, you signed this before, are you sure you want this?

Aaron van Wirdum Right.

Sjors Provoost And by the way, the amount changed.

Aaron van Wirdum Yeah, so that would require more memory.

Sjors Provoost Perhaps, or at least it requires another software change. There might be ways to fool the hardware wallet with that kind of thing, so it's more complexity.

Aaron van Wirdum All right, Sjors, you want to move on to the next topic?

Sjors Provoost Yes, let's talk about our favorite topic.

Aaron van Wirdum RBF. Replace by fee. RBF. There was a news blitz in the crypto media this week about RBF and how there was a vulnerability, major weakness. Bitcoin was hacked.

Sjors Provoost Yes, Bitcoin was hacked. That's what we all read. Completely destroyed. Miner death spiral to come. End of the world.

Aaron van Wirdum There were news stories about RBF. So let's get into what was this news story about. Or maybe we should start with RBF.

Sjors Provoost Let's start with RBF.

Aaron van Wirdum What is RBF? What is replace by fee?

Sjors Provoost Okay. So basically, when you create a transaction, you don't put it in the blockchain. That's not how that goes. You actually send it to other Bitcoin nodes. And they send it to other Bitcoin nodes. And everybody sends it to each other in a happy circle. And eventually a miner... puts your transaction in a block.

Aaron van Wirdum Hopefully.

Sjors Provoost Yeah, or not. And then it's confirmed. Now, the reason why they might want to do that is not just because they're nice. it's because they want to make money.

Aaron van Wirdum Most of them are nice, though, aren't they?

Sjors Provoost Yeah, I would say so, because in the beginning, transactions paid very little fees, pretty much not worth the electricity.

Aaron van Wirdum True, for the first couple of years, yes.

Sjors Provoost So yes, miners also have some incentive to keep the network useful, but ultimately it's nice if you pay them. And the other thing is, let's say you have a lot of transactions, and they're competing for space, and now a block is full. Or, it's not full, but basically the miner has more transactions to choose from than he can fit in the block. What do you do? Well, if transactions pay fees, you just start with the highest fee and you work your way down. It's a little bit more complicated than that because transactions might depend on each other. But basically, that's the rational thing to do. Take the highest paying transactions, put them in the block and leave the rest out.

Aaron van Wirdum Yeah, it's a bidding war between transactions in that case.

Sjors Provoost Well, yeah, but the bidding is, you know, it's just one bid.

Aaron van Wirdum Right.

Sjors Provoost So then the question is, can we make that a little bit smarter? And so you might think it's a very quiet day, I'm going to pay the absolute minimum fee, one satoshi per byte, and I'm going to send that transaction around, and then all of a sudden, I don't know, BitMEX pays its daily user base, and the mempool is full, or it's busy, and actually your transaction is not going to confirm for hours and hours, and you're like, oh, okay, what am I going to do? You increase the fee. Now, this is always possible. It's always possible to increase the fee and to send it to other peers and to give it to a miner. And then they may or may not...

Aaron van Wirdum To be technically accurate, what you're really doing is creating a new transaction, spending the same coins to the same addresses, but with a higher fee this time.

Sjors Provoost Exactly.

Aaron van Wirdum Basically, right?

Sjors Provoost Yes. You're creating a new transaction that spends the same coins.

Aaron van Wirdum So it sort of overwrites your previous transaction.

Sjors Provoost Well, it's different than your previous transaction. And now the question is, why would other nodes and miners care about that? Now, other nodes might not care about it at all. And so initially, I think the default was that they would just ignore it. Because for them, other nodes, there's nothing in it to relay your transactions. It's just using their bandwidth. So they're not going to do that. but you could send it directly to a miner, and the miner might look at this and say, well, this new transaction you're sending me pays me more than the other thing I had, so I'll happily replace that and put that in the block.

Aaron van Wirdum Right.

Sjors Provoost And so if you can reach the miner in time, it'll get replaced. And in this case, of course, because the mempool is very busy, you have plenty of time to do this. But there was no official mechanism for that. And so some people would do that and other people would not. But generally, most of the time, it wouldn't be done. And so people kind of started trusting, okay, if I send a transaction, it's probably not going to get replaced by something else. So I can just accept it.

Aaron van Wirdum Okay.

Sjors Provoost but eventually a mechanism was introduced to formally ask for a fee raise, essentially to ask nicely, hey, this transaction has a higher fee, please replace it. And then other nodes, if you use that scheme, would do that for you. And you would indicate in advance, okay, if this transaction is, if I offer a higher fee, then you should relay the higher one.

Aaron van Wirdum Right. So then nodes will accept a new transaction and forward it for miners to ultimately take it and replace the previous one.

Sjors Provoost And there were some rules there. For example, the fee has to be substantially higher than the previous one. And so that way you're kind of disincentivizing, DoSing all your peers. And then all the peers would relay it.

Aaron van Wirdum How much higher does it need to be?

Sjors Provoost Just one Satoshi. No, I think the minimum relay fee. So if the mempool is empty or not busy, then that's just one Satoshi per byte. But if there's a lot of transactions in there, and say the minimum transaction fee is 100 Satoshi per byte, if you then want to [unclear], if you then want to bump the fee, you'd have to bump it with another 100 Satoshi per byte.

Aaron van Wirdum I see.

Sjors Provoost I think. Or it's, I don't know.

Aaron van Wirdum So that's a big difference.

Sjors Provoost At least one Satoshi per byte. I think it depends on how busy the mempool is.

Aaron van Wirdum Right.

Sjors Provoost You have to look it up.

Aaron van Wirdum Okay.

Sjors Provoost Anyway. So it's just a way to coordinate this fee-bumping thing. But fundamentally, a miner can do whatever they want. They don't have to care about this RBF flag being present or not. There's a lot of debate about whether you should make this deliberately unsafe to discourage people to not accept unconfirmed transactions. It gets a little political or practical. In practice, how high is this risk? Some businesses are happy to accept unconfirmed transactions for small amounts because they realize that it doesn't happen, it doesn't go wrong that often, or they have other fraud detection mechanisms to keep them safe. But anyway.

Aaron van Wirdum And on the plus side, I would say it makes the fee market operate way more smoothly.

Sjors Provoost Yeah, but the concept of raising fees in general is good for the fee market. Using the specific mechanism of RBF is just one way to do that. that people happen to have agreed upon, like this is the way to signal it and these are the rules, rather than just say everybody for themselves, you decide when you accept a new transaction or not with a higher fee.

Aaron van Wirdum Yes, but by adding flags like this and tricks like this, it allows the fee market to be more efficient. Or at least, as a user, I can start with a lower bid. And only if I see it's not enough, I can start to increase my bid. As opposed to having to go gung-ho on the first bid and lose money unnecessarily to miners.

Sjors Provoost But now the problem is, let's say your wallet is receiving such a transaction. And now the question is, what do you do? What do you show the user? And so usually a wallet receives a transaction and says, well, this transaction is unconfirmed. And then when it's replaced with a different transaction, well, then you just show the other transaction and say it's unconfirmed. But maybe you want to have a more consistent, like it might look a little weird for a transaction to disappear and to reappear, or even for two transactions to appear. So maybe you want to make that UI look nicer. But it gets complicated quickly. And one of the things that you can change about a transaction is you can bump the fee, but you can also completely change the destination. As far as I know, there's no rule against that.

Aaron van Wirdum I don't think so.

Sjors Provoost Yeah. So one moment you think you've received a transaction, and then the fee is bumped, and you're not receiving that transaction anymore. It goes to somebody else. So your wallet needs to be smart enough to realize that, to say, okay, wait a minute, this is no longer going to me. It's going somewhere else.

Aaron van Wirdum Right.

Sjors Provoost Another complexity is that somebody might send a transaction with a higher fee, but... a block is mined, and that transaction with the higher fee reached you just in time for your wallet to see it, but then it sees the new block, and it goes away again. So the experience can be quite confusing, depending on the timing, depending on who relays what fee increase, all that sort of stuff. And it's possible to make mistakes in that, and that's what happened. And that's why the internet is on fire, and Bitcoin is... It's all being sold to Peter Schiff for $1.

Aaron van Wirdum So what's the mistake? It's a wallet problem.

Sjors Provoost Yes.

Aaron van Wirdum Wallets are just not showing unconfirmed transactions as unconfirmed transactions?

Sjors Provoost No, I think one problem that was described as one wallet might have been the Ledger desktop wallet.

Aaron van Wirdum Yeah, Ledger Live, I think.

Sjors Provoost Yeah, that was pretty much doing what I just described. It would show a transaction, unconfirmed transaction. To you, it would increase your balance, you know, saying, okay, look, you've already got more. But then if somebody changed the destination, it would not lower the balance again. So you would see the wrong balance.

Aaron van Wirdum Right.

Sjors Provoost And I think even if a transaction then confirmed,

Aaron van Wirdum it wouldn't forget about it.

Sjors Provoost So that's a bug.

Aaron van Wirdum Yeah.

Sjors Provoost At least. Yes. And, you know, they should fix that because it can, you know, cause problems for their users. And the other problem sort of related to that is if your wallet can spend an unconfirmed transaction, your wallet has to choose a bunch of coins to spend, a bunch of inputs to spend. And the question is which inputs is it going to pick. And maybe it does it randomly. But now let's say it also includes unconfirmed transactions and it's completely random. And now for some reason you have like a million unconfirmed transactions because of all these RBF bumps. You keep picking these unconfirmed pieces to compose your transaction.

Aaron van Wirdum And the reason it could plausibly be a million is because once someone has your address they can just keep sending you transactions which they then replace so it's plausible that this could happen to your wallet

Sjors Provoost yeah and one transaction could contain you know I don't know, hundreds of outputs that all go to the same address, and then with a slightly different amount, and then you keep replacing the transaction with a transaction that has the same outputs, but with slightly different amounts, or different outputs altogether, and you could keep doing that, and your wallet would just be totally confused. So that's a way to sort of DoS a wallet. It seems a bit of a far-fetched attack to do, but it's possible, and there might be an economic reason to do it. So again, defense in depth, you just want to deal with that. But... And one way to deal with it is the way Bitcoin Core does it, which is a lazy approach, perhaps, but very robust against it. You cannot spend unconfirmed transactions, period. You just have to wait for confirmation. So there might be some noise. I think Bitcoin Core even shows all the different versions of an RBF transaction in a row, like they're separate transactions. So I'm not saying it's the best UI ever. but you can't spend it until it's confirmed, so it's not really bothered by this particular attack. But I'm sure there's other ways to fix it too. Anyway, this was presented as a complete drama, and I think it was marketing for a new wallet.

Aaron van Wirdum It seemed to me like this was an issue between... wallet developers like hey guys look this is something you need to fix we found a bug in your wallet and like that's it there was no news value to it other than that we found a bug in your wallet it was presented as if it was a big problem with bitcoin itself as if someone figured out how to double spend bitcoin but that's not

Sjors Provoost well i'm not sure who did that because There's also just the news media, like CoinDesk, that needs to sell clicks, and I think they also just made a bit of a mess of the article.

Aaron van Wirdum Maybe, maybe, but I'd be curious to see the press release that was sent to them, because I've seen press releases where... You know, they try to make it sound dramatic as well in order to get a journalist to write about it.

Sjors Provoost The blog post published by this wallet was very sensational and quite ridiculous. But I don't think they were claiming Bitcoin was broken. I think they were just claiming that these other wallets were broken.

Aaron van Wirdum Right.

Sjors Provoost But, you know, by the time this reaches CNN, Bitcoin is broken. And that's how that goes.

Aaron van Wirdum Yes, that's how it works.

Sjors Provoost But the thing is, security vulnerabilities, I'm very happy that more and more... Companies are taking security work seriously, Google Zero, etc. They're doing a lot of very important security work. But they're also using it as a marketing tool. And at some point, when the marketeers start to get a little bit too dominant... They have an incentive to make a problem sound way worse than it is. Sometimes bounty systems also make that the case because you get more for severe bounties, so you just make it sound very severe. So that incentive sometimes gets out of hand and people just start making a lot of noise about something that's probably not that bad just to get more clicks. I mean, it keeps everybody sharp, but at the same time, if there really is a bug that is really severe, like, I don't know, an inflation bug, then there has to be some language left to describe something that is actually severe, could actually hurt people very, very badly.

Aaron van Wirdum So was this bug fixed?

Sjors Provoost I don't know. I'm guessing that they'll release a fix. I mean, the Ledger Live software auto-updates, or at least you can click to update it.

Aaron van Wirdum I'm fairly sure that at least for some of the wallets it was fixed. I don't remember which one fixed it exactly and which one didn't yet. Some of them fixed it.

Sjors Provoost It sounds to me mostly like a denial of service attack, which is a problem. But it's not necessarily going to steal your coins.

Aaron van Wirdum Alright, so Bitcoin is still alive.

Sjors Provoost I don't know.

Aaron van Wirdum I think so.

Sjors Provoost Yeah. Last I checked, it was running.

Aaron van Wirdum All right. Good, right?

Sjors Provoost Yeah.

Aaron van Wirdum Anything else?

Sjors Provoost No, I think that's it.

Aaron van Wirdum That was it. Oh, we needed a closing sentence as well.

Sjors Provoost Thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.