WBD215 Audio Transcription

Bitcoin Tech Update with Andrew Poelstra

Interview date: Friday 10th April 2020

Note: the following is a transcription of my interview with Andrew Poelstra from Blockstream. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

In this interview, I talk to Andrew Poelstra, the Director of Research at Blockstream. We discuss the upcoming upgrades to the Bitcoin protocol, including Schnorr signatures, Taproot and Miniscript and what that means to Bitcoin users.

“It feels, in some way, like Taproot is a bigger deal, but it’s because we are taking it a lot more seriously, even more seriously than we were taking things in the SegWit era. The stakes are higher.”

— Andrew Poelstra

Interview Transcription

Peter McCormack: Andrew good morning! How are you?

Andrew Poelstra: Good morning Peter. I'm doing pretty well, how are you?

Peter McCormack: Pretty good, thank you. This is our third time, but this time we have to be remote. We recorded about a year ago in Boston and then we did another one in New York, but we're on a lockdown man! So we've got to do this remotely.

Andrew Poelstra: Yep, exactly. I'm calling in from Austin Texas at my home here, where I'm locked down and I guess you're in London?

Peter McCormack: Well just outside of London, in little Bedford. I just saw you, I was there recently. I like Austin! How is Austin at the moment?

Andrew Poelstra: It's nice. It was storming here yesterday, but it's sunny again now. I think we were going to have on and off rain all week, which is nice. It's very green actually. It's very pretty, but it's nice.

Peter McCormack: What's the lock down state?

Andrew Poelstra: So same as a lot of places, all the bars are closed, all the restaurants are closed except takeout, non-essential workers are either not working or working from home, the buses are cut down, the buses are free, because the drivers don't want to take fares, but they're pretty much empty anyway. Yeah, so that's pretty much lock down.

Peter McCormack: That's interesting on the free fares, because we've had I think 15 transport workers in the UK die and they think it's probably from the exchange of money as one of the potential risks, which was kind of interesting. All right man, well listen, look, I've been doing a lot of shows on the finance side of things and the libertarian response and I've kind of neglected Bitcoin itself for a while. I don't really know what's going on with the tech and this is why I reached out to you.

I thought it'd be good to do an update with you and you can go through a whole bunch of shit that I don't fucking understand and explain it to me like we've done the last couple of times, because I've got no idea what's actually happening in the background. The first thing I wanted to talk to you about actually, we've got a halving coming, what does that mean in terms of the protocol itself? Does it actually have any meaning at all? Is there anything that you, as a techie, as a developer, has to keep an eye on with regards to that?

Andrew Poelstra: So believe it or not nothing at all. So this halving takes us from 12.5 to 6.25, so what does that make it? The third or the fourth halving? Anyway, so the first one, maybe we were a little nervous about what was going to happen, because it had never happened before and then it went off technically, without a hitch and nobody had to update any software. There was nothing funny that happened, nothing weird and interestingly actually, Bitcoin Cash, I think just had a halving and they had no blocks for two hours after that and we're not sure I haven't heard too much about it. It could be just a coincidence, but it kind of raised some eyebrows.

But no from a technical perspective, life just goes on as usual. There is a concern always that when the mining reward halves, because that is the bulk of the payment the miners get, maybe miners will go offline and blocks will slow down, which is possibly what happened to our Bitcoin Cash friends. But other than that, it's just part of the protocol. As far as the protocol, it is a fairly simple one and it's one that we've tested several times in real life.

Peter McCormack: Well we should talk about that because the difficulty adjustment is part of that and somebody, I can't remember the interview now, but somebody told me that is the most beautiful part of the Bitcoin protocol, is the difficulty adjustment. So I think for those people who don't understand this part of mining, do you want to explain why some of the hash rate might fall off and then what the impact will be and what we will see?

Andrew Poelstra: Yeah sure. So that's a fascinating claim, that this is the most beautiful part of what Bitcoin does. So briefly the way that a difficulty, or what difficulty is in Bitcoin, is a way of controlling how much work miners have to do on average to produce a block. So the way the blocks are produced of course, is that miners are just trying very many hashes over and over and over again, they try a hash, they tweak the block by a tiny bit, they change a number called a knot, then if the resulting hash is within some narrow target, then that's great, they get a block. If not, they just try again.

So everybody's trying over and over and over again in parallel until somebody hits the target and what the difficulty is, both inversely proportional to the size of the target, that the higher the difficulty, the smaller the target and the more hashes you have to try. The lower the difficulty, the wider the target. The way the difficulty is computed is that every two weeks, the protocol looks at the timestamps and the blocks. I shouldn't say every two weeks, every 2,016 blocks, which should be two weeks at 10 minutes a block. The protocol looks at the timestamps and the blocks, and says, "Did these last 2,016 blocks take two weeks?"

If they took more than two weeks, then it decreases the difficulty because it seems like mining is too hard, so it should be easier. If they came in in less than two weeks, it seemed like mining is too easy, it should be harder, the difficulty increases and it does so in a linear fashion. Basically it looks at the last two weeks at timestamps, says, "Oh, the blocks came in 10%, too fast, so let's increased the difficulty by 10% to compensate" and then assuming nothing else changes, then next week we'll be roughly on target and we will actually hit that two week target and that's how blocks wind up being spaced every 10 minutes, even though there's always miners coming online and going offline and the price of Bitcoin changes and all these things that otherwise would cause massive variances in the amount of hash power, and then the rate of blocks.

So what the difficulty adjustment does is all of a sudden there's sort of a cliff and every four years roughly, there's a cliff, where the amount of new coins that are minted, just gets cut in half. So right now every block a miner produces gives the miner 12.5 Brand new Bitcoins in addition to whatever transaction fees there are, which I think these days are somewhere between like half and a whole Bitcoin or something. So not a huge amount relative to the block reward or the block subsidy, which is a creation of new coins. Then in a month or two, you might know better than me with the exact date is.

Peter McCormack: Mid-May I think.

Andrew Poelstra: Mid-May okay. So yeah, we've got about a month to go, cool! All of a sudden that 12.5 is going to drop to 6.25 and since the fees, as we mentioned are still a fairly small proportion to that, more or less what's going to happen is that the income a miner makes per block goes in half and that means that miners who are on the margin, who are producing all of these hashes, who are running these computations in the hopes of finding a block, suddenly the value of each of these individual hashes basically is cut in half and if they're unable to pay for their electricity at half the income, which many miners might not be able to, they're just going to stop mining.

So in theory, you could have a massive drop off and hash power right after the halving if there's no compensating price action and if there are a lot of miners that are on the margin. So what happens then, is that for the next two weeks, we'll see blocks coming in very slowly, because there aren't as many miners, as there are only the high margin miners still running and then the miners who aren't able to shut down because they have electricity contracts or something like that. They're just going to keep running and we'll see blocks produced very slowly, but then after two weeks they're up and we have this difficulty adjustment, which will say...

Hey sorry, I keep saying after two weeks, I mean after 2,016 blocks, which will be significantly more than two weeks, the difficulty adjustment algorithm will kick in and it'll say, "Hey, these blocks are being produced very slowly, we should reduce the difficulty to correspond to the new number of miners that are operating and then blocks would return to the normal speed after that" and actually because mining becomes a bit cheaper, maybe more people will come online and we'll see a little bit of oscillation, but it will dampen out very quickly.

Peter McCormack: That's really interesting that point on the 2,016 blocks, because it is estimated a couple of weeks, but rightly as you said, if the blocks are running quite slowly, it could be more than two weeks. So we could see some congestion in the blockchain for some time. Is there an ability to do an emergency difficulty adjustment? Is that something that I've heard about before?

Andrew Poelstra: So the short answer is no. Is it possible? Yes. So is it so in principle, it's possible to do anything right? The way Bitcoin works is ultimately Bitcoin is a social contract, everybody has the software that for most people is Bitcoin Core, but there are other things out there. Everybody has a set of rules encoded in software, which define what it means for a Bitcoin to be a Bitcoin, for a Bitcoin transaction to be a transaction, for a Bitcoin block to be a block, all this kind of stuff. These rules include, among other things, the difficulty adjustment algorithm.

They include the rules for what the difficulty means, for how many hashes on average people need to run through before they're going to get a block and so in theory, if everybody agreed, they could just go ahead and change this and they might change it to allow the difficulty to adjust more quickly or allow an early detection of something like a massive hash power drop off or something like that. We've seen some other blockchain systems try these things over the years and there are two big categories with difficulties.

One is the difficulty in deploying a sudden change to the software. Changing the difficulty algorithm would be a hard fork, meaning that if people upgrade, then they follow the new rules and if they don't upgrade, then they keep following the old rules, and they're incompatible in both directions. Meaning you would get a fork here that should be two separate blockchains with separate rules that has some shared history, all the coins you get split. If this happened accidentally or without prior preparation, there would be all sorts of crazy, messy consequences to that and in practice, you wouldn't be able to deploy such a fork, certainly not with one month of notice.

What would that look like? Somebody would write some code to change the difficulty algorithm, they would publish this on GitHub or they'd publish it on the mailing list or something or on Bitcointalk and people would look at this and they'd just laugh. They say like, "We're not going to deploy a fork in the space of a month, that's not how Bitcoin works and it's not how Bitcoin ever worked." I think no matter who did it, you could have like every famous Bitcoin person write a joint letter with like a hundred signatures from everybody you've ever heard of and it still wouldn't go anywhere. Just the way the Bitcoin community is and the way that Bitcoin users are, they just wouldn't go along with such a thing.

So because Bitcoin is ultimately a social contract and because the politics of Bitcoin are averse to sudden and dramatic and reckless and destructive changes, you wouldn't be able to deploy it. But then there's the second category of problems, which are more technical, where we've seen with a lot of other blockchains that try to do weird difficulty adjustments that really dramatic bad things happen to them. So the most recent example is Bitcoin Cash, which interestingly seems to have come up with a difficulty adjustment algorithm, which is not too far out of the realm of reasonable algorithms and which has worked fairly well for them.

But historically this has been a point of experimentation for different alt coins for a long time, since like 2011, people were talking about this. People would come up with all sorts of crazy schemes, like the Komodo Gravity Well, and then crazy names like this and they would deploy these difficulty adjustment algorithms. What would happen is these coins have seen massive hash power shocks, like they're priced to go down 5% in a day and suddenly it would be more worthwhile to mine Bitcoin then to mine their coin. So then all the hash power would leave and your hash rate would go from a normal amount to zero and then back multiple times within a day or multiple times in a week.

Then these difficulty adjustment algorithms, by trying to measure the hash rate too quickly, or with too few samples, would wildly overcompensate and then suddenly it would be next to impossible to mine any blocks or you'd have a thousand blocks in a minute and you would fail to get consensus because you can't propagate blocks that quickly or what have you. They're all sorts of crazy failure modes that happen when you try to mess with the difficulty adjustment and where I think this comment you brought up about Bitcoin's difficulty adjustment being beautiful, is that it is so conservative. It's not going to cause runaway oscillations pretty much no matter what you do.

No matter what happens with the hash rate, you're not going to get these wild runaway oscillations, it won't converge very quickly. It doesn't converge as quickly as it could if it were designed with fast convergence in mind using also the cool control theory and stuff like this that I don't really understand. But it will converge and it's very easy to understand, right? If the blocks are 10% too fast, increase the difficulty by 10% and you aren't going to see crazy whiplash things.

So I guess a third comment, it's hard for me to see what event could happen to Bitcoin that would cause there to be any appetite for an emergency difficulty adjustment because unlike other blockchains, other coins out there, Bitcoin is not prone to seeing all the hash power disappear at once, or to see some other much more important coin, like Bitcoin just overwhelm the hash power of the system. So you're just a very much at the whim of high variants hash rate. Bitcoin is very stable relative to other systems by virtue of being the biggest, and also by virtue of having somewhat of a conservative culture and community.

It's just that as the biggest, we don't see these wild variances and even if you did, Bitcoin's current difficulty adjustment algorithm, while being slow to react, would ultimately react in the correct way. So we'd see a few weeks or a few months of chaos, where chaos means the blocks are slower than you want them to be, so fees are a bit more expensive. In reality it wouldn't be a big deal and I can't imagine the relative chaos and this is real chaos, of having some sort of fork, a hard fork to a new difficulty adjusting algorithm that might have problems of its own. I can't see that happening.

Peter McCormack: Okay, so realistically, it's just the case of, it's coming, we may have some congestion, it may slow down for a few weeks and we just need to prepare. We have to accept it and what will be will be, but I guess it's just a waiting game then. It's going to be fascinating!

Andrew Poelstra: It really will be, because the last couple of halvenings, we saw the price just ramp way up right before, and then the effect of miner's income was kind of zilch and I don't know why this happened. It doesn't make any sense and it doesn't make sense that it would happen again. Maybe some people are betting on it, I don't know. But there's no reason for that to happen. So this might be the first one where we actually see miner's income get cut by a whole lot and you're right, we're just going to have to wait and see.

Peter McCormack: Fascinating! All right man, well listen, what are you working on right now? What's keeping you busy?

Andrew Poelstra: So keeping on the Bitcoin theme for a bit, I'm actually not doing... Well everything I do is ultimately Bitcoin, but what I've been working on a lot lately is kind of blue sky research, but something that's fairly close to reality is miniscript. I think I've talked to you about miniscript before on your podcast, this has been around for a year or two. I'm not going to go too much into detail, but it's basically a way to make Bitcoin scripts easier to read and to make all the cool features of the Bitcoin script accessible to people using ordinary wallets.

Peter McCormack:       Is this something that Pieter Wuille is also working on? I'm sure he spoke to me about it.

Andrew Poelstra: Yeah absolutely. So miniscript is more or less Pieter Wuille's brainchild. It's Peter and myself and Sanket Sanjalkar, who was an intern at Blockstream, who was one of... He was an incredible intern who did maybe half of the current miniscript stuff, it was him and Pieter working on the whiteboard.

Peter McCormack: I think I met him.

Andrew Poelstra: Maybe you did.

Peter McCormack: So when I interviewed Pieter, there was an intern in the room at the same time. So I got him on for like 5 or 10 minutes at the end of that interview and he spent 5, 10 minutes explaining what he'd been working on. I'm sure that's the same guy.

Andrew Poelstra: Yep, I think it would be. The timing works out. So miniscript is basically a way to template scripts so that you can use it. You don't have to be restricted to a bunch of specific, very restrained templates, there are a whole bunch of cool new features you can use. But now they're in a standard way where different wallets can interoperate with each other, they can do things like fee estimation, they can jointly participate in multisignatures and stuff and not have all these interoperability worries.

So miniscript itself has not changed since you last talked to Pieter, or I should say it's changed in a couple of very small ways. Basically renamed a couple of things to make them more compatible with existing code and Bitcoin Core. But what the exciting new development in miniscript, is that it is being merged... How do I want to describe this project? The way Bitcoin Core handles coins, the way that it identifies the coins that it owns in its wallet right now, is kind of messy.

It started out with Satoshi, the original wallet, which used elliptic curve public keys to identify which coins were owned by the wallet and the thing in Bitcoin though, is that elliptic curve public keys are sort of one component of what goes into an address, one component of what goes into a script that identifies coins, but it's not the whole component. Initially there was this one-to-one mapping, the way that you created an address was you literally took the public key, you put this in a script, which means you put a push public key opcode followed by the public key, followed by the check signature opcode. So three components.

Then you would encode that in some way, and you would get an address out of that. This is, I'm talking 2009, 2010 and actually there was paid IP, where you would connect to another computer and exchange a public key and it was really hokey. Then we came up with what we now call legacy access, where instead of having a whole public key, you actually hash it, you make it a little bit smaller, and then you reveal the whole public key later, when you're spending and so you have another way to think of public keys. Then we had, well P2SH showed up, this is the three addresses, the ones that start with three, where you could do multisigs, you could do slightly more complicated things and now maybe here's yet another way that you have public keys.

Then SegWit showed up and we have these BC1 addresses, these BCH addresses, that are encoded in Bech32 and here's yet another way that an BC public key might correspond to an address. The way the Bitcoin core wallet has worked the entire time, is it's still using the public keys as identifiers, which means that conceptually it's a little bit of a mess, quite frankly. I could give you a legacy address that I generate with Bitcoin core and in principle, you could pop open that legacy address, you could re-encode it as a SegWit address which still has exactly the same public key, but it's a completely different address, send coins to this new address, and my Bitcoin core wallet will recognize it because all it's looking at is the public key.

So what that means is that you can send coins to an address that I never came up with that I never gave you, and I'll still receive them and as you might imagine, this could cause trouble if I'm trying to write accounting software or something around this, I'm going to see coins coming in that I can't quite identify the source of, I'm going to not see coins coming into the original address. You'll say that you paid, but we also prove that you paid, but I won't be able to see the proof. It's just a complicated situation and the reason that this has happened is because it's all been an outgrowth of the original Satoshi public key-based wallet design, whereas Bitcoin has grown and become more featureful, things have been hacked onto them.

So there is a new scheme called descriptors that was developed by Pieter Wuille and now Andrew Chow, and this originated a week, maybe, before miniscript, because I see it as this wonderful coincidence of ideas. The idea behind descriptors is rather than starting with a public key, you actually encode what an address is, if you're using P2SH you say P2SH, if you're using a legacy address, I think you say PK or PKH, or whatever the encoding for legacy address is, if you're using SegWit, you use WPKH for SegWit addresses, and so on.

Then you put your key, so you have what's literally a text file where you have your key encoded and this public key, which might be just a straight up public key or it could be a BIP32 path that describes how to compute the public key. I think those are the two things right now, but there are a couple more things we're going to extend this with. Basically you write out your public key in a way that tells the Bitcoin core wallet how to compute that public key, or how to find it, or which hardware wallet it needs to go ask to get the key and you also tell it how that key is encoded in the blockchain.

"Are we using a SegWit address? Are we using a legacy address, are we using whatever?" So what's cool, I'm going to bring this back into miniscript now, is that the text encoding for these descriptors and the text encoding for miniscript are designed to fit together and so what this means is that rather than going from the Satoshi thing where we've just got one key and it's a free for all, descriptors bring us some structure on that, where now we have a key and we're also specifying how to use that key and how to encode that on the blockchain and which actual address was produced.

Then with miniscript, we can even abstract over keys and say, rather than looking at how keys are used, let's look at how scripts are used, let's have multiple keys, let's do multisignatures, let's do time locks, let's do hash pre-images, all this cool stuff. So when we're going to start seeing miniscript used is basically after Bitcoin core supports descriptors and then extends the scriptures to include miniscript. On the descriptor front, we are rounding the bend, you probably have to ask Pieter or Andrew Chow for real timelines here, but Andrew has been working on implementing descriptors on Bitcoin core and actually overhauling the wallet code, which has been a tremendous undertaking that's taken the last, I guess depending how you measure it, 12 to 24 months and we're finally starting to round the bend on that.

We're nearing completion of the descriptor wallet overhaul and once we have descriptor wallets, aside from the Bitcoin core wallet suddenly being, in my opinion, a real wallet that I'd be willing to put money in, which I wouldn't now, we'll also have the ability to deploy miniscript within core, and then all of these cool benefits of miniscript I've been talking about. We get interoperability, we get new features, blah, blah, blah. Suddenly those are really in users hands because Bitcoin core, which is the most popular wallet, or most popular self-custody wallet, will have support for that. So that's been a lot of exciting development. Jumping topics quite a bit, another exciting thing in Bitcoin is Taproot.

Peter McCormack: Well, let's go back to the miniscript thing.

Andrew Poelstra: Okay!

Peter McCormack: Look, I'm going to let you into a secret. I'm not very technical Andrew. I'm not!

Andrew Poelstra: Oh wow, I couldn't tell!

Peter McCormack: So most of that, I had no idea what you were talking about. The odd word came up where I'd be like, "Oh yeah, SegWit. I know what SegWit is a little bit", but what does it actually mean? So what does this mean for you as a developer? And what does that mean for a Bitcoiner like me who just holds Bitcoin, buys Bitcoin, uses it for things. Does it actually mean anything for me? Will I see any difference or does it just make your life easier?

Andrew Poelstra: Absolutely. So let me answer you the developer question first because that's actually a fairly simple question. So as a developer, I often find myself writing my own special purpose Bitcoin wallet for various one-off projects, because maybe core doesn't quite do what I want or Green doesn't do what I want, or whatever my personal wallet is. It doesn't do coin selection in a way that I want to do it, it doesn't do seed computation and it doesn't change transactions or whatever, blah, blah, blah.

Peter McCormack: Yeah I'm the same. I've wrote one this morning!

Andrew Poelstra: Yeah, pretty much every day I wake up and I think, "How do I want to use Bitcoin today?" and I write a new wallet software to use Bitcoin in that way and this is very meditative for me. This is how I hone my powers. So what miniscript does for me, is there's a whole bunch of really awful, fiddly, temperamental shit that you have to do to write a wallet where you have to estimate for all the coins that you're holding, how large a transaction might be to spend those coins, you have to figure out where the signatures go if you're using a weird script, maybe they appear in a certain order or maybe there's extra filler stuff that you have to put between the signatures.

I have to think about how to... Well I need those sizes so that I can estimate my fees, if the fee is proportional to the size of the transaction. If my wallet is going to interoperate with other systems using the same wallet or using, God forbid, different wallets, say the whole ball of wax there and so miniscript lets me abstract all of that away. I have a library called the rust-miniscript, in the rust programming language and I just use that library and it solves all those fiddly problems for me. So I can actually focus on the business logic that I'm trying to implement into this wallet. So as a developer, it saves me a lot of very repetitive and fiddly work with that. Really, it's just really fiddly.

hey have all these off by one errors you can get, it's all this counting. You break apart a transaction into 50 different parts and count up the bytes in every one, it's horrible! Then as a user though, what does this mean for you? What does this mean for me? So I can tell you something that bothers me and probably bothers you is a concern when you hold Bitcoins. If you own your own Bitcoins, chances are your coins are spread across a number of addresses and every address has some public key associated to it, just a single public key and then maybe these are all derived from a BIP32 seed or something.

Maybe you have a Crypto Steel or a titanium plate or whatever you might have that's encoded the seed, but ultimately all of your coins are controlled by single private key and if you lose those private keys, then you will never get your coins back and if somebody finds that secret key material, they would be able to steal your coins and you will never get your coins back. If you die, or have amnesia, or suffer a brain injury or something, and are no longer able to access the secret key material, then you will never get your coins back and if your software become unmaintained and you weren't using a very popular standard and there are no longer software that can decode the secret data, then you will never get your coins back.

This is all very uncomfortable, I think, as a Bitcoin user. I've got a couple of Bitcoins somewhere other that are stored basically in this fashion where basically, if anything happens to me or if the wallet that I wrote this morning, I no longer feel like maintaining, which has happened to every single wallet I've written by the way, this is constantly happening to me, and then I have to go back and read the code whenever I want to spend them, it's a very fragile situation and what I would like, first of all, I would like to have a multisignature solution. I would like to have, rather than one single key, have multiple keys, so maybe have five keys and any three of them brought together are able to spend the coins.

This is something that there are actually several solutions out there in there are various services. There are companies that will be a countersigner for you, and that will hold keys for you. So just adding multi-signatures is kind of a solved problem and I say kind of, because while this is completely solved, these different multisignature services are still behaving in an ad hoc... I guess ad hoc is what I want to say. So if the service that you're using goes out of business or something, you'll have their software and you'll be able to recover your coins by whatever recovery mechanism they happen to have.

But in general, you're going to have to move your coins, because they went away so now you need to move the coins and hopefully there's somebody who has written software to allow that kind of recovery to happen, which there will be of course, with anything remotely widely used, but it's still an ad hoc situation. So that's one thing, you want to have multisignatures. But then another thing that I would like to have for my own coins is some sort of dead man switch where if I don't move my coins for 6 months or for 12 months or something, I would prefer if the coins then transferred from my control, because presumably I've lost my keys or something.

If I'm not moving the coins ever to some alternate set of keys, and maybe that alternate set is held by my parents or my lawyer, or something like that, and so I'll still have a recovery mechanism. To the best of my knowledge, there are no services out there that offer this kind of recovery mechanism and the reason is that even going from single keys to multisignatures, in the absence of miniscript, it requires that you hire some people who really knows Bitcoin script and knows how to do weird things with Bitcoin, going from multisignatures to these various conditions, where at time zero, you have a certain set of keys, and then at time six months, you have a different set of keys and maybe at times 12 months, you have yet another set of keys.

Now the technical requirements are much higher and it's not only the technical requirements for just coming up with a script that does this, which miniscript solves, it's also the technical requirements for, how do you estimate fees and how do you produce transactions, which miniscript solves. Then also the technical requirements of, how do you make this work with various hardware wallets? If you've got a multisignature setup, how do you make sure that whatever software that your user is using is going to work with your complicated multisignature with counterfactual setup?

And that last problem, is something that works for multisignatures, because everybody likes multisignatures, and at least for a small number of keys, there's only really one way to do multisignatures and everybody has some way of supporting it, including core, including Trezor, and Ledger, and Coldcard, and all the popular hardware wallets, and Electrum, and Armory, and all that good stuff. As soon as you get into complicated scripts, you lose that interoperability. So suddenly, your service provider is going to have to write their own special purpose software and you, to use a service provider, are going to have to use their software instead of using Bitcoin core or Electrum, or whatever you'd normally be using.

As a user, that's pretty scary and I wouldn't go for it and I think most people who are conscientious enough or wealthy enough to want this kind of service are also not going to want to take that risk. So as a result, it's not a good business proposition. You're creating a business that requires you hire a bunch of very expensive experts to produce a product that people don't quite understand that they want and the people who do understand what they want, won't use it. What do you do? So what miniscript will do is solve all of the problems that I just listed.

It will not only solve your technical problem for you so you can get away with fewer experts or maybe less time from your experts. It will also solve interoperability issues, which are the reason that people are hesitant to use this in the first place and as a side effect of solving interoperability issues, not only do you let your users use their own wallets, it also means that if you go out of business, or your software becomes unmaintained, or something crazy like that, then there is a way for your users to recover their coins, because if I have a dead man switch that activates in a year or in several years, or whatever, and by the time it actually activates nobody remembers how to use it, what have I accomplished?

So miniscript, by virtue of being a standard that covers all of the different use cases I'm talking about, makes this possible. So once we have miniscript deployed in core and in a few other places, then I'll actually be able to do this crazy dead man switch scheme that I have been planning, but have yet not done it for many years right now. Just so you know, I shouldn't say this in public, but if you kill me, my Bitcoins will just disappear. There's no way to recover them right now.

Peter McCormack: Well that's not good.

Andrew Poelstra: Yeah, it's really not! I won't mind so much, but certainly...

Peter McCormack: Someone will!

Andrew Poelstra: Somebody will, yes!

Peter McCormack: All right, so listen, the first time we met was... Actually, prior to us meeting, I sat down to watch your presentation about Schnorr signatures in Boston. Do you remember that, at the expo?

Andrew Poelstra: Yes!

Peter McCormack: And that was about two hours before we did the interview and I watched that presentation and I was like, "Oh shit, what are we going to talk about?" And then we made that show that everybody loved. Everybody loved that show and it was good fun, but this is important stuff right now, right?

Andrew Poelstra: Yes.

Peter McCormack: This Schnorr stuff. This is related to Taproot, yeah?

Andrew Poelstra: Yep, this is related to Taproot.

Peter McCormack: So you're going to have to go through this and explain again to people what Taproot is firstly and then talk to us about the progress that's being made.

Andrew Poelstra: So Taproot, on a high level, is actually very simple. So when I've been talking about miniscript, I'm talking about Bitcoin scripts that you do all of these cool multisignatures, or time locks, or hash locks, or different if-thens, and alternatives and blah, blah, blah. The idea behind Taproot is usually your coins are controlled ultimately by one public key, this is the original Satoshi vision, right? One public key, one coin.

There's just one public key that controls the coin and that corresponds to one user. But then, it turns out there are actually many other cases. It doesn't have to just be one user where there's one public key. If you have a multi signature, you've got three people who all want to simultaneously sign, there's a way that they can produce one public key that represents all of them, and then they interactively do some protocol and they wind up with a signature and you can do more interesting things. You can do thresholds, you can do various complicated signing structures and blah, blah, blah, and whatever.

But the upshot is that the vast majority of coins in Bitcoin, even ones that aren't normal, single key wallets could actually have their spending conditions represented by one key and the only time that you need to use Bitcoin script is in the case of weird things like this dead man switch, or in the case of a non-cooperative close in Lightning, or in the case of atomic swaps where somebody has to reveal a hash [inaudible 00:44:40], or something like that. So what Taproot does is it says, let's circle way back to the original public key scheme for holding coins. Let's stop hashing things and let's stop just encoding them in a script.

Let's just throw a public key there, if you have a public key, but here's the thing, we still need scripts. There's a reason that we have all this scripting mechanism. So what Taproot does is it let you tweak your public key in a way that it cryptographically commits to a script, but continues to be a public key. It continues to be a key that somebody can sign for and in fact, the same people can sign for it. If I have a public key that I can sign for, I can tweak it using the Taproot mechanism and I will still be able to sign for it, I just get a slightly different public key.

What's cool about this is now I can go throw that on the blockchain and the blockchain will see it as a public key. If I spend the coins by signing with that public key, that will just work and nobody will even know that I did this tweak. I'll have a script committed in there, but nobody will even know that it existed. But if I find that I do need this script, because say, my original keys were lost and I need to use a dead man switch alternative or something like this, at that point I can go to the blockchain, I can provide what's called a witness. I can prove that actually, this public key committed to some alternate script. I provide the new script and then I satisfy the script with whatever my alternate keys were or whatever. I get all of the benefits of Bitcoin scripting system, but unless I actually need to use them, I don't reveal them to the blockchain.

I don't even reveal that I was using a script, and this, of course, improves scalability. The less things I reveal to the blockchain, the less things people have to verify, and it also improved my privacy because now, even though I'm doing something complicated and uncommon, I have my coins stored in just what appeared to be ordinary public keys, the same as people using a Bitcoin core wallet and the same as people using some sort of multisignature wallet. In fact, the same as people using, pretty much, any wallet scheme that's out.

But even Lightning payment channels, assuming co-operative closes are going to look identical to anything else, as everything's just one public key. One public, one signature. So that's what Taproot is. The core premise of Taproot is a trick where you take a public key and you're able to commit to some data and what we're using this for is to commit to a script. The idea is that, usually overwhelmingly frequently, the script will never be used, so it never gets revealed. Okay so that basic premise, more or less, has not changed in the years that we have been talking about this.

There has been a fair bit of detail-design iteration on Taproot that is very valuable but most of it is a bit too technical to get into here. There has been a whole bunch of both outreach and implementation and this happened since we've last talked. On the outreach front, there is an entity called Bitcoin Optech, which is sort of like a group of people who have been working on messaging between large entities like corporations and businesses. They don't have to be big, just anybody trying to use Bitcoin in an institutional setting and people doing Bitcoin protocol development and people doing wallet development and trying to bridge the communication gap here and make Bitcoin possible to use for institutional people.

The Bitcoin Optech folks, Mike Schmidt, John Newbery, and several others who I'm just not going to name, put together a series of workshops on Taproot using what are called Jupyter notebooks, a sort of interactive Python script where people were able to show up for these workshops. We've had a few of them, there was just one in London, recently, Adding maths to Bitcoin. There was one in New York that I attended alongside a conference... I'm blanking on which conference it was. There was one in San Francisco that I wasn't able to go to and this helps people figure out how to use Taproot. So you go through how some of the cartography is constructed and we got a lot of really valuable feedback from people doing this.

Alongside all of these sessions, we had an IRC channel open where Pieter and I and Andrew Chow and all of the people working on development were able to talk to people actually trying to use Taproot and get a feel for where the pain points were, get a feel for what questions people had, get a feel for what concerns people had, and we're able to update the design and also update our BIPs, our writeups and our rationale, and our proof to reflect all of these things. So it's been awesome! That was really, absolutely spectacular. First time I went to one of these sessions, I was just blown away at how well put together this all was, it was really great. Then on the implementation side, we've written a whole lot of code. When I say we, I don't actually mean me.

Pieter Wuille of course, as always, Andrew Chow, Jonas Nick, Tim Ruffin and Greg Maxwell even pops his head up and contributes from time to time, which is nice. He's been mostly laying low for the last couple years, but his alive and sometimes he reaches out. There is a branch of Bitcoin Core, I don't think there's pull requests, it's a private branch on Pieter's repo that has Taproot implemented and there is a reference implementation of all the Taproot code and the derivations and stuff that are in Python and I think, a couple of other languages. There are a whole bunch of test vectors that people have produced to poke at various possible ways to spend coins, and the various possible ways to create hidrosis. So all of that implementation work has been done.

As we iterate over the design, I mentioned there have been a few technical changes that we made. All of those technical changes required redoing all the test factors and tweaking a bunch of things and so forth. So that's on the Taproot side. That's sort of on the verification on the consensus code, on what actually, would go into Bitcoin-core nodes to verify Taproot and to verify Taproot outputs. But there's a whole other half of this, which is the signing side, which is, if I have coins controlled by one of these Taproot outputs, how do I actually, send them? This brings us into the second thing that you mentioned, which is Schnorr signatures.

This is sort of how Schnorr signatures and Taproot are related. Taproot is this new Bitcoin output type that comes with new rules for validation and new scalability and privacy benefits, Schnorr signatures are the digital signature mechanism that Taproot uses. What Schnorr signatures get you is the ability to have a single public key that represents a whole bunch of different signers, or a single public key that represents an atomic slot, or a Lightning payment channel, or something like this. The current Bitcoin scheme uses an alternative to Schnorr signatures called ECDSA.

Peter McCormack: Yeah, I remember that from the last one. That was to do with the Schnorr signatures, which had like a 50 year patent?

Andrew Poelstra: Not 50. I think it was an 18-year patent, from 1990 to 2008 I believe, was the lifetime of the patent. ECDSA was developed in response to this patent and ECDSA is remarkably similar to Schnorr in spirit, but on the algebraic-level, on the technical-level, it differs from Schnorr in a couple of important respects. The results of these changes is that a lot of the cool multi-party things that I've been talking about are very difficult to do with ECDSA and they require a much heavier crypto.

They're much slower, they might require new assumptions, they might require multiple rounds interaction where Schnorr would require much fewer rounds of interaction, it's harder to understand the stuff, it's harder implement it, it's harder review it and as a consequence, more or less, nobody has ever deployed, certainly not in a production setting, nobody has deployed ECDSA multi-signatures. Although I understand there are a few people working on this as people are getting impatient with the Taproot deployment timeline. People are trying to do it for ECDSA, but you can tell it's much slower and more complicated and more fragile because of it. Schnorr signatures are, from a unit perspective, are just this minor component, where it was swapping out the ECDSA component for the Schnorr component and as a result there is, basically, no changes.

But from a development standpoint and a functionality standpoint, suddenly, a lot of cool things that were previously kind of very theoretical or very insufficient things become possible and importantly, the most important one of course, is these multi-signatures. We have one key that represents multiple signers and they just interactively produce signatures whenever they together want to spend coins. On the Schnorr signatures side, around the multi-signature side, there has been quite a bit of development. I'm trying to think. I guess the last time we talked would have been after the talk of the MIT Bitcoin Expo, which I guess was over a year ago now.

Peter McCormack: No last time we talked was after we got into bed together in New York.

Andrew Poelstra: Ah, that's right, Consensus, I always forget! I go to the Consensus conference in New York, there's all these suites, there's so much money everywhere, there's so much coke, it's hard for me to remember sometimes who all I get into bed with! But you're right, that was the last time.

Peter McCormack: Let me just ask you another couple of things on Taproot. The first thing, again, is the same question as before, for me, as a frontend user who never digs into the tech too much because I don't understand it, again, how would it affect me? Is it just something that will happen in the background and I won't notice a difference?

Andrew Poelstra: Yeah, that's correct. You won't.

Peter McCormack: I should have asked that at the start. But let me ask you another thing. This is a major change, right? This is not an insignificant change. Do you get nervous about a change like this different from any other change? Do you and the other guys, when you're talking about it are you nervous about this at all?

Andrew Poelstra: Believe it or not, no. What's very interesting to me is that this change in terms of scope is much, much smaller than SegWit was. The reason I say that, is that Taproot provides a new open-type. It means it's not a new address type because SegWit was using a new address-type that was future-compatible with this new version. But with the new output-type, it's a new way of storing coins that wallets can choose to support and what that means is that all of the risk inherent in Taproot is limited to these new outputs, it's limited to the people who want to use them who are able to deploy and do testing and stuff on their own schedules, and then, the consensus part, that the nodes are validating all the new code.

When they see these new outputs, they need to validate those new outputs, of course, but they don't need to do anything more than that. So SegWit was kind of terrifying because SegWit would change the transaction formats, introduce this new witness field, so on the peer-to-peer layer when people transmitting transactions around there was this negotiation that had to happen to decide which transaction format was supposed to be used. There was change in the size of transaction as measured by legacy nodes versus as measured by upgraded nodes, as there is change in the format and the waiting of blocks.

There was a change from the pre-SegWit model where if you tweaked any part of a transaction including stuff like the signatures, then it would change then it would change the TX-ID, which is bad. This causes immalleability, this causes all sorts of problems. SegWit went into this witness field where if you change the witness field and the transaction ID doesn't change, this makes it a little bit difficult sometimes. If you see the same transaction with two different witnesses floating around, how do you deal with that on the peer-to-peer layer. There are all these really complicated logistical questions and it affected every part of the Bitcoin consensus protocol. It's really terrifying!

It's a miracle that SegWit was implemented and deployed as well as it was and that nothing awful happened. It was kind of terrifying. Even aside from all of the messaging and fear mongering and all of that about SegWit, independent of all that, that was all the stuff that you read in the news during the SegWit time was for the most part just technically bankrupt. It was meaningless, these were not real and there was no meaningful opposition to SegWit that you've heard about in the news that people were shouting about and stuff.

But there really were reasons to be scared of that level of change and that was reflected in the amount of testing QA and the tremendous amount of time that went to developing and implementing SegWit. Taproot, in contrast, is much narrower. It doesn't introduce... So we made a lot of efforts to minimize the number of new things that are happening even within this output type we have no new cryptographic assumptions. Okay, we're still using Schnorr instead of ECDSA, but we're using the same elliptic curve, we're using the same hashes and we're using the same type of merkle trees.

We are simplifying some things, we are making somethings more robust versus the way these were designed in other parts of Bitcoin. But ultimately, it's all the same stuff. It's just we've taken the lessons that we've learned, which for the most part, are just fairly narrow, minor technical things, and we're putting those into Taproot and then it's limited to just this new output type. It doesn't change the peer-to-peer layer, it doesn't change the way blocks are formatted or transactions are formatted and it doesn't change the address format. Basically all the software that we're using today will continue to work in exactly the same way after Taproot is deployed and so for that reason, Taproot doesn't scare me at all.

Peter McCormack: It's a breeze.

Andrew Poelstra: Yeah, what's interesting is that the Bitcoin community demands an even higher standard of reassurance than it did back in the SegWit era, so the kinds of arguments that we're making to argue security and argue that this is actually a simple change, as this is the least risky thing we could be doing. There's a lot more work that goes into this, we have some published papers related to this, we have mathematical arguments of security of the new crypto transactions, even as narrow as they are and even though there's stuff that's been deployed, we have arguments for security, we have a lot more eyes on this code and on this design.

It was really, again, it was amazing what the optech folks put together when they did this first workshop. I remember they were expecting to get 20 or 30 people to sign up for it, and it got I think over 150 with just different developers working on the Bitcoin protocol and working on wallet stuff who wanted to learn about Taproot, so we got a tremendous amount of feedback from a very diverse crowd, which is great. It feels in some ways that Taproot is a bigger deal, but it's because we're taking it a lot more seriously, even more seriously than we were taking things in the SegWit era.

The stakes are higher, right? Bitcoin is worth more is more from the entrance. It's not just the price of course, the price is maybe the least important thing, but Bitcoin is much more entrenched with mainly large institutional players looking at it. We have a lot of people, we have like a generation of people who grew up to become software developers, who became cryptographers with Bitcoin, I know a lot of people for whom Bitcoin has been their entire career and we're a lot more conservative about how we deploy changes like this.

Peter McCormack: All right, so there's a lot of stuff happening that's going to make your lives better in terms of protocol developers. Anyone who is a protocol developer is going to be very happy with all that's coming and also it's going to make Bitcoin itself more efficient, right? It's going to make it better. But in terms of a normal user like me, all this stuffs got to happen and I'm going to blindly not know any difference. I'm not going to notice any of this amazing hard work you've all done, which seems a little bit unfair!

Andrew Poelstra: It is a little bit unfair. There's a couple of things that you will notice. So what you will notice actually, is that the fee pressure is going to go down. A consequence of the scalability improvements that come as Taproot, a consequence of having one key, one signature for pretty much every coin is that the size of your transactions and therefore the amount weight that you have to pay for of part of the block is going to go down, so fees will be a little bit cheaper.

Another thing that you will notice is that because it will be possible to do multi-signature stuff in this more efficient way, you'll see an increase use of multi-signatures, and the upshot is that you'll see less fragility. So right now, you remember earlier on this podcast, we were talking about how I was just rattling off a whole bunch things where if they go wrong, you lose your coins forever. When you introduce multi-signatures into the control of your coins, you are providing redundancy against those if you lose your keys, you lose all your coins.

So rather than having one set of keys that you keep under your pillow beside a handgun, you've now got multiple kinds of keys that each, independently, would all have to be lost and presumably, you would notice as they became compromised, and so now you have that much more redundancy, and your coins are that much more secure and you have some ability to recover from partial losses of keys, because this can now be deployed in a way where what hits the blockchain is again, one key, one signature, you no longer have to pay a penalty for them. So you'll see as a user, both of this stuff is more popular, it's more widely deployed and also that it's not going to cost you the way that it would cost you today.

Then I guess, the third thing of course, is the interoperability that I've mentioned, although that's more... That's not necessarily a Taproot thing. That's really just the ecosystem maturing and people working better with each other kind of thing. As a user, you'll find... It's funny, ultimately you want to use all the expected stuff, right? You'll see the software is more robust against various failure modes, you'll see that it's cheaper and more efficient to use and you'll see that there are some new features that exist in various services that we're using.

You will also find, although as an end user, you won't see this, that privacy is improved by this. This is something that unfortunately is not user-visible at all. It's really, really important to Bitcoin to work as a currency and to work as a network, but it's not something that's really user-visible. I guess as a user, you'll just see things just generally get better and more mature in ways that wouldn't be happening without Taproot.

Peter McCormack: Interesting. So what comes after Taproot? What's the next big thing? What are you guys all debating in the background that you want to do next?

Andrew Poelstra: In the short to medium term, one thing that we need after Taproot, and possible in conjunction with Taproot is we need a new... What's called a new SIGHASH mode. This is a very narrow technical thing. We need the ability to sign transactions where we don't necessarily commit in our signature to the use out coins that we're spending. There's a bit of a controversy about introducing this ability into Bitcoin, it's a bit of a dangerous thing. It means that, if I create a signature where I'm not committing to the specific coins that I'm sending, that's means that if that signature gets out, if it's floating around the internet, then whenever people send coins to me if they send coins to the same address as before, somebody will be able to grab that signature and use it to spend those coins.

So the signature floating around can be used multiple times, so that we can pause a replay attack. Unfortunately, there are a few other things called replay attacks out there but this is one example of them. These look very dangerous. Why would we want those? There is kind of a controversy about it. The reason that we want it is that in protocols like Lightning where you have payment channels that are produced where, basically two participants rather than directly sending coins to each other, they put some coins into a pot and they repeatedly sign transactions which send the coins to the two users in different proportions.

So maybe initially, we're sending one coin to me, one coin to you and if I want to give you half the coin, then we change it, so now I'm sending half the coin to me and 1.5 to you. We're sort of adjusting the proportions. We keep signing new transactions, spending money out of the same pot, saying new transactions and sending it to each other in various proportions. The idea is that eventually we're going to part ways and then we'll take the final transaction and post that to the blockchain. But until we do, rather than going to the blockchain, why don't we just keep replacing this one transaction and just changing the proportions, and then we don't pay the fees, we don't have to take the privacy hit and we don't have to reveal anything to the blockchain.

There is a problem with the scheme I just described where if we have a whole ton of transaction signed that are all spending the same coins, then when we part ways, ideally, only the most recent one would be what gets published to the blockchain, but there's nothing stopping you or I to go back into the past, into the giant piles of transactions that we've signed throughout our interaction and just find which ever one is most beneficial and you're going to find which ever one was most beneficial to me and post that to the blockchain. So how do we prevent that?

The one idea among many, is that when we replace a transaction, we also sign a transaction that sends a bit more money to you then to me. We take the old one that was beneficial to me and we sign a transaction spending the output of that giving it all to you. So now if I try to publish this old state, rather than me getting all the coins, rather than me getting more coins than I should, I publish the transaction that you're immediately able to follow up on where you take all the coins, so I'm not going to do that. I'll be penalized if I do that. So the idea is now is we're still doing the Lightning model where we keep replacing these transactions over and over, but every time we replace a transaction, we make sure that the old one is somehow poisoned.

So that if one of us were to publish an old version of a transaction, we would get burned by doing this. There's a scalability problem here, which is that if every single transaction needs to be poisoned with a new transaction, moving the coins from that place and if every time we replace, we have to poison the previous transaction, then we're going to wind up with this giant pile of old transactions and those giant pile of poisoning transactions and this is going to accumulate on both of our hard drives and eventually we're going to have a problem.

If we don't want it to be online all the time and monitoring each other, if we try to outsource this, then we see that they have an even bigger problem because you have these entities called watchtowers that are outsourcing all this transaction monitoring and transaction poisoning and now they have the scalability problem times the number of users that they're being watchedtowered for. So one idea is that we could take this thing, this new SIGHASH mode, that lets you sign a transaction, but not commit to which coins you're doing and create one transaction that poisons a lot of old transactions at once.

You can, maybe I'm speaking a bit abstractly and removing details, but you can almost see how that works. When we create a new transaction, rather than poisoning just a previous transaction, we find a transaction that poisons the previous one and everyone that came before it and so we can just throw out the old poisoning transactions [Inaudible] an even better one that poisons even more. So now, rather than having this ever-growing pile of transactions and pile of poisoning transactions, we can now just always have only one that we keep replacing.

So we have O(1) scalability instead O(n), and that solves, well probably the most serious scalability problem in Lightning. So because this is such a dangerous technical tool... On the technical level, this enables a lot of new ways to lose money if you abuse it, that don't exist in Bitcoin today. There's a fair bit of controversy about this, so it might not be deployed at the same time as Taproot. But I think that we've narrowed it down to just one or two high-level approaches for this, but that's something that the Lightning folks really want and that a few other people really want and I would expect that that would be the next big change to Bitcoin. So like post-Taproot, that's what we're looking towards.

I'm not sure that there's anything else that I can point to and say like this is coming next after Taproot or something, there are a lot of different research projects that are very exciting. But I think within this decade, we're going to see it deployed in Bitcoin, but I can't tell you in what form or in what order or how exactly is it going to out, because they are all research and development things. My feeling is that the exciting development in Bitcoin for the next year or two, aside from Taproot, is actually not going to be on the consensus layer. It's not going to require updates and it's not going to require forks.

I think the exciting stuff to watch for are the implementation of these multi-signature schemes that I've been talking about, the deployment of miniscript and the ensuing interoperability and ability for users to have complicated spending policies for their own coins. I'm looking forward to continue iteration on just the usual efficiency improvements, better fee estimation, more efficient transaction creation, better privacy technology, more widespread use of things like CoinJoin and reducing what are called fingerprints, when different wallets produce transactions in slightly different ways that identify which wallet is being used or which version of a wallet is being used.

All of that stuff's exciting, but to me what's exciting is all the multi-party transaction, all the innovation in the world of multi-party transactions, where we can do multi-signature, there's one key, multiple signatures, and maybe we'll be able to do Lightning payment channels this way. I'm thinking a bit here about how there's this like super cool thing about the cooler the things get, the more I have to delve into detailed mathematics and so there's some sort of maximum, I think, in how cool I can sound before I start sounding like a nerd!

Peter McCormack: Because you love math, that's it, isn't it! I think that was the name of our first show, Bitcoin and Math.

Andrew Poelstra: Yeah, you see what's exciting coming down the line and I'm like, "I'm going to read these five books." So on a high level, there are all these different multi-party ways of constructing transactions. I've been talking about multi-signature, where you have like five participants and all five of them interactively cooperate to sign things. There are a bunch of cool variants on this. One is that you can have threshold, so you have like three of the five instead of five out of five. That's cool because it's actually that any three of the five participants are able to come together and no matter which three you choose, they're all using the same key.

But if any two of them come together, then they can't do anything. It's surprising mathematics, if that would be possible. You can do more elaborate things, like you can have like any two of these three participants or any three of these five other participants or just this one guy or something like that and you can also encode those kinds of policies into a single public key. You can have mechanisms where you add people to the pool or where you remove, that should be covered. You can't really remove people from the pool without having everybody delete secret key material and you can't verify that. But in principle, you can change these policies.

You can add new people, you can add new ways of spending and if you have some sort of deletion mechanism that everybody's willing to trust, you can also remove different policies, so you can update this without changing the underlying public key, which is exciting. Another really exciting thing is that in the two-party case, if you're doing a two-of-two transaction, you can set up the protocol so that when one party signs by, virtue or whatnot, I should say when one party contributes to the final signature, by virtue of contributing to the final signature, they reveal some secret to their counterparty and this is useful as a building block and things like Lightning, where the idea is you have a lot of different payment channels that are linked to each other, where when one payment channel is updated, the update revealed secret, like a house payment, that can be used to update other payment channels.

So you have one update that propagates across this whole chain of different payment channels, you can do that just inside the signatures. So now we no longer need a script to do these complicated updating these simultaneous updates to payment channels. You similarly don't use scripts to do atomic swaps, even across multiple blockchains. All these schemes where normally you have the script system enforcing, the secret is revealed, you can now do this inside of the signature protocol.

Then there are a group of researchers like Pedro Moreno-Sanchez, Aniket Kate, there are a couple of names they don't have at the top of my mind, who are developing this whole field of research into what kind of cool protocols you can do in this way, where ultimately what comes out of the protocol and what hits a blockchain is one key, one signature, but what you can do with this becomes much more powerful, certainly than just one person signing. In one specific cool example, actually, if you can set up... How do I want to say it? You can set up like punitive parts of the protocol. I can do something like, we have our multi-party protocol going on and imagine you don't want me to sign something.

We can set things up so that if I were to sign it, if I were to move the coins in a certain direction, say by signing a transaction, by doing that signature, I reveal something to you that allows you to go do something bad to me or something. So you can introduce knots, you can introduce negotiations into these protocols and so you can have these complicated contracts that are instantiated in these multi-party protocols and just like... Every word I just said, they're made like academics and people developing stuff because it's really technically difficult to do this stuff in multi-party protocols.

But this is how research goes, this is how things progress. You can introduce negations into these protocols and this is really fascinating because you actually cannot do that with script itself, with Bitcoin script. There is a not operator, but it's not really useful and then we try to give an illustration of why it's not useful. Imagine that I have coins that say you can spend these coins as long as Andrew signs but Peter doesn't. You can imagine that I could write a Bitcoin script just like that, that says, "You aren't allowed to spend these coins if Peter signs them, they're not on the..."

Well that doesn't actually accomplish anything for me to say Peter is not allowed to sign, because even if you do sign, obviously, I can just take your signature, remove it, and then publish the resulting transaction. So what does that not clause actually accomplish? The answer is nothing and the technical word for this is a monotone function. Bitcoin script is able to express a monotone functions of different signers and hash scrimmages and whatever and what monotone function means is that if it's possible to sign with some group of people, then it is also possible to find with any larger group of people, okay? You can't say Andrew can sign, but Andrew and Peter cannot sign.

You can't increase the group and then exclude people because that's just not logically sensible. But when you're doing this interactive protocols where suddenly people's actions can trigger different events and trigger revealing of different secret data. They might be encryption keys for other transactions, they might be a component in a zero-knowledge proof, they might be other signatures, they might be all this kind of stuff. Suddenly you can do these knots, so now I can have something where maybe I signed this transaction and if you were to try to sign that transaction, this would reveal some secret that would then allow a third party to just sweep the coins off the table, or would somehow invalidate the contract.

So this restriction to monotone functions, which is to be clear, this is not a limitation of Bitcoin script, this is just a limitation to things count if you publish them on the blockchain and they don't count if you don't publish them. Suddenly this limitation, which seems like a really philosophically inherent limitation to the way blockchain contracts work. It seems like we might be able to work around it within these interactive protocols and that's something that's really exciting to me and I'm really excited to see how this research develops. Then I have a couple others... Look at that, we're at like 90 minutes, aren't we?

Peter McCormack: Yeah we are.

Andrew Poelstra: I have a couple of other related things that... So I have a hard stop in 40, just so you know. There are other people thinking about multiple transactions. So in particular, I guess you were not at Advancing Bitcoin, because you are not in London that week. Unfortunately, I had to go to Bletchley Park without you!

Peter McCormack: Yeah that was when I was in Venezuela, because we were going to go and see the machine, weren't we, that I promised to go with you? I'm really sorry because I really wanted to do that! You know you're not the only one that wanted to go and see that as well.

Andrew Poelstra: Well definitely next time. I would love that.

Peter McCormack: Definitely next time! I'm sorry about that, I was away in Venezuela, sorry about that.

Andrew Poelstra: It was really cool actually. I could go like a hundred times and I would never get tired of going! At Advancing Bitcoin, James Chang talked about a research project he was doing. Well it's a bit further than just research, the code he is actually writing to model multi-transaction protocols where you have some set up, like a Lightning payment channel or something, where you have a chain of unsigned transactions that all spend each other's output from their various different PALS that these series of transactions might take, depending on how the protocol evolves and depending how people behave.

Using miniscript, James has a way where he can actually enumerate all the different possible PALS that coins might move through these series of transactions. But even though you have multiple transactions, each of which individually have scripts on them that control under what conditions the coins can be spent and you have multiple parties contributing and or not contributing to the scripts and various ways, you can get a handle on all of the different ways that things are going to go.

You can actually reason about this and say with confidence, even though unchaining four transactions in a row, and even though I, as a participant, am doing signatures under these 1,000 different, complicated conditions, I can actually enumerate all the different possibilities and be assured that this protocol is secure and it is not going to lose any money. This is an important thing because over the years, when I've been talking about all these cool new things we'll be able to do in these complicated multi-party contracts, something I've been sweeping under the rug is that to use this in real life, you have to be able to reason about it and you have to be able to assure yourself that this stuff is secure.

When I'm talking about things that are on the edge of being able to give us experts that as human possible and being able to convince a programmers so that they understand it well enough to be able to deploy it, arguing that its secure or that its robust is much harder. So this kind of technology, and I'm going to plug miniscript again, miniscript actually makes this possible, whereas before it wasn't. This kind of research is really exciting to me because this means that all of these cool ideas that I've been talking about being possible, they start to go from being possible to being real, to being a thing you can actually envision real people doing on the network.

What's really exciting about this, I think we're going way back to your original question about what's next, is that this does not require updates to Bitcoin. After Taproot, we get these cool new... All the Taproot benefits, we get Schnorr signatures, which make a lot of this stuff much more efficient and easier to reason about and in some cases possible where it wasn't before. After that, we can start building a lot of cool new things that are really knowledge which has never existed before and yet, which don't require any updates to the Bitcoin protocol itself, which for validators mean nothing changes.

They can still be full nodes, they can still validate all the rules, they don't have to download new updates and learn new rules or anything like that, they just keep on doing what they've always done and yet the network still gains functionality. So that's what I think you're getting and I think that's where all the exciting stuff in the next two, three, four or five years is going to be, is in stuff like that.

Peter McCormack: Do you know Andrew, you're one of my favourite people to interview and I never have any idea what you're talking about. I listen along, but I really don't understand it. But I also, at the same time, find it fascinating about all the hard work that goes into this and I think it's really commendable the amount of hard work that goes in. The due diligence that goes in, that everyone puts in to ensure that everything is as smooth as possible to avoid any crazy bugs, I can only say thank you and then apologize for the embarrassing little I understand about it.

But I think people are going to listen to this, and the techie ones, the ones who understand Bitcoin, the ones who contribute to the protocol, I think they're going to really enjoy listening to it. For me, I just enjoy catching up with you mate.

Andrew Poelstra: Yeah, that's great and thank you. I love talking to you! It's always great to catch up and yeah, hopefully people listen in. Hopefully I'm making some sense to somebody!

Peter McCormack: Yeah, I pick up a bit here or there. I understand more than I did before and I did a show with Shinobi about the protocol and I did a lot of prep, so I definitely know more than I did, but Taproot and Schnorr signatures and all that stuff's another level. But I will listen again and I will pick up a bit more. I can't see me programming my own wallets just yet or ever getting there. But it is fascinating.

Andrew Poelstra: No, you'll get there.

Peter McCormack: Come on now! I can't program anything. I can design stuff though and all that.

Andrew Poelstra: I should not be though. Nobody should be writing their own wallets. I joke about this, but actually this is how you lose clients.

Peter McCormack: Well listen, it is great to catch up with you. I hope you're safe and well in Austin. I don't know when I'll see you next because I just had this conversation with somebody else because I don't know when flights will start up again and I don't know how the world's going get back to normal. I would have thought I would see you like every few months with some event or another or in Austin, but I honestly don't know when we'll get back to travelling. It's a very strange time.

Andrew Poelstra: Yeah it's hard to say. I think conferences and large gatherings, they're probably going to be one of the last things to start up again. So yeah, it could be a little while.

Peter McCormack: Yeah, it's strange man! Well listen, stay in touch. You're not on Twitter, so I'd have to actually just drop you an email every now and again, but let's stay in touch and thank you for doing this and I wish you all the best man. Stay safe and stay healthy.

Andrew Poelstra: Yep, you too, on all accounts! I'll talk to you later.