Cool. Okay, thanks everyone for coming. I think we're going to go ahead and get started. It's right at 11.02 on my time, so that hopefully more people will show up, but for everyone who's here, I want to make the best use of all of your time. Okay, great. So for those of you who aren't really sure what dual funding is, maybe you've heard people say that word before, but let me give you a kind of a quick overview.

I guess, of how opening a channel on Lightning works right now. Then we can talk really quickly about what dual funding channels is. And then I'll go ahead and get into the demo.

So right now on Lightning, so when you open a channel, this requires sending some messages, a series of messages between two nodes. So let's say we have node A, and it's talking to node B. Right now, just because of the way that the protocol is written, when you open a channel, node A decides they want to open a channel to node B. And when they do that, they will usually start this in c-Lightning, they'll do something we call a fund channel request. So node A will call Lightning CLI, they'll say fund channel, they'll give you node B's pubkey ID, which is like the identifier, and then they'll say how much money that they want to put in it, in the channel. And this is the command that you would run.

lightning-cli fundchannel NODE_Bs_PUBKEY_ID $$$

And then, so what's going to happen behind the scenes is node A is going to send a message to node B that is, hey, I want to open a channel to you. So they'll send an open channel message. Node B will decide, oh, that looks like a great opportunity for you to open a channel. I don't have any problem with that. So they'll send back something to node A called accept channel. Oops. Sorry. That's not what I thought. And then node B will send that back. Node B sends back accept channel. And then I forget exactly how this is because I haven't done it in a while. So node A will then be like, okay, great, with this info, this allows node A. So open channel and accept channel contain a lot of information. Once these have been exchanged, node A has enough information to know what the funding output script is.

What is this exactly? I guess this is more of a how are channels opened enlightening talk than how does it work exactly. The funding output script is what you need. This is what so node A is going to make a funding transaction that has, and basically this is a transaction with an output that pays to a two of two script. So that's what node A needs to produce. In order to know the two of two script, they need to know node B's funding pub key is what we call it. And that comes back in accept channel. So this includes some stuff, a bunch of channel parameters stuff for node B, but it also includes their funding pub key. And node A sends their funding pub key to node B and open channel. Like I said, there's a lot of other stuff in these messages. These are kind of just little packets of information that gets sent between nodes. Anyways, but after they've been exchanged, node A can go ahead and create the funding transaction. So they make a funding transaction on their own. They have their own, node A has their own inputs and outputs. One of which is the funding transaction output, which includes the funding output, which will create the channel. This funding output, once it gets mined, will create the channel. So the channel opening is basically when this funding output gets included into a block and is an output that then can be spent.

Okay, so once you have this funding output created, you need the funding output and the funding transaction ID really. So you really need the funding transaction ID, which you get from node A knows, because node A builds the funding transaction, right? So node A builds the funding transaction, which means that node A knows the funding transaction ID. And outnum, this is like really detailed, but that's fine. And outnum of the funding output. Then since node A knows these things, node A can now send, A can build something called a commitment transaction, which spends the funding output. Okay, cool. I should probably look at the spec to make sure I'm getting this exactly right. But basically, once node A can build a commitment transaction and knows the funding ID, it can build a funding commitment transaction. And then once it knows the commitment transaction, it can, since it knows the commitment transaction, it is able to create a commitment transaction signature. And that is what it sends to node B. So it sends to node B two things. It sends them the commitment transaction signature, and it sends them the funding transaction ID and output outnumber. Basically, this will let you, these things together, will let you identify the funding output when it gets published to the block. So you notice it's built the funding transaction, but it hasn't broadcast it yet. So then I should probably double check. At some point after that, then node B will send to node A. So they'll get back, this will come back. It'll send its commitment transaction signatures. At some point, it'll send those back. So it's come from node B, gets sent back. And then once node A has this commitment transaction signature, it checks that it actually fits the commitment transaction. So node A will then validate the commitment transaction signature that it got. And then once node A has a valid commitment transaction signature, basically what this means is this guarantees that node A can spend the funding output. So you wouldn't want to put money into a transaction and broadcast it. If you want to put money into a funding output, basically, right, since that's 2 of 2, you don't want to broadcast that to chain until you have the guarantee that you can get your money out of that. The guarantee that lets you get your money out of it is this commitment transaction.

Commitment transaction is basically, all that this is is a transaction that spends this funding output that you put in the funding transaction. So there's two transactions here. Two transactions, the funding transaction, which has a two of two output, and then a commitment transaction, which spends the two of two output. Right, so you don't wanna publish the funding transaction here until you have received a signed commitment transaction, which guarantees you can close the channel. Okay, cool, so this is all that happens. This is like all, why am I going into so much detail about this? This is the entire, this is what happens when you open a channel. This is basically the entire negotiation that needs to happen before the channel can be considered open. Once you have a successfully have gotten a commitment transaction from your peer, Node A can go ahead and then broadcast the funding transaction. And then after that, you're kind of just waiting. Both nodes wait. Both nodes are waiting, do, do, do, do, do, do, do, do, until for, they're waiting for the funding transaction to get mined. And then they're also waiting for that to, until it reaches a depth of like X. And this depth was negotiated as part of the open channel message that you sent originally. Okay, cool, so that's how the, that's basically how a channel opens right now.

Once both sides watch, so both sides like node A and node B watch the blockchain for the funding transaction ID that Node A sent. And then once they see them, so they'll like first they see it unconfirmed, and then they see it confirmed, and then they see it buried at X blocks. I think it's about still like six or three. I forget what the default is. But yeah, but you will basically, you want to make sure that that transaction is definitely in the block, and there's no chance it can get like reorged out. Right, okay, so once it's buried, then just to finalize it, Node A and B will tell each other, hey, they both send a new message to each other that's called funding locked. They send this, this gets sent as soon as this milestone is reached. You send a funding locked message to your peer. Once you both exchange, so that means I've sent and received a funding locked, which is confirmation that I've seen the funding transaction in my version of the blockchain reach whatever dots we've agreed on, let's say three. So I'll send my funding locked when that happens. And then Node B, like the other side, once they, on their version of the blockchain, once they've seen the funding transaction buried at the same number of blocks, three blocks, they'll send a funding locked. And then once both of us have exchanged a funding locked, this marks the end of the open channel process. Super exciting, okay, so open channel has ended. And then you move on to something that's called Normal Channel Operations.

Normal channel operations. All of this is outlined in the spec so I'm gonna see if I've got it open. Yes, so in the RFC there's a 02 peer protocol. This view of it is in the draft that I have for dual funding open so some of this won't look like the current thing but what we've just talked through is this right here, this section. So we talked about open channel when A tells B they want to open a channel. Accept channel is when B says back to A, okay that sounds great here's some info you'll need. Node A will make the funding transaction and will send the funding transaction ID and their commitment signatures over and this funding created so this is sent from A to B and then B sends back to A, okay great I've got your funding transaction ID I've built the commitment transaction and checked your signatures that looks good so now I'm sending you my signature for the commitment transaction for this funding transaction you've created. So B will send that back here and then at the end the new funding locked.

Great, okay so we've just learned how the original and current channel establishment protocol works. Once it's done it goes down to this section so this is what I meant like once it's finished you move to normal operation and then you've got a whole different series of messages that happen. Okay cool so that's how it works right now.

So what does dual funding change? What we're moving from this is the original or the current operation. Dual funding adds or makes the changes the protocol a decent amount. And so the goal of dual funding is to allow node B to also contribute inputs to the funding transaction. Okay cool so you'll notice on the whole protocol that we just walked through we just talked our way through the only person that built the funding transaction when did the funding transaction got made it got made after node A received an accept channel they went and just created whatever funding transaction that they wanted to with the only requirement is that the funding transaction included this one output that had a two of two scripts that's basically the channel script.

So node A is allowed to create any transaction that it wants that transaction just the only requirement is that it includes an output to this two of two script and that's basically the opening of the channel the channel that's basically represents the channel and once I get mine and channels open. Okay so node A can do whatever they want.

Cool so what we want to be able to allow is we want to allow node B to coordinate with node A to create this funding transaction. So in order to do that we change the protocol a good bit so now instead so the old way node A would send the funding transaction ID and the funding output index which you need both of these right to identify an output to spend you need the transaction ID and then which output it is on that transaction. So old node A used to just create this funding transaction they wouldn't broadcast it this is important you can't broadcast it to get a commitment transaction back. So they would just tell node B hey here's what the funding transaction ID is going to be and this is what the output will be and then node B would just say okay great here's some commitment transaction info you need so that you can you can spend it if you need to. The new way is that instead of doing that now we're going to collaboratively build a transaction together. So this means that we no longer need to send a transaction ID and funding output and output because instead no more this now yes send every input and output to peer. Okay so as you can see it's gotten a little more complicated there's more information we need to share between two peers but the upside of this is that you get more interesting and complex transactions and when your channel opens it's more likely or there's a possibility for opening channels where both sides have a balance at the beginning. Okay so I don't know if I want to talk to you how we accomplish this yeah sure whatever okay so it changes open channels basically the same it's just been renamed to open channel 2, very clever. So there's still a node that decides they want to open it we call it the opener so node A is now known as the opener but I'll keep calling them node A because that's easy. So they still send like open channel over to the peer and then and then you still get back something, haha, you guess what you get back you get an accept channel 2 back from node B we'll send that back. Now node B another name for node B is also known as we call them the acceptor because there's a peer in the channel that's sending back the accept channel which makes sense. Okay and so now instead. It used to be node A would build the funding transaction now instead they start sending over their inputs and outputs and node B will either respond with their own input that they want to do so this part of the protocol I call this the interactive transaction construction.

We call this the interactive transaction instruction part of the protocol. And so basically nodes will take turns answering messages back and forth from each other. Node A is the opener. They're responsible for always adding the output that is this one in this example would be the funding output. So this will be that two-of-two script, right? That opens the channel. And then, you know, let's see, let's say B's if B is adding an input, let's say they're adding an input for like 0.05 BTC. They're adding an input also for 0.05 BTC. Then this is like, so this is node A, this is node B. Node B is gonna wanna send back a change output probably, right? This is change output. And then node A is also probably gonna want their change output.

So this transaction will have like three outputs on it and two inputs. And then once, once the site is finished, they'll say something called add or I think I probably, I think I might've read dummies. I think these are actually, sorry (fixes typos...). So then you do TX complete. So this is basically signaling, hey, I'm done. So Node B's done adding things. Maybe node A realizes they need to add another input that's got money for fees on it. So then B is gonna keep responding, hey, I'm done. A decides they wanna change, update their change output cause they had to add more money for fees. So they're gonna remove an input, remove change output. I know that's it. Sorry, this is a, they're gonna remove the output and then they're gonna re-add it. Sorry, I'm going into a lot of detail here, but hopefully this is interesting. So then they re-add their output. They put their change output back. So A's change output, A has money for fees. This is A's change output. This is B's. This is A added funding transaction, B added, A added. Okay, so then you talk back and forth, like, hey, here's all this stuff. You know, B's done. So they're just responding every time they say, hey, we're done. And then Node A is also done. So they'll do TX complete. And then once you get two of these in a row, that's when this kind of transaction construction part of the protocol is considered ended. So end that section. So now we move on to the next part of the, what do you call it?

Next part of the funding transaction stuff, which if you recall from the first version of things was just exchanging commitment transactions, right? So both sides should now be able to build the funding transaction. So they should be able to figure out what the, so now node A is gonna build the transaction that was communicated via the above. So they're gonna build a transaction that was communicated. They're gonna figure out what the TXID and output are for the funding output, right? They're gonna build a commitment transaction for that output that spends that output. And then they're going to send node B their commitment transaction signatures. Okay, so the next thing that node A will send to node B is going to send a commitment transaction signatures. I forget what this is called. But they basically send their commitment transaction signatures to B and then B should be able to reply with their commitment signatures. Of course, B checks to make sure that A has given them the right thing. And then they send node A their commitment signatures.

So now we've got kind of a little bit of a departure. Once you've both got the commitment signatures that you need. Yeah, once node A had sent the commitment signatures, then they send their transaction signatures. A will send the transaction signatures. These are the signatures for the funding transaction. So these were the signatures for the commitment transaction. Cool, and then node B will respond back with this A, also with theirs. Once those have been exchanged, then you broadcast the funding transaction.

And then you basically are back to the same place you were with the... Back to the, what do you call it? Back to kind of the original opening thing where you're waiting for the funding transaction to get mined. And then once it's been buried, let's say 3 blocks, then you both exchange node A or B or whoever sees it first will send A. B will send the funding_locked. Funding locked. And so that's kind of like we're waiting just to exchange that. And then once that's done, we're done. We move over to normal channel operations.

Let me check really fast to make sure I got the names of these right. Tx complete, Tx signatures. So that Tx signatures message is actually considered part of the interactive transaction construction. Though as you'll notice, there's kind of the negotiation section and then we do some other stuff and then we go back and send the transaction signatures. That's because funding transactions are really special. You wanna make sure that you definitely have signatures for the commitment transaction before you broadcast or make the funding transaction broadcastable. So it's a little bit more stout. And then, oh it's commitment signed is what it's called. Okay, and then this is yeah, transaction signatures is the same as this one. Okay, cool. So that's basically, so this is, this message here is, I know I, sorry. Sorry, I just wanted to, whatever, okay, these are the same. (fixes typoes..)

Okay, cool. So that's basically overview what happens. Okay, great. So let's watch, let's make this happen. Okay. Cool, so the latest version of C Lightning, the one that will be shipping this whatever, this is all implemented, which is very exciting. Make sure it's made. I just tested this, so hopefully everything's fine. Okay, great. Okay, so for this example, basically all I'm gonna do is I'm gonna open a channel and both channels are gonna put money into the opening funding transaction, which will be very exciting. Basically, I gotta do a couple things in order to put C Lightning into the, what do you call it? The mode where it can use dual funding as a protocol, so the secondary protocol. When you start the node, so normally when you start lightningd, you do stuff like daemon, you pass in config options. So you need to pass a config option to tell your lightningd to enable this protocol. Since it's experimental, we put it behind a flag. It's called experimental dual fund. Okay, so I'm not gonna do that. I'm actually gonna use this kind of nice script that I like a lot that lets me run local regtest connected nodes so I can test stuff out on the command line pretty quickly. I find it's really helpful for prototyping stuff or if I need to write a test, but I'm not really sure exactly what to test, I can run through a couple things locally.

So that's in contrib startup. Regtest, it's this guy, it's a nice little script. There's one thing to note about this script is that it's kind of hard. There's not an easy way right now to add additional configuration options to the nodes that it starts, so I've like hard coded this thing in. I might try and see if I can get this in for this release or I'll put up a patch. So if you wanna play with it and it's easy, it'll be here. But basically, so I'm gonna source it. So this will make, add it to my command line stuff. It's got a couple aliases, so you need to make sure you source the script into your bash environment so you get all the fancy stuff. So start, I think it's start_ln, I just forget. Start, yeah. So I'm gonna start up, let's start up three nodes, sure. Okay, so it gives me three nodes, these are how I can kind of access them. And then it also gives me like a local Bitcoin regtest thing.

So to start, I'm gonna need to send L1 some funds. So if I list funds, it should be empty. Okay, good. So in order to like do, in order to do, what do you call it? In order to do dual funding, you have to have funds to put into a channel. So I'm gonna need to add funds to both L1 and L2, these are like L1. So I do that, we need to get a new address and then I need BTCLI to send address. Let's send it a Bitcoin. So I'm gonna do the same thing with L2 now. So this is an L2 address, cause I typed in L2. And then BTCLI is basically a local regtest Bitcoin. Yeah, I'll send them a Bitcoin, so if it is a Bitcoin, I need to mine it into a block. It is earlier, so I'm gonna cheat and you generate, no. It's not working, okay, fine. I'm really weird about this. I really don't like sending generating blocks to lightning nodes because they have coin bases. So you can't, any money you use generate CLI to send to a lightning node, you can't use for a hundred blocks and that just like kind of annoys me. So when I generate to stuff, I always generate to a address on the Bitcoin wallet. I don't know, you don't have to do this, whatever. Get new address. So I do generate address. I just have to do one.

Okay, so now there should be money in the thing, great. And then so both of these guys have money. Cool, okay, and it's all confirmed. So the guys both have a Bitcoin that we just sent them. That's awesome, cool, looks good. Okay, so now we want to open a channel. Oh, wait, there's one more thing we have to do. If I try to open a channel right now, even though both of these are running the dual funded protocol, well, I guess I'll show you what happens. The second node is not going to contribute funds. And the reason for that is that you need to add an additional plugin to your nodes so that it adds money to any inbound requests. Right now it just like any, it treats any normal, right now it treats any inbound request as like a normal inbound request and doesn't put funds into it. I haven't. I'm in the process of writing a quick little plugin that you can turn on and set some parameters as to when you want to add money to a node and at like what rate. So that's kind of like work in progress. But for now I have some test code that will do exactly the same thing for this demo. So I'm going to add, so if you're not familiar

If you're not familiar with C-Lightning plugin architecture, there's some really great info in Docs plugin. Basically, this is a whole way of adding extra functionality to C-Lightning. So part of the dual funding flow in C-lightning uses for the acceptor side of it has a whole kind of workflow that it goes through on the opposite side of those signing things and whatnot that allows your, whatever you call it, sorry, that allows your acceptor node to respond to these open channel requests, basically based on the policy that you've set up. So I'm going to be using the very a hacky, I don't know if it's not hacky, I mean, it's fine, something called DF acceptor. Basically, this implements all of the hooks that you need when a open channel request comes in and does cleanup and stuff if it disappears and whatnot. OK, cool.

So what I need to do in order to make this work is I need to add it to the node that's going to be the acceptor, and that's going to be L2. So I'm going to just say, plug-in start. This is in test plugins. L2 CLI plug-in start. Test plug-in CF acceptor. OK. Cool. And so you see it lists all the plugins that are currently active. So it's on. OK, cool. So that's all the setup. All that we've done so far is we've put money into two, we created two new nodes, Lightning nodes. We've added money to their wallets, and then we've turned on a plug-in for one of them, the DF acceptor one. OK, so now we're going to open a channel. Woo-hoo, this is so exciting. Except first I have to connect, so I need to get info out of this guy. Oh, OK, so now you can see the whole thing. Connect to that guy. Localhost. Localhost 7272. That's right. That looks right. OK, so now they're connected, so first step to opening a channel is connecting. OK, so now I'm going to connect to the channel. Opening channels, connecting. OK, so now this should just work, hopefully. I'm going to put in 0.08, because that's the, what do you call it? The way that the, so I know that the acceptor plug-in is hardwired to match whatever you can up to the limit. Actually, I'll do this. It might be more fun.

So the current max channel capacity, if you haven't enabled Wumbo, which lets you do bigger channels, is 0.16 Bitcoin. So this would be like the max. If I, as the funder, attempt to put in the max, I know the acceptor won't add any, because there won't be an extra space for them to add any money to the channel. It'll be at the max capacity already. So I'm going to put it down a little bit, so we give our peers an opportunity to put money in if they want to. And then, just because this is on regtest, I usually put in a very, very low fee rate. Don't do this, I already... Okay, this is... No. Oh, no. Yeah. No, it's dying. Why is it dying? Method, open channel, connect. Oh, this is embarrassing. Hang on, I can't read this. You gave bad parameters. It's too large. Oh, okay, never mind. It's not as smart as I thought. Okay. Just kidding. Someone needs to fix that plugin, basically. Is this going to work? Ah-ha! No! I got to connect. Okay, sorry. This is what you get for deviating from your practice scopes. Okay. Okay, it worked.

The reason it wasn't working was exactly the reason that I said that the plugin could do, but clearly it can't. It tried to match the 0.1 that I added up here, and it was like... So, it's trying to put 0.2 in, and the whole thing was falling apart, because they're like, you can't create a channel that big. It's over the limit. Okay, so I put it back down to half the channel capacity. And so, the peer matched my channel capacity, which is why it looks good. Yeah, so when I do say list peers... So, you'll see that it's awaiting lock-in. That means that we're still waiting for the channel to... We've produced the funding transaction, we've exchanged commitment transaction signatures. At the point now, we're waiting for it to be broadcast and then mined. So, we're waiting for the lock-in. So, basically, your node is waiting until the blockchain includes the funding transaction, and it's been confirmed up to like, however many times, three times, or whatever.

Okay, cool, but check this out. This funding allocation msat, it has got 0.08 Bitcoin for each side. So, this means that we were successful. The other side of it actually contributed funds to it, which is super exciting. Notice how big this transaction is. This is going to be nasty. Okay, so we can use BTCLI to decode transactions. Which is cool. So, we can see that it's got two transaction inputs. One of them is ours, ostensibly, the other one is from the peers. So, one of these L1s, like the first nodes, and one of these is node B's. They've managed to successfully exchange their signatures with each other. And they've produced a transaction that's got, like we said, three outputs. This is the funding transaction output. No, this is the funding output, I'm sorry. This output creates the channel. You'll notice that it's got a longer address than these guys, or rather that the type is a script hash. That's because channels are locked to two of two multisignatures. So, yeah, so this is our funding output that creates the channel. And then these are the change outputs for each of these.

This is kind of cool. You'll notice that both of them, so we both started, both of our nodes started with one Bitcoin each, right? They put out 0.8 to here, so you can neatly see that 0.8 is missing. But then there's also some amount of money that's been paid for fees. One of these nodes has been paid more for fees than the other. I can tell that this one is the, so this one would be the acceptors output, change output. I know that because they paid less in fees than the opener. The opener, so like who pays fees on this opening transaction, right? Okay, so right now when you, as you can imagine, when you open a transaction, the person who opens it pays for the funding transaction. Which is the only thing that makes sense because they're the ones who build it, right? So they build it, they pay for it, they broadcast it. It's all their deal. Now, since we do it together, each peer pays for the inputs and outputs that they put into the transaction. So the acceptor side of it paid for this output and for whichever output that they, whichever other of these inputs, they paid for one input and one output.

The person that opened the channel pays for one input, one output. They also pay for the funding output. So the opener paid for this output in particular. So that's why their funds are like, their fee is a little more than the other person. Okay, cool. Yeah, and then I guess we can mine a block. Let's mine like what, like three blocks? And then... Oh yeah, okay. So that mining it moved it from awaiting lock-in, so it's now in CHANNELD_NORMAL, which means this channel is now open and ready to be used. Cool, yeah, state is it normal.

So mining the transaction or basically broadcasting three blocks moves the chain forward far enough so that the funding is available. Forward far enough so that the funding locked messages would get exchanged. And now you're basically back to where you would with any other normal channel. Okay, I've done a lot of talking. Are there any questions that anyone wants to ask about any of this?

MG asked, are there any backup channel security differences with a funded channel versus a normal channel? The answer is no. The channel is exactly the same. So the backup, so like backups in Lightning, so backups in Lightning, what data needs to be backed up? Backed up in Lightning, I think is kind of the real question that you're asking, right? Is any of that data related to the open channel process? The answer is, the answer is the only, so the data that you need to keep track of are the commitment transactions. And the commitment transactions have not been changed at all for the opening by moving, by changing the opening protocol. In fact, the commitment transaction is exactly the same, no matter which of these protocols you use to open a channel with. Your data backup requirements are unchanged, and in fact, are identical, because you still need the commitment transaction data.

It looks like someone else is typing a question. No, just a thanks, okay. Let's see, what else? What else, what else can I tell you about? Yeah, what else would be interesting to know? Splicing, oh, that's a great question. Okay, so Adam wants to know about splicing. So the cool thing about, the cool thing about this open transaction thing is that so that they go back up to this long thing, this interactive transaction construction, basically, you can reuse this for building a, so now that we have a protocol for building a transaction between two nodes, you can use this, there's two places that we wanna use it. The next place that we wanna use it is for closing a transaction.

So this would basically mean, so what would that mean? Right now when you close a close a channel. Another way of explaining what happens when you close a channel is you spend the funding output, right, that was created in the funding transaction. So it would be cool if when you, so right now the transaction that you use to spend the funding output is canned. Sorry, this isn't slicing, but we'll get there, I promise. Okay, so right now when you spend the funding transaction, you use like a close command on C-Lightning. And this is a, I'm gonna call it a canned transaction format so that you can't really change what goes into that transaction.

We can take the interactive transaction protocol and we can update the closing channel, what do you call it? Update the closing channel protocol to use this, to take advantage of this. So instead of having a canned transaction format, you would have a, you could basically, a closing transaction could be anything. Even another funding transaction, which basically gets you splicing, right? That is basically, that is basically splicing. There's a little more nuance around splicing. There's a little bit more nuance around the splicing question and that basically, so this is definitely like kind of what you want to happen for a splice, right? You're gonna spend the previous funding transaction and you're gonna spend, not funding transaction, you're gonna spend the previous funding output in a transaction and that transaction is also going to recreate a new, is going to create a new output that, it's gonna create a new output that allows the channel to continue. So there's like, basically the only question then is, first of all, for this whole process is, are you still allowing like payments to move through the channel while you're waiting for this closing funding transaction hybrid that you've built to get mined and buried, right?

So that's like 30 to 60 minutes or whatever, maybe it takes longer. So are you still allowing payments to move through the channel is kind of the big question around like how splicing works exactly. This is possible, it's possible, but it requires, it might require a little bit of, probably gonna result in more commitment transactions. So basically you could, one way that you could do this, again, we haven't exactly figured out what the protocol is exactly. Christian Decker has some good ideas, has had some really good ideas on the mailing list in the past about how this would work.

The commitment transaction, so basically you would need for every splicing command, so for every splice that's currently in flight and hasn't been locked in yet, right? So this kind of goes back to when you're opening a channel, you have to wait until a lock-in happens before you start sending funds through it. So until funds, so until lock-in happens, you basically need two copies of two commitment transactions, two commitment transactions for every in-flight splice. One of these is for the old funding output, and one would be for the new, not yet confirmed, buried output.

So basically you would need your commitment transaction, whenever you exchange commitment transactions, you would need to change the message format so you could send more than one commitment transaction. So there's a little bit more paperwork involved, so to speak, with splicing, but I think that encompasses much of it. So yeah, this is a very big step towards, this is a huge step towards splicing, right? Because we're basically halfway there, or kind of over halfway there. Cool. I've got about ten more minutes if there's any more questions. Be happy to answer. What is up with portals? That is a great question. So we've decided to punt on portals. PUNTing on PoDLEs. The reason is that Lord Lloyd Fournier wrote a really great post to the mailing list that basically gave a good explanation of why the exposure of your...

But OK, so what is a portal for those of you who aren't familiar? A PoDLE is basically a proof of discrete log equivalence. Basically, this is a way of making a channel opener prove that their UTXOs sent in tx_add input are valid and exist and that they haven't used them elsewhere, sort of. And you kind of prove that you haven't used them elsewhere. The point is that you're trying to keep a node on the network from attempting to probe other. PoDLEs are kind of a information leakage defense. The goal is to keep it. Because so right now, since anyone can ask you to open a channel with them, you send them your UTXO set or a portion of your UTXO set. When you send them tx_add input, tx_add input includes spendable UTXOs. And the fear is that this will allow people to track your UTXO set.

Lloyd Fournier actually had a really good response as to why this isn't something that you need to worry about so much. I need to go back and look at it. But the general idea is that your UTXOs are going to become public in short order anyway if you're actually looking to spend them into channels. And by opening a channel, you're kind of sort of giving away who your UTXO set is anyway. I'm totally bashing. I'm totally messing up what the explanation was. But let me see. Oops. Pulling up the page. Yeah. So basically, based on what Lloyd kind of came up with back in January, here I'll paste the link in the chat so you can look at it. The general idea is we generally decided that we could wait on PoDLEs until it either became a big problem and then we have a solution that we could use. So PoDLEs are definitely something we can implement to implement to drive down the number of these probing attacks and their efficacy. But it was a lot to do for just starting out, so to speak. Is it done? So they haven't gone anywhere. It's just been made not a priority for first getting the protocol out and ready.

Yeah. Great. OK. I have about five minutes. Are there plans are doing something to construct more interesting commitment transactions? No, I don't think so. Not that I know of. I have not heard of any. So the question is, are there plans for doing something like interactive transaction construction to construct more interesting commitment transactions? As far as I know, the answer is no. I don't think you want. So the thing with commitment transactions is that they are a worst case scenario. So you can't just do something like a contract. The thing with commitment transactions is that they are a worst case scenario. You do not want to publish a commitment transaction to chain. They're expensive. There's a good chance that you will pay more fees than you wanted to on it. If there are any payments in flight at the time that it goes to chain, it's expensive to get them out because you have to pay on-chain fees for every HTLC. If the HTLC wasn't big enough to cover its, what do you call it? If it wasn't higher than dust limit or whatever, you've like basically lost those funds. Like commitment transactions are very expensive. And like I said, they're kind of like worst case scenario. You really only use a commitment transaction. A commitment transaction only hits the chain. In the case that you and your peer are unable to agree on a mutual closing transaction or your peers disappeared entirely. So like publishing commitment transaction is really... Or you've got like a payment you need to pull out and your peers are unresponsive. So I guess that's basically a subcategory of your peers unresponsive. So making commitment transactions more complicated or more interesting or putting more different useful stuff in them is like not what you want to be doing at all.

The closing transaction, the interactive closing transaction protocol that I was talking about is what you would want really. So doing more interesting closing transactions, like I was saying is kind of like a pre-step to the final slicing, like final form. That is actually kind of where you'd want to put that effort and not into making transactions any more complicated than they currently are. Cool.

Okay, I have time for like one more question if anyone's got one.

Daniel, did you have any last thoughts or anything?

Daniel: All good on my side. I think Calle is typing a question.

Lisa: Okay. I think there's a recording. So maybe Daniel can post the recording link again just to round things off. Oh, yeah. So I guess maybe just like going forward, like I said, the final this 10.0 or .10 release of C Lightning should be available end of this week or early next at the very latest. So it's currently in RC1. It's currently in RC1. So if you want to check out RC1 and give it a try, you can. The stuff that I showed with the little command line flag just got merged into master today. So you'd need to check out master if you wanted to look at that or whatever or like to use that because that's a great way to do it. Yeah, and if you've got any questions or comments or you want to – oh, I should post the link for the RFC thing in the chat also. So let me do that really fast. This is the wrong one. But if you want to take a look at the dual funding proposal, it is up and available on the Internet at this link that I am in the process of posting. Cool. Thanks for everyone's time.