Lightning & Splicing: Explained by Lisa Neigut of Blockstream | 05.17.2022

Link to the YouTube: https://youtu.be/nDPVeTY9eeQ

Lisa Neigut: We’re talking about splicing, so in order to understand Lightning I think that it’s a good thing to do a quick overview of how Lightning channels work. So one thing that I find useful to keep in mind when you’re talking about what a Lightning channel is is to remember that Lightning channels come out of this idea of like, What if we took contracts and law and use the blockchain to enforce contracts, but all of the contracts would be private party contracts unless there was a problem, and if there was a problem you would take the contracts and you would put the contracts to the blockchain so the blockchain would be the final arbiter, so to speak, of whose contract was correct? So I think this is useful for me talking about Lightning because we do talk about these off-chain contracts and how the contracts get updated, but the general idea is that you’ve got these off-chain contracts that get negotiated between parties and then you’ve got this on-chain anchor that either serves as the original backing behind that contract, or it’s how you close out a contract. So let’s walk through how this works: so a Lightning channel — again it’s a contract between two parties. The way a channel is opened is that two parties come together and they agree to put some money into a shared output on the chain together. So two parties come together and they agree that they’re gonna put some money together. So they put their money together, and the way that you express that you put your money together in Bitcoin is you create an object — we call them UTXOs on the chain. And so you get this UTXO object over here and the money from both parties is in this shared object, and the way that you govern who owns what in that shared object is with this little contract, and the contract will have in it information about who — so let’s say there’s 15 Bitcoin in this thing, in this UTXO. Then each side will have a contract, and the contract will say how much of that total on-chain amount belongs to each party in the contract. So each party here has a copy of the contract, and at any point in time either party can take their version of the contract and send it to the blockchain. So let’s say that one party decides to publish their contract and sends it to the blockchain to get mined. So we’ve got a little blockchain to get mined — they’re gonna send their version of the contract to get mined — once it ends up on-chain, what were just contractual holdings of who owned what, they actually turn into UTXOs once you mine them, once the contract gets on-chain. And then once a UTXO has been mined, basically this actually spends this old one and produces two new outputs, and once you’ve created new outputs, the one that you spent basically loses its value — the value is transferred through the mining process over to the new transaction outputs that are created. So that old UTXO goes away, and these new objects that are created each have a value which maps to what the value was in the off-chain contract. So you can take your off-chain balance and you can close the channel — so what actually happened when you did this is the channel closed. So once this one contract has basically been put in the chain and what was in a contract as who owns what money now has been made real on the blockchain through these little output objects and they have a value, that value should map to what was the value off-chain. Okay, so this is a very high-level overview of how you open and then close the channel, but we didn’t really show how useful it is, like, Okay, so you had 5 and 10 Bitcoin, you put it into a big thing that was worth 15 Bitcoin — your little contract that said who owned how much — then you sent it to the blockchain and it got created into two little outputs. Like, okay, that’s cool — I don’t understand why that’s useful? So let’s go back a few slides to when the channel is open. Okay so we’re back to where the channel was, so we’re back to where we started off — we’ve got this one thing on the blockchain and we’ve got these little contracts of who owns what. So how can we move Bitcoin around or settle Bitcoin without interacting with the chain? So the way that money or Bitcoin moves between two parties in Lightning is that all the two parties have to do is exchange updated versions of the contract. So let’s say that fox decides to pay the wolf 5 Bitcoin — they would create a new version of the contract where the fox only has 5 balance and the wolf only has 10 and then they would make another copy of that and they would send the new copy of the contract to the wolf. The wolf has an opportunity to sign off on it and say, This looks good to me. So once both of them have exchanged signatures for the new contract, they can throw the old copy away. And so this updating of this contract not having to touch the chain — that’s settling a Bitcoin payment off-chain using a Lightning channel. So we were able to update what the balance in the channel was without having to get onto the blockchain. And you can obviously do this as many times as you want back and forth until at some point you decide you want to close. So now though if this party on the right (fox) was to publish this transaction and going through the same process we went through above, the outputs that they would get here once it got published — instead of being 10 and 5 — it would reflect what the current contract is of 5 and 10. Now that we have a very simplistic understanding of how channel balances work and how money is moved between two parties in a single Lightning channel, let’s get into the idea of what splicing is and how splicing enables the money that you have in a channel to be a little more flexible. So currently with Lightning channels, the amount of Bitcoin that’s held in this UTXO on-chain — which is 15 — is fixed. So you can move Bitcoin back and forth between these two parties — these guys can update how much money they have — but the total amount of money in this contract is fixed at 15, and that’s tied to an object on the blockchain. It’s governed by this output which lives in the blockchain — how much total money there is in there. So there’s always going to be 15 Bitcoin. So if one party decided that they wanted to pay someone else outside the channel using their in-channel balance — so they’ve got this much in channel but they want to pay someone else who isn’t fox and for whatever reason they can’t reach the Lightning Network (we’re not really talking about routing today, we’re just talking about splicing) — if they wanted to use this money anywhere else, they would have to completely close this channel, and if they wanted to restart it, they could ask to open another channel with the channel party, and that would take two on-chain transactions. You’d have to have one channel to close it, you’d have to have another to open it, and in the meantime, any payments that you could be routing could be sending between these people — and we haven’t really talked about routing so this is a little bit of a handwave, but — any money that you would be sending between these parties, basically all ability to send money between these two people stops when you close the channel and reopen it. So with splicing though, if we wanted to send some money to a third party like the frog — like I was saying, you can’t do it right now in the current thing, but if we do splicing, all of a sudden we’ll be able to take some of the wolf balance out of the channel and send it to this third party who isn’t part of their channel. So in order to do this we’re gonna have to go to chain — we’re gonna have to make a new transaction, we’ll go to chain, it’ll be a single on-chain transaction. So the way that’s gonna work is that the first thing they’re gonna do is the party who wants to splice out — we’ve got money in the channel and we want to move some of it out of that channel — they’re gonna create a new contract that updates the terms. So in this case the party had 10, they want to move it down to 5 — they want to splice out 5 to send to a third party. So they would make this new contract proposal that they would send, so they’re gonna have the new contract and then they’re also gonna create an on-chain little output that sends the frog 5. So there’s still 15 Bitcoin across all three of these things now, but now we’re gonna have an on-chain thing. We haven’t gotten this mined yet, so this is all just like a proposal. They’ve made a copy of their contract, they send it to their peer, and the peer’s gonna say, Sure, is gonna sign off on it and say, Okay sure, that looks great, then we’re gonna take this old transaction and we’re gonna spend it by getting it mined and we’re gonna create two new outputs out of it. So this one was worth 15 and then we mined it and we created two new ones instead. We created (1) one output that’s worth 10 — so this is now the output that governs this channel with the new channel contract. We already have a signed and updated contract which covers exactly 10 Bitcoin that’s in this new on-chain output. And we’ve also created (2) another output that went and got sent to another third party for the other 5. So at this point we have successfully spliced out five Bitcoin from the channel — notice the channel didn’t get closed. We still have these contracts between these parties. And while we were waiting for this mining process to happen, we had two sets of contracts — we had one for the old version and we also had a new set of contracts for what would happen after that output got mined. Once the new output that governs the channel has been in the blockchain for a certain amount of time — you usually wait like five or six blocks — you can throw the old contract which covered 15 Bitcoin away. You only have to keep the new contract which only has 10 Bitcoin worth of it in it, and with a lower amount for the one party. And now you can send money back and forth between these two parties in the channel, and up to 10 Bitcoin of value, which is pretty cool. Now let’s look take a closer look at what happened on-chain when this happened. So originally we had one UTXO and the two channel peers had shared custody over it, and that shared custody was governed by this off-chain contract that they both had a copy of. It was worth 15 Bitcoin. They had this private contract, again, that explained how much of that 15 Bitcoin each party held. Once the peers decided they wanted to pay someone out, they took the 15 Bitcoin and they spent it on-chain. So they created two new UTXOs on-chain: one that was worth 5 and got paid to a third party, another that was worth 10 that is going to hold the new channel contract — the new channel contract will now point to this [new] one, basically, instead of this [old] one, so we’re just updating what the channel contracts are pointing to on-chain. So this is all the on-chain stuff. And so once you spend this 15 Bitcoin thing and this has been mined in a transaction, the value transfers over to the new outputs that are created, and now that they’re on-chain, the new contract between the two parties will reference this new 10 output thing. So now they are pointing to this new output with a new 10 value and it’s updated to reflect that. And the other output we can just forget about because it’s been mined, it’s been spent, it’s no longer valid Bitcoin that’s worth spending. So that’s how that works — just a quick overview. Splicing is pretty cool because it allows either party to add or remove funds — we just talked about the remove case in this example, but one party could also bring their own funds. For example, we could add funds instead, so we could have a little add funds that got added. So you start with the channel output and let’s say you wanted to add another 2 Bitcoin to this channel for whatever reason, then you would be able to basically splice these together so that they would go together into a bigger object and then this total contract would be worth 12 now. And then once the transaction that creates this new thing is mined, the money, the value moves over to this new object and then these contracts would get updated, so fox would now have 7 here and 7 over here. So this is basically how you would splice in value to the network. So you can add funds, you can remove funds, you can add and remove funds at the same time. So fox could add money in at the same time wolf was splicing money out — it’s pretty flexible in terms of who can add and remove stuff. It all happens in one single transaction, which is pretty cool. So it allows either party to add or remove funds from the channel. What’s also cool — we didn’t really talk about how this works, but — channels can still process payments while you’re waiting for the new contract to be enforced. Again, that delay really depends on how long it takes for the transaction which spends the old channel out point and creates the new one — usually it’s about an hour or two but could be longer depending on some stuff. But it’s cool that you can keep processing payments — you don’t have to wait until the whole thing is over. And then the last thing which is pretty cool about splicing is that you can splice funds into and out of multiple channels in the same transaction. So I think this is a useful thing to see happen which is cool: let’s say, instead of two parties with one channel, we’ve got three parties with two channels. So since Lightning channels are two-party right now we’ve got two channels between them, so again there’s contracts that govern them — I’m not showing the on-chain stuff here, I’m just showing how stuff works. So you could do a single splice, so this is their on-chain object that has the entire balance for the channel and the little off-chain contracts which keep updates for it. So you could do a single splice that does a reorg where you can move — those are the current balances in the channels, there’s 10 here and there’s 9 here — and the wolf wants to move their entire 5 balance from this channel over to this channel for some reason. Wolf wants to move it from here to here. So that means we’re gonna need two new outputs on the chain. You can do this in a single transaction because a single transaction can contain multiple outputs, so we’ll build a single transaction that spends these two and creates these two new ones at the same time and then get that mined so that the value moves when they’re mined. And now we’ll have to update our old contracts for both sides and then they replace it. So it went from being 5 here for wolf’s balance and 5 here to what happens after it: the wolf’s new balance is now 0 in this new output because fox owns all 5 and they now have 9 over in this channel. And so the splicing protocol that we’re working on will basically allow you to move money around between channels pretty easily, hopefully, while still having the channels open — you can still send payments, etc. So that’s that’s all I had in terms of illustration. I know it’s pretty high-level, but hopefully it gives you a good idea of what the goal is and why this is such a cool and exciting project that we’re working on at the Core Lightning project. If you want to read more there is a draft for the splice out, which is what we’re building on. So this is #863, you can go look it up, if you want to read more, if you’re an engineer and want to see more about what’s going on here — this is a good place to see it. This explains more of the details about how exactly it works and how the messages these parties need to send between each other in order to negotiate the new contracts and the transaction that they then send to the blockchain — the transaction that’ll actually make this update happen. We’re spending these as inputs and we’re creating two new outputs. So that’s everything I had. I know that was a lot faster than an hour, but splicing is not too complicated as a topic. I think it’s definitely gonna create some new opportunities in terms of thinking about how you deploy capital to Lightning and where it ends up and how you manage it. So Core Lightning is a great project — we’re working on fun and exciting things like this that help with liquidity management and nice decentralized ways. You can follow us on Twitter @Core_ln. I am @niftynei. And then I also forgot to shill my other project that I work on part-time — I teach developers and curious people about how Bitcoin works at the transaction-level at Base58. So if you want to learn more about how the output stuff that we were talking about works, we have a 6-week developer-oriented transactions class — it’s got a really good description of what we cover, some really awesome prerequisites that I’d recommend you check out. And then our next class starts June 27th, so if you’re looking to get more into how Bitcoin works and want a deep dive on the Bitcoin protocol, come check us out at Base58 — we’ve got some great stuff going on. I guess I should also plug BTC++ — I’ve got a lot going on right now — I’m also organizing a conference. It’s going to happen in Austin, June 7th-10th. We’re gonna have 2 days of action-packed workshop stuff and then we’re gonna have 2 days of a hackathon to build on what you learned. I hope you join us. It starts 3 weeks from today, and I think we’ve only got like a handful of tickets left at this point, so get on that if this is you. It’s also right before Consensys, so if you’re going to Consensys you might consider getting a ticket and coming to check out some workshops on what people are building on Bitcoin. Okay, if there’s any questions or if there’s anything I can answer, anything that maybe wasn’t super clear, it’d be helpful to know?

Lilit: The question from Cody is: How does splicing affect liquidity ads or service providers? Are you able to splice into a channel created off a liquidity ad? Or do you have to wait until after the commitment elapses?

Lisa Neigut: That’s a good question. I think that is an open question. So for those who aren’t familiar, liquidity ads is a project that I worked on last year which lets you buy — negotiate with a peer when you open the channel for them to put Bitcoin into the channel that you open so that you can immediately start receiving payments through your Lightning channel. And we call them liquidity advertisements because you pay the peer a little bit of a premium for them putting capital in the channel with you so that you can then start receiving Bitcoin over Lightning, which is really cool. So I think there’s definitely a big opportunity here with splicing to do a couple things: one is we could figure out a way to use liquidity ads so that when you’re splicing a channel you could actually negotiate with your channel peer to put more Bitcoin into the channel if they have it available for a fee or whatever. And so the cool thing about splicing — the fact actually that you can do this thing with the multiple channels getting done at the same time — is that there’s a cool possibility that if the fox needed more inbound liquidity for this channel, maybe the reason that the fox is splicing money out of this channel into this channel is because koala has offered to pay them for that liquidity so the wolf decides, Actually I can do better if this Bitcoin’s been in this channel with the fox for a while, nothing’s really happened here, I can move this out of this channel into the channel with koala and koala will pay me to do that. So liquidity ads give you the opportunity to negotiate movement of liquidity or express that you have a need for inbound liquidity and at what rate you’ll pay to move money around. So there’s definitely I think an opportunity to take what we’ve done with liquidity ads and make them also work on channel splicing so that you can use those as signals of where it’s most profitable to allocate your capital on Bitcoin and Lightning channels — but more dynamically, so not just at the channel start, but over the lifetime of the channel, you can dynamically reconfigure where your capital is based on who’s willing to pay you for it. Cody’s question though had to do with the fact that when you sign a liquidity agreement you usually agree to a lease term, so liquidity ads have a fixed length of duration of that commitment for I think four weeks — 4032 blocks — which is roughly four weeks. So I think Cody’s asking if the lease hasn’t ended, I think it’s really up to your channel peer — the one who paid you for liquidity in the first place — whether or not they think that that splice is in their benefit. So someone could always propose a splice during the middle of a channel lease and it would really depend on your channel peers whether or not that would succeed — they could easily say, No, I don’t want to splice. And this is true of any situation where you’ve got your peer — at any point one side always proposes to say, Hey, let’s splice! The other side at any point can say, No, I don’t think I want to do this. So if you had a contract where the wolf had said that they were gonna keep 5 Bitcoin on this channel with fox for four weeks and it’s week three and wolf decides they want to move it to the channel with koala with this double splice between two channels thing, the fox party could always say no to splicing out that capital, and that would be fine. The option there is that if the fox doesn’t want to do what you ask them to, you can always take your contract and go to the chain and close the channel on your side and then reopen it and move your money elsewhere. So I think in general most people, their nodes will probably be very willing to move your stuff around for you. It’s worth noting though if you had a channel with these 5 Bitcoin where they’re locked so they had like a little star on them because fox had paid you to put those 5 Bitcoin — they still belong to you, they’re still yours, but fox paid you a little a bit of Bitcoin to put it in a channel with them until the lease ends. If this contract goes to chain, the wolf won’t be able to spend your output so when it goes to chain then the one that the wolf owns — let’s say this was the wolf’s on-chain thing — this was worth 5 BTC with a little star. The little star there would mean that they wouldn’t be able to spend it — it’s under a lock time, basically — they can’t spend it until after the lease ends anyway. So basically there’s no incentive to closing the channel early if you’ve locked your funds in if they’ve been leased from you because you won’t be able to use them until the lease ends anyway, so you’re stuck. Better to keep the channel open and maybe route a payment than close and go to chain and not just be able to access that capital until the lease runs out is the thought. So this 5, if this was actually leased out to the fox for like a week or two — for four weeks — then you really aren’t able to deploy this capital anywhere else until either the fox gives you permission to close a channel, which they probably wouldn’t, or the four weeks runs out.

Lilit: Thank you, Lisa. I think there’s one more question from Cody in the comment section. The question is: Are there any new opcodes or Bitcoin improvement proposals required to make splicing work? Or is it just an engineering problem of actually implementing it with the protocol as it operates right now?

Lisa Neigut: Yeah so splicing we can do today. In fact, my co-conspirator who’s working on getting this working has already done a main chain splice — not with software that we’d want anyone else to use, but it’s totally possible and doable today. Again, it reuses a lot of the stuff that we use for the collaborative channel opens that Core Lightning can do where both parties open the channel at the same time and can put money in so you can start with balanced channels. So it’s really just reusing a lot of code that we’ve already written. There’s a little bit of trickiness around the contract updates, so when you’ve got two sets of contracts in progress at the same time, you’re waiting for this transaction to get mined. There’s some trickiness in the engineering around it, but no it doesn’t require any new opcodes, it’s doable today. In fact, one has already been done on main chain. So yeah it’s really just an engineering time problem, and at this point we’re working on it and depending on how the next few weeks go, there’s a small chance it’ll be an experimental option in our next release sometime in late summer.

Lilit: One more question — thank you Nicolas by the way for the question. And the question is: What are the advantages of splicing compared to on-off-chain swaps? Both involve an on-chain transaction, both allow you to operate the channel while the operation is underway — any important difference?

Lisa Neigut: Yeah so I think the biggest difference is when you do an on and off-chain swap, you’re not renegotiating this on-chain object that holds 15 Bitcoin, so in your off-chain swap, some other party has to have other Bitcoin that you’re using to push Bitcoin back and forth in the channel. So typically the way an on-chain or off-chain swap works is that fox would create a payment, so the payment would go from here to here, and then fox and frog (third party) would have a channel that you’d be able to pay them, so you’d be able to push a balance, so fox is gonna push 2 of their Bitcoin over to frog for whatever reason through the Bitcoin thing, so it’s frog and wolf now and let’s say that they had 1 and 10, and then after the payment gets put through then frog has 3 and wolf only has 7. So you would push a payment this way through the Lightning Network — so this is through the contracts — the contracts are getting updated, that’s off-chain contracts. And then when the frog receives this 2 Bitcoin, they would then create a new little on-chain transaction from some money that they have to have somewhere else. So frog would create a new off-chain thing that they would pay to fox, and now fox would get 2. So now the frog would create a new output on-chain on behalf of fox that has to get mined before it has any value. But I think what’s notable, at least the point I’m trying to make here with this little illustration, is that fox would now have a new object on-chain that’s worth 2 because they had pushed this money here, but then it’s like, Okay, where did frog get the money from? There was 10 Bitcoin locked up in this channel that frog has with wolf, and moving the money between the two parties doesn’t change this, so there’s still 10 Bitcoin here and there’s still 15 Bitcoin here. This extra 2 Bitcoin that this third party is paying to fox, they have to have sitting in some reserve somewhere. So the entire amount of money that is locked in the Lightning Network doesn’t change when you do a swap in or swap out. All that changes is that some extra money that’s not in Lightning gets distributed from a wallet that frog had somewhere else and now it belongs in fox’s wallet. So the cool thing about splicing is that you actually renegotiate dynamically the amount of money that is locked into a Lightning channel. So they both take on-chain things but the difference is that splicing offers you a lot more flexibility in terms of the total amount of Bitcoin locked in Lightning. I would say it makes it a lot more dynamic, so you can add more to a Lightning channel or pull money out of a Lightning channel depending on whether doing an on-chain payment or Lightning payment is more feasible at that time, so to speak. So it’s pretty cool. Does that answer your question Nicholas? Okay cool.

Lilit: There is one more question that I want to read on behalf of Cody. The question is: Is that swap atomic? It seems like you are trusting frog for the swap versus splicing the off-chain only happens if the on-chain goes through.

Lisa Neigut: Yeah, so the swaps are usually orchestrated — this is a bad example — but usually they’re orchestrated in a way [where] a real atomic swap is trustless and that this on-chain payment isn’t eligible to be claimed by fox. And in fact, actually I think this makes them a little more expensive than swaps because you need two on-chain transactions to make them trustless, I think. I’m not an expert at swap-like architecture, but my understanding is that swaps — and peerswap is a project that we’ve been working on at Blockstream to let you do on and off-chain swaps like this with your peer. So instead of routing through someone, you can just swap money off and on-chain with your peer, and it takes two transactions for those to actually go through, so they’re more expensive than a splice which only needs one on-chain transaction to be done trustlessly, because I think you need one which is like an intermediate state that creates outputs that can only be claimed in the case where the on-chain Lightning payment gets done successfully, and once the on-chain Lightning payment is done successfully you release information to fox which gives them the ability to claim their on-chain funds. But they’re not able to claim the on-chain funds until frog has verified that they’ve received the payment, basically. And that’s why they’re called swaps, because I hand you a piece of information in order to make this Lightning payment succeed, and then by handing you that piece of information I basically make it possible for you to claim the on-chain funds. So once I send that information to claim the payment on Lightning, you can take it and claim the payment on-chain, but most swaps that I’ve seen are two phases, so you need two transactions — you need one that locks it to the contract where frog can get their money back if the Lightning payment doesn’t go through, and then it also has a clause where if fox gets the information from frog which proves that frog got the payment then they can make another transaction to claim the funds for themselves. I forgot about that, but yeah so splicing is a lot lighter weight in terms of the on-chain transactions because you only need one. It gives you the ability to grow and shrink the total Lightning balance so it makes it a lot easier if you have a lot of Bitcoin that you want to keep in a channel. You can keep most of your Bitcoin in channels, and then if you get an opportunity, say, to lease Bitcoin to someone else or to make a payment to someone on-chain — let’s say it’s a big payment — and so it’s more economical to send a large payment on-chain versus through the Lightning Network. This is because on Lightning you pay per volume of payment whereas on Bitcoin you pay a flat fee rate for how big the transaction is — it doesn’t matter how much money you’re moving on-chain. So if you’re making a really big payment it’ll usually be more economical to pay it to make it go on-chain. Anyways, I’m getting into a lot of trade-offs between these different strategies, but that’s hopefully pretty interesting. So splicing is a lot more dynamic, it’s cheaper in terms of on-chain footprint as opposed to swaps, and it gives you a lot more flexibility with a limited amount of Bitcoin because it does let you move it into and out of channels now without totally shutting out the amount of ability to keep processing payments through those channels, so to speak. Thank you.