Guy's Take_073 - Lightning is Dead, Long Live Lightning!

It. If you hadn't heard, there is a new exploit in the Lightning protocol referred to as the replacement Cycling attack, and it enables a cheater to steal funds from a channel. Today we dive into what it is, how it works, and what it means. And another concern making the rounds again is that technically, lightning is completely trusted below the fee threshold. If it costs 3000 SATs to settle a payment on chain, then is a thousand SAT payment on lightning even real?

I think it's time for another guy's take episode. Lightning is dead. Long live Lightning. The best in Bitcoin made audible. I am Guy Swan, the guy who has read more about Bitcoin than anybody else you know.

And now that the dust is settled a little bit on the recent exploit that was announced with Lightning and the crypto Bros have beat their chest and claimed that lightning is dead and never going to work and all of this stuff, despite the fact that I have continued to use it without error for this entire time, the exploit is actually a thing, and I think it's very prudent to understand how and why it works and most importantly, what the potential level of risk is and who specifically is at risk. And then, because I guess it became immediately popular to just drum up all of the things about lightning, and I realized this one is something that I hadn't really addressed before on the show. At least I've talked about it, but not in a let's break down the economics of this sense. The idea that all payments below the Bitcoin, the on chain fee threshold. So if the fees right now are $2.36, they're like 7000 SATs, 9000 SATs, whatever it is, for a bitcoin transaction to confirm.

Well, then how could you possibly send a $0.01 payment over lightning if it's inside of an HTLC, that's going to HTLC, which is just a temporary hash locked payment that's going through your channel, that can only be secured that the only reason you know it's yours is because you can take it to the Bitcoin network and settle it. It's a pre signed transaction that's ready to go. And so you want to settle it off chain because you don't want to go back on chain, but you have that provenance, you have that guarantee that you can take it on chain. But if it's a $0.01 payment and it costs $2 to settle it, well, then that means it's not worth anything. That means you can't secure it.

That means it's not yours. That means it's totally trusted, right? That means it's custodial in a sense. People keep bringing up this argument and I think there's one really, really big issue that everyone keeps ignoring. So I felt like it was worth digging a little bit deeper into that and explaining why we have and continue to make hundreds of thousands, millions of these 21 Sat, thousand Sat, 100 Sat, 2000 SAT payments on lightning.

And it does work. And that's a really big key. When somebody says in theory, something is broken, can't possibly work and it's never going to succeed. But then you see in practice that it's being widely used and we're seeing, and every single day, thousands upon thousands upon thousands of noster zaps in a sub thousand SAT payments are going through and that we're aggregating it. And that after a week or so of the streaming SATs that I get on fountain, the zaps that I get on Noster, I have another few hundred thousand SATs that I then zap back out to people or I make to use somewhere.

Because we are aggregating all of these payments and there are tons of real economic payments going through at this level. Why does it work? Well, how could it possibly work if what they say is true? And does it mean that we're just completely trusting each other? And in fact, if anybody joins into this mix and just decides they want to start stealing all of these payments, they can, because there's nothing we can do.

We can't actually settle them on chain, is it? The only reason this works is because everybody is a good guy and there's nothing at all keeping anyone from just jumping in and just mass thieving all of these tens of thousands, hundreds of thousands of tiny SAT payments. Because that's the implication, right? Is that if it's not real economic activity in Lightning Network, the Lightning Network can't actually secure it. Well, then it's a suggestion that somebody is just the ability to steal it is just easy.

And it's only that no one has tried that this massive theft hasn't occurred. Because if that isn't true, if there isn't a really easy way to steal all of this, well, then that kind of defeats the very premise of saying that they're all trusted payments that aren't real economic activity and don't mean anything. So we're going to dive into that a little bit, too. This episode is brought to you by Fold, the fold debit card that gets you SATs back on everything in your life. So the fam here has decided that we are going to finally remodel the front bathroom.

And I gotta tell you when you can buy a lot of these things on Amazon and you can buy it all with the fold debit card. Getting the spins and the SATs back on those large purchases just feels like magic. I can't imagine using fiat without getting SATs all of the time from everything that I do. If you aren't doing this yet, you have got to check them out at my link bitcoinaudible.com fold and you'll get a ton of free SATs. I think it's 100,000 SATs right now just for checking it out.

Then you're going to put all of those SATs that you stack and the free SATs that you get onto your cold card. Why? Because you want to keep it secure and you want to know that it's yours. You want to be able to sleep cozy, warm, comfortable, and stress free at night, knowing that your SATs are safe. That is why you get a cold card and you can get a discount with my code, Bitcoin, audible, all one word which is right there in the show notes.

And then lastly something else you're going to send to your cold card, which is going to make your online life so much better. If you can just accept Bitcoin and lightning easily with almost no setup, no node, no channel management, nothing like that, no KYC, even go to nodeless IO guy. Nodeless is the easiest way to start accepting bitcoin payments with absolutely the least amount of hassle possible. Simple matters. And if you want simple and you want it to be quick and you just want it to work, that is why you use nodeless.

And it never hurts when you have a no KYC, no subscription option that you can just go check out with absolutely no obligation, just try it. Use my link Bitcoinaudible.com slash nodeless, which you will find right in the show notes. Alright, so let's dive into the exploit first. What happened with Lightning recently? And why did Anthony quit?

Said he's not working on Lightning anymore and he's moving over to Bitcoin core. And honestly, I think the fact that that announcement came with the announcement of the lightning exploit is really what just made all the crypto bros just cream their pants. They would just love the idea that lightning would fail and all of this would blow up in the bitcoiners faces. But of course, as I went digging into it, I could not find any of them who could explain anything, which is often the case, everybody just calls victory without even being able to make sense of what the hell went wrong. And so that's why we want to dig into it on the show.

And it is actually a pretty clever and pretty fascinating thing. And I also want to delineate, make sure we talk about the difference between a bug and an exploit. And maybe this is just my thinking of it, because this isn't classified in kind of the realm of, oh, we have like a buffer overflow bug in Bitcoin, and now somebody can print like a billion bitcoin that was not intended by the protocol. This is more of an exploit in the context of how the mempool works, how Bitcoin works, and how lightning works. It's more about the fundamental model of it, which you could actually argue could be potentially more severe, because it means that the very architecture of lightning may be at greater risk than we think.

It's not as secure as we think it is. And because it's exploiting kind of the economic reality of the mempool and how the fundamental bitcoin network works, that it could very well be a serious issue. But it's also not a. And that's why I refer to it specifically as an exploit, because it's exploiting the way the economics and the settlement work on the main chain, kind of that arbitrage between how lightning settles and how bitcoin settles. Whereas when I think of bug, I think specifically of, oh, somebody punched in something wrong and it broke a bunch of lightning channels, and now we have to emergency update, because the whole thing is like, somebody can steal something because a key was used wrong, or there was a bad random number generator, et cetera, et cetera.

It was something that I think of as more explicitly, the code was broken, or the code is wrong, rather than someone figured out a way to exploit the architecture of how the thing secures an ownership of some amount of SATs as payments flow through lightning Network. So, in trying to distinguish that, I'm referring to this specifically as an exploit and not a bug. And when I make that distinction, that's what I'm referring to. So, this was posted by either Anthony or Antoine. I honestly don't know.

And depending on what corner of the world they are from, it could be either. But it got published on the mailing list from an Anthony or Antoine Riard. And it starts with this hi end of last year, December 2022, amid technical discussions on L Two payment channels and incentives compatibility of the Mempool Antidos rules, a new transaction relay jamming attack affecting lightning channels was discovered after careful analysis. It turns out that this attack is practical and immediately exposed. Lightning routing hops carrying HTLC traffic to loss of funds security risks both legacy and anchor output channels, a potential exploitation plausibly happening even without network Mempool's congestion mitigations have been designed, implemented and deployed by all major lightning implementations during the last months.

I skip a little bit here because I just want to hit another important piece or framing that he gets into. It says while neither replacement cycling attacks have been observed or reported in the wild since the last ten months, or experimented in real world conditions on Bitcoin, main net functional test is available. Exercising the affected lightning channel against Bitcoin core mempool at the 260 release cycle. It is understood that a simple replacement cycling attack does not demand privileged capabilities from an attacker. For example, no low hash rate power and only access to basic Bitcoin and lightning software.

Yet I still think executing such an attack successfully requests a fair amount of bitcoin technical knowhow and decent preparation. From my understanding of those issues, it is yet to be determined if the mitigations deployed are robust enough in face of advanced replacement cycling attackers, especially ones able to combine different classes of transaction relay jamming, such as pinnings, or vetted with more privileged capabilities. All right, so what does that all mean? And what is this attack he links to, or at least refers back to the flood and loot attack. So this is the idea.

Know, being able to crowd out the mempool such that if you want to be able to get your transactions. All right, let's take a step back and think about HTLCs. So the way an HTLC works, and by HTLC, all I mean is a payment that is going through my node towards another node. So it's a routed payment that's locked up with a quote unquote HTLC. So we're trying to make one of these payments.

We're trying to route payments through a series of nodes and channels. So in this example, I have a channel with you, you have a channel with Apple, and Apple has a channel with Starbucks, and I want to pay Starbucks. So I pay you, you pay Apple, Apple Pays Starbucks. We've routed through all of our individual channels. So let's say that payment is $10 worth.

The way we make that payment is we hash and lock the payment to a secret key that no one in the middle has. It's shared only between myself and Starbucks, who I am Paying to. But in updating my channel with you, we basically create a new branch to our little multi sig that just says, here's an explicit amount, it's $10 worth. That would go to a completely different address with a completely different time lock and a completely different key. And it's locked with this secret key, but you don't know the secret key.

You can simply see that there's some other piece of information which locks this up, and it's locked for, let's say, 150 blocks. Then you make your update with Apple also making this exact same payment, less some sort of fee that we've agreed to, and you lock it up for 130 blocks. And again, neither you nor Apple has the key to unlock this. So it might be temporary and it might work, or we might just be deleting it. If the payment doesn't go through, it's just an extra branch that can be settled.

If the secret key to unlock the payment makes its way back through this channel route, then of course, Apple does the exact same thing again with Starbucks. Now, I locked the original payment, and all of these locks were made based on a secret key that only Starbucks has. So it's Starbucks who received the payment because it was their key that I locked everything with, or the hash of their key that everything was locked with. And also, another important note is that the time lock was shorter, again, between Apple and Starbucks. And this is really important.

So it's like the first channel is 150, the second one's 130, and then the one between Apple and Starbucks is 110 blocks. And what that means is that each subsequent channel in the route will settle before the previous channel. So nobody can take the payment before the person it was intended to be sent to has the ability to get their payment first. But again, this is all locked to Starbucks secret key. So what happens is Starbucks unlocks it with their key, and then that key is given to Apple, who can then unlock the one in your channel to take the payment.

And then that key then comes back to me, which we unlock in my channel with you to you. So the payment went from me, it left me, got locked up all the way to Starbucks, and then unlocked all the way from Starbucks back to me. Now, technically, we actually didn't do any unlocking. What happened is that because we exchanged the secret key that could unlock it. Remember, the unlocking only happens on chain.

So it's if this gets sent, that $10 gets sent to the UTXO, then the UTXO can only be unlocked with that secret key. So technically, we just kind of exchange the secret key and then update the other channel and remove the HTLC. So nobody ever actually uses it or does anything with it. It's just there as a temporary measure to if something goes wrong, I am owed this payment. Okay, nothing went wrong.

Well then let's just delete it, update our main channels and then continue to update new payments, do new HTLCs and continue to update our channels. So in other words, because we know that everybody has the information needed to settle it on chain, nobody needs to settle it on chain. Now the reason for the cascading time locks is really important is because you need for the payment because it settles. It gets unlocked from Starbucks. It gets locked up from me to Starbucks, me to you to you to Apple to Apple to Starbucks.

But it gets unlocked in reverse. So the time lock needs to favor the person who forwards the payment before they receive their redemption. So Apple forwards the payment to Starbucks, or technically Starbucks claims the payment from Apple and then Apple needs to be able to claim it from you before you can claim it from me. So one of the other kind of known attacks in this system or in this setup is, let's say Apple and I conspire to keep you from getting the payment. Or better yet, maybe I am posing as Apple somehow.

And so you think you have a channel with Apple, but really you have a channel with me on the one hand and then another channel with me on the other side. And when you think you're routing the payment, you're actually talking to me with both channels. Well, that means that I can get the secret that unlocks this payment from Starbucks. And rather than give it to you in the middle, I can just keep it for myself and redeem it from both of my channels. To make it easier to picture, let's assume we're different.

Apple, it's Apple. And me is know, go on to Telegram or Nostra or something and send me the secret key without telling the secret key to you. And so I can settle and Apple can settle with both of the channels with you. But we don't actually give you the secret key to unlock anything. We just went around you.

And so we're trying to pull the same payment from both directions, which would just leave you high and dry. You forwarded the payment and I didn't forward it to you. This is when you would need to go on chain. But here's the thing is, you wouldn't actually forward the payment to Apple because the only way that you would automatically do that is if they gave you the secret key. So the only way for them to take it by not giving you the secret key is by publishing it to the chain.

But then just by needing to do that, because it's a hash lock, it reveals the secret key by publishing it on chain. And with the secret key, all of this is immediately valid. Without the secret key, that's when you have the time lock. So if their time lock is shorter than yours, if their time lock is 110 blocks and yours is 130, well, then that means you have 20 blocks between the time that they submit their refund in order for you to submit and confirm your refund. So it just ensures that in the case of something going wrong, the order of operations, the time lock of each of the refunds is such that the payment still goes to the proper person, and so it can't be refunded earlier in the route before the parties later in the route can get their funds.

And in the case of a successful transaction, where the secret is actually revealed, well, then you also want that time lock to make sure that the person, like, let's say I am trying to do a refund from you, but you actually have the secret, and you sent it to me. But I just decided to be a butthole and pretend that you didn't. Well, as long as you have the secret key, as long as you got it from Apple, well, then the secret key actually makes that transaction valid instantly, because essentially, that secret Key is what allows you to avoid the time lock. But then broadcasting it reveals it. So the next party in the line can just watch for any broadcasts from your channel, from whatever address you are using for your lightning channel.

And when they see the secret revealed, in order to send the payment to when you see the secret revealed in Apple's attempt to take the payment, well, you can go ahead and apply that same secret to our channel and submit it and get those funds immediately. So a lot of these attacks that occur with this are, like, flood and loot attacks and pinning attacks. A lot of these things rely on flooding the Mem pool with traffic so that it's really, really hard to get a transaction broadcasted or published in time. Because if it's only 20 blocks and blocks are, like, super full and transactions and fees are really, really high, well, then someone may be able to, especially if they're coordinating with a minor. They have a lot of hash power themselves or something.

So in this situation, there may be a way for me to keep your transaction out of a block or make it very, very difficult for you to confirm your transaction. And then I can maybe work with a miner or whatever, so that the second mine is valid. I get into the next block as fast as possible, and then technically I can beat you on that redemption. And there's like a handful of various economic attacks and Mempole attacks and things that attempt to take advantage of this sort of congestion arbitrage, if you will. But most of them require sending an enormous amount of information on chain, which is costly, it requires paying very high fees, which is costly.

And it requires either collusion or multiple channels with the counterparty that you're trying to steal frOm, or to just have an attack, like a DDoS attack, to the entire network, where you just flood it with all sorts of HTLCs that are never actually going to get settled. And you try to just lock it up at both the send and receive. Like, let's say you're doing like, I'm doing the attack or whatever, and I'm trying to do like looped payments is I could do a payment to you, to Apple, to Starbucks, to breeze, and then back to me on a completely different node or channel. And then I can just give myself, I mean, I don't give myself anything. Both of my nodes can freely share information with each other, and so I have the secret key and I just don't give it to anybody in the route.

And then I just keep doing that over and over again. I just lock up as many payments and as many channels as I possibly can. However, there's also a lot of mitigations for trying to make sure that there's just not blanket traffic like that, and you're not letting a whole bunch of HTLCs lock up and you time them out quicker. And in addition, pretty much all of this still requires the attacker to go on chain in order to get the funds. Unless of course, they're just trying to cause disruption and they're just trying to crowd out the sort of data bandwidth and the payment bandwidth for each of the individual nodes.

If they're trying to steal funds, they eventually have to go on chain. And then you have that 20 block. Actually, the default, I think, is 34, but the 34 block delta, the difference between the payment through each subsequent channel and then it all lands with just a ton of data on chain from all of the different parties and channel partners and all that good stuff. So what specifically in this mix is the replacement cycling attack? And what makes it special among the other kind of various exploits that we've sort of known about and are risky in certain situations or certain conditions.

So with that as our context, what is the replacement cycling attack. And just to frame this again, that our key thing that we want is we've got all the different refund transactions in each of the channels between me and you, you and Apple, Apple and Starbucks. And then we've got the success transaction, and we've got these two branches locked up and waiting to see what happens every time we start to route a payment through all of these nodes. And what we don't want is for someone to be able to redeem the success transaction from. In your case, you have Apple downstream in the payment, and then you have me sending the payment to you.

What we don't want is for Apple to be able to redeem their success transaction and for me to be able to successfully submit my refund transaction, because that means you lost the balance in the channel with Apple forwarding it to Starbucks. Starbucks got the payment. Everything appeared as, uh, I made the payment successfully to Starbucks, and I got my coffee, I got my goods, they got their money. But I somehow successfully redeemed my refund transaction to you, making it seem as if the payment didn't go through. So Starbucks got their money, Apple got their money, I got my money back, and you got left holding the bag.

You got screwed. That's why in the case of the refund, you have that difference. Know how many blocks there are between confirming the refund transaction? So that's the bad scenario that we want to avoid. How does the replacement cycling attack make that possible?

Well, it's actually possible because, or it's quote unquote easier in a sense, because of a few things that were made in order to kind of make it easier to submit and resubmit lightning transactions with higher fees. So this is actually not unrelated to the full mempool RBF, the replace by fee, so that you could just keep bumping the fee and evicting all the other transactions with smaller fees. This is actually related to helping this attack go through, but at the exact same time, a lot of those things are actually part of making sure that Lightning channels don't get stuck. So let's say I submit one with a really small, with exactly the fee for the next block, but then in the next two minutes, a big flood of transactions come in and the transaction fee actually doubles. And then for 20 blocks, mine just never goes through.

I need to be able to resubmit it to make a bigger fee, right. So it's important that I can get my transaction through quickly to ensure that me, as the rightful owner, can confirm before someone who is trying to take money out of that channel from me. And with that we have a lot of different things. Where we have child pays for parent, we have replace by fee. We have a lot of these different mechanisms for trying to replace transactions in the Mem pool with another one.

So, like, another way that child pays for parent is a cool one that I've actually used. I think I used it in nunchuck. I think Nunchuck has this option available, or no, maybe it was a different wallet, I don't know. I can't remember exactly. But child pays for parent means that.

So let's say you send a transaction to me, to my green wallet or something, but it's not getting confirmed. Your fee was too low. It was like just right. But then a whole bunch of shitcoiners and ordinal inscription people just flooded the market all of a sudden. Flooded the Bitcoin network with transactions, and now it's stuck waiting for the fees to drop.

Well, what I can actually do to speed that up is I can actually submit a transaction from the address that you were sending to. So you're sending it to my address and it's not confirmed. Well, if I send a transaction from that address as if I already have those bitcoin with a really big fee, well, what happens is that my transaction isn't valid unless your transaction gets confirmed. So what happens is they basically get attached the child, the secondary payment, which I technically can't send it until you give it to me. Right.

I need to own the bitcoin, so that needs to be confirmed. Well, they get attached together because, well, in order to get my big fee, they're going to have to submit your and confirm your smaller fee. So essentially they can think of these two transactions as just having a joint fee, your small fee and my big one. And thus it's actually economical to put the small fee transaction in the latest block as quickly as possible because they're trying to get the big fee. So how does this attack work?

It's actually really clever, and it takes advantage of a lot of this replace by fee dynamic so that they can evict transactions from the mempool. And this is ultimately the trick is how can we make sure that you. You're trying to get your refund transaction and Apple and I are trying to prevent that refund transaction. Is there some sort of a clever way in which we can make sure that your refund transaction keeps getting kicked out of the bitcoin network? And can we keep that up long enough so that I can get my refund confirmed.

We can cross that Delta between the block, the delays and Apple can get their success transaction with the secret key confirmed as well. All right, so pay attention very closely. I'm going to go through this slowly because it's really clever and it's kind of neat to think about these dynamics, but it is a little bit difficult to explain. It took me a bit to wrap my head around it as well. So one of the key things is that because we want to be able to keep increasing the fee, we don't commit to everything.

Commit as in we don't have this locked guarantee as to exactly what's in the transaction. Which means that I can put other stuff in the transaction with it, so that if I wanted to batch, well, I could batch it with some other channel. Like, let's say I wanted to get my HTLC out and it's only 1000 SATs. Well, I don't want to spend $2 in transaction fees to get 23 cent or 30 cent. However, if I'm also batching a bunch of other transactions, I have some other cold card transaction that I need to settle and I have some sort of payout from fountain or my podcasting app and from my breeze wallet or something else, I will have these other wallets that I want to confirm transactions with.

Well, I can put them in at the same time and I can make it more worth my while. So not only do I have the output from the channel that we have that I'm trying to confirm, but I can put in a bunch of other stuff in order to make it more cost effective for me. I can batch this transaction with other things. So we haven't committed to only having just this one HTLC, this one routed payment to being the only thing that I can put in the transaction. We've allowed ourselves to change the fee later if we want.

We've allowed ourselves to add in additional outputs and transaction data so that we can batch a lot of stuff together. Now that's good in a sense, right? We want to be able to keep bumping the fee to make sure that the payment goes through. So let's go back to our situation. I pay to you and you pay to Apple.

Now, Apple's success transaction that reveals the secret key and your refund transaction both pay from the same address because they are both paying out from the channel that you have together, which means that they conflict within the mempool. If you submit your refund transaction and then Apple submits the payment success transaction with a slightly higher fee, your refund transaction gets removed because you're both trying to double spend from the same address. However, this is normal lightning operation. That secret key is revealed in doing so. So you don't care that that gets replaced because now you just submit the success.

You now have the secret key to submit the other one. You ignore your refund transaction altogether because now you just want to redeem the money. So that's normal operation. And Apple, the success transaction can always replace the refund transaction. Here's where the trick comes in.

You submit your refund transaction and Apple submits the success transaction into the mempool with a higher fee to get yours bumped out. However, because they can do whatever they want. In addition, with the transaction, Apple goes ahead and tosses in a completely unrelated amount of Bitcoin in a different address going to a different payment. So they basically do a tiny batch where some payment that has nothing to do with any of this is also tacked onto the success transaction that reveals the secret key to you. But they don't want you to see the secret key.

So what they do is they immediately resubmit that random address transaction to another place with a higher fee still, and immediately evict their transaction with the secret key so it doesn't get confirmed. They don't want anything to get confirmed, and in fact they don't want it to even reach your mempool. That's part of the problem is they're trying to keep this from propagating at all, but they still have to submit it with a higher fee to make sure that yours gets kicked out. Your refund transaction gets kicked out, but then they resubmit this unrelated address with a new transaction with a different one with a higher fee, so that they then kick their own transaction out and it never gets confirmed. So they've successfully kicked you out of the mempool for your refund and successfully kicked their own transaction out.

That would be confirmed. That would reveal the secret to you. And every single time you resubmit the refund, they keep doing this over and over again. Their success transaction never gets confirmed because it keeps getting booted and your refund transaction can't get confirmed because it keeps getting booted by their success transaction, while at the same time I am submitting my refund transaction which isn't getting booted. So if they can keep this up for 20 blocks or 30, the default I said earlier the 34 blocks between valid channel closures or valid refund transactions, then we can stretch it across that time such that I can get my refund transaction confirmed.

And then Apple at any time can just submit their success transaction, and that will reveal the secret key to you, but you won't be able to use it anymore because I already submitted the output. I already got the money back, and that's the output that you're trying to spend from now you're double spending with the secret key because my refund transaction already got put through. And apparently this succeeded in the Testnet or signet, whatever it is. They ran an experiment with this and they could actually pull it off. Now here's the thing.

This is difficult to pull off, and it requires very explicit and very kind of meticulous attempts at controlling the mempool and controlling how information propagates. Because they have to be able to ensure that your mempool, that you never actually receive the pending transaction that has the secret key, or you can go ahead and get your funds. So it's not as if this is the easiest thing in the world. Now, there's another element to this, and this is something that we've talked about before, is that largely lightning transactions, lightning channels, excuse me, are, in a sense, trusted relationships. And I don't mean it in the sense that they're custodial.

I mean it in the sense that reputation, uptime, liquidity, responsiveness of the nodes, all of these things matter in a noncustodial situation because it is also a live payment network. So it's trusted in the sense that you just don't want to open up random channels with each other. It's not trusted in the sense that you have a custodial relationship with somebody. It's trusted in the sense of the time and the fees and the on chain data and the reliability of having a network connection into this protocol or into the lightning network. And for a long time, we've already entered this space where you just don't indiscriminately open channels with everybody.

In fact, a lot of the major nodes are extremely picky about who they open channels with. And this attack specifically requires opening two channels with the person you are attacking. So, first off, if you're not a routing node, then you have nothing to worry about if you only open channels with people or nodes that you already know or trust. Like, I have a channel with Async, I have a channel with fold, I have a channel with a couple of my pleb friends in the pleb net. I'm not worried about any of them trying to make that attack.

And I also know for the people that I've interacted with I mean, somebody could be running like a really long con on me and posing as two different people in our chats and conversations. But I just have channels with people that I know. And I also know that I don't have two different channels with them, that I am under the impression that they are separate. Like I have a channel with BTC sessions. I am not worried about him submitting this attack against me.

We do not have a custodial relationship. I just know that I'm most likely not going to have to unilaterally close the channel and pay some on chain fees when I don't want to because he has a good node, it's got great uptime, and I can message him, I can contact him in a completely different avenue and make sure that things are okay if there is ever anything that goes wrong. So this is already hard to pull off just from that context. Not a lot of nodes are opening channels with just anybody arbitrarily. But the beauty is that you can bridge trusted relationships.

So you can have trusted channels, so that you can have an untrusted network or a trustless network combined or in aggregate from a bunch of trusted connections is I can trust BTC sessions. BTC sessions can know who you are and trust you. You can trust Apple, Apple can trust Starbucks. And then because of that I don't have to trust Apple or Starbucks because I know that BTC Sessions isn't going to attack me. So we have, even though I am totally untrustworthy of Apple and Starbucks, or maybe you're totally untrustworthy of me, you just don't like me.

Well, that's not a problem because we bridge it through someone we do trust. So that right there we just don't have this environment where we're opening a whole bunch of random channels with anybody. So really I think the biggest vulnerability to this, and that doesn't negate it completely. Obviously people can fake things. You can just open channels with somebody because they have the appearance of being big.

And maybe they're the NSA being trying to establish themselves with a whole bunch of nodes and a whole bunch of channels and they do want to do a long con and they want to attack the network. So it's not as if this is some sort of failsafe. But I'm just saying that the conditions are not ripe for this to be easily exploited. In addition is that the node of the person being attacked has to be specifically targeted to make sure at all times that the success transaction with the secret key never makes it to that node. Because as soon as you get the secret key, the gig is up.

Now, there's another element here. Remember, each time these things are getting replaced, we're replacing Apple's replacing your refund transaction with their success transaction and then replacing that themselves with a different one. Well, if that last replacement transaction gets confirmed, well, then they pay a fee, and they pay a fee purely for the sake of attacking you and for no other reason. And now they need a different input to attach in this transaction and do this again. So Apple might accidentally, just in booting a higher fee in order to get the transaction continuously booted from the mempool, your refund continuously booted, they might accidentally confirm like 20 arbitrary transactions that they're just making out of nowhere and pay like $50 in fees just trying to keep this up.

So it's not as if this is costless. And the better view that you have of the network that your node is connected and everything, well, then the more aggressively you keep rebroadcasting your refund transaction, the more difficult and potentially more costly it's going to be for Apple to keep yours out of the mempool. So, in short, this is a really clever attack. And it's really kind of neat how adding that extra address into the transaction that's unrelated allows them to boot their success transaction while still using their success transaction to boot the refund transaction of you. That's a really clever way to use the kind of economic dynamics of the mempool and the fact that the mempool has no hard structure.

Right. It's just this kind of ethereal thing where everybody's just trying to get, miners specifically are just trying to get the highest fee transaction to go in the block. So essentially, the longer that Delta is between confirmation of the refund and the validity of the success transaction, most likely the higher that transaction fee is going to keep getting bumped in an effort to keep this battle going. So the payment that gets routed needs to be pretty big for this to even be viable, which is related to our other issue that we're going to hit in a minute of why small fee transactions are in fact still, quote unquote trustless, or trust minimized in the conditions when we're talking about the Lightning Network. This episode is brought to you by the fold card.

This is the debit card that I use for everything, and it is how I get SATs back on literally everything that I do. And I'm a big fan of the in app gift cards they have for major merchants, specifically the Amazon gift cards. With 2.5% back. I do a lot of shopping and a lot of different, like all the computer stuff that I have for my AI machine and a lot of the ducting and stuff that I did for my home mining setup. I just got my stuff off of Amazon.

I got 2.5% back in SATs on all of it. This is a phenomenal cheat code to be regularly stacking SATs just by using Fiat, the normal way that you use fiat. Check it out and get a ton of free SATs just for signing up with. And that means the free version, you can just check out the free version, you don't have to pay for anything by going to Bitcoinaaudible.com fold, and that link will be right in the show notes. So there's actually a number of mitigations against this and some of the basic mitigations, which he specifically says he's not 100% sure if these are actually going to confidently, so to speak.

Maybe this is still possible even with some of the mitigations, because a lot of them are kind of abstract or they're not abstract. They still just kind of depend on giving enough time in order to make sure that the proper transaction gets put through. And so the basic mitigations are lengthening the difference between the time lock on refund transactions and then aggressively rebroadcasting the transaction to make sure it's not getting bumped from the mempool. But then there are also tricks that you can do, like, and I think Shinobi mentions this specifically in one of the articles, the article that he wrote on Bitcoin magazine about this is the SIG hash all flag. But basically what he's saying is that you can commit to the inputs, you can basically just sign it such that the party that you're in a channel with can't add that extra random address into it, and that you've signed explicitly which addresses are going to be in this transaction so that they can't then bump their own transaction with the secret key that you need to redeem yours.

So essentially, everybody's locked into only submitting the HTLC that routed payment by itself, so that there's a more explicit battleground in which the competing transactions are going through. And that actually mitigates the thing entirely, because they can't bump their own transaction, they can't replace it without a valid transaction, which means they have to reveal the key. And so this isn't even an issue if you're not leaving the whole thing open to adding a bunch of different random inputs. But you might still want that to be the case, especially further down the line. You want to be able to add in, you want to make these economical to submit.

And a lot of that might mean batching with a bunch of other addresses and transactions and that sort of thing. But therein lies something that the defender can actually do as well. Let's say this is being like the prime people. I think, to attack in this regard would be somebody like Breeze. It would be an LSP, somebody who's doing a lot of routing and doing a lot of opening of channels with random people.

Now, these are also the people, the nodes and the institutions that would be most prepared to defend against something like this, because everything that they do is about actively managing and understanding what's going on with the mempool and their lightning channels, et cetera. But one thing they can do is that same trick that Apple is trying to do to evict the transaction by adding a ton of other inputs and a ton of other transactions. So, yes, let's say my mitigation transaction, your refund transaction, is going in with a dollar fee. And then Apple tries to evict that by cheating you with a dollar and ten cent fee. Well, what if you're an LSP and you're also submitting 200 other transactions at the exact same time?

Well, you can do the same thing they do is add it in with all of those other random outputs, those addresses and transactions, and then stick a $200 fee on it, a $300 fee on it, because you're batching all of this stuff together. Now, it's actually economical for you to submit that payment and have a really, really big fee that is going to upset Apple and their attempt to evict that transaction because they don't have to evict your small transaction with a $1 fee. They have to evict this giant transaction that you're settling with all of these other. That the LSP in this situation is settling with a ton of other addresses and balances and all sorts of stuff like a coin know could be involved in this. So something like that is also possible.

And I've always thought that there could know kind of batching services, know on chain settlement insurance sort of companies that aren't quote unquote insurance companies, but they are literally they're selling block space at a discounted rate at some point in the future. And what they do is just basically make sure that you have a way to batch a transaction if anything ever goes wrong. So I talked about this a lot. I think this is going to be a big deal in the context of really big channel pools or really big arc setups, these things where you just have tons and tons of people. Well, within that, you can have a batch transaction service where you sign with them and just you hold off on the side a way to submit that transaction where if individual on chain fees end up being like $50, well, you don't want to submit any sort of small payment like that with a $50 fee in order to guarantee your payment or guarantee your ownership of it.

But you could batch with a really, really big group doing it all together and pay a really big fee for that transaction in aggregate, and then your little share of it is only like 50 cent. So this is not the end of the world. This is not the death of lightning. Far from it. In fact, it's just another hurdle and another potential negative that I think will just continue to improve and have us think very, very strongly about and adversarially about the ability to filter and limit what types of transactions go through and who we do transactions with, who we make channels with.

And I think it's not unlike the like, if you talked about the DDoS problem on the Internet and how bad distributed denial of service attacks can be, well, you could easily claim that the Internet will never ever work because it's always vulnerable to this. And yet we have firewalls, we have Cloudfare, we have all of these services and things that specifically mitigate these things. And they have policies. It's not mitigated in the protocol at all, but we have all of these policies and all of these devices and traffic analyzers that do exactly that and mitigate the problem such that it shows up and you have some random denial of service attack from time to time. But for the most part, the Internet does just work.

It doesn't mean that we shut down everything and we say, oh, we give like it does work in practice. And I think this is kind of along those sorts of lines where maybe additional upgrades to the Mimpole policy and the way, and I think John Carvalo made a point. It's like this is kind of the failure of RBF here, because this does kind of help his argument. But I don't think it's so clear or so white and black saying that it's definitely good in this direction. We're definitely not good in this direction, because part of the very mitigation of this is rebroadcasting with a slightly higher fee.

But then there are other SIG hash all. And these things like means to commit more to explicitly what is in the transaction. And then I'm also curious how other things like l Two and a lot of these other signature schemes and commitment types, how they change this dynamic. But long story short, is this the end of the world? No.

Does this kill lightning? No. Are there mitigations to this? Yes, there's a handful, and they will work in varying different conditions. And honestly, the simplest mitigation is just the process of constantly rebroadcasting and bumping the fee a little bit higher.

And of course having a very well connected node and or having numerous well connected nodes that you connect directly to to ensure that you get a full map, you get a full picture of what's going on with the mempool, and even better, with the fact that we have these pre signed transaction schemes and now we have BITVM. Maybe there's actually a really simple way to create a pre signed transaction, to actually replace the HTLC with something unique that utilizes a very small and simple BiTVM architecture that just lets you do things that have nothing to do with bitcoin script, such that that transaction can actually be, the risk of that transaction can be mitigated in a totally different way. Like the scope of being able to solve this problem is pretty huge now. And I think just understanding the dynamics of the mempool, of the fee structure and the economic conditions that lend itself to this sort of like data replacement and things in the mempool and in the node network specifically, I think just understanding, recognizing and continuing to find these exploits is just going to really cement down how we establish insanely robust security in the conditions where we have explicit time locks. And we need to make sure that some data gets in during a specific amount of time, because that is a sort of ephemeral security model.

Right? Is that, well, we just have this gap in which we can ensure, or we can prove that we are the rightful owner. So there may be a better way to actually pull that off, especially when we start talking about things like BiTVM. Just having this kind of agnostic means of agnostic computation to actually be reliant on the transaction, or for the transaction to be reliant on. And then also there's an interesting, this would require a consensus change, but there's an interesting proposal by Peter Todd on rather than making transactions valid after a certain time, it actually does the opposite.

It creates an invalidity. It makes it invalid after some certain block of time. So that's interesting. I don't think it's a little bit extreme, and I think Shinobi, I believe, said it in his article too. I think he mentioned that one and said it's a little bit extreme and probably not necessary because it doesn't.

Basically, there's too many low hanging fruit means of largely making this not a concern, especially not enough to have a serious conversation about consensus changes. So that is the lightning bug, the replacement cycling attack. Hopefully that made a little bit of sense and you can kind of picture what's going on there. Now, the other thing I wanted to talk about was the idea that small value transactions on lightning are not real. And I think the really big thing being ignored is that they work and there's a very simple reason why they are not.

This is also why opening up a channel with someone is not totally trustless. There's an element of uptime. There is an element of being able to forward payments. There's an element of having reliable responsiveness and reliable liquidity. That is a trusted relationship.

But it's not a trusted relationship in the sense of custody. It's a trusted relationship in the sense of oat uptime. It's like kind of having a little bit vaguely like having a fully encrypted drive that a host can't get to. They can't see anything inside your drive, but they host a backup of it for you so that you can get it. It's a semi trusted relationship, but it's not trusted in the sense that they can see your information.

It's trusted in the sense that that information is available when you need it. And I think this whole thing is just constantly conflating those two things. Because the fact that you're depending on them for one area or for one particular service or thing that they're offering, well then immediately it's like, oh, well, this isn't sovereign. Well, this is custodial. You might as well just use a bank and just misses all of the important elements of the actual dynamic of the reason why it can actually work in practice.

And another reason specifically is that if it's not enough value to quote unquote, settle on chain without, because the fee threshold is higher, well, then it's also a value that can't be stolen. I mean, how do you steal that amount? How do you try to contest it? You try to take it on chain, you try to get the refund transaction to go through, and nobody's going to do that if it's less than the amount of fee that they have to pay to even try. So it's not secure because the rightful owner can be unilaterally determined by the bitcoin on chain transaction.

By settling that UtXo, it's secure because it's mutually assured destruction. Nobody's going to get that value if anybody allows it to end up in a conflict. It's like if you and I are both holding a dollar, and that the only way for any way to contest who owns the dollar is that it just rips in half, well then we have every benefit. Like that's actually a model that was specifically created for the darknet markets is that if there is no agreed outcome with multisig, then you literally just have mutually assured destruction. Both parties lose the money.

This is sort of an informal way in which that actually happens. Now the caveat is that if you want to take it on chain because your counterparty is not online, or they go offline and they don't come back, or they lose their keys or something, well that's just the uptime problem. Again, you're specifically trusting that they're going to be online to settle those sorts of small payments, which means that in aggregate is the only thing. It's when you get the commitment transaction for the new balance of the entire channel, where the entire balance can be paid for with the fee in which you actually have that unilateral ownership. Because in the HTLC case, when it's still in limbo, you might just want to send that to anyone can spin like, treat that like a fee.

But I don't see how this is really unique in the context of trusting your channel partner. It's for the exact same reason that you don't want to get attacked by your channel partner. That you don't want someone who's going to go offline, that you don't want someone who has crappy routing or has just a really bad node who can't even figure out the routes for you. You want a reliable connection into the lightning network. So when you establish those, you do it with people or nodes that have some sort of a reputation, and thus the entire network can be bridged through individual trusted relationships and have an entire untrusted, a trust minimized network on a global scale that can bridge and route payments through an endless number of counterparties and from people using six degrees of separation you can be connected to everybody in the world.

And nothing can ever move from anything other than a channel relationship. That you actually have high reliability in that you know the reputation of your counterparty and you know and expect them to be online. And then in aggregate, when you get streamed, thousands of these payments, and you get a lot of Zaps on Nostra and everything, well, that updated channel balance is secured by whatever fee and whatever the channel party that you have that you can always unilaterally close and take that with you. So anyway, I just wanted to bring that up because I saw that point come up like a number of different times, and I'm just Like, it's just one of those things. It reminds me of Eric Weinstein talking about how Bitcoin won't work or whatever, because you need to have a quantum entropy feel like, I can't even remember exactly what he said.

He just goes off on all of this ridiculous stuff about how proof of work isn't complete or something. God, Jesus Christ. It was such know, intellectual masturbation, I can't even remember the words. It's like one of those things. It wasn't quantum.

I cannot remember what he referred to it. But like, all I could think when I was listening to it is he mentioned it on Joe Rogan one time that he was on, and all I could think was that like, okay, build that shit. And I'm just like, so you're saying that something won't work. That does work. And you're saying that the solution is this completely like Star Trek thing that you've imagined out of your ass.

And it's just like one of these things exist and one of these doesn't. At some point, you're just screaming at reality and you're saying it's not going to work as you watch it work. So with that, I'm going to go zap a few people on Noster. A thousand SATs. In fact, I might even lower my zap amount just for fun.

Now, that's not nice. I'm going to keep it a thousand SATs for a long time, and I'm going to keep using lightning because that's how I use Bitcoin now. It's practically all my payments happen over lightning, except for maybe one or two a month. And I'm going to keep using it because it keeps working. Works like a charm.

So with that, let's close out today's episode. This is a fun one. I really think this is a fascinating attack exploit on lightning, and it really lends itself to really clever usage of the mempool and replacement of fee replacement and transaction replacement, and that trick of using a different input. It'll be really interesting how we think about these things going forward and new dynamics and proposals to make it more secure at kind of another layer as we kind of pinpoint all of the time lock security limitations because we cannot know or have a concrete proof of what is going to be in the mempool because that's such an open market square. It's just kind of like this global broadcast network, right?

And it's all just kind of best guess. In fact, that's probably a really good one to link to. Is the open. What is it? Bitcoin's open square or the Mempool is Open Square?

Crap. I can't remember the name of it, but it's a really great old article that we haven't covered in a really long time, and I'll try to find that episode and have the link in the show notes for you. It's really fun when it's just talking about conceptually what the mempool is and how to think about this open network where everybody just kind of screams their transaction and individually all of the nodes and all of the instances on the network just try to collect as much as they possibly can and confirm and batch and hash these things into the canonical chain. Just a really fun article, and if you haven't heard it, I definitely recommend it. And also keep an eye out.

We have Lynn Alden's broken money. The audiobook is roughly done. We are in the rough draft, and I'm listening through it as we speak. I listened to it earlier this morning and I will be continuing to to make sure we get all the errors out and, you know, final versions up. And it usually takes a couple of weeks, two to three weeks maybe, to get audible to approve it.

So hopefully in the next couple of days we'll have it uploaded and you guys can get to hear it in your ears. And if you want a copy of the physical book or the audiobook, check out Prodcast IO. That's P-R-O-D-C-A-S-T io. It will automatically grab any of the suggestions or like book recommendations or anything and just have it in that list. So it should be there pretty quick after I release this episode.

It's a really cool project built by a cool Bitcoiner, and it's also a pretty neat way to support this show. So check it out. And a huge thank you to a lot of the people who helped make sense of this. To Anthony or Antoine Riard, however you pronounce that name. I'm sorry.

Shinobi. Matt Corralo. Let's see, there's a number of posts. John Carvalo had a couple of posts about this. I read through a bunch of stuff on the mailing list everybody who has been talking and fighting and yelling about this problem.

Thank you because I was slowly getting piece by piece by piece how this thing worked and it took me a long time to wrap my head around it so I really appreciated everybody who is angrily or happily trying to explain it because it helps. And a final shout out to the audionauts. Thank you guys for supporting the show and our amazing sponsors fold nodeless and cold card or coinkite, the makers of the cold card you should be using, and checking out every one of these services and their products. They are literally at the center of having a fully integrated and secure bitcoin life. Highly, highly recommended.

And with that, thank you guys so much for listening and I will catch you on the next episode of Bitcoin Audible. And until then, take it easy guys.

It is better to be hated for what you are than to be loved for what you are not. Andre Guide.