Schnorr Taproot Tapscript BIPs
Speakers: Anthony Towns
Date: December 27, 2019
Transcript By: Stephan Livera
Category: Podcast
Media: https://stephanlivera.com/download-episode/1699/137.mp3
podcast: https://stephanlivera.com/episode/137/
Stephan Livera: AJ, welcome to the show.
AJ Towns: Howdy.
Stephan Livera: Thanks for joining me AJ. I know you’re doing a lot of really cool work with the Schnorr and Taproot proposal and the review club. But let’s start with a bit of your background and I know you’re working at Xapo as well.
AJ Towns: Yeah, so I, I’m working at Xapo on Bitcoin core dev, which basically just means that I get to do open source work full time and get paid for it and it’s pretty freaking awesome. So I kind of got, into lightning from being interested in micropayments like, embarrassingly long ago at this point, I guess. So like mid 2000s and like I’ve always wanted some sort of micropayment thing to be workable so that I can like charge for emails so that all the 10,000 spams I get a month, I charge a cent for those and I make a tiny profit or nobody spams me anymore. And it’s kind of win-win so that, that’s my end goal with Bitcoin and lightning and whatever. And, yeah, so I followed Rusty since his Linux days and he started doing petty coin, which was a Bitcoin clone and got into lightning when it came out essentially.
AJ Towns: And that’s kind of the first realistic like technically practical thing for the micropayments that has ever happened. And so then I kind of fell down the rabbit hole of OK to get lightning to work, you have to get Bitcoin to work. So does Bitcoin work? How do we make sure it keeps actually growing and making sense and yeah, so, I’m now working on Bitcoin. So the lightning works and once we’ve got Bitcoin set up to the lightning works, I’ll be trying to get lightning to do micropayments stuff and then then I’ll get my email working and then I’ll be done.That’s my theory.
Stephan Livera: So all of this is just to stop the spam, right?
AJ Towns: Yup. The original goal of hash cash. Right.
Stephan Livera: The real Hashcash. Lightning is the real Hashcash. But I, I’ve noticed as well on the Bitcoin devs mailing list and also on the lightning dev mailing lists that you’re also quite active there as well. Coming out with different ideas on constructions of, okay, once we get Schnorr signatures and taproot, then that can help lightning benefits here, here and there. So that, that’ll be cool to get into as well. But maybe we could just start with a bit more of a high level understanding around, what is Schnorr signatures and what’s the application of it to Bitcoin?
AJ Towns: So the way Bitcoin works is you have transactions and the way you ensure that only you can spend your coins is you have a digital signature on it that only you can produce. And the digital signatures that Satoshi chose, as far as I’m concerned, that was elliptic curves because they’re short and efficient and it was ECDSA because that’s what open SSL implemented. And if you just use what open SSL implements, you don’t have to implement something yourself. It’s a pretty broadly accepted standard. And that was like, that’s fine if you’re just doing signatures and you want them to work. But the benefit of Schnorr is that you can do as far as I’m concerned, the benefit of Schnorr is that you can do maths with them. So with ECDSA to avoid the Schnorr patent, they came up with this complicated method that is kind of equivalent, but the maths is really complicated and you can’t, you can do a signature with it, but you can’t do anything else with Schnorr.
AJ Towns: You can essentially add signatures together. You can kind of multiply them by things. And you, if you add two signatures together, you don’t quite get a signature out, but you get something pretty close. And basically with that ability, we can have two partial signatures that you add together to get a real signature. And that starts making things like multisig not require as much space. Like instead of having two signatures to do multisig, two of two, you just have the one signature that’s the addition of something else. But you only have to have the one signature on the blockchain. So it’s half the size. And so Xapo does three of five multisig for it’s vault or two or three for regular stuff. So if we can get Schnorr implemented and get that working, that kind of halves, the fees that Xapo will be paying and we can do more complicated stuff than that. And in theory if we can make it all work, it’s pretty awesome.
Stephan Livera: Awesome. And so the other component I’ve heard is that even the patent aside, that there was this idea of having it being battle tested and having been out in the wild and so on. Do you put much stock into that or is that overrated?
AJ Towns: I wouldn’t put it quite that way. It’s more that because of the patent, Schnorr wasn’t really used in industry. So you had like open SSL has is a library that’s written so you can just plug it in and use it. You don’t, there’s already a standard out there. Different libraries implement the standard. People kind of know how to interoperate with it. Whereas with Schnorr, there’s papers on it and that’s kind of where it stops because you have to pay money to go any further than that. So patent’s finished and okay, that’s fine. ECDSA still works for everyone. So everyone keeps using it because it’s easy and no one’s written up a standard for Schnorr. So if you want to use Schnorr, you’ve got to write up a standard for it. You’ve got to implement the libraries for it, then you’ve got to test the libraries. You’ve got to make sure you don’t have any weird edge cases. And that’s, that’s essentially what we’re going through now.
Stephan Livera: That also brings to mind another common saying I’ve heard, and again, I’m no expert, but I’ve heard this idea of, Hey, don’t roll your own crypto. Right? And that’s, that’s like meant to be a really bad thing because you know, it’s really, there’s so many ways that you can make a mistake. What’s your reflection on that idea as applies to what we’re doing now?
AJ Towns: That’s totally true. There are so many ways you can make a mistake. And that’s why, first of all, you want to be an expert before you do it. But then even if you are an expert, you’ve got to realize there’s so many ways as an expert you can make mistakes and get as much review on it, as much testing, leave yourself time to think about it, get academics, get industry, get everyone to look over it and don’t kind of rush into things. So one of the things, that Blockstream came out with as part of the Schnorr thing is a thing called Musig, which is the, which is kind of a secure way of doing this, adding two signatures, adding two pub keys together to get the multisig in a single pub case, single signature. And that’s, and the original paper that came out, I think six months, maybe a year later, they came out, some academic cryptographers who’d written the papers that the Blockstream paper was based off of, came out with a new paper saying that the MuSig proof was broken and that it didn’t work as specified.
AJ Towns: The proof was wrong. It was maybe exploitable theoretically and they came out with a fix for it as well, which, which was basically making an extra interactive round of essentially making it a bit more complicated in set up. And since then I think we’ve come up with a fairly practical way of attacking the original original design of it. So it’s just, these things are really complicated. There are lots of lots of edge cases and you need to be careful and like slow and steady wins the race about it sort of thing.
Stephan Livera: Right. And on that idea as well, as I understand, part of the building the case for a change is to understand what are the current assumptions that Bitcoin relies on and under this proposed change, are there any changes to that? And I’ve heard it said that currently, Bitcoin relies on what’s known as the discrete logarithm problem. And I’ve also heard the argument put forward that actually the Schnorr scheme requires sort of less assumptions. Can you help explain that for us?
AJ Towns: So I’m not a cryptographer so I can’t explain it really accurately, but the simple kind of explanation is that the Schnorr signature idea is what came first. And so it’s fairly simple. It’s you do a hash of something, you add it with a random number and you take the, so going from a private key in Bitcoin to the public key is, point multiplication going from the public key back to the private key is taking the discrete log. So that’s what the discrete log problem is. It says that you can’t get the private key just knowing the public key and the Schnorr signature is basically just upgrading that, that same difficulty to let you do a signature so that you can say, okay, this public key definitely signed this thing, but there’s no way of getting back to the private key from it.
AJ Towns: And there’s no way of someone else with just the public key being able to produce a signature without having the private key and to get ECDSA, what we currently use in Bitcoin, they basically tweaked around with the formula for SChnorr and made it a whole bunch more complicated and a bit harder to analyze. And there’s no proof that the ECDSA thing is secure as long as Discrete log is secure. There might be some other assumption in there. And there is, there is a, there is a proof that uses some extra assumptions that ECDSA is secure, but proving that Schnorr is secure uses fewer assumptions. So it’s simpler to understand for on the academic side and it should be at least as secure, possibly more secure.
Stephan Livera: Awesome. And so can you help us understand a little bit around the relation with taproot and tapscript? So what are they at a high level?
AJ Towns: Okay, so Greg Maxwell came up with the idea of taproot, which at a really high level basically takes the, like you’ve got the existing sort of address types at the moment you’ve got pay to a pub key, which you just Pay to a pub key and then you can sign that with your hardware wallet or whatever. Or you’ve got Pay to script hash and then your script hash can be a complicated script that says I need this pub key and this pub key and I need this time lock and I need the reveal of this hash pre image. And it can only happen under a full moon or whatever. Have kind of any arbitrarily complicated thing you can express in script, which isn’t that complicated but could potentially be. So taproot basically takes the idea that if you do some of this fancy point addition stuff that Schnorr allows you can, combine the two in such a way that you either just pay with a key. So you’ve got a single address that works as a pay to pub key, but you’ve also got a way of pulling a script that was originally hidden in the pub key out and then paying with a script. So you’ve got, you can create an address that gives you a choice of, of either pay the pub key or pay to script hash, and you only have to decide which of those you use when you want to spend it.
Stephan Livera: Yep. So maybe we could just go back a little bit on the address types and the script types. So as I understand in the very early days, it literally was pay to pub key it was, you were paying to a pub key then the newer type was the pay to pub key hash, which is hiding the pub key and you’re paying to the hash of the pub key. And then there was also P2SH which is paying to the script hash, not the script itself. So that’s a hash of the script. And then as I understand, we would now have like a pay to taproot output. Can you help me understand that part of it?
AJ Towns: Okay. So originally, originally there was just pay to script, so you’d have to, every Bitcoin UTXO in the blockchain would have a script in it, which says which gives the rules, that allow this, this coin to be spent. So it could be a multisig script, it could be a pub key check sig script, which is you pay to pub key. So you’ve got the actual pub key in there. And then you’ve got the check sig op code in there. So pay to pub key hash is just a script that says here’s this hash, now I want you to give me a pub key when you spend it and then I’m going to hash that and check that it matches the hash that I provided in the UTXO. And then I want a signature and then you got to check sig that the signature and the pub key match match the transaction that you using.
AJ Towns: Then on top of that we added a thing called Pay to script hash, which is a magic template. Things so that it’s not, it’s not a script that would previously have been been verified. It’s just a hash and then check it. And so if you hadn’t done the soft fork upgrade, the Pay to script hash all you would have had to provide is something that matches the hash. You wouldn’t have had to provide any signatures, anything that actually proves you are in it. Just the, just the script itself, but the soft fork that implemented Pay to script hash also added the extra rules that say that you’ve actually got to satisfy the script that you provide. So then the script says check multisig and you’ve got to provide the pub keys and actually the signatures. And so SegWit built on top of that along the same idea, which says that you can provide either a 20 byte pub key hash or you can provide a 32 byte script hash according to the SegWit template and those then the appropriate rules for that will be executed so that you have to provide the pub key and the signature.
AJ Towns: Or you have to provide the script and whatever the script requires. And so pay to taproot will be a similar thing, which essentially goes from version zero with SegWit to version one with taproot, which will require either, again, a signature if it’s taking the key path. So it’s just a pay to pub key by taproot or it’ll take a point reveal, a script and whatever stuff you need for the scripts for the script path.
Stephan Livera: Okay. Gotcha. I think I’m getting you. Yeah. And so what you were referring to there with the SegWit versions of that is, those are the addresses. You might, we might’ve seen that written as Pay to WPKH or pay to WSH, right? Yes. That’s like the SegWit versions of the pay to pub key hash and pay to script hash. Right. And then, that was v0, right? Because you know, in the programming world, some languages and things start with zero. So that was v0 and then the new version is going to be the one and that’s what we’re talking about now with taproot and tapscript. Right?
AJ Towns: Yes.
Stephan Livera: Gotcha. So let’s talk about some of the other ideas around Schnorr that I’ve heard of and hopefully the listeners might have heard of these and maybe they want to understand a little bit about what, what those are. So you mentioned MuSig earlier. That’s one particular way in which you can add signatures together if I understood you correctly.
AJ Towns: Yeah. So the problem with, so if you want to do Schnorr multisig then you basically get say three public keys, you add them together and then you do three separate signatures of the transaction, one with each pub key, and then you add the signatures together. And the sum of the signatures is basically a signature for the sum of the public case. But the problem with that is what happens if you don’t entirely trust the guys with the other public keys and one of them sets up their public key to be not their public key, but their public key plus the negation of the other two public keys. So you go A plus B plus C minus a minus B and that just adds up to C and then they’ve, they could just sign for the address directly. So what MuSig is a way of basically adding hashes to each of those public keys in a particular way so that you kind of multiply each of those public keys by something and add them together and there’s no way you can do that tricky maths to exploit the other two guys.
Stephan Livera: Right? So basically it’s there as like a defense against a malicious party at the setup point.
AJ Towns: Yeah. Yeah.
Stephan Livera: Okay. And so what’s the relation then to Schnorr? Like what is that?
AJ Towns: So the relationship’s kind of fundamental in that Schnorr is the thing that let’s you do the math that lets you add up the signatures usefully to get something. There’s some really complicated 2 party ECDSA stuff that lets you kind of do the same thing, but it then uses much more difficult cryptography. You’ve got zero knowledge stuff passing around between you when you kind of get the same result, but for a lot more complexity. The advantage of Schnorr is that if you can cope with doing elliptic curve mathematics, which is already a relatively high bar, then adding Schnorr signatures and stuff is really easy.
Stephan Livera: Right, I see and you might’ve touched on this earlier, but I’ve seen this benefit called batch validation. So what is batch validation?
AJ Towns: So again, because you can do maths with it if you’ve got a whole bunch of public keys and a whole bunch of signatures, you can do some hashing to make sure you can’t just cheat easily, but you can add all the public keys up with some factors, add all the signatures up with the same factors. And the only way that you get the two things adding up to be a single signature at the end is if they were all valid signatures independently at the start. So it’s still a fair bit of work. So it’s not just, Oh, I had a hundred signatures and I’m only going to do 1% of the work, so I’ve only got to verify one signature. But you still get like a three or four times increase in performance. So instead of taking 30 seconds, you take 10 seconds to do like 10,000 signatures. So that’s a little bit of a benefit for just relaying transactions in the mempool. But if you’re doing IBD so the initial block download to get your full load set up and you’ve got, I don’t know, 3000 signatures in a block, then you’re cutting down the signature verification time for each block by a factor of two or so.
Stephan Livera: Okay. So some pretty good performance benefits there. I’ve heard also of this idea of key aggregation. So what’s that?
AJ Towns: So pub key aggregation is where you’re adding a bunch of public keys up together to get a single public key. That’s what what goes on chain, but it’s representing an n of n multisig.
Stephan Livera: Yup. Gotcha and around the interactivity that’s required for that, maybe if you could help us understand what is that? Is that basically people having to pass information back and forward for a few rounds in some different way? And that could be Bluetooth or it might be like an over an email or like through some way that the software communicates with other parties. Can you talk us through what that means? Like the interactivity part of it?
AJ Towns: Right? So current multisig is not interactive in that you set up your address and you can do that just by knowing all the public keys that you need. And then when you want to spend from the address? You figure out the transaction you want to spend, maybe do a PSBT or whatever to set this up and you go to one hardware wallet and you get a signature from that. And that’s done. You go to another hardware wallet, you get a signature from that. It’s done and however many hardware wallets, whatever you’ve got to get signatures from, you just go each of them in turn, combine all the signatures at the end, publish it and you’re done. The challenge with Schnorr mult sig is that you need to be interactive, which means that the protocol, so the original protocol they had was, this is the broken one, was just, you go to one hardware wallet and you get the nonce from it, which is half of the signal, the first half of the signature go to the next one and you get the nonce from it.
AJ Towns: And the next one then you get the nonce from it, collect all the nonces, and then you tell all the hardware wallets what all the nonces from the other hardware wallets were. And then they calculate the signatures and then you combine the signatures. So you’ve got two passes through all the wallets, but then they discovered that was broken. And first of all, you need the hash of the nonce from each one. Then you need the nonce from each one and then you can get the signature from each one. And so you’ve got this three-phase interactive thing. And so Xapo has these fancy vaults in places, all over the world that they, our three of five multisigs are stored in. And so if we want to go to those vaults, we need to take the transaction down, go through all the security measures, and then get a signature back, which is fine for the noninteractive stuff.
AJ Towns: But if we want to go down once and we get a nonce and then, sorry, we go down. Once we get a hash of a nonce, then we take that back up and transmit it to all of them. Then we go down again and we pass down the hashes of the nonce from all the other vaults and we get a nonce back, then we come down and do it again. That’s kind of painful. So that’s the drawback of interactivity and it’s kind of a pain for hardware wallets. But maybe if you can plug them all into the same PC at the same time, then maybe that’s okay. But if you’ve got deep cold storage, it’s pretty hard. And so that’s the, disadvantage of MuSig. Like it’s much cheaper. It’s much more private because you can’t tell how many n of n you were using.
AJ Towns: But you’ve got to work through this burden of interactivity.
Stephan Livera: Yup. And that’s not just for the set up, but also for the signing.
AJ Towns: That’s for every signature.
Stephan Livera: Yeah.
AJ Towns: So the MuSig set up, you still just need the pub keys from everyone. The MuSig set up is pretty easy. If you’re doing the thresholds MuSig setup where you’re doing K of N, instead of n of n, so three of five instead of five or five, then you need interactivity at set up as well. And you’ve got a store, a bunch more data and, the thresholds Musig is still kind of a researchy work in progress. Like we’ve got something that works on paper, but going from that, so a workable API that people can actually use is pretty tough.
Stephan Livera: Wow. Okay. So it might be a good time now to bring up threshold signatures. And so what is a threshold signature?
AJ Towns: So a threshold signature is just three of five instead of five of five. So in the academic world, the multisig is, everybody has to sign it and then a threshold multisig is some number or more of them have to sign it.
Stephan Livera: And then with Schnorr and taproot, what’s the, is there any implication there or is that basically the same part you were explaining earlier?
AJ Towns: So you can do so with the, with the MuSig where you end up just adding all the public keys and then adding the signatures. You can do a thing called Legrangian interpolation, which you might have met in like first year mathematics analysis at university or something maybe in high school. And it’s just, you’ve got a polynomial, you make a polynomial of degree three out of your five points and you solve it by having any three points and the maths is well known.
AJ Towns: It’s basically the same stuff behind Shamir Secret Sharing. And the, the benefit of Schnorr with this is that you can construct the signature just by adding the signatures of the individual three keys. You don’t have to ever actually reveal the private keys so you can keep using them afterwards without having to trust. But the disadvantages, it’s really complicated. Like just writing out the maths for it is pretty complicated. There’s extra storage and, and yeah, we basically just don’t have a good API for it yet.
Stephan Livera: Okay. Gotcha. And what are adaptor signatures?
AJ Towns: Okay, so adaptor signatures are a form of what we call a scriptless script, which is Andy Poelstra’s term for so taking a step back, the scripts that lightning use. So lightning’s design is that you can, you want to send money to someone but only if they give you the payment receipt.
AJ Towns: So the payment receipt is the pre image of a SHA256 hash. So you give some value that hashes to something that you were given on the lightning invoice. So the script for that is more complicated than this, but it’s basically give me something, I’ll SHA256 it, then I’ll check that it matches this thing, that I was presented in the first place and then I’ll check a signature. And so that’s a script. It’s got some OP codes in it. And if you see one of these scripts on the blockchain, then you know that it was probably a lightning channel. So the Optech guys or BitMex or someone has got a webpage that monitors for every lightning channel that was closed via these penalty transactions. And you can track every single person on the lightning network that has closed channels in this way sort of thing.
AJ Towns: And so that’s not not very good for privacy. So the idea of a scriptless script is that you get the functionality of a script at least in a limited way where you can say, I need this pre image revealed and I need a signature. But you do it in a way that there’s only a signature on the blockchain. So no one can actually tell what you were doing or get a copy of the pre image apart from the two people that were trying to do the initial negotiation. And so the technology we use for, that’s an adaptor signature, which is so I mentioned that the signature is composed of two values as an R and S, they R is called a nonce. You’re basically subtracting the pre image from the nonce. And then the only way that you can calculate the signature is by also subtracting the, I’m sorry, you’re adding the payment secret to the nonce. And the only way you can create the signature is by adding the pre image to the S part of the signature.
AJ Towns: And it works better if you can write it down on paper and kind of explain the maths. But that’s the idea. So you’ve, you’ve done the partial signature in the first place by saying, this is what I need. And the only way that you can construct it in the end is by subtracting the, adding, subtracting, whatever, the secret value that you want to reveal. So you say that on the blockchain, you subtract the S value on the blockchain from the S value you had as a partial thing, and the difference is going to be the secret you needed. And that’s the concept of adaptor signatures.
Stephan Livera: Right. Okay. And while we’re on this topic of scripting, it might be good to just talk through maybe just a basic understanding on what, okay. So, again, I’m not a developer, but my understanding is there are different op codes that go into the scripting and these, for an example, it might be OP_CHECKMULTISIG and the script will be written out in such a way, right? Like it might be like an IF statement and then the way it resolves is, there is a stack and it you have to sort of one at a time resolve them until you’ve resolved the whole thing. And then now the coins are able to be spent. Could you just give us an overview on how that works? Like that idea of this stack and the idea of OP codes.
AJ Towns: Yeah, so it’s a forth like language, which works pretty much as you described. So, you provide a script and a witness stack when you, when you’re spending the SegWit outputs. And so the witness stack is, I don’t know, like a stack of face up cards. So you can see the one on top generally and you can take it off or you can put something else on top or you can cheat and you can look underneath one. You can like pick up the top three and move the fourth, the fourth one to the top. And so the script is a set of op codes. So it’s a set of instructions that say, do this, do that, do something else. And each instruction might be so, and if instruction says, take the thing on the, on the top, if it’s a zero, then we won’t, we’ll stop doing this until we see an ELSE or an ENDIF.
AJ Towns: If it’s a one, we’ll lose the one and then we’ll do the do the IF part. And once we get to an ELSE, we’ll stop doing stuff. And once we get to an ENDIF, then it’s all good again. And so there’s a bunch of op codes, which are kind of like a forth language. So there’s ifs and this pops and this pushes to manipulate the stack. There’s basic maths operations, so you can add two numbers together, divide them. Compare them. There’s some crypto operations, so you can take a thing on the stack and hash it. So take the SHA256 hash of it or the RIPEMD160 of it or the combination. What else can you do? There’s an alt stack so you can take something from your regular stack of cards and move it to a different stack of cards, which you can then build up and then move back.
AJ Towns: And that’s about it. It’s not a very exciting signing operation. And yeah, you can have these are just instructions that are defined in script. So we can do a soft fork and add operations or we can do a soft fork and disable old ones. But the main ones that people use are the check sig. So here’s a public key. Then I want you to take something off the stock and check that it’s a valid signature according to that pub key of this particular transaction according to whatever restrictions we’ve got in the SIG HASH. So you might say anyone can pay or you might say single and that’ll, restrict which parts of the transaction the signature has to verify. In current Bitcoin, we’ve got a thing called check multisig which pops say five public keys off the stack and then three signatures and then checks it.
AJ Towns: The three signatures are valid for three of the five public keys. And that’s your check multisig OP code. Because of the batch validation stuff with, we’re changing that to separate OP codes so that, instead of one check multisig op code, you’ll have five check sig add OP codes. So you pop a public key and a signature off the stack. If the signature is just null, then we won’t do anything. If the signature is valid, we’ll add one to a counter and then we’ll check that the counter equals three afterwards to make sure we’ve got five, three of the five signatures valid. And so yeah, we can with, if we add opcodes to that, we can do much more complicated stuff. So the two recent OP codes that were added were Check Sequence Verify and Check Lock Time Verify which let you do the absolute and relative time locks which were needed for lightning and for like OP HODL kind of stuff.
Stephan Livera: Yup. And so I guess in terms of op code changes that are coming as a result of this proposal we’re gonna as you said, take away check multisig and you’re just going to be doing op check sig add, but just for however many signatures you have in that multisig let’s say. And there is also, I’ve seen OP_SUCCESS, what’s that?
AJ Towns: So the way that script was originally designed was the, were about 10 reserved opcodes called op NOP, which if you had the manuscript they just wouldn’t do anything whatsoever and you just continue on fine. There’d be no action. So it was possible to soft fork behavior on top of that, like check sequence verify and check lock time verify. As long as they didn’t modify the stack and the only thing they could do was abort the script if something wasn’t valid. So if you had a check lock time verify and the lock time wasn’t what it was supposed to be, the script would fail and the transaction wouldn’t be valid, which is great, but you couldn’t do more complicated stuff like push the lock time to the stack and then add it together with the CSV to have to say, make sure the sum of the lock time and the relative lock time where this value you say and that kind of limits the upgrades you could do.
AJ Towns: So because we’re doing a completely new version of the witness stack that lets us make arbitrary changes to script. So what we’ve decided to do is keep all the normal OP codes just doing what they’re currently doing apart from the check multisig. But instead of just having OP NOPs for upgrades in future we’ve got all the unused OP codes as what we’re calling OP SUCCESS. And so as soon as you see an OP SUCCESS in the spirit, that’s just an automatic success at the moment. And what that means is that any behavior we have at all, we’ll only make the script fail because it was an automatic success. And so that means we can soft fork in pretty much any behavior we want for future OP codes. So it’s a much more flexible approach.
Stephan Livera: Okay. Gotcha. And look, I have, I meant to touch on this earlier, but wanted to talk about the benefits of this proposal as well. Obviously I think we’ve spoken a bit about what makes it more difficult, but what what might be more difficult with interactivity requirements but maybe we could just touch on some of the benefits. I understand one of the benefits is referred to as policy privacy. So it’s this idea that you might have multiple possible spending paths and you’re not necessarily revealing what those are, but could you tell us a little bit that and what some of the other benefits are?
AJ Towns: Yeah, so as I was saying at the start, you’ve got this alternative between just having pay to public key or having a script hidden inside there. And you can choose when you’re spending, which one of those. And what I didn’t say was that we actually have a Merkle tree of scripts. So you can have many scripts up to a completely ridiculous number that you can’t actually produce on real machines, of alternative scripts that you could spend. So you could have a script that says, if it’s been five years and I haven’t spent this yet, then I can just use my old secret, my old secret key. But otherwise I have to use a three of five multisig or you can have, you can have something that’s really complicated. But so one of the things that people are considering for lightning is that you need, you might want to be able to do a child pays for parent to get the lightning transactions out faster.
AJ Towns: And maybe that means you need to have a kind of zero satoshi output that anyone can then just either of the two parties in the channel can just spend to do a child pays for parent. But if they don’t need to do a child pays for parent, then you want the option to have a miner just claimed the UTXO, so it doesn’t pollute the UTXO set forever. And you can have with a taproot set up, you can have all those different options at essentially no expense if you don’t use them. And so if you’ve got all these options and you don’t ever actually use them, then no one can see, there’s no reveal of them on chain if you don’t use them. So that gives you a little bit of extra privacy that way too.
AJ Towns: And it’s kind of limited privacy in that you will spend it eventually and however you do spend it, then that’ll be obvious. And it doesn’t make the amounts or the addresses particularly secret. So you can still do all the same chain analysis that you can kind of do now. But it’s kind of an incremental step into, better privacy. And I think it’s a pretty good step into more efficient, complicated scripts because I know I’d like to be able to say I might trust this hardware while it most of the time, but I’d also like a backup so that I can use a different hardware wallet if this one breaks or the software stops working or whatever else. And taproot lets me have that without having this great long script that I have to use all the time. That’s kind of expensive and all that awkward and whatever else.
Stephan Livera: Yup. Yup. And as I understand also there are big benefits that will come for lightning as well if we do get this. So one, one I’ve seen, well I guess very high level one is just when you open a lightning channel, right now it’s very obvious that you’re doing that because it’s a two of two multisig and people can just do that just straight on the blockchain. Whereas in a Schnorr taproot world, it starts to make them look more indistinguishable compared to a standard Bitcoin on chain transaction versus a lightning channel open. Right?
AJ Towns: So the big advantage for lightning is that lightning is always online anyway. So you’ve two peers are connected over the internet. Maybe it’s via tor or something, so maybe it’s a little bit slow, but there’s no problem with any of their attractivity. So they’re always communicating to each other anyway. So sending these hashes of nonces back and forwards so they can always do this nice interactive, add up the signatures, MuSig stuff. So all the transactions can basically look like a here’s a key, here’s a signature. Was this just a hardware wallet signing it? Was it a lightning thing? We can’t tell because it’s just, it just looks like a pay to pub key and yeah, because lightning’s a hot wallet and always online and whatever else, then that works great. And because of the adaptor signature stuff, it can also do a fair few of the complicated things.
AJ Towns: It doesn’t get, it gets a little bit more identifiable at that point because of the lock times, but it’s still, even if it’s not private, it’s much more efficient with the blockchain usage. So if fees ever start rising again, it’s cheaper and phase. And yeah, more efficient as well. For lightning, it should be super cool. And the other, the other thing about Schnorr for lightning is that it enables the decorrelation stuff. So with the hashes that we currently use for the payment secrets and the pre images, you can’t do any maths on that but with, but you can do maths with elliptic curve points and they kind of act the same as hashes with the discrete log problem where you can’t go from a public key or private key, but you can go from a private key to a public key.
AJ Towns: So what that means is that we can convert from the SHA256 images we’ve got to curve points instead. We can use Schnorr signatures with the adaptor signatures to do the reveals of them so that it’s still something we can actually express in script and put on the blockchain. And because we can do maths with them, we can change the point in a predictable way at each step. And so only the two hops in the whole path for lightning can tell which particular points they’re using. And you can’t tell if you’ve got two completely separate points in the same path. They can’t actually tell that they’re in the same path. So that starts getting much better privacy for lightning and the some other other pretty cool things you can do with it too. Like if you’re doing the points then a point.
AJ Towns: So the discrete log of a point is kind of the second half of a Schnorr signature. So instead of paying just for some point or some hash pre image, that doesn’t really mean very much. You can actually be paying for a signature which signs some sort of statement to say, yes, I was paid for this. And then you’ve actually got a signature back as your proof of payment rather than just some number that doesn’t necessarily mean anything. And I don’t know, in theory, you could take that, signature to a court and say, yep, he signed that. If I pay it and then he hasn’t delivered. And you’ve got actual enforcement of lightning contracts in the real world. Maybe that’s my theory.
Stephan Livera: Right? Yeah. So let me just summarize again. So currently lightning network uses HTLC hashed time lock contract, and then as you’re saying in the Schnorr taproot world, we could move to PTLC point time locked contracts. And then the currently right now there’s this thing called payment correlation. And what we want is payment decorrelation, meaning that it adds a little bit more privacy to the way we’re routing our payments across the lightning network. Correct?
AJ Towns: Yes.
Stephan Livera: Yep. And I think the other one, I’m just thinking back to my earlier interview with Rusty. We were talking about a atomic multipath payment or multi-part payment. And one of the, I think sticking points or debating points there was around how can we retain proof of payment. And as I’m understanding from you, it’s more possible to retain proof of payment in a multi-part payment scheme using using this right?
AJ Towns: So the, the multi-part payment stuff that they have at the moment, the base AMP stuff that retains proof of payment, but because it’s the same hash that goes through every step and every month and every path of the multiple paths, that means that every single one of those steps can know that it’s the same payment. And if you block at one point, then maybe that blocks the entire payment or maybe it risks you spending slightly more than you thought you were going to be spending or something else with the points and the decorrelation, you can have every step in every one of those paths get a different point that only at the time it gets to the person you’re paying. All comes back to revealing the same single discrete log, pre image, whatever you want to call it. And so , that still retains the, the atomicness of the payments.
AJ Towns: So it’s still reveal a single secret at the end and collect all of the and, and all. And that propagates all the way back through. But it has the decorrelation so that, okay, I’ve got this point with this amount here and I’ve got this completely different point with this completely different amount here on the separate path. Are they the same payment going to the same person? Are they different payments going to different people? Are they different payments going to the same person? You can’t, you can’t tell just from looking at it. Whereas at the moment you can tell just from looking at it.
Stephan Livera: Yeah. So I guess to summarize that then it’s basically saying with this new proposal, if we get it in then it gives us both payment decorrelation and multi-part payment or we can get that right?
AJ Towns: Yeah,
Stephan Livera: That’s kind of the summarized I guess way to put it. Whereas right now we don’t have that. So another cool thing I’ve seen is apparently taproot helps with getting SIGHASH NOINPUT, which enables eltoo. So could you just speak to a little bit of that?
AJ Towns: So the original plan for no input was to use the next SegWit version and upgrade check sig and have and have an extra flag in the sig hash that does the no input that that, gets support for the features that gets eltoo whatever while we were doing. So part of the, I don’t know, design goals that we had, the design priorities that we had for, for taproot was to try and get this stuff in because obviously everyone or a whole bunch of people really want it and it’s been thought about for years and it kind of makes sense, but we kept getting into little does it go this way? Does it go that way? Is this going to be a problem? And we didn’t, we couldn’t quite get it to the point where we were comfortable as comfortable with it as we are with the rest of the proposal.
AJ Towns: And so what we’ve ended up with is a feature where when the check sig operation pulls a public key from the stack, it’ll say, okay, if the public key is 32 bytes, like the regular public keys that we’re using for the rest of taproot, then we’ll do a taproot check sig and then check that it’s valid and whatever else. But if it’s a different size, so if it’s 33 bites, say, then if we say a signature for it, we’ll just assume it’s valid. And that means that we can soft fork in changes later that support different rules for it so it can support the no input stuff. And so that, that seems like it’ll be a really easy upgrade path for this sort of stuff. And that’s kind of the reason we haven’t had no input so far. It’s because the upgrade path has been doing your SegWit version, which means trying to get all the other features people might want to prioritize in at the same time and coordinating that and making it all happen.
AJ Towns: And so that’s why there’s been BIP118 just sitting there not progressing, it’s like there’s been code for it. There’s a kind of plan for it. There’s questions about it, which is why we haven’t finalized it yet, but it’s hard to make progress on something that requires lots of coordination. If we can get it, so that the upgrade just requires this one feature to be defined, then it’s a lot easier to make progress on that. And so that’s what our unknown public key types are hopefully going to work for signature hash flags like this. And so we’ve got a update to the no input proposal that I’ve been working on with Christian. That is defined in terms of these features. And it looks like it should work for eltoo aspect, but as of just the other day, we’ve come up with another concern about whether we should actually be committing to the value or not because I think not committing to the value.
AJ Towns: So no input, no value. Essentially will make eltoo work a bit more like lightning currently does, where you can have week-long channel closed times with much shorter hash lock times. And so yeah, we’re still debating that on email and we’ll see how that goes. But I think we’ll have a pretty solid plan for no input any prev out, I don’t know, first quarter, next year maybe. And how long it takes to actually go from that to working code is like acceptable working code is another matter. But yeah, cause eltoo makes like backups of lightning channels much more trustworthy, kind of like it just takes the risk of running lightning channels down.
Stephan Livera: Yep. Gotcha. Would you mind just giving us a, maybe just a high level of what no input is and how that helps with lightning and that idea of trying to force it to update on the latest channel state update and not allowing people to broadcast an old channel state?
AJ Towns: Yeah. So I’ll go the other way around. Eltoo, the idea is so in lightning. You’ve got a bunch of channel States that you call a commitment and so you want to send a payment or route a payment or whatever, you update the commitment to say that, okay, as long as the hash is revealed then the payment goes this way or as long as the timeouts reveal has passed and the payment goes the other way. And so you’ve got this history of commitments to the lightning channel that goes back for however many payments you’ve made, however long you’ve had the channel open could be at this point, I guess it could literally be years in the time that some people have had channels open on main net. And if you’ve had a lot of activity, there’s a lot of updates and so you don’t want to have to keep all of these updates forever.
AJ Towns: And the way the lightning works at the moment is that if you, if you publish any old update then you lose all the funds in the channel. And that’s fine, if your server is completely reliable. But if you somehow do an update and then your node crashes and the update wasn’t written to disk and you reboot up and you’ve got the previous update and you can’t reconnect to your channel and they’re not closing it and you close it and then suddenly they reappear and they take all the money, then that’s like, it’s not a high probability risk and we’re all hashtag reckless and whatever else. So it’s not it doesn’t kill the whole concept, but it’s kind of annoying if you want to take it to kind of mainstream production stuff. And so the eltoo approach is that instead of saying that if you publish an old transaction you lose all the money, the idea is if you publish any old transaction, any old commitment from the state, whether it be five seconds ago or a year ago or whatever, then the thing that the other guy can do is publish the new state on top of that.
AJ Towns: So any more recent state, so they publish it from a month ago, then you publish it from two weeks ago and then they publish it from one week ago. And that doesn’t make sense. You always would publish the most recent version you have is the only thing that makes sense in a game theory kind of way. But the problem is to do that, you need to have a transaction with a signature that will be valid for any of these older transactions and potentially any path through these older transactions to get there and all those old transactions. And if they have a different path to get to them, that means that they’ll have a different transaction ID. And at the moment, every signature we do commits to the transaction ID. So you’d have to have a different signature for every different state to get to the current state.
AJ Towns: And that’s like, that means you’ve got to have storage that just grows every time your state grows and is completely, completely unreasonable. Whereas with no input it doesn’t commit to the TX ID. It just commits to saying that essentially it commits to whatever you want it to commit to in script, but it commits to this was, this was a previous state, in the same channel and as long as that’s the case, then this the signature will be valid and few other signatures will be valid on top of it. And so the no input feature lets you do that so that you only have to have basically one signature to have to move from any previous state to the current state. And because that’s just a signature, it’s not a secret in any particular way. It means you can give that signature out to other people.
AJ Towns: And then if you’re offline and they see an old state replayed, they can publish the transaction for you.
Stephan Livera: Right. Watchtowers.
AJ Towns: Gives you, yeah. Efficient watch towers.
Stephan Livera: Right. So as I understand in the current model, watch towers are not as efficient because as you said, they’ve got to save all of these states. Whereas in the eltoo world it would be cheaper computationally or hard drive space wise for them to do that.
AJ Towns: Yeah. So at the moment you’ve got to the watchtowers have got to have a reaction transaction to any previous state that’s been out, which is good for privacy because you’d not, there’s no way real way for them to say, Oh, this thing that I’ve been given and this thing is all for the same channels. So I can tell how frequently the channel is updating. But it’s terrible for disk usage, reliability, whatever.
AJ Towns: With the eltoo world, they just have to have a constant amount of stuff for the current state, which does let them see how often a channel is being updated maybe. But that’s kind of all they get to see. Yeah.
Stephan Livera: And actually while we’re here, do you mind explaining us the difference between the SIGHASH NOINPUT and ANY PREV OUT?
AJ Towns: So they’re different names for the same concept. When we were working on the taproot stuff, it was suggested that no input isn’t quite accurate because it really does sign some parts of the input so that it can be any prev out rather than no input kind of made sense, but they’re the same thing. And I think the current no input BIP will be updated once we’ve resolved this stuff to be any prev out so that that should resolve the slight weirdness there.
AJ Towns: It’s just a different name for the same thing.
Stephan Livera: Gotcha. Okay. Gotcha. And so there’s been this review club going on. Can you give us a bit of an overview what happened with that and you know, what was the objective of it? I guess let’s start with.
AJ Towns: Yeah, so anyone listening to this podcast so far has probably got an idea of how complicated all this stuff is. So we were, myself and a few others were on IRC on basically an optech channel saying, okay, what’s the next steps for this taproot stuff? How do we get it making progress? Like what are we trying to do, are we trying to do like workshops with people or what. And so we throw a few ideas around and one of the things that John Newbery’s been doing has being the Bitcoin core pull requests review club, which has been going really well.
AJ Towns: So he was on the channel and I forget quite how it came up, but we said, well what about a review club sort of thing and kind of got on a Google doc and wrote up what that might look like. And it seemed like it made a lot of sense. And so two weeks later we had 160 people signed up, which is kind of crazy and went from there. So it was basically six weeks long of content. So we went through the taproot BIP and the tap script BIP and the Schnorr BIP. And then we went back through some of the details for each of those things and kind of an in depth review of all the concepts that we went through with kind of references to the academic papers and some links to the code. And we broke everyone up into little study groups so that they had in theory, have a meeting once, twice a week on, on IRC or on Slack or on video chat.
AJ Towns: And hopefully like the idea was that that’d get a lot of people with a much better understanding of taproot so that we can have intelligent comments and criticisms and people would kind of understand the proposal rather than just having an idea that some people are working on this and those people seem cool and they probably know what they’re doing. So let’s just trust that they do and accept it. Cause trust don’t verify. Right. That’s the rule. And yeah, so we had like the first couple of weeks where we were doing I dunno, I don’t want to say high level overview, mid-level overview or we didn’t go into all the horrible details that was, that went really well. Like had huge numbers of questions. Huge interest, huge attendance. I’m not sure. So it faded off a bit after that. I’m not sure if that was because it was getting close to Thanksgiving and everyone was starting to kind of wrap up for the holidays if it was just too intense in contact and content sort of stuff. If there was maybe too much like surveys and stuff getting sent around. But it faded off to like about, I think 20 or 15 people made it all the way through and I would kind of have been happy if only eight people had signed up in the first place, so that’s still pretty good. But 160 down to 20 I don’t know. That’s a lot of attrition.
Stephan Livera: Yeah, I guess look, it’s pretty complicated stuff. I’ll be honest, I was doing a lot of reading myself and yeah, I still struggled. So tell us a little bit about how it went. Did you get much criticism? Was there much constructive feedback?
AJ Towns: So there was very little criticism. Like one of the things we’re concerned about is the having the, so rather than having pay to pub key hash, we’re having a taproot public key as part of the output. So you’ve always got the public key there and public keys in elliptic curves are vulnerable to like, I won’t use quantum supremacy because that apparently doesn’t actually mean anything. But if you have effective quantum computers, then those fast ways, if you actually have effective quantum computers, which is like a long way away, but if you imagine that you did, then you have fast ways of going from your public key to your private key. And if you have a hash in the way, then that kind of makes that more difficult but not in any effective way. So we were pretty worried about that and thought about it a bunch and, and I know Peter’s made some Twitter posts and stuff about why it doesn’t make sense to think of that as protection.
AJ Towns: And so that was a thing we worry about, continued to be a bit worried about as people follow the proposal, if that becomes more of a concern than we think it should be. And there are kind of other things maybe like that that I can’t think of off the top of my head that it’s really been much more, yeah. Okay. What you’ve decided seems to make sense and we don’t quite understand this explanation. Can you go into it in a bit more detail or we understand how you explain it on IRC, can you put that in the actual text rather than just explaining it to everyone individually each time. And so there’s been, there’s been a bunch more update the rationale to explain things better than actual changes to the spec. We had the one big change before the spec was going from 33 byte public keys to 32 byte public keys.
AJ Towns: So like currently all your public keys start with a 02 or 03 and that doesn’t really add any useful security whatsoever. So we’re just dropping that and keeping the bits that do add the security. And so that was just adjusted by John Newbery, I don’t know, mid year sometime and required a bunch of updates for that. From the actual review club we’ve gone into a problem with the bech32 bc1 address format. So it turns out that you can add, if you’ve got, if you’re unlucky and you have a P towards the end of your address, then you can add q’s before and come up with different addresses. And they still pass the check sum, which is what’s meant to avoid that kind of, you make a typo, the checksum fails, so you get an alert about it.
AJ Towns: But if you make this particular typo, you don’t get an alert about it. And so that means that your addresses, the address that goes on chain is different. So it’s not a problem for SegWit as it stands because the only two valid sort of things are 20 bytes and 32 bytes, which is more than just one q. But the original idea with taproot was to leave 33 byte addresses basically as unencumbered so that we can do future upgrades with them. And that would have allowed someone to, if they can convince you to accidentally type a q, then that means miners can still the money that goes to your address. So there’s been there’s been some, like that was raised as part of the review club and the review sessions and has been something that we’ve been working to come up with a fix. So that’s probably gonna result in a update to the bech32 specification. And basically some restrictions in the code to say that if it’s not a 20 byte or a 32 byte thing, then it’s not something you use bech32 addresses for anymore.
Stephan Livera: Right. Yeah. I see. And there was a little bit of, I think Pieter, as you said, Pieter commented about this idea of the supposed quantum safety of Bitcoins that are stored on a UTXO that has not had its public key exposed. Right. And.
AJ Towns: yeah.
Stephan Livera: And so this supposed argument that sort of goes back and forward and I think Pieter’s argument there was that look, even in that world, there are many Bitcoin UTXOs out there today that have had their public key exposed. And I think the other argument was also that even in the case that you have not yet exposed the public key for your UTXO, at the point which you broadcast your transaction, but before it’s been confirmed, there is still the risk then that somebody could take it then and try to, you know, theoretically again, this might be a long way away, it might not even happen? But they could theoretically try to take it and basically steal your bitcoins in that time.
AJ Towns: Yep. If you’ve got a quantum computer that’s already science fiction, so what makes you think the quantum computer can’t solve a public key in the 10 minutes it takes to find the next block. And then they solve they solve for the private key, then they create a new transaction that has double the fees. So basically RBFs your transaction and then they get all the money. By then their transactions are vulnerable to someone else with a quantum computer. So are they stealing the funds? Or are they just breaking Bitcoin? And like the other thing is that there’s a lot more ways that you reveal your public key than you might think. You don’t have to just spend it or reuse an address. If you’re doing lightning, then you’re constantly revealing your public keys to your channel partner. If your using an xPub and sending that to your auditor for tax purposes or something, or your using Electrum or something else that sends xPubs out to other nodes, then that reveals the public key so.
Stephan Livera: Yeah. So just, yeah, so in reality, most people have in some way exposed a public key for many, if not all of the UTXOs, unless they’ve been very, very careful in terms of what software, what set up, you know, using their own Electrum server, et cetera. And so I guess the argument then was, look, it’s not really actually saving you much, so that’s why we’re going to, you know, we want the benefits of taproot and tapscript and so on. And that was essentially the argument. Right?
AJ Towns: Yeah. Yup.
Stephan Livera: Okay, great. Also just had another question around the review club. In terms of participants, were there any who came from more like the wallets world or hardware device world? Did they have any feedback in terms of how it might impact their software or their hardware or their product?
AJ Towns: I don’t think we got super in depth feedback like that. Everyone was still pretty much at the stage of learning how this works, rather than actually getting to the point of adapting it into their own projects. And I think the, I haven’t got today’s numbers, but we got like 13 responses on the, what was your final analysis of this? And they were all positive. We should move to the next step and start getting code and patches out. And as we like move to getting code then test cases and stuff. So we’ve already got code that we’re pretty happy with, but test cases, we’ve got test cases but they’re not, they’re not as up to scratch as we’d like them to be. So I think the next phase is probably going to be doing lots of more test cases, getting people to help break the test cases or find ways of breaking the code that the test cases don’t catch and setting up a test net and then getting the test net for people to actually integrate with their software I think it will be more interesting. So we mostly had like, yeah, I think we can, we can work out cool multisig things to do in our use cases for this, but only at the on paper level, not at the writing code. Finding all the little problems that there might be with that.
Stephan Livera: Let’s talk now about upgrade pathway. So as you were touching on their test cases and so on, what would an upgrade pathway look like and what’s been proposed?
AJ Towns: So I said earlier about the OP NOP and the OP SUCCESS. So the OP SUCCESS’ let us add a whole bunch of different OP codes that, that might be interesting in the future. One of the ones that’s getting a lot of attention at the moment is Jeremy Rubin’s I think current name for it is check template verify. It’s previously been called OP secure the bag and something else, which I’ve forgotten now. And it’s the first really simple, obviously safe covenant construction that we’ve seen. So the idea is basically that you say, okay, at this transaction it’s going to go to these five addresses in these five amounts, but I’m not going to do that yet. I’m going to just commit to doing that now so that sometime later, maybe when fees are cheaper, I’ll send this full transaction that spends to all these people, but for now I’ll just commit to it so that they’ll know they’ll get the money eventually, but I don’t have to construct this huge transaction for it because nobody’s in any rush to get the money.
AJ Towns: And so that’s, that’s the first condition we’ve had with the first way in Bitcoin. We’ve had of saying that a future spend of this stuff is constrained in some way. Like normally you get the funds to your address, you can do whatever you want with them. You just have to be able to sign for them. But this one says that it doesn’t matter how you sign for them, you can only send this funds on to these people. And so that’s, I don’t know, at a technical conceptual level. It’s a pretty interesting thing. And the use cases is got in the proposal for it. Seemed to make a fair bit of sense and seem like they’ll enable some kind of interesting use cases. And so that is something that we can do with an OP NOP So it’s not particularly enabled by by taproot.
AJ Towns: The interesting use case enabled by taproot is for alternatives. So if you want to have the check template verify on the one condition happen in one way and under another condition happen in another way. Particularly if you want to have, so in the future, if fees goes down, then it’s easy to do it. But if fees don’t go down, maybe you want to reduce some of your change that you’d be getting from it just to make sure it goes out eventually. And maybe you want to have that time lock so that only happens if fees haven’t gone down over a week or something like that. And so that’s the biggest thing that I think people are interested in at the moment. There’s other longer term stuff like OP CAT, which lets us do other kinds of smart contract stuff, which is just relabelling some of the OP codes that got disabled because there were basically exploits available for them.
Stephan Livera: And so in terms of how it would be like, what’s the next steps, I guess a BIP past to get proposed? Oh, sorry, the BIP is there rather. But in terms of like signaling and someone, could you, could you outline a little bit of what are some of the possible ways that could happen?
AJ Towns: Do you mean for taproot or for other things?
Stephan Livera: For Taproot.
AJ Towns: Okay, so for taproot, the next step is to get numbers assigned for the BIPs. So I think there’s still a couple of open issues, pull requests, or at least there were a couple of days ago. And so we’re going to get those resolved and send a pull request to the BIP repo to get numbers assigned so that we can start calling them whatever number gets assigned rather than the draft Schnorr BIP and the draft Taproot BIP, and the draft Tapscript BIP. And yeah, that’s pretty proforma. So that’ll happen. And then we’ll start working on the code and getting pull requests up for Bitcoin and having a test net ready.
AJ Towns: I don’t expect that to result in major changes, but who knows, maybe it will. You’ve got to leave that possibility open. And so we’ll get the code worked out and hopefully people will do some, some trial. Can we make a test net version of lightning work with this payment points with this design of taproot and Schnorr and whatever else. And so once we’ve got all that done, that’ll result in a pull request to Bitcoin. So we’ll have the code in Bitcoin, but it won’t be executed. So it’ll be there so that it can be enabled in via version bits or whatever in future. And the idea behind that is so that the code’s there, it’s not no longer a major change to Bitcoin to activate it and release it. So that we can have these discussions about UASFs and whatever else without that having a huge impact.
AJ Towns: On the code and therefore taking forever to get in and causing more delays. And yeah, we’ve kind of deliberately not discussed exactly how activation will work because that’s A) it’s something that the community has to decide and B) It’s something a lot of people in the community have very strong opinions of. So it’s probably going to be a Twitter flamefest or whatever about it. And I know just in private discussions already, there’s people who strongly disagree with me, so I don’t know if that’s, I can say there’s strong disagreement amongst lots of people, but so I at least feel like I’m going to argue about it. So I imagine that means lots of other people are going to argue about it too.
Stephan Livera: Well, what’s your position then? What’s your thought on it?
AJ Towns: Well, I think like on the good side, I’m in favour of UASF, so I liked the BIP148 approach and a bunch of people didn’t like that. They thought it was too risky and it was indeed risky. And whether it’s too risky is a judgment call and I didn’t, I thought it was the better choice amongst the possible options. Other people don’t agree. And so which one, which approach we take, is going to require some resolution of that potential disagreement. But the other thing is I don’t think there’s any possibility of wrecking miner’s setups in the way that SegWit wrecked ASICBoost setups. If hypothetically anyone was actually using it cause nobody has admitted to it I don’t think. So I don’t think there’s going to be the same actual opposition that the ended up being to SegWit. So in practice, I think the whole UASF argument won’t actually matter. Like won’t practically matter, it might be good to have as a reserve or as a policy thing to make sure that that problems don’t happen again next time we do stuff so that we’ve got a this way worked twice, we’ll just do it the third time sort of approach.
AJ Towns: But, my suspicion is that will effectively just have a BIP 9 upgrade. That’ll work great and smoothly, and everything will go fine, but there’ll be huge Twitter arguments before we get to that point. I don’t know.
Stephan Livera: Yeah. So could you just outline the, for people who don’t know what is a BIP 9 activation?
AJ Towns: So every block that comes out has a version number associated with it. And the original approach to soft forks was that you’d go from version one, to version two to version three, and each of those versions would be a particular soft fork that got enabled. And there were two problems with that, one is that if you’re doing that, you kind of use up a version every time. And you might run out of versions eventually, like you run out of versions after 4 billion of them, Bitcoin’s meant to last forever so that could actually happen. Right? But the other problem is that what happens if you say that if one of these soft forks fails, so you say, okay, version five is going to be tap root. And so if you’ve got a version higher than five taproots enabled, but then we discovered this huge problem with taproot and we don’t want to actually activate it. If we then come up with a better something that we want to upgrade as version what we can’t do any number greater than five because that would imply that taproot’s enabled. So we’re kind of stuck and at that point, as soon as you propose an upgrade, you have to have it accepted, otherwise you can never do an upgrade again. And it just wasn’t, it wasn’t a well-designed kind of system. So in I guess 2016 we moved to a thing called version bits where instead of having a version number assigned to a thing we have, we temporarily assign a particular bit in the 32 bit version field.
AJ Towns: So check sequence verify was the first one that used this, I think, which was, I don’t know, bit zero I guess. And SegWit used maybe bit two. And so the idea is that while we’re working out whether we’re going to activate the deployment, miners will signal on a particular version bit to say they’ve upgraded and they’ll be able to support mining these transactions and enforcing the rules. And once all the miners have done it and hopefully everyone supports it, then at a particular threshold of signaling on those version bits the rules will start getting enforced forever. And then those version bits no longer have to be set and then they can be reused for a future upgrade later.
Stephan Livera: Yup. And so then that’s the BIP 9 approach. And then what would a UASF approach look like as opposed to that?
AJ Towns: So I think we will always want to have miners signaling just so we can see that they’ve upgraded or not. But the, so the approaches proposed for SegWit were BIP I think 148 and 149. 148 just said that as of the start of August, 2017 or whenever every single miner has to signal for SegWit and otherwise their blocks are invalid. So the idea there was that, okay, we’ll definitely pass the threshold if everyone signals and if we just drop the blocks that don’t signal well that’s the miner’s loss and their risk, so that probably they’ll end up signaling and that’s as it turned out what happened. And the other idea was the BIP 149 approach was okay, our deployments failed because miners has been opposed and we couldn’t really get consensus.
AJ Towns: So what we’ll do is we’ll wait till that properly finishes in November and then we’ll have a new deployment of SegWit, which will just automatically activate at the end of, I think November, 2018, I guess. And if miners, do come around and start signaling before then, then that’s great. We’ll activate it sooner. If they don’t, it’ll just activate at the end. So that was codified as BIP eight I think. So BIP9 is miners signal and it goes in or it doesn’t. BIP8 was miners signal and if they don’t signal it definitely goes in by the timeout. And the only, I guess the big question with deploying these things is you don’t want to ever have, as soon as the deployment starts, then everything’s set in stone and you know it’ll activate at some point cause you want, do you want, there’s always the possibility that the code is buggy or that the plan is wrong and someone will discover that and we’ll just want to back it out and fix things.
AJ Towns: And so we want to make sure we’ve got an option for that. And so at the moment, the option for that is we tell the miners, “Hey, this is a really bad idea. You don’t want to activate this. Please stop.” Or like you on your podcast, reach out to people, I don’t know, whatever. It’s not, developers make a decision. And that’s it. Like that’s, that’s exactly what we don’t want to have happen. And the BIP8 as it’s specified, as soon as you do a BIP8 developers made a decision and that’s by the time out then that’s what’s going to happen. And so that’s not what we want but what we actually do want. That’s where the flame war’s going to come in I reckon.
Stephan Livera: Okay. Yeah. And from a risk point of view, is the risk then that, you know, the network splits and that there’s two, unknown. Like it’s unknown which one? Yeah. Is that the risk in your view or what is the risk then in your view under the UASF scenario?
AJ Towns: So if you have a legitimate UASF with everyone having kind of looked at the proposal or talked to experts, they trust to look at the proposal and like everyone’s discussed it and has opinions and the vast majority of opinions is that it should be good then that’s sort of UASF, I am not concerned about the risks. Like, I think everyone’s clear on what they want to do, where they want to end up, have looked at the ideas fairly thoroughly. Like there’s always going to be some risk that there’s some unknown unknown that’s going to bite you in the butt. But like that’s the best you can do. You’ve got lots of people, lots of different viewpoints and they’ve all decided that yes, this makes sense. The risk if you don’t have that, like, I mean there’s a risk that if you don’t actually have everyone on the same page, you’ve just got a noisy majority on Twitter or something, then you haven’t actually looked at stuff in detail and kind of, that’s mob rule, whatever you like and can go wrong in that way.
AJ Towns: If you’ve got developers making the decision, then that’s the, I don’t know, bureaucracy or the elitist, whatever. That’s not really taking everyone’s opinions into account. So like that’s that sort of risk and there’s just the general, if the code’s wrong, then like we could be losing money or people could be stealing money or you might not be able to spend your coins because there’s some bug that makes stuff not work right. And a lot of those things in a change like this is stuff that we could back out with more development efforts. So I think there’s ways of mitigating all those risks but it’s kind of better to take the time, make sure as many people as are willing to look at things in as much detail as they’re willing to and kind of get as much consensus as we possibly can.
AJ Towns: Yeah. Cause I mean it’s a consensus protocol so getting consensus kind of makes sense. Right,
Stephan Livera: Of course, of course. So are there any takeaways that you want listeners to take away from listening? Any key areas that you would like them to look at and go and go away from with this?
AJ Towns: So if your supporting like a wallet developers or anything like that, like the ones that looking into new stuff like this, whether it be for lightning, whether it be for multisig wallet. So stuff. I think those are the developers, companies, whatever to be supporting. Like the ones that are kind of sitting and sitting on their haunches aren’t doing as great a job. But as far as I’m concerned, like the better people understand this, the better everyone is going to be.
AJ Towns: And if listening to a podcast, that’s an awesome step. If you are up to reading the BIPs or reading other articles about stuff, then that’s great too. If you’re up to writing code or reviewing code and that’s even better. I know there’s at least a few developers that are, that are supported by kind of sponsored Patreon sort of arrangements. So supporting those guys is great. Just being supportive on Twitter and like saying good job or asking technical questions is more constructive than getting in flame wars I find. I don’t know. But yeah, like I think this is pretty cool. I think it’s going to enable a lot of cool stuff and as the more kind of smoothly that we can get this out, unless less conflict or flame wars or whatever, I think it’s going to encourage more development like that.
AJ Towns: That’s been one of the friction points for this. Like SegWit was very painful for a lot of people like making it happen and getting it out and kind of not getting the feedback that this was going to break things at the point when it could have been fixed rather than at the point when it just had to be stopped or suffered. Like the more, the more technical engagement we can have between everyone and developers, the better off we all are, I think.
Stephan Livera: Awesome. Well look, I think we’ll leave it there because we’ve gone for an hour and a half and I’m not sure how much more the listeners will take on some of this stuff. But look, let’s make sure you let the listeners know where they can find you online, or if they’d like to find any more material. Obviously I’ll put the links in the show notes as well.
AJ Towns: Yeah. So I’m ajtowns on social media stuff these days, so you can find me there, and yeah, hopefully it’ll all be great.
Stephan Livera: Hope so, well thanks very much for joining me AJ.
AJ Towns: Yep, Merry Christmas and Happy new year.