Episode 91: Splicing

Aaron van Wirdum Live from Utrecht, this is Bitcoin Explained. Hey, Sjors.

Sjors Provoost Hello.

Aaron van Wirdum First of all, I want to... thank Coinkite, the sponsor of our show, for producing a beautiful COLDCARD Q, which Sjors just passed me in my hands. Sjors, what is this? I see it has a full QWERTY keyboard. I see it's an ECC calculator.

Sjors Provoost An elliptic curve cryptography calculator.

Aaron van Wirdum It is a beautiful device. It's unfortunate we don't have a video for our podcast.

Sjors Provoost It essentially looks like a Nintendo, I guess.

Aaron van Wirdum You mean a Game Boy?

Sjors Provoost Game Boy. See, I did not play that many computer games.

Aaron van Wirdum Clearly.

Sjors Provoost Well, I played PC games. Anyhow.

Aaron van Wirdum So this is a hardware wallet?

Sjors Provoost Yeah, I believe it's essentially the same as their other COLDCARD wallets. It's just bigger.

Aaron van Wirdum Yeah, bigger screen, bigger everything.

Sjors Provoost Yeah, but my understanding is that fundamentally it's very similar. So it's not like they're introducing completely new security assumptions.

Aaron van Wirdum Right. Did you buy this or did you get this?

Sjors Provoost No, I got this one for free. I don't think we got it because we're sponsored. I always get them because I test them as a developer.

Aaron van Wirdum Fair enough. All right. Well, that's our sponsor, COLDCARD. They got a Q device. You can buy this, right? Online, go to coldcard.com, coincoin.com.

Sjors Provoost Probably.

Aaron van Wirdum Something like that. All right. So today, actually, we have another guest.

Jesse de Wit Hello.

Aaron van Wirdum Jesse de Wit. He's back.

Jesse de Wit Here I am again.

Aaron van Wirdum Maybe for those that didn't listen to the previous episode, you can repeat a small introduction of yourself.

Jesse de Wit Yeah, a small introduction. Jesse de Wit, I'm a Lightning developer working for Breez.

Aaron van Wirdum Right. So we got you in last episode because we've been getting some requests to do Lightning episodes and Sjors and I are sort of getting out of our depth with like advanced Lightning topics. So very thankful that you came back. We're going to do another Lightning episode. This time we're going to discuss splicing.

Sjors Provoost But before we get carried away by the wind...

Aaron van Wirdum Yeah, yeah, there's something else we want to discuss real quick, right, Sjors?

Sjors Provoost That's right.

Aaron van Wirdum We made an episode on the Tornado Cash trial at some point. This was episode 69, and the trial... Well, the trial actually happened this week. Prior...

Sjors Provoost That's right.

Aaron van Wirdum In previous, there were, like, hearings. There were, I don't know...

Sjors Provoost Yeah, previously, there were just, like, five or so over the last two years, meta hearings. So they were about his pretrial detention, about which documents the defense wants, that sort of stuff. And today, no, sorry, this week there was two days of the actual trial in Den Bosch with extremely uncomfortable seats. Well, I mean, the seats are fine. They have little pillows, but if you have to sit on them for eight hours, it's very uncomfortable. There was quite a few people in attendance, like multiple journalists, even from the mainstream media. And lots of, you know, some of his supporters, probably also half the FBI, I wouldn't know, but some people in suits.

Aaron van Wirdum That spoke American?

Sjors Provoost Maybe, at least they, you know.

Aaron van Wirdum So you attended, and so what I recall, I mean, I was at the hearings, and I was at the trial briefly, but not for the full two days like you. And what I recall from the hearings at least was that they revealed it really seemed like the case was going to boil down to should a DAO be considered like a company? No,

Sjors Provoost it goes beyond that. They're basically saying the whole DAO is just a little fantasy and really the three people were in control of everything.

Aaron van Wirdum I mean, that's kind of what I mean. It's not really decentralized in any meaningful way.

Sjors Provoost They don't really care what the company is. They're saying that Tornado Cash, whatever that is, whether that's a company or an entity or just a group of people, is like a business in the way it's operated, you know, as they would, like if they were prosecuting, say, a criminal organization, they don't care that it's, you know, Mafia Incorporated doesn't exist, right?

Aaron van Wirdum Yeah.

Sjors Provoost So in that sense, they're arguing it's just a business and they're doing things for profit and the profit came from pumping the token, if I translate it.

Aaron van Wirdum Yeah, the tornado token.

Sjors Provoost Because it's very clear that there was no money coming directly from the transactions on the mixer in the way it's designed. We explained that in episode 69. But they said even though there's no direct flow of money, they're still profiting from it. But I guess even if they weren't profiting from it, they're still allowing mixing to happen, and that itself is enough. So it's a pretty fundamental case, I would say. In the beginning, we didn't know if maybe there was some gotcha, like something really different that would have made the case. For example, they were not running relayers themselves, any of that stuff.

Aaron van Wirdum The original concern, at least, was writing open source code should not be illegal, basically whatever people use it for.

Sjors Provoost Yeah, so the prosecutor keeps saying that writing open source is fine, it's great, we love it, but... If you want to make money with it in any way, I guess, then you can't do it. So it's like privacy is legal, but if you make any money offering it, it's not legal. That's sort of my takeaway from it. And they're trying to make the distinction between VPN privacy, which is like communications, and money privacy, which are... objects or money which is treated differently.

Aaron van Wirdum Were there any new insights this week as far as you could say or compared to the hearings that I attended? Or was it kind of the same thing, just a bit more?

Sjors Provoost Well, the hearings you attended were not supposed to be about the case itself at all.

Aaron van Wirdum I mean, I know, but they kind of were.

Sjors Provoost Yeah, they were exactly because there's lots of media present. I don't know. I don't really think so. It felt to me like it was roughly just, you know, going into more detail, explaining which law articles, you know, the prosecution would explain, okay, you know, there's this money laundering, different articles, and we're not talking about Article A, but we're talking about Article B, that sort of clarification. So I took a lot of notes, but I really have to take my notes and go talk to an actual legal expert to understand the meaning.

Aaron van Wirdum Right.

Sjors Provoost Exactly what it said. And then the prosecution always has the advantage they can paint a very nice narrative, a story, but the defense does not have that. It's not so easy. I mean, of course, they try to explain how open source works and that decentralization is a good thing and that privacy is important, that sort of stuff. But a lot of the time they just have to spend shooting holes at individual arguments of the prosecution. So they have to say, well, if you look at Article 64B, you know, the word holding means this and it doesn't mean that. And they also have to try 15 different arguments just to see if one of the 15 works. And that makes it, as the audience, makes it more difficult to understand. And especially if you're not a lawyer yourself, it's hard to estimate whether just because he says it with conviction doesn't mean it works. And it's important to know that we don't have jury trials. So the goal is not to explain things and to convince a jury of non-legal people, like in the US. It is merely to convince the judges. And the judges have already received, I don't know, a million pages of documents and reports and they've all read it. So they also already know the arguments that both sides are going to make. So it's kind of a performative thing almost, where you have to say it out loud so people can... listen to it, but the judges are kind of like, you know, behind the screen, and they're listening and they…

Aaron van Wirdum Yeah, and, uh, the verdicts will come in

Sjors Provoost May 14th.

Aaron van Wirdum May 14th. All right, last question, so what's… I guess we discussed this in the actual episode, episode 69, so we don't have to get into it. But the reason you attended is it could have relevance for Bitcoin development as well, potentially.

Sjors Provoost In the long run, it will. I'm pretty sure about that because it's kind of a moving game where the front line is moving and maybe you could say, oh, the front line is in shitcoin land. But if you read some of the arguments that the prosecutor is making, the really generic arguments like if you make something, that is decentralized, the fact that you could have made it centralized, but you made it decentralized already means you deliberately did something to aid money laundering. So if that argument stands, then, you know, basically Satoshi would be screwed.

Aaron van Wirdum Right.

Sjors Provoost Because Satoshi could have made a centralized system, right? And he didn't. And he made money. Arguably. We don't know if he has any money.

Aaron van Wirdum I mean, he still had to earn it as well, right? He still had to mine it.

Sjors Provoost Yeah, but he wouldn't have been able to mine it if it didn't exist. I don't know what kind of argument would be made there.

Aaron van Wirdum Anyways, thanks for your sacrifice. I'm impressed to hear about the cushion situation and that you pulled through anyways.

Sjors Provoost I found that if you pile some jackets and stuff, then it's a little bit more comfortable.

Aaron van Wirdum You got it all figured out. All right, one more quick note before we actually get to splicing. You wanted to mention something about MARA Pool. MARA did this thing with the block. Which you could see on mempool.space, that's what this is about, right?

Sjors Provoost Yeah, if you are into nonsense, then you may have noticed that MARA Pool mined a block that if you look at it on mempool.space, it looks like a picture of an M just because of the way mempool.space visualizes it.

Aaron van Wirdum It's their logo, yeah.

Sjors Provoost If you go to any other website, it won't look like that. Point is, they achieve this by putting transactions in a very specific order. All these transactions are nonsensical OP_RETURN transactions.

Aaron van Wirdum All of them? Not all of them, right?

Sjors Provoost As far as I know, the whole block.

Aaron van Wirdum The whole block was nonsense?

Sjors Provoost Yep. I'll get to that. So basically, we had episode 84, where we talked about about six months ago, MARA Pool mined an invalid block. And the reason they mined an invalid block was because they were putting transactions in the wrong order. So if transaction A is created and transaction B spends transaction A, they must appear in that block in that order. So transaction A first, transaction B next. And they just sorted them all by, I don't know, by name or something crazy. And so the order was wrong and the block was invalid, and they lost a couple hundred thousand dollars. But now, looking back, that they have created this graffiti block, I guess, where the order of the transaction is used as a feature, my guess is that's what they were sort of trying to get to. That still does not explain why they tested that on Mainnet instead of on Testnet.

Aaron van Wirdum They were experimenting back then.

Sjors Provoost But the reason, I guess, why they picked OP_RETURN transactions this time is because you can just make them all independent and the order doesn't matter. You don't get an invalid order. But it would be more, if they want to continue this artistic career of theirs, I think it would be better to mine real transactions that are actually paying roughly the maximum fee that you would mine, maybe slightly less and then order those in a visual pattern. So you do not know in advance what the block is going to look like. Your algorithm just has to figure out how to take whatever is in the mempool and write copyright Sjors on it.

Aaron van Wirdum Yeah, you just got to make sure that the order is still not invalid.

Sjors Provoost Exactly. So you have to, exactly. So it's much more, it would require significantly more skill. I do not believe it is a good use of anyone's time, but if you are into this, please do it well.

Aaron van Wirdum Right, okay. So that sort of explains what was maybe, probably, possibly going on in episode 84. So that was a second callback to an earlier episode. Now let's make a new episode, Sjors.

Sjors Provoost Yes, good idea.

Aaron van Wirdum Yes, sir. You're down to make a new episode?

Jesse de Wit Let's make a new episode.

Aaron van Wirdum Let's make one about splicing. Okay, so splicing is a concept that exists in Lightning. First, what is it? Let's start with a very basic one-sentence explanation. What is splicing?

Jesse de Wit Splicing is basically giving you the capability to change the capacity of an existing channel.

Aaron van Wirdum Okay, so I have a channel with Sjors, say. There's, I don't know, let's say one Bitcoin in that channel. And we can increase that to two Bitcoin or half a Bitcoin, increase or decrease.

Jesse de Wit Increase or decrease, yeah.

Aaron van Wirdum Yeah, that's what splicing is. And why would anyone want to do this? Maybe that's a good follow-up. What's the actual benefit here? Why not just open a new channel or why not, I don't know, receive coins in the channel?

Jesse de Wit Yeah, so a Lightning channel, you basically want the lifetime of a Lightning channel to be very long. And during the lifetime of the channel, you want it to be operational. And definitely as a routing node, for example, if you want to increase the capacity of your channel as a routing node, you want your channel to always be available. because otherwise people won't be able to route payments over it and you won't make any fees. The alternative would be closing and opening a channel or opening an additional channel, for example. But yeah, it saves a lot in chain fees in the end, basically, as well.

Aaron van Wirdum Why does it save in chain fees versus opening an additional channel? What's the benefit?

Jesse de Wit It's basically the closing cost that you don't have. Because... Well, you splice in this channel, so that means maybe we should talk a little bit about how splicing works.

Aaron van Wirdum Well, hang on, it makes sense. I mean, eventually you're going to want to close the channels, and if you keep opening new channels, that means you have to close all the channels, while if you replace the same channel, then you only have to close one channel. So that's what you're saving, essentially, right?

Jesse de Wit Yeah, that's what you're saving.

Sjors Provoost And it's half the transactions in the long run, right? Because closing is one transaction, opening is one transaction.

Jesse de Wit Right, yeah.

Sjors Provoost Though I guess you theoretically could combine them. I think you mentioned another reason why this was good.

Aaron van Wirdum Or you want it to always work and the fees are, there's less fees, less on-chain transactions.

Sjors Provoost Yeah, we covered the part that it always works. Because if you close the channel, then nothing works until you've reopened it and waited six blocks.

Jesse de Wit Yeah, exactly. Yeah, so if you would close and reopen the channel, yeah, your channel is temporarily unavailable. So nobody will be able to route over it. With splicing, we'll get into that. You'll be able to keep using the channel while you've spent your previous channel, basically. During the splice, you can...

Aaron van Wirdum Okay, why is this like a challenge at all? Why is this a problem? What is the challenge here?

Sjors Provoost Why wasn't this finished in 2017 like the white paper promised?

Aaron van Wirdum Yeah, or just why isn't this standard? What's even the problem that we're trying to solve?

Jesse de Wit Um, so there were many design decisions on how to do splicing, like, how do you increase the capacity of a channel? Because what a channel, a Lightning channel is, it is basically a UTXO on chain. So that has a certain capacity.

Aaron van Wirdum Right. It has a fixed capacity. There's no way to add something to an existing UTXO.

Jesse de Wit No, no.

Aaron van Wirdum Yeah, exactly. So that's the challenge we're trying to solve.

Jesse de Wit So that's the challenge we're trying to solve and multiple ways people are trying to do that. For example, Rene Pickhardt, he mentioned, maybe we could have like two UTXOs in the same channel or there are other design decisions.

Aaron van Wirdum And then replace one at a time, something like that.

Jesse de Wit Yeah.

Aaron van Wirdum I mean, this is obviously not what we don't have to get into, but that would be the general sort of idea there. Yeah, okay. But that's not what splicing is.

Jesse de Wit That's not what splicing is. Because with splicing, what you do is you spend the funding transaction. So the funding transaction is your channel on-chain, right? And then off-chain, you have a bunch of commitment transactions, which are the previous states of your Lightning channel.

Aaron van Wirdum Yeah, every time Sjors and I update our channel, we're getting a new off-chain transaction that spends from the UTXO, basically. And we're not broadcasting that initially.

Jesse de Wit Yeah, and all these transactions are valid transactions, and you would be able to broadcast them at any time, but only one of them is the latest, and you will, um, yeah… but with splicing, what you do is you spend the funding transaction. And... With the transaction that spends a funding transaction, you add an input to that if you want to increase the channel capacity, or you add an output to that if you want to decrease the channel capacity, basically.

Aaron van Wirdum Okay, so we're spending basically all the funds from the channel, from the UTXO, to a new UTXO, which then becomes the channel, I would assume, right?

Jesse de Wit Yeah. That then becomes the channel, yeah.

Sjors Provoost Okay, so from the outside, this would look, but we'll get to that, I guess, towards the end. It looks like you're closing the channel and you're just opening another channel, but there is magic involved, which means that the existing channel continues.

Jesse de Wit Yes.

Aaron van Wirdum Yeah, so let's get there, because for now, it would sound like you can't use the new channel until the new channel would confirm, or... Kind of, right? That's sort of at least where my mind is going to when I hear this.

Jesse de Wit Yeah, and you're sort of right.

Aaron van Wirdum Okay.

Jesse de Wit Because when we're spending this funding transaction... We have to update the states. Every time a new payment will come in after that, we'll have to update the states on both of our channels, like our old channel and our new channel. We have to update the states on both of them.

Aaron van Wirdum Wait, that's a small note. Of course, I would assume, but please just confirm. So when you are splicing, this has to be cooperative between both parties, right?

Jesse de Wit Yeah.

Aaron van Wirdum Yeah, okay. So that's the only way you can do it. You have to both agree, we're going to update this channel. And that's how you spend the coins from the UTXO to the new UTXO.

Sjors Provoost And then you have to do duplicate bookkeeping. Because I guess the question is, you just made a transaction, but it's in the mempool, and it may or may not confirm. If it doesn't confirm, then the splice never happened. So you'd better have all the transactions that keep happening while your channel is in this phase. You'd better remember all those transactions as if the channel was never spliced in. But if it does confirm, well, then the original things didn't happen. So somebody could cheat you that way. So you really have to pretend that you have two identical channels and update them both at the same time.

Aaron van Wirdum Hang on. I mean, I am following, but I also think you're skipping ahead.

Sjors Provoost Okay.

Aaron van Wirdum So let's, I mean, I think what you say sounds right. But let's go back to the challenge. The challenge is it's not confirmed yet. So how can you use an unconfirmed UTXO as a channel when it's not confirmed? Isn't that like a risk, right?

Jesse de Wit If we hook into what Sjors was saying, then you had an old channel on chain, right? And this channel is on chain and it has these off-chain commitment transactions. So these... Off-chain commitment transactions can be broadcast at any time and spend our channel. And if that ever happens, then our new spliced-in channel that's in the mempool will never be the truth.

Aaron van Wirdum Right, that could become a double spend, essentially. So that could be rejected if one of the channel states is broadcast before the splicing transaction is confirmed, right?

Jesse de Wit Yeah.

Aaron van Wirdum That's what you say. Yeah, okay, I get that.

Jesse de Wit Yeah, that's what I'm saying.

Aaron van Wirdum Right.

Jesse de Wit So that's one of the scenarios. And the other scenario would be that eventually our splicing transaction confirms. And maybe that's closed later as well, but let's just assume that the splice transaction confirms. What you have to do during this period...

Aaron van Wirdum The problem with that...

Sjors Provoost Now let's say I have... Before the splice, all the money was on my side. A while before the splice, all the money was on my side. But then it moved to your side. And then we do the splice. And if the splice then happens, now could I just cheat and try to cheat with the original transaction? Because all these punishments transactions that you have won't work anymore because we have just created a new on-chain transaction. So all these old penalty transactions don't work anymore. So that needs to be solved.

Jesse de Wit So in the old, you're talking about the old channel?

Sjors Provoost Yeah, so I would, you know, can I still cheat with the transactions from before the old channel was closed? I know the answer, but I'm asking it.

Jesse de Wit You can still cheat with those. Yes, absolutely. But because your peer has the revocation key for these transactions, he can then steal all your money in that channel. So in that case, if you are stealing from like the old channel, right? then your commitment transaction will confirm. And then because you were cheating, I can then spend the funds in that channel all for myself.

Sjors Provoost But if I understand correctly, after the splice is confirmed, then I can no longer cheat with the old transactions, right? Because those old cheat transactions won't work anymore.

Jesse de Wit Yeah, exactly. Those won't work anymore because UTXO is spent.

Sjors Provoost So it's like you have a blank slate basically every time you do this.

Jesse de Wit Yeah, so once the splice transaction confirms, you can actually drop all the old states that you had.

Aaron van Wirdum Once it confirms, yeah.

Jesse de Wit Yeah, once it's deeply confirmed, basically, and you're sure that it won't be reorged out.

Aaron van Wirdum But I think the question we were still getting at, or the answer we were still getting at, is how can you safely use a channel before it's confirmed? That's the key question here, right?

Jesse de Wit Yeah, and that's, I guess, the key question. And the trick, how we're doing that, is that we're actually using both channels at the same time. We're using... every state update that we do to the channel, we're doing them on the old channel and on the new channel.

Aaron van Wirdum Right.

Sjors Provoost So then what happens if I try to spend more than is in the old channel?

Jesse de Wit Yeah, so that won't work during this period. You will only be able to spend... So if you added funds to the channel, you will only be able to spend the additional funds after the transaction is deeply confirmed.

Aaron van Wirdum Okay, so basically for a while we have like a quantum channel. It could still go either way and therefore we're updating both to keep track of each other, keep them in balance.

Sjors Provoost Yeah, or to scare the regulators, it's a shadow bookkeeping.

Jesse de Wit No, no, no, it's not shadow bookkeeping people.

Aaron van Wirdum Anyway, so Sjors and I, if we're updating, if we're splicing and then we keep transaction or forwarding transactions, blah, blah, blah, we'll keep using Lightning, then we're doing everything double. We're just updating the old channel and the new channel until the new channel is confirmed on the chain. Now we can forget about the old channel. Now we just have the new channel.

Sjors Provoost And while we're waiting, we cannot use the extra capacity that was added because we have to take into account the smallest of the two.

Jesse de Wit Right. The smallest of the two. Yeah, exactly. Because you could also have removed funds and then it's basically the new lower balance that's the limit there.

Aaron van Wirdum Okay. Well, that sounds actually kind of straightforward to me. But I would imagine there's a lot more sort of nitty-gritty to, like, how does the rest of the network, for example, know that this is the same channel rather than a completely new channel? Do they need to know? They need to have the routing information, for example, I would say.

Jesse de Wit They need to have the routing information, but they won't know that this is the same channel.

Aaron van Wirdum Okay. They'll consider it a different channel.

Jesse de Wit They'll consider it a different channel.

Aaron van Wirdum Okay.

Jesse de Wit But there is a little thing there, and maybe we can skip to that now, because your old channel was gossiped through the gossip network, and it's a sender that wants to route through your channel. He has a graph of the Lightning Network on his local node, and he had that channel inside his graph, right? And as soon as you spend that channel on chain, he would consider that channel closed. So now the sender wouldn't be able to know, wouldn't be able to use your channel because he thinks it's closed and the splice transaction hadn't confirmed yet. So in the BOLTs, there is a...

Sjors Provoost BOLTs means improvement for Lightning.

Aaron van Wirdum Yes, basics of Lightning.

Jesse de Wit Basics of Lightning technology.

Sjors Provoost Yeah, basically a BIP for Lightning.

Jesse de Wit Yeah. And there they say that once the channel closes on chain, you should wait now for 12 blocks before you actually remove this channel from your channel graph. And because we're doing this, now for these 12 blocks, we would still be able to be trying the old channel. And after the splice transaction confirms, gossip will probably reach us in time to make us learn about the new channel.

Sjors Provoost It probably will happen almost immediately, right? Because the moment the splice confirms is the moment that other nodes, when they see that block, they all think that channel is gone. But at that point, the gossip is being spread that there is a new channel in town. And so there might be a few seconds in between those two moments, but for those seconds, you don't want to think that the channel is gone.

Aaron van Wirdum But what's the benefit of keeping the old channel in memory for 12 blocks? If you try to use it, will these peers themselves just figure, oh, well, that channel doesn't exist, but we have a new one. We updated it. They'll just figure it out.

Sjors Provoost That's where the double bookkeeping comes in, right? They see a transaction for the old channel, but they'll honor it for the new channel. Well, I guess this is after confirmation, so there's another trick for that then.

Jesse de Wit Yes.

Aaron van Wirdum We're talking after confirmation, yes.

Jesse de Wit So we're talking after confirmation.

Aaron van Wirdum So it appears smart enough to just forward it anyways.

Jesse de Wit Which peer are you talking about right now?

Aaron van Wirdum So I'm trying to pay you, Jesse. Yeah, and I see that you have a channel with Sjors. Yeah, and you guys just spliced and it's confirmed, and I have a channel with Sjors. So now it's still in my memory that you had the old one. So now I'm trying to send it to you through Sjors. Yeah, is Sjors smart… Is Sjors smart enough to figure out that he has this channel with you still, even though I was not…

Jesse de Wit Yeah, Sjors is smart enough to do that.

Sjors Provoost We stopped the double bookkeeping, right?

Jesse de Wit Yeah. Yeah, Sjors will be smart enough to do that.

Aaron van Wirdum I could have known that Sjors was smart enough for that. Well done, Sjors.

Sjors Provoost Thank you, thank you.

Aaron van Wirdum Okay, that answers that question. Okay, so that's why it sticks in memory for essentially 12 confirmations.

Sjors Provoost Yeah.

Aaron van Wirdum Right.

Sjors Provoost Now I think we need to go back a little bit to talk about something fundamental.

Jesse de Wit Yeah, something in the fundamentals is underway. So the way a splice begins, we want to make sure that there's no funky stuff going on in our channel while we're doing all this complicated business initiating a new splice.

Sjors Provoost Yeah, so it's not this time that it's confirming in the mempool. It's really the time between we like to splice and the moment we submit a transaction to the rest of the network. And that period of time is like a second. To the outside world, but to computers, that is an eternity in which many, many things can go wrong in that one very second.

Jesse de Wit Yeah, like the funky stuff I meant adding HTLCs basically to your channel or removing HTLCs.

Sjors Provoost So we're in the middle of a conversation about building a splice. It's a very intense conversation. And then Aaron comes in and is like, please forward this for me. And we're like, no, no, no, not right now.

Jesse de Wit This is complicated enough as it is.

Sjors Provoost Come back in one million microseconds. Yeah.

Aaron van Wirdum I've come back in 0.6 seconds. I don't have that type of time Sjors.

Sjors Provoost No, so you would see your transaction fail, basically.

Aaron van Wirdum Oh, right. I'll go somewhere else if you don't want to help me within 0.6 seconds.

Sjors Provoost Yeah.

Aaron van Wirdum All right, got it. Okay, so the actual time that it takes to say, hey, do you want to splice? Yeah, I want to splice. Let's splice. In that time, you can't route. The computers can't route in that time.

Jesse de Wit Yeah, the computer [unclear] route. And that's because we initiated quiescence.

Aaron van Wirdum How do you pronounce that?

Sjors Provoost We Googled it and we believe it is quiescence. Quiescence. Or quiescence, I guess, if you're American.

Jesse de Wit When I read it, I thought it was quiescence. But yeah, internet says quiescence. So you send a STFU message to your peer.

Aaron van Wirdum Is this an actual term?

Jesse de Wit This is the actual term. It stands for something fundamental is underway.

Sjors Provoost Yes. Dear children listening, do not Google these letters.

Jesse de Wit And then your peer sends back.

Aaron van Wirdum No, that doesn't add up. You said S-F-T-U and it stands for what?

Sjors Provoost Something fundamental is underway.

Aaron van Wirdum Oh my God.

Jesse de Wit Something.

Aaron van Wirdum Anyways, enough.

Jesse de Wit Keep it straight.

Aaron van Wirdum What were you saying? Something fundamental is underway.

Jesse de Wit Yeah, so what we're saying is now we're going to quiescent mode and now we're not going to update our channel until we're finished negotiating the splice.

Aaron van Wirdum Okay.

Jesse de Wit Then we're going to say to the peer like, okay, I want to do a splice for this extra amount and for this fee rate. And what we're then going to do is we're going to start the interactive transaction construction protocol. And that's, yeah, that's a new protocol that's been merged into the BOLT spec last month.

Aaron van Wirdum Oh, very new.

Jesse de Wit Yeah, very new. So because it's merged in the BOLT spec, that means that at least two implementations implemented that already. And with this, basically, what it does is you say, like, add an output to this transaction, add an input to this transaction, remove an output, remove an input, and you're going to negotiate what the new funding transaction will look like.

Sjors Provoost Right. And I guess this is different from how things worked before, where one side would just say, this is going to be the transaction, like it or don't like it, just sign it. And now this is a more sophisticated conversation.

Jesse de Wit Yes.

Sjors Provoost Does it use PSBT?

Jesse de Wit It uses PSBT, yeah.

Sjors Provoost Cool. We did an episode about that.

Aaron van Wirdum A long time ago.

Jesse de Wit And so this Interactive Transaction Construction Protocol is also used in a new protocol in the BOLTs called Open Channel V2. And that's a version 2 of the Opening Channel Protocol. And that also allows for RBF, which means that splices also allow for RBF.

Sjors Provoost And so does anybody who would use this for opening a new channel, because in theory you could use it for that too, could now also use RBF, right?

Jesse de Wit Yeah.

Sjors Provoost I think you said nobody's implemented it?

Jesse de Wit Yeah, so I think nobody's implemented it for normal channel opens yet.

Sjors Provoost But I can imagine it's very useful for a zero confirmation channel, for example, where a service provider opens a channel to you. You know, there's some wallets that will give you a zero confirmation channel briefly. That's a risk you're taking as the recipient. And then they might say, well, we're just going to pay one Satoshi per vbyte. And then if we start worrying as a service provider... then we'll just increase the fee to make sure that it confirms.

Jesse de Wit Right, yeah. And it makes sense in any situation to be able to RBF a transaction. And you've seen that in the last periods where the fee rates were changing a lot, right? So if the fee rates are increasing a lot, then you definitely run into problems of channels not confirming. And after two weeks, then your peer forgets about the channel altogether. And so your funding transaction will be worthless.

Aaron van Wirdum Right.

Jesse de Wit So that's cool features in the BOLT spec as well.

Aaron van Wirdum Okay.

Jesse de Wit So now that we've negotiated the transaction.

Aaron van Wirdum Uh-huh.

Jesse de Wit And after negotiating transaction, we exchange signatures for this transaction. And once we've negotiated signatures, then we're out of quiescence mode.

Aaron van Wirdum Yeah, and then the double bookkeeping starts, basically. And then the splice in which we discussed starts.

Jesse de Wit Yes.

Aaron van Wirdum Until the new transaction is confirmed.

Jesse de Wit Yes, until the new transaction is confirmed. Or if it's like a zero conf channel, so a channel that doesn't need any confirmations. Basically, you will instantly be able to use the...

Aaron van Wirdum Oh, that's also possible.

Jesse de Wit Yeah, that's possible. If you have a channel with Sjors, and you trust Sjors that he won't double spend your channel, you could do a zero-conf channel.

Aaron van Wirdum Right, right, right, Sjors. Okay, does this cover splicing? I want to ask you who's implemented, unless there's something more to say about the technical details.

Jesse de Wit Yeah, I think it covers most of the technical details, yeah.

Aaron van Wirdum Okay, yeah. So splicing was not in Lightning since day one, obviously, right? But still now it's not like a standard thing, right? It's still a work in progress, but there are implementations that have this? What's the status of splicing?

Jesse de Wit Yeah, so the spec is still a work in progress and it's still being negotiated exactly how the spec should look like.

Aaron van Wirdum Oh, even the spec is still... Open for discussion?

Jesse de Wit Yeah, there's a few things in the spec, like, uh, how many confirmations the splice has, like, you should be able to negotiate the, uh, confirmations before the splice is locked. Um, there's also, for the gossip protocol, maybe they want to add a feature bit to the gossip messages saying, oh, this channel is a splice channel, and, yeah, there's a few, like, uh, bit more minor things. And one of the bigger things is, um, um, in a channel, you have a channel reserve, uh, so one percent of your… Of each side of the channel has… Each side of the channel has, uh, one percent of the channel capacity as reserve, and you're not allowed to spend this one percent in in the channel. Um, and so that was, um, because… You always want your peer to have something to lose.

Aaron van Wirdum You always want to be able to punish your peer.

Jesse de Wit You want to be able to punish your peer.

Aaron van Wirdum You want to inflict pain on your peer potentially.

Jesse de Wit Yes.

Aaron van Wirdum Okay. So this is true for all Lightning channels?

Jesse de Wit Yeah, basically all Lightning channels. I work for Breez, but with Breez, the clients don't have a channel reserve. Because with Breez, we know we are always online. So you basically wouldn't be able to cheat us, even if you tried, because we have a two-week period in which we can broadcast a transaction on chain. So we're all right with that. So you could configure that.

Aaron van Wirdum But generally speaking, every Lightning channel needs at least 1% for each peer.

Jesse de Wit Yeah.

Aaron van Wirdum But you can open a channel with 100% on one side, right?

Jesse de Wit Yeah, so this is an exception to the rule. Like once you've opened the channel, all the funds are on your side, so your peer won't have the 1% yet. But as soon as you send something to the other side, then they won't be able to spend that 1%.

Aaron van Wirdum As soon as the other peer has 1%, that… Needs to be stuck there, essentially.

Jesse de Wit Yeah, okay. Yeah, but there's a… So now there's an issue with splicing, because, um, let's say, uh, Aaron, we have, uh, we have Lightning channel, and and now I decide to add a huge amount of funds on my side of the channel. Now your part of the channel dips below that 1%. So they're still discussing, like, how should we handle this?

Aaron van Wirdum Okay, this is still part of the discussion of the spec, and there's no real... So if the spec is still being discussed, then I would think there's no implementation that has splicing yet, or are there...

Jesse de Wit Yeah, there are implementations that have splicing. You've got the ACINQ team. They've implemented splicing in Eclair and in Phoenix.

Aaron van Wirdum Okay.

Jesse de Wit You've got the LDK. LDK has splicing support, and Core Lightning has splicing support as an experimental feature.

Aaron van Wirdum Okay, and are these all compatible with each other?

Jesse de Wit Compatibility is sort of happening now. This is the period that people will start compatibility testing.

Aaron van Wirdum Right. What about Breez?

Jesse de Wit We're working on this.

Sjors Provoost So the rule is that once two different implementations are compatible, that's when a spec is final or can be made final.

Jesse de Wit Yeah.

Sjors Provoost But there needs to be at least two different implementations that are compatible and the only way to find out if things are compatible is to actually build it because that's how you run into the things you did not think about in the design. So I think that's a sane strategy, but the problem is, and I think we've talked about that in earlier episodes, different Lightning projects like LND or Core Lightning or whoever, they all have their own priorities. And so if they all have their, if they all literally have just one pet project and they don't pay attention to any of the other projects, then nothing happens because there's never two different implementations. And this is one reason why things can take a while. You need to have two, at least two that happen to have the same priority, but there's no Lightning CEO out there.

Jesse de Wit No, exactly. And, yeah, by the way, LND also has it on the roadmap for somewhere in the future.

Aaron van Wirdum Yeah, I thought they had it years ago, but apparently I'm just wrong about that. I remember writing an article, but maybe it was like one of these articles about what's in store for the future of Lightning that I wrote like five years ago.

Jesse de Wit Yeah, eventually it's still the same things in store.

Aaron van Wirdum They seem to stick in production for a while.

Sjors Provoost Yeah, and I guess one observation I can make is that the reason why Phoenix can use Lightning in the wild... because they really are shipping it as part of their tap swap. Is it tap swap? Swaproot? Oh yeah, Swaproot protocol, which is swapping and using Taproot and using MuSig and other cool stuff. They can use that in the wild because their wallets only connect to the Eclair node. And so even though the spec is not completely fleshed out, they have control over which nodes you're connecting to, so the app is not going to break, even if it's not completely following the spec yet, because the spec is still being changed. Now, I assume they have thought about safety, because everybody can, you know, it's open source, the Phoenix app, so you can look at it and see how it works, and you can change it and make it misbehave. And presumably they've made it strong enough that it will survive abuse, but it may not be compatible yet with other nodes.

Jesse de Wit Exactly that, yeah.

Aaron van Wirdum Can you splice from a splice?

Jesse de Wit Yeah, you can splice from a splice.

Aaron van Wirdum You can update.

Jesse de Wit You can have a chain of unconfirmed splices. And yeah, so what happens then is then you have a transaction that spends a transaction, that spends a transaction, that spends a transaction.

Aaron van Wirdum But they have to all confirm on chain.

Jesse de Wit Yeah, basically they should eventually confirm on chain.

Sjors Provoost Because I think one question we hoped you would be able to answer is, can you change the splice? Can you place a splice that is in progress but not confirmed? We know we can RBF it, so we can increase the fee of the splice, but could we also change the size of the splice?

Aaron van Wirdum That should work, right? That would be better. It sounds like the spec

Sjors Provoost would be even more complicated.

Jesse de Wit I think that should work in some circumstances, but yeah, you do fall into issues with will the mempool accept my new RBF splice. I'm not sure how implementations do this, where the restrictions are.

Aaron van Wirdum Okay, well, that's getting a bit into the weeds.

Jesse de Wit But the one thing I wanted to say about these chains of unconfirmed splices is that yeah, well, then you have to, for every channel update, you have to update all of these.

Sjors Provoost And the same goes for RBF, right? Every time you RBF, you have to update everything? Or is RBF done more efficiently?

Jesse de Wit Yeah, with the RBF, exactly, that's the same. Yeah, so every time you RBF, it's basically like a new... a new splice. So you have to, yeah.

Sjors Provoost You have to have 10 times the number of, you have to, every transaction you make, every HTLC you forward, you have to keep track of it in 10 different ways.

Jesse de Wit Yes.

Sjors Provoost Yep.

Aaron van Wirdum Right. Okay. I think that kind of covers it because we're getting into weird weeds now. So I would assume that the main splicing topic has been covered now, right? Did we miss anything?

Jesse de Wit No, we got it all.

Aaron van Wirdum Okay, awesome. Well, yes, thanks for coming back. Do you want to pitch where people can find you or something like that?

Jesse de Wit People can find me on Twitter and on Nostr. I bet it's going to be in the show notes.

Sjors Provoost It will be.

Aaron van Wirdum I will put it in the show notes, yeah.

Sjors Provoost All right, then. Aaron, do you have anything to add?

Aaron van Wirdum No, I'll see you soon, Sjors.

Sjors Provoost All right, then. Thank you for listening to Bitcoin,

Aaron van Wirdum Explained.