Episode 35: SIGHASH_ANYPREVOUT and Eltoo

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum What's up?

Sjors Provoost Not much.

Aaron van Wirdum Not much here either. Our topic today is SIGHASH_NOINPUT.

Sjors Provoost Also known as SIGHASH_ANYPREVOUT or SIGHASH_ANYPREVOUTANYSCRIPT

Aaron van Wirdum Yeah I guess it's ANYPREVOUT now I'm just using an old name aren't I?

Sjors Provoost You are.

Aaron van Wirdum Yeah I I wrote an article I guess a couple years ago by now and uh even at that point ANYPREVOUT was a thing but no input was earlier so I kind of decided to go with the no input class.

Sjors Provoost It had Lindy because the name was changing all the time.

Aaron van Wirdum So uh yeah, so okay… Sorry, actually, so I guess the episode is about ANYPREVOUT.

Sjors Provoost That's right.

Aaron van Wirdum And that's a proposed new SIGHASH flag.

Sjors Provoost Yep.

Aaron van Wirdum And it's being, I think it was originally, so I guess it was originally proposed by Anthony Towns, but it was based on work by Christian Decker and Rusty Russell. And even before that, I think it was mentioned in the Lightning White Paper. Am I saying that right? I think so, right?

Sjors Provoost I think so. The BIP says it.

Aaron van Wirdum What's the BIP number?

Sjors Provoost BIP number 118, 118.

Aaron van Wirdum Okay. ANYPREVOUT?

Sjors Provoost Actually, if you go to BIP 118, you'll find, I think, there's still the SIGHASH_NOINPUT. So if you Google around a bit or look in the show notes, there'll be a link to a pull request slash branch that is the new version.

Aaron van Wirdum Right, okay, yeah. So just to be clear...

Sjors Provoost It's in flux, but that's the new name.

Aaron van Wirdum We're calling it ANYPREVOUT today, I think, right?

Sjors Provoost Yes.

Aaron van Wirdum Okay, so it's a new type of SIGHASH flag. So what is a SIGHASH flag?

Sjors Provoost Okay, so when you sign a Bitcoin transaction, the question is, what are you actually signing, right? You're signing a message that says, send coins from A to B. And what a SIGHASH flag does is normally you would just sign that entire message. So you would sign a message sent from A to B. But what you can do with SIGHASH… SIGHASH flags is to say, well, I'm going to sign only part of this transaction and leave the rest as a blank check, basically. Well, not necessarily a blank check. Because a blank check means you can send it to anyone. That's usually not what you would do. But the other side might be blank. So you might sign a transaction saying, well, here's one Bitcoin from me and send two Bitcoin to this other guy. And I'm going to sign that part, but I'm going to leave open extra inputs. So I believe that is called SIGHASH anyone can spend. No, ANYONECANPAY.

Aaron van Wirdum Yeah, there are a bunch of different SIGHASH flags and the SIGHASH flags specify which part of the transaction is actually being signed. And that means that other parts of the transaction can potentially be changed.

Sjors Provoost That's right. Because remember when you sign the transaction, well, that's... Then you can't really change it anymore, right, normally. But if somebody else wants to add an input, well, then they would sign their input, but now your signature is no longer correct. So you'd have to do another signature, which includes their input. And so to prevent that, you have the SIGHASH flags. So you sign your input with just saying, only look at my input, and they sign their input saying, only look at my input. And then you can basically, anyone can combine these transactions. You can combine these inputs and it still works.

Aaron van Wirdum Yeah. I just realized in case there are sort of really beginners listening, the thing is that with the cryptographic signature, it's really unique to whatever you're signing, while a regular signature just looks the same on every document.

Sjors Provoost Yes.

Aaron van Wirdum But in the case of a cryptographic signature, it's very unique to the specific thing you're signing.

Sjors Provoost Yeah, because it uses a hash. You're signing a hash, essentially. So we talked about hashes before. A hash is just a piece of text that you hash. And so this piece of text would not include the other inputs, for example, or it would include the other inputs.

Aaron van Wirdum Right. So a SIGHASH flag, it specifies which part of a transaction you're signing. You can either sign the whole transaction, excluding the signature itself in that case. Or you can sign a part of a transaction.

Sjors Provoost Well, yeah, you're always signing part of the transaction because you're not signing the signature itself.

Aaron van Wirdum Yeah, I guess that's even more accurate. You're just specifying which part of the signature you're signing. Okay, then... So there are a bunch of these already, and now a new proposal is SIGHASH_ANYPREVOUT.

Sjors Provoost Yep.

Aaron van Wirdum So which part of the transaction are you signing in the case of ANYPREVOUT?

Sjors Provoost Well, more… more importantly, which parts are you not signing?

Aaron van Wirdum That… that would be another way to ask.

Sjors Provoost Right. So, what you're not… what you're usually… what are your… transaction always… you know, a transaction always refers to the thing it's spending. So a transaction says, I am spending this earlier transaction. Well, that's called a prevout. And so with this new flag, you don't sign that bit. So basically, somebody else can create a whole new transaction and take your signature, and it's pointing to a different original transaction, but the signature is still valid. Because the signature does not say which other transaction you're spending.

Aaron van Wirdum Yeah let me try to rephrase that: so every transaction has sort of the input part, and the output part. The input part refers to a previous transaction and then an output part that's that specifies how the coins can be spent again in the next transaction. Okay. If you're not signing the input, which is the case with ANYPREVOUT, that means the signature doesn't specify to which previous transaction it's referring. The signature doesn't. The transaction itself still does, of course, but the signature doesn't. The reason, let me say if I'm saying this right. Yeah, of course, the signature still needs to be valid compared to the previous transaction. You're still signing with the public key from that previous transaction.

Sjors Provoost Yeah, so to put it another way, I guess, again, is that a transaction input refers to a previous transaction. This previous transaction has a script that has to be satisfied. And as we talked about, that script could be as simple as give me a signature for this public key, but the script could be anything. But for the simplicity, we say, okay, the script just wants a signature. And now... And so when you're spending a transaction, that's important that you're actually satisfying that script. But you're also saying this transaction actually needs to point to that original transaction. So that's a double thing. It's kind of a double check. You don't just satisfy the script. You also make sure that you're pointing to the previous transaction. And you don't have to sign that part.

Aaron van Wirdum Yeah, I'll briefly mention why I'm sort of re-explaining this. It's because when I was first learning about this...

Sjors Provoost I also find this confusing. Don't worry.

Aaron van Wirdum I was incredibly confused about the fact that you could sort of change inputs because I figured... How can it be possible? That could mean you can spend any coins on the blockchain, but that's not the case. The signature still needs to match with the previous transaction, with specific coins that it needs to match. With the transaction, it's just that you're not signing the specific input. That's sort of the only difference. Am I saying this right now? I think so, right?

Sjors Provoost Yeah, exactly. So the signature still has to, indeed, you still have to satisfy the script. The script says, I want a signature for this public key. You have to give it a signature for that public key. But the thing is what Bitcoin is doing is really two things with these signatures. One is it's using signatures to prove that indeed you have a private key, but it is also using signatures to commit to a hash. So that's kind of where the confusion comes from. So the committing to a hash is the part where you're saying, this signature, when I set it, when I made the signature, it can't just be moved around. This really belongs to this specific transaction. That's one thing you're doing with the signature. The other thing you're doing with the signature is saying, yes, I actually own this private key. And so the SIGHASH_ANYPREVOUT proposal does not change that first property. You really do have to satisfy whatever condition, which might not be any signature. Of course, then it doesn't work, but yeah.

Aaron van Wirdum How do you think it's gone so far?

Sjors Provoost I think this is amazing. Everybody totally understands it. Maybe we should actually go through a much more practical example of why this is useful, and that might even help clarify what it actually is.

Aaron van Wirdum Actually, I have an alternative proposal. Let me first explain the problem with this with ANYPREVOUT, like a reason how it could go wrong… Okay, that's fine. That that helps me understand. So, let's see if it might help others. Okay, so let's say someone is reusing an address which is recommended against. This is something people shouldn't be doing, but let's say you're reusing an address, so you know it's like a donation address or something. Okay. People send money to this address. So we're just going to use round coins, which are worth an all-time high today, I guess, right? $60,000 or whatever.

Sjors Provoost I'm sure one Bitcoin is worth one Bitcoin.

Aaron van Wirdum You're right. Okay, so I'm receiving Bitcoins on this one address. Now, at some point, I decide to spend one of these Bitcoins. And I do it using ANYPREVOUT. Which is a problem. Or it was an even bigger problem for no input for very technical reasons, I think. But let's ignore that. Okay, now I'm sending this coin to you, Sjors. So I'm signing the transaction, but not the input. The transaction is still valid. It's a valid signature from my Bitcoin. And the transaction is valid. All the scripts are satisfied. So you get that Bitcoin. However, what you can do now... Is you can copy the transaction and so now there are two transactions and they look exactly the same and you swap in another one of my coins from itself at the same address.

Sjors Provoost Yep.

Aaron van Wirdum And also transmit that to the blockchain. And that will confirm as well. So now all of a sudden, even though I sent you only one transaction, you were able to claim two coins. And the reason both of them are valid is because they're both secured by the same private key. So the signature matches. And I'm only signing the part of the transaction. That doesn't include the input, so the inputs can be swapped.

Sjors Provoost Yeah, or to reverse this argument is why do transactions commit to their input in the first place? Why do signatures commit to the input in the first place? That's to prevent this.

Aaron van Wirdum Right.

Sjors Provoost Because, of course, [unclear], you know, it's… it's impossible to prevent.

Aaron van Wirdum Yeah, so that's sort of... For me, this is how I understood it. This was what I needed to hear, to understand. So maybe this would have helped someone else by now.

Sjors Provoost Yeah, so maybe now some of our listeners are jumping with the Eureka and others may still be confused.

Aaron van Wirdum That's almost certainly going to be the case. Okay, now let's get to an example where this actually is useful, which is why we're discussing this. And I think the most obvious example... Is eltoo.

Sjors Provoost Yep.

Aaron van Wirdum Which is a confusing name in itself. It's uh, to explain that real brief, it's just a new Lightning network version protocol.

Sjors Provoost Yeah it's spelled E-L-T-O-O, right? It's pronounced as L2.

Aaron van Wirdum Which also means Layer 2. Exactly. And it is also a Layer 2 thing. It's brilliant. Eltoo, you could arguably say that it is a simplification of the Lightning Protocol. Exactly, yeah. So the Lightning Protocol exists. I think most [unclear] will know that. And eltoo is a proposed simplification of it.

Sjors Provoost Yeah, and it uses this new technology.

Aaron van Wirdum Yeah, and I think the main benefit of it is... You can correct me if I'm... No, I'm pretty sure I'm right, actually. The main benefit is that it's... Right now, the way Lightning works is it uses something called penalty transactions.

Sjors Provoost Yep.

Aaron van Wirdum And it means that both parties in a payment channel, they're both stacking up unconfirmed transactions, basically. If one of them sends an old transaction, so an old channel state, then that allows the other channel partner to use their penalty transaction to claim all coins from the channel. So that keeps everyone honest. That ensures that everyone, both parties in the channel, will only ever broadcast the latest channel state. The problem is that sometimes... Code is buggy, or you know, someone accidentally messed up a backup of his wallet or something, happens that wasn't you know, ill intended. It was just a small accident, and now all of a sudden all that person's coins are gone so eltoo offers a solution that isn't so harsh.

Sjors Provoost Yeah, basically there's two problems, right? One is that you have to hold on to a lot of material. If the other side is cheating, then you have to remember a lot of different things to make sure that you can actually punish them when they're cheating. And the other is if you have toxic waste, as it's called. So if you accidentally publish any of that material too early or at the wrong time, maybe because you lost an update and you think you have the latest state. You will lose all your money. So it's scary in both directions. You have to remember a lot of stuff, otherwise you lose your money. You have to not leak a lot of stuff, otherwise you lose your money.

Aaron van Wirdum Right, yeah. So these are some complications with the current Lightning protocol. So eltoo is a proposal to simplify and improve on this.

Sjors Provoost Yeah, much easier.

Aaron van Wirdum Do you want to give it a go?

Sjors Provoost Yeah, I'll try. So in both protocols, the first step is both parties put some money into a multisig address. And then before they do that, so they'll draft it. But before they actually sign that and put it on a blockchain, they make a transaction that takes it out of the multisig address or at least that redistributes it. And that is called basically the settlement transaction. So yeah, you're taking it out of the multisig address. And then once you've signed... The way out, you publish the way in so that you know for sure that the coins are going to come out to you. That's the first step.

Aaron van Wirdum Yeah, so let's say we're both going to put 10 coins into a Lightning channel.

Sjors Provoost You really like these very large channels. All right.

Aaron van Wirdum Then the first settlement transaction, am I saying it right? I get confused about it.

Sjors Provoost Yeah, the funding transaction puts 10 Bitcoin in, 10 Bitcoin out, and the settlement transaction takes 10 Bitcoin out. For each of us.

Aaron van Wirdum Yeah, exactly.

Sjors Provoost Back where we started. Now, if we wanted to start using this channel, what we do is we have this thing called an update transaction. And this update transaction, and now we're just talking about eltoo, but Lightning works similarly. The update transaction just says, okay, now nine Bitcoins go to me and 11 Bitcoins go to you or the other way around.

Aaron van Wirdum Yeah, that meant you gave me a payment. You made a payment of one Bitcoin to me.

Sjors Provoost Exactly. And at the same time we do that, we also, at least in this eltoo protocol, we also create a new settlement transaction. That takes the money out of that update transaction and really gives it back. So it's kind of a double transaction. So, yeah, an update transaction and a settlement transaction.

Aaron van Wirdum Right.

Sjors Provoost And then we make more payments. For every time we make a new payment, we create a new update transaction. We do not send it to the blockchain. But here's the magic. Whereas with Lightning, you have to remember all of these. With eltoo, you only have to remember the most recent one. So that means that if you publish an older update transaction, then I can simply publish a more recent update transaction and then the final settlement transaction. So there's no punishment, but there's also no toxic material.

Aaron van Wirdum Right. Yeah. So you could argue that this is already possible under the current Bitcoin protocol in a way. Uh in a complicated way, in a not useful way, but I'm just going to explain real brief, to understand the idea. So the idea then is um we have transaction number one transaction number two transaction number three you know these are all updates going up to transaction 100 That's the most recent channel state. Now, at some point, you try to cheat on me and you broadcast transaction 13 to the blockchain because that was the point in time where you owned most of the channel. Now, the way for me to counter that in a naive way is to then broadcast transaction number 14, which sends the... Did we cover this already? Am I skipping ahead?

Sjors Provoost No, that's fine.

Aaron van Wirdum Transaction 13 sends coins to transaction number 14, and then I broadcast transaction number 15 and 16, and I do this all the way until 100, until we get to the honest point of the channel.

Sjors Provoost Yeah.

Aaron van Wirdum So that would be my way to counter. Your attempted theft is to just publish everything that happened on the channel so the blockchain will sort of run its course and I get my money. Yeah, what eltoo does is it says okay, you don't need to publish all 87 newer transactions any newer transaction will do. So you transmit transaction number, what was my example, 13?

Sjors Provoost Yep.

Aaron van Wirdum You broadcast transaction number 13, and then I immediately broadcast transaction number 100, and now the blockchain will check, yep, 100 is newer than 13, so it's valid.

Sjors Provoost Exactly. So you do not have to broadcast all the intermediate update transactions. And then, of course, the question is, was that possible?

Aaron van Wirdum What could also happen is you try to cheat with number 13, And my highest, you know, my most beneficial state was 67. So I tried to counter with 67. But then you, after that, you know, okay, let's settle on 100 and then you broadcast 100.

Sjors Provoost Yes.

Aaron van Wirdum We'll always get to the most honest state probably as long as we're both paying attention.

Sjors Provoost Yeah, to the last state. Exactly.

Aaron van Wirdum The last state.

Sjors Provoost So there's a little gotcha there with this publishing. There's a time limit. So when you cheat, I have so-and-so many blocks to respond to that. And that's because every transaction essentially has a switch statement in it where it says there's two possibilities. Either you wait 100 blocks, and then you can take the money, or you actually show me a new update transaction, which you can do immediately. So if we're at update number 13, if I have update number 14, I can just put that on the chain immediately. But if I actually want to take the money out of the update transaction with a settlement, then I have to wait 100 blocks. And this guarantees or basically says that, you know, you can try to cheat, but I'm just going to publish the new version and the new version and the new version. And I can always do that immediately. Whereas, you know, if you want to take the money out, you have to wait. That's still with the original protocol. And that's actually the same with eltoo. But now the question is, what is the magic that lets us skip these intermediate transactions?

Aaron van Wirdum Yeah, so to first... Very briefly reiterate this, the benefits of using this system is that we don't need to store all the other transactions. We just publish the latest one, and we're not punishing the counterparty too severely, because we're just going to the latest state and we both get what we deserved. We both get our latest channel…

Sjors Provoost Yeah, and there's also there's no toxic waste right? Um…

Aaron van Wirdum Okay, so I think that makes it clear what eltoo is, at least for some listeners, hopefully. And I think, hopefully, for some reason, listeners, it was clear what ANYPREVOUT was. So I think now the last step is to sort of connect. How does ANYPREVOUT actually make eltoo possible?

Sjors Provoost Yeah, because normally when I, you know, you published version number 13. And we previously signed update number 14. And when we signed update number 14, well, we only knew about number 13. So we created the transaction that referred to number 13. The signature was committing to the hash. Sorry, it was committing to that specific input. And so what this ANYPREVOUT thing lets us do is we say we don't commit to this specific input anymore. We just say that any transaction that looks like this, we can spend. And it gets even better because, well, yeah, I think that would be the first step to explain. So that means that update 15 will work, update 16 will work. Basically, any of them will work because we're actually skipping two things. That is important to say now, I think. We are not committing to the previous transaction. We are also not committing to the script that we're spending. So these transactions... These update number 13 and 14 and 15, they all pay to a slightly different script. And I can spend from them all, as long as I can satisfy that script, that is. This is very powerful, but there's a problem. And I think you can guess what the problem is.

Aaron van Wirdum I cannot guess what the problem is you have in mind right now.

Sjors Provoost So if transaction number 13 is on the blockchain and I want to spend it, and we've signed this transaction number 13 to say you can spend this with... Basically, you don't have to commit to the script and you don't have to commit to the input. So that means I can put any update transaction on top of that, including earlier ones.

Aaron van Wirdum Right, sure. Okay, sure.

Sjors Provoost So that's not good. And this is why the input script actually uses a little trick itself, which is to commit to a block height. Not a block height, but just to a number, to an nVersion.

Aaron van Wirdum Right.

Sjors Provoost Is it [unclear]… nSequence, sorry. So basically what it is, what the input script… because remember, we don't have to commit to the input script, but we do have to satisfy the input script. That's a little tricky confusion there. So we can't just take any… any coins we want. We do actually have to satisfy the script. And what the script says is, well, your sequence number must be higher than this… Must be high… Say, must be higher than 13. And so the only way my sequence number can be higher than 13 is you know, if it's… if it's a newer update. So, this is how we guarantee… how eltoo guarantees that you can only spend… you can only publish a newer version. Otherwise, you keep going in circles. Because you would publish 13, I would publish 5, you would publish 20, and I would go back to 18. No, you have to go up because of this trick. And then basically... So the update transactions don't commit to the input and they don't commit to the script, whereas the settlement transaction, which there's one settlement transaction for every update transaction that we signed at the same time, this commits to specifically one input. It does commit to one script. So it commits to the script that says, well, it has to be number 14 or it has to be number 20. So this should make your head spin a little bit.

Aaron van Wirdum I understand it, but even for me, it gets pretty complex with these kinds of topics, doesn't it, Sjors? Or is it just me?

Sjors Provoost No, no, it quickly does. I have to say, actually, I've read the eltoo proposal several times in the last few years, and I think I understand it better today than I did yesterday. So this will take some iterations and it's quite hard to explain over audio.

Aaron van Wirdum Yeah, it is. One of the takeaways, and maybe this is obvious for some and maybe it's not for others, but one of the reasons this works, especially in the context of something like Lightning or eltoo, is that each update transaction needs the same signature because the coins are always stuck in the same multi-address. That's always what you're spending. So it always needs the same signature. So therefore, if you can just swap the inputs, you can keep updating.

Sjors Provoost Yeah, pretty much. Exactly. So we've made the signature once when we updated the channel, and then we assume we might not see each other again. So that signature still has to be valid. And now that's good because I can actually tweak the transaction to point to our newer state. And even that newer state, even though that newer state has a different script because it requires a higher version number, and that requirement is in the script, I can still do that. Because the real cool thing is not just SIGHASH_ANYPREVOUT, so any previous input. It is SIGHASH_ANYPREVOUTANYSCRIPT. So I can, yeah, I can change everything. Well, not everything, those things.

Aaron van Wirdum Okay, do you think that covers that part? Did we just cover how eltoo is enabled by ANYPREVOUT?

Sjors Provoost I think we did.

Aaron van Wirdum Okay, then I want to briefly get into the watchtower part because that's another big benefit of... ANYPREVOUT and eltoo itself right?

Sjors Provoost Yeah, it sounds to me like you would not have to store as much stuff when you're building a watchtower.

Aaron van Wirdum Yeah, exactly. Let's get into this very briefly because we've already discussed… we've already been discussing pretty technical stuff for a while now, and people are probably… people's… heads are spinning, like you said. But the idea of a watchtower is the idea of Lightning and eltoo like we mentioned is that you need to keep paying attention to the blockchain to see if anyone is trying to cheat on you and if that happens you need to respond.

Sjors Provoost Yeah, you need to respond on time.

Aaron van Wirdum Yeah. So watchtowers, they exist now, right? There are some watchtowers out there, I think, right now?

Sjors Provoost I think so.

Aaron van Wirdum Yeah.

Sjors Provoost I mean, you don't need them if you run your own node and it's always online. But if you have, say, a mobile client or if you think you might be offline.

Aaron van Wirdum Yeah. So in short, you're basically outsourcing this channel monitoring to other parties. Now, this is done in a way I think that it's pretty privacy preserving and secure and all of that. But the idea is that a watchtower is watching the blockchain for you. If someone cheats, they will broadcast the penalty transaction. And, you know, that way that saves you. Time and effort to to do that yourself. The problem is in order for a watch tower to do this right now, with the Lightning network they need to keep all of these penalty transactions for all of these older states of the payment of the channel, plus they need to do this for all of their users. So that's that's gonna quickly add up to keeping a lot of data in order to operate a watch tower. Now with uh eltoo They don't need to keep all of this data for all of these people. They just need to keep the latest transaction for each channel once. So that's a lot easier. So that's a big benefit for Watchtower.

Sjors Provoost It's the same benefit for your own node.

Aaron van Wirdum Yeah, but I guess your own node is just watching one channel while Watchtower maybe watching thousands or even who knows how many.

Sjors Provoost No, that's true.

Aaron van Wirdum Uh okay one final thing I want to ask you, uh… so I already mentioned earlier and I think at the very start of the episode, that it started… ANYPREVOUT started as no input and I think that one of the main differences between no input and ANYPREVOUT is that ANYPREVOUT is designed specifically for Taproot.

Sjors Provoost That could be. At least I know that it's designed specifically for Taproot. I don't know when the name changed.

Aaron van Wirdum I think that's when.

Sjors Provoost Okay. But what happens in Taproot, so what happens normally with SIGHASH, you know, the different SIGHASH type, like the crowdfunding one that we talked about in the beginning, is you can just do that whenever you want to. So you can take any of your inputs in your wallet and you can send them somewhere and that new transaction can have any of these SIGHASHes. But for this new type, you can't just do that with any of your wallet addresses. So that's kind of a safety feature. You actually have to put them into a new address that you create. And that is a Taproot address with a special version number in it. Technically, I think it's a new public key version, but that doesn't really matter. You have to opt into this. So you have to actually create a Taproot thing where your coins go. That actually says, okay, this can be spent using the ANYPREVOUT mechanism.

Aaron van Wirdum Right.

Sjors Provoost So that reduces the chance of accidental foot gun scenarios that we talked about in the beginning where you receive donations on the same address and they just disappear.

Aaron van Wirdum Right, right. Okay, how do you think that went, Sjors?

Sjors Provoost I don't know. I mean, it's one of those topics I think you have to hear several times in several different ways to get it. And we have contributed one such way. But I don't think this is the thing. I think it's rare that people will understand this in the first go.

Aaron van Wirdum Yeah, at least for me.

Sjors Provoost I mean, Lightning itself is hard to wrap your head around.

Aaron van Wirdum Well, exactly. That's the sort of big part of the problem, that the higher up you get in all these layers, the more complex it seems to get, because now you've got to understand more.

Sjors Provoost Yeah, but in a way, this is simpler than the real Lightning.

Aaron van Wirdum Yeah, we're actually simple. We're taking a step back in a way.

Sjors Provoost Which is similar to the Schnorr story, where Schnorr is easier than ECDSA, so Taproot is going to make... Is going back to the simpler ways. And eltoo would also go back to the simpler ways. And hopefully one day this soft fork will happen.

Aaron van Wirdum It's much, much simpler. We haven't mentioned that. So it's a soft fork. So it's a protocol upgrade. It's definitely not going to happen before Taproot.

Sjors Provoost No, because it needs Taproot.

Aaron van Wirdum Exactly.

Sjors Provoost In its current incarnation.

Aaron van Wirdum So we'll first have to see how the whole Speedy Trial thing ends up.

Sjors Provoost Yeah, but I hope that it's a much simpler soft fork. I think from the proof of concepts I've seen, it's like 30 lines of code to do this.

Aaron van Wirdum Sure, I guess it's quite possible that if Taproot activates that this would be the next soft fork after that.

Sjors Provoost Yeah, I mean, nobody's in charge of that, but given that it's pretty simple and hopefully no longer controversial now that it's been flushed out into this version.

Aaron van Wirdum And now that everyone understands it perfectly, thanks to our podcast episode.

Sjors Provoost Exactly. You're welcome, world. Yep.

Aaron van Wirdum Okay, that's it for me.

Sjors Provoost All righty then. Thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.