I'm gonna basically kind of go over ways that I've been thinking about, basically like hardening Lightning in terms of basically making security better, you know, making the client more scalable itself, and then addressing some issues and pain points that come up at times when you're dealing with like fees on mainnet, and there's gonna be some, you know, changes I'm gonna propose to Bitcoin, but in my opinion they're like relatively minor, so I can maybe see a pretty good chance of them getting in. There aren't like really big sweeping changes, one's a new sighash type, and one is a new opcode, and then there's covenants, but that's like a whole nother story in itself though, right?

Yeah, so a quick overview first. I'm gonna give an overview of the Lightning security model. I won't really go into, you know, mechanics of Lightning itself as is now, because I kind of assume people know what that is vaguely. You have payment channels, you connect them, you can route across them, and that's like the gist of it. I'm gonna talk about a little bit about kind of like hardening the contract breach events. So some people talk about ways you can do that in terms of like adding more consensus changes, when we're going at it from a point of view of just kind of like, you know, doing a different strategy when a breach actually happens in the face of like a large backlog, then I'll go into like a new channel type, a new channel design, for basically making the channels more succinct, meaning you have to store less history, and also, you know, things like outsourcing get a lot more efficient as well. Then I'm gonna talk about kind of like outsourcing and kind of like a newer model, and a model that, you know, assumes, has basically minimized the client state as much as possible, because if you want this to actually scale and the outsourcers to, you know, basically support a large number of clients, then we basically want them to store as much, you know, a little state as possible itself. Then we're gonna go into basically, you know, making a Lightning a little more succinct on chain, because, you know, if it's off chain protocol, you want to basically ensure that we have the smallest footprint on chain as possible, right? Otherwise, you know, it's not really scaling, because you're hitting the chain every single time, so it's gonna be off chain itself.

All right, so first, security model. So like, you know, there's this little kind of like layers of Lightning over here. People always say it's like layer two, but to me, there's like, you know, a lot more layers on top of that, right? So for me, layer one is basically the blockchain itself, you know, Bitcoin or whatever else that is. Layer two is actually just like the link layer between channels, right? So this is basically, how do I open channel between, you know, me and Bob, and how do you, you know, how do Bob and I actually update that channel? Layer three is kind of like the end to end routing, so like, you know, HTLCs and like, you know, end routing, whatever else that is. Then layer four is kind of like the application layer. We're actually like building, you know, building on top of lightning, things like, you know, exchanges and whatever.

I have emojis there, but I guess it didn't translate somehow. That's okay.

So basically, the way Lightning works, it basically uses Bitcoin as, or, you know, whatever else, probably Bitcoin, is basically like a dispute mediation system, right? So rather than like every single transaction going on Bitcoin itself, we basically say, all right, you know, we do contract creation on Bitcoin itself, and we do, you know, enforcement, but the execution is actually off chain, right? So, you know, we do the creation initially, then we do all the execution on the side, and that makes it really succinct, and that's fine. And basically what we do, we basically treat, you know, the chain is like, in this like trust anchor, right? So basically the way it works is that any time we have a dispute, we basically go to the blockchain with our evidence, and with that evidence, we can basically say that, hey, you know, Bob was cheating me, he violated clause number five in the contract, and then I get all the money back, basically, right?

And, you know, basically the way it is, we kind of have like the easy way or the hard way, optimistically, we can basically just do everything off chain, or if we actually want to exit the contract, then we kind of just do like signatures between each other, and boom, it goes on chain, everything's fine. The hard way is basically in the case that I have to go on chain, and either, you know, sweep contracts myself, or possibly go on chain to, you know, actually do like a property dispute, because you violated something in the contract itself. And, you know, when we're handling disputes, we basically say that we can write the chain eventually, but eventually this is basically configured by, you know, a time parameter called T, which is like a CSV value, right? Which means that any time someone goes to chain, there's basically like a contestation period, and I have up until time T to basically refute their claim, right? And we say eventually because T can be configured, you basically want to configure T based on like the size of the channel. If it's a $10 channel, maybe you want like a few hours, if it's a million dollars, maybe you want like, you know, a month or whatever else, right?

And the other thing we assume as well is that, you know, we're assuming that like miners or pool operators aren't colluding against us, basically, because otherwise they can basically just censor all our transactions on chain, right? So, and we also assume like a level of decentralization of mining, because otherwise, you know, so you can get blacklisted, but, you know, there are ways where you can try to make the channels basically blend in with everything else, you know, in the network, and there's some really cool work on that front too itself.

So, but yeah. All right, moving on. Now talking about a little bit about contract breach defense strategy, right? So something that comes up a lot is basically people are, you know, asking like, all right, how do I handle a contract breach in the case of basically like massive backlog, right? This is the case where maybe, you know, for whatever reason, like fees are sky high, someone's spamming the chain, and then someone tries to actually do a contract breach. What am I gonna do from there on, right? So, you know, there's some things that people worked on in terms of like adding new consensus changes to Bitcoin, maybe something like, you know, the time lock would stop after the blocks were so full, or possibly like, you know, you'd have some kind of like a preallocated like arena where you can kind of like, you know, do battle for your smart contracts. This is basically looking from a little more strategic standpoint, and looking at basically the dynamics on the fees of the way we actually handle the commit transaction itself, right?

So whenever someone tries to broadcast a prior state, maybe I should have this out of order, that's okay, they're basically locked into that particular state, right? So, you know, Bob basically had $2 on the new state, and he had 10 on the other state so we're gonna go back to the $10 state, right? At that point, Bob can only access just his money from the channel itself, right? But me, myself, because he actually revoked all those outputs, I have a little more wiggle room. So what I can do is basically, I can progressively start to siphon Bob's fees, basically into miners fees, right? So this is now a situation where it's kind of like, you know, some strategy there, because Bob basically has two options. He can basically stop, or I can keep going, and I'm gonna eventually siphon all his money into miners fees, right? The only way his will actually succeed, basically getting that prior transaction into the chain, is if he pays more in miners fees than actually in his balance himself, right? And he can either do that by using pay per parent, well, that's the only option really, right? So I think this is a pretty good, you know, kind of intermediate approach, and basically what we're doing here is that like, the justice transaction is gonna be using a replace by fee, we're gonna use that to progressively bump up and siphon the fees, you know, the money of the cheater, basically into fees. And I think it's a pretty good, you know, stopgap in terms of the way things work right now, that if you have someone that can be vigilant at all, you can basically almost always penalize this person, right? So even if there's a massive backlog, assuming the miner wants the package with a higher fee rate, then, well, you know, Bob basically gets nothing, right? So now this basically adds even further incentive from actually people trying to do cheating, because now there's this kind of, you know, kind of like strategy where basically I can just pull your money to miners fees and you get nothing. And, you know, I'm still made whole this entire time. So whenever this happens, I'm okay, I wanna punish Bob, right? This is me punishing him in the worst way possible, and I'm gonna basically jump to the queue, front of the queue for everything else in the, you know, in the mempool, right? So like I could have put maybe like 20 BTC towards fees, and I'm fine, I'm just punishing him. So basically scorched earth, and I basically wipe my hands, I walk away, and everything's okay.

All right, so now we're gonna talk about basically kind of like scaling lightning itself, right? You know, basically from the client side of it, right? So basically the way it works is that because contract execution is local, we kind of have like a local transcript, right? And every single time we do a new state update, there's kind of like a shadow chain, right? By shadow chain, I basically mean that we have like, it's kind of like a blockchain itself, because the states refer to each other in a particular way, but also we can basically do state transitions between these states themselves, right? And you know, the shadow chain is only ever like manifested on chain in the case of basically like a contract breach or if I just wanna force close, right? Typically in the normal case, we basically do a regular cooperative close, which means, you know, we both sign the multisig, we go on chain, you see nothing else, right? So the shadow chain is only manifested in the case of a breakdown or some type of breach remedy thing, right?

And you know, these state transitions we have in the channel, you know, they can be super generic, you know, probably like later this year, we may get even fancier with some cooler stuff. Right now it's basically just adding new HTLCs, removing HTLCs, and basically keeping track of that prior state itself. So the goal here is basically to reduce the amount of state that the client needs to keep track of. This can be good because if they can keep track of less state, they can basically, you know, have kind of like more high throughput changes, but also it has implications for the outsourcer, as I'll get into a little bit later, right? If the state required for the client to actually, you know, act on the contract is reduced, and that makes the outsourcer more succinct as well, and if the outsourcers are succinct, then people are gonna rent them, and if people are gonna rent them, we have more security, so it's kind of like, you know, like a laudable goal to actually go forward.

So first, before we get into this, we're gonna talk a little bit about the history of basically how you do commitment and validation on Lightning, right? So I was talking about basically that you have a series of states, and you basically walk forward in these states one by one, right? Every single time we go towards a new state, we basically revoke the old one, right? So that's like state sequence, we were on state number one, revoked it, state number two, revoked it, now we're on state number three, right? So like, you know, a central question, basically the way we do channels, basically how do you do invalidation? One thing to note is that this only matters for bidirectional channels, when you're basically going both ways, right? If it's a unidirectional channel, every single state update I do is basically benefiting the other participant in some way, so they don't really have an incentive to go back on the prior states. But if I'm in a bidirectional channel, there's likely some point in history where we are currently, in which the other participant was better off. So they have some incentive to basically try to cheat me and try to go back to that prior state, but we solve this basically by invalidating every single state once we make a new one, right. And the penalty here is that if I ever catch you, it's in the contract, if I ever catch you broadcasting a prior state, you basically get slashed, which means your money all goes away and that kind of has some strategy in that other thing itself, right. So naively, you basically keep all the prior states, right? But that's not very good because now you have this linearly growing storage as you're gonna do these updates, right. People like lightning and different off chain protocols because they can be super fast, but if you have to store a new state for every single update, then that's not very good, right? And the other thing here is that you can kind of like, say you can close it, you can go to the bucket and close it out to basically reset the prior state, but then that's not very good because now you have all these control transactions on the chain which aren't necessary, we wanna make everything succinct itself.

So first, going back, you know, in the history, basically how we currently do commitment and validation, right, so when, you know, channels first came across, when the first bidirectional channels, initially it was like a BIP68 mechanism, right? What that means is that like BIP68 is kind of this like relative time lock thing, so we started out at like 30 days, right? Then we do an update, now it goes to 29. We do an update, that goes to 28. And basically the way this enforces the latest state is that you can only broadcast the latest state using the time locks, right? If you had state 30, then I'm gonna broadcast 28 before you can actually broadcast that, the time lock hasn't gonna be expired yet, right? The drawback on this one is that like, this has a limited number of updates, right? So we can only actually do, you know, 29 updates, or 30 updates, or 50 updates, or whatever else, we have to be able to lock that into the, you know, lifetime of the channel going on.

Then some people, you know, Decker, some other people made this thing called the invalidation tree, right? The thing with the invalidation tree is that you kept this, you know, decrementing time lock thing, then you added like another layer on top of this, which is basically a tree layer, right? And because of the way the time locks work, you can only ever broadcast the, you know, you can't broadcast the leaf before you can broadcast the root itself, right? So basically, and also because they were bidirectional channels, they had to basically reset every now and then. They were constructed basically of two unidirectional channels, and when the balances get out of whack, we basically have to reset that, and every time we reset that, we have to decrement the time lock, and every time we decrement the time lock, we have to measure this root thing, and that worked out pretty well, because that could let you, you know, with a tweak called the kickoff transaction, that could let you basically have an indefinite lifetime channel, which is pretty cool, but the drawback of that is basically you have this additional off chain footprint, right? So if you have this like, you know, massive tree that you need to broadcast to basically get to your certain state, now it's not very succinct, because you have to broadcast that entire state, and we want to, you know, make it even more, you know, make the state a little more succinct, and then kind of what we do now, we basically use this commitment verification thing, right? So basically the way it works is that every single state has like a public key, and when we go to the next state, you basically must give up that private key to that, you know, it's a little more complicated than that, that's how it works more or less, and the cool part about this is that like, we figured out this way to basically generate the public keys in a deterministic way, so what can happen here, like me as the client, I have a constant tied state, and I can basically do this kind of like tree type, you know, choose random number generator thing to basically generate all these different secrets, and you as the receiver, you can collapse these down into the particular state themselves, right?

So the goal here is basically to develop a commitment that actually has symmetric state, right? So one thing about commit revocations now in Lightning, that the state is actually asymmetric, right? And this is basically due to the way we ascribe blame, like, you know, I know what my transaction looks like, and you know what yours looks like, so therefore if you broadcast it on chain, I have what I need, but that can get worrying in terms of like multi party channels, which are pretty cool, so if we can make them symmetric, multi party channels won't have like this like weird, you know, kind of combinatoric state blow up, and also we can basically make all the state, you know, much smaller itself.

So here's a review of basically the way we do, you know, revocation right now in Lightning, well I put 1.1, we're on 1.0, I don't know, I guess I was thinking ahead basically. So basically the way it works is that every single state has this thing called, we call it commitment point, right? Commitment point itself is just like, you know, an EC base point, right? And the way we develop the private, actually derive the private keys for each of these points is a thing called shachain, right? So shachain, you can think of it, you basically have a key k, and you have an index i, it's gonna give you like this random element an i, right? And me as the receiver, because it has like this particular structure, I can collapse them, and anytime I have, you know, shachain element number 10, I can forget everything else, because I can rederive everything else from shachain 10 more or less, right?

So, you know, we do this key derivation, which is like, you know, kind of complex, but the important takeaway here is that when we do the state update, basically, you give me a public key, and then I basically, you know, do some easy math, where it turns out that like, once I reveal the private key to this thing, only you can actually sign for that state, right? So every single sign, you know, we make one of these, you know, commitment points and the location point, we put it in this new commitment, when we go to the next state, you basically must reveal that to me, and then that's how it works, right?

But you know, this one has a few drawbacks, you know, one thing is that, you know, it kind of gets involved, because they were, we were trying to like, you know, well, sha 356, that doesn't exist, but we were trying to kind of defend against kind of like rogue key attacks, things like that, but I think we can get it even simpler, right? Some of this drawbacks, so this one is basically the client storage, you know, he has to store the current state, but then he has kind of like log K state, which is log K, where K is actually the number of state updates ever, but the outsourcer, it's, you know, it's a little bit worse for the outsourcer, because the outsourcer needs a signature for every single state, and then in addition to that, it needs a signature for, you know, any other HTLC that we have, and it also needs to basically collapse this log K state itself. So, you know, the goal here is to make it a little bit simpler, make it more succinct.

So now, a diversion, basically. So I'm proposing, basically, this, you know, addition to Bitcoin called OpCheckSigFromStack, right? So Bitcoin, you know, checks signatures, you probably have like millions and hundreds of millions of signatures when you're validating the blockchain itself. One thing in Bitcoin is that, you know, the method digest is always assumed to be, you know, this thing called the SIG hash, right? So anytime there's a signature operation, implicitly we generate this thing called the SIG hash, which is derived from the transaction itself, and this SIG hash actually, you control basically what's being signed itself, right? So that's cool, but it's a little bit restrictive. So, you know, I'm thinking, like, you know, what if we can add the ability to basically actually generate, validate signatures on arbitrary messages, right? So now this is like super, super powerful, because this can let you do things kind of like, you can do like delegation. I could say, hey, you know, here's Bob's public key, it's signed by mine, therefore we can actually take this output. We can do things like oracles, right? We can say, okay, this is an integer signed by Bitfinex, and we're gonna use it for some contract. We can also do things like kind of like, have these like blessed message structures, where your protocol, you know, has like a message that may be kind of opaque, but has a particular structure, and this can only be signed by both participants, right? So this acts as evidence that we're actually, we actually signed this at some point in the future, and we can use this as evidence later on.

But, so this is kind of like a very strong proposal, but it's not like super soft fork safe for Bitcoin or anything like that, but basically, you know, you have message signature, a public key, maybe you have like a version, maybe, you know, you're gonna have like different signatures in the future, or we're gonna have like an ECSA or schnorr, or whatever else, and basically tells you if it is valid, you know. Regular Bitcoin, you'd have like an op drop and all this other stuff, but we're doing this for simplicity for now.

All right, so now to the new commitment and validation. So those things are called signed signature commitments, right? So rather than now us basically using this revocation model, what we do is every single state has a state number, right? We then commit to that state number and we sign the commitment, right? And that signed commitment goes into the script itself, right? And you know, this is cool because we have this like random number R, so when you look at the script, you don't really know what state we're on, right? But in order to actually do the revocation, what we do is we say, hey, if you can open this commitment itself, and then, you know, because it's signed, you know, you can't like really forge it because it's like a two of two multisig, you can open the commitment and then show me another commitment opening whose R sequence number is greater than the one in this commitment and that means that there was some point in history where two of you cooperated to sign this new state and you went back to the prior to try to cheat me, right? So this is like, this is a little bit simpler. Basically what we have is a signed sequence number, you prove to me that there's a newer sequence number and we commit to it because we hide, you know, the state of it, because it could be the case that like when we go to chain, we don't necessarily want to prove, want to, you know, reveal to the participants basically how many states we've done in the thing itself.

So yeah, you know, so signing is basically pretty simple. You basically have this number R which we derive from some deterministic method, we increment the state number, we have C and then, you know, the signature is important because it's actually an aggregate signature, right? It's gonna be signature between, you know, between both of us and, you know, the free techniques you can do for this, you can do these like two party ECDSA like MPC techniques, there's some aggregate signature stuff gonna be talked about tomorrow, basically. It's just somehow we collaborate and do the signature and it works in a lot easier itself, right?