path: root/transcripts/tftc-podcast/2019-06-18-andrew-poelstra-tftc.mdwn

TFTC podcast with Andrew Poelstra - June 18th 2019 (Abridged)

<https://twitter.com/kanzure/status/1160178010986876928>

Podcast: <https://talesfromthecrypt.libsyn.com/tales-from-the-crypt-80-andrew-poelstra>

# How the idea of Taproot was formed

Andrew: There are some small off suit IRC channels of bitcoin-wizards where people discuss some specific topics such as Minisketch which is a set reconciliation protocol that was developed by Greg Maxwell, Pieter Wuille and Gleb Naumenko among a couple of others. It was mostly those three. They have a channel where they talk about things. There is one where there was a whole bunch of discussion leading up to the Taproot BIP proposal. There was five or six of us that were iterating on that. In addition to that some conversations happen in private communication, in emails and IRC messages and stuff. And then a fair bit happens face to face. We try to meet people at conferences, we try to meet each other if we are in the same city, usually we’ll call each other. One cool example of this is Taproot itself. The original idea for Taproot was developed by Greg Maxwell, Pieter Wuille and myself. We were at a diner in California, within 100 miles of the San Francisco Bay I’ll say. We were just getting breakfast and talking and shooting the s*** as we do. Taproot showed up kind of serendipitously. What had happened was that somebody had messaged Greg privately asking about some more efficient script construction they had for hiding a timelocked emergency clause for their spending policy. I had also had basically the same problem. It may have been with Larry working on Blockstream Green actually. Greg and I were talking about this thinking if we had a future version of Bitcoin script how could we hide these timelocks? Is there any way we can make the timelocks take like zero space. We got it down to 32 bytes and then we were spitballing about this construction we knew about that would let you hide stuff inside of an elliptic curve public key with zero additional space. I thought “Hey what if we took the public keys that go through CHECKSIG and we had an alternate CHECKSIG operator that would expand the public key and pull out this hidden data? Then you could spend that script and stuff. Greg said “Screw CHECKSIG. What if that was the output? What if we just put the public key in the output and then by default you signed it.” That was where Taproot came from. It was a very quick exchange of ideas. It was not only because we had a small set of people who all knew each other very well and we tend not to miscommunicate and we can talk very quickly. But also because we were all in person we were able to communicate very quickly, there’s a lot of facial…

Marty: You can read inflections and stuff like that. That’s why I do these interviews in person.

Andrew: It is just much easier to come up with ideas like that, at least the seeds of ideas. There is quite a bit of discussion that happens that way. I think all of us try to find our way to certain conferences throughout the year where we know there will be other people in the Bitcoin crypto community.

# Schnorr signatures

Andrew: Schnorr is a crypto primitive called the digital signature. It is a replacement for ECDSA which is also a digital signature. Schnorr signatures are basically the simplest possible digital signature. They are the most obvious, if you were to come up with a digital signature you would come up with this. They are incredibly obvious, they are a derivative of a bunch of other work that had been done. Unfortunately the US Patent Office disagreed with the fact that is obviously a derivative. They granted Schnorr a patent that lasted from 1990 until 2008 which is why Bitcoin uses ECDSA today. So what we’re doing is we’re going back to the signatures that we should have been using that have a very simple algebraic structure. The consequence of that algebraic structure is that they are very extensible. There are a lot of things that we can do with Schnorr signatures. Ultimately Schnorr itself is a drop in replacement for ECDSA. It is kind of not very interesting by itself. I can certainly list the things in the Taproot and Tapscript proposals that we are able to efficiently do or do at all because we have Schnorr signatures as a primitive rather than being stuck using ECDSA.

# Taproot

So Taproot itself. As I mentioned, it is this construction where you hide a script inside of a public key. The idea here is that since most coins are spent by somebody creating a single signature we should privilege that mode of spending. Your coins that you and I have in our Bitcoin wallets, our coins have public keys associated to them. Right now those public keys are encoded on the Bitcoin blockchain in the form of a script. A script that says here is the public key, give me a signature that validates to those public keys. Here we just make that implicit. We just put the public key there, no script, no anything. Only if there is something other than a signature you need to satisfy the conditions of spending these coins do you need to reveal your script in Taproot. You reveal your script and anybody can verify that the script was actually committed inside of the public key. But if you don’t reveal it nobody can tell what the script was or even that it was there. This was cool by itself but if that were the whole story it probably would not get a lot of traction. People would be very suspicious. They would say “Well maybe right now people are using single keys for all their Bitcoin but they shouldn’t because that’s fragile and it increases the risk of losing keys or key corruption or the many things it increases the risk of.” One thing that Schnorr signatures get us which makes this interesting again is that with Schnorr you can very efficiently create multisignatures and threshold signatures that are themselves Schnorr signatures. You can think of this as making a multisignature or you can think of this as jointly producing a single signature. The idea here is that something like Blockstream Green where we have a 2-of-3 threshold signature, if we had Schnorr signatures rather than doing that the way we do today where you have two signatures and you put two signatures onto the blockchain, the user of the Green wallet and Blockstream would jointly produce a single signature that hits the blockchain. Because there’s one signature you can spend it using Taproot without revealing any scripts. Now we’ve extended the things you can do with just a signature from somebody spending their own coins to any kind of multisignature or threshold signature or more complicated policy related to signatures.

Marty: And this is when you’re looking at it on the blockchain you can’t really tell the difference between anything and it sort of hides these functionalities in the signature?

Andrew: Yeah exactly. You get a tremendous privacy and fungibility boost because there is no difference from a verifier’s perspective between a normal single signer signature and something more complicated that may have been created by Blockstream Green or by BitGo or by Casa or by Liquid or any of these things that are using multisignatures today. They would all look the same and verify the same.

# Miniscript

Marty: That’s a good segue into Miniscript, something that you’ve been working on. This would work without Taproot, Schnorr and any of this but it is something that would make the unique scripts that something like BitGo makes, that you guys make for Liquid and other stuff, you’re able to communicate across correct?

Andrew: In the same vein but in some sense completely different. Today Bitcoin script is actually very expressive. This is for some reason not very widely known. The Ethereum people showed up, took this word smart contract and started meme-ing that smart contract meant something where you have this incredible key-value store of key-value stores that nobody can possibly verify and you make sure all of your transactions are updating a tremendous amount of state and doing so in a way that their validity depends on what block they’re in and what order they appear in so that every re-org is catastrophic. Bitcoin has always supported a form of smart contracting that doesn’t have any of those problems. We just don’t call it smart contracts because in some sense it is an obvious idea. Actually I have no idea why we don’t call it smart contracts because in the early days, back when folks like Nick Szabo were around in the Bitcoin community more actively and more visibly we did use that term. Bitcoin script was designed for smart contracting purposes. Here’s what I think happened and why we don’t think of Bitcoin as being a smart contracting platform and how Miniscript intends to fix what I believe happened. Bitcoin does interesting contracts. It does things like multisignatures, timelocks, hash preimages and Lightning HTLCs and all of this crazy stuff using a special purpose language called Bitcoin Script. Bitcoin Script was designed to be very easy to reason about. It doesn’t have unbounded loops like Ethereum does. It doesn’t have goto’s so you can jump around randomly in the script like Ethereum does. Those two things are huge by themselves because if you don’t have either of those then in principle given a Bitcoin script somebody could look at it and determine how big the transaction might be to spend coins controlled by that script, they should be able to tell you how many signatures are needed, all these kind of things. In practice this is actually very difficult to do. It is possible to do quite pathological things with Bitcoin script meaning that general purpose analysis of scripts is basically impossible. To the extent that it’s possible it is useless because it would give you such general answers about what a script is and does that you don’t really learn anything about it at all. The reason for this is that Bitcoin script has a whole pile of OP codes that do weird things. We might talk later about the disabled OP codes. Believe it or not none of the disabled OP codes are problematic here. It is the ones that are still there that do weird things. Because of this problem people doing interesting things like Green or Liquid or BitGo who have scripts that do non-trivial things. The implementers of those systems are forced to write adhoc code to produce these scripts, to assemble signatures that satisfy those scripts, to reason about the fee market in the presence of those scripts, trying to decide how large a transaction will be that spends them, to guarantee that the scripts do what their creator expect them to. BitGo acts as a countersigner, they want to make sure that coins can’t move without their signature or a timelock I think they have in case they go down. Similar for Blockstream Green and the users should also be assured that the coins can’t move without their consent. That’s the most important thing. Because Bitcoin script is so difficult to reason about, everybody has their own independent codebases doing all these things and there’s a lot of human analysis and a lot of specific scripts that are done because humans need to vet everything. What Miniscript is, one way to look at it is a subset of Bitcoin script where there is nothing confusing or difficult to analyze. It supports signatures, it supports hash preimages, it supports timelocks, it supports any combination you can think of those. So you can say 3-of-5 signers or a timelock and then 2-of-3 or a longer timelock and a hash preimage has to be revealed. Whatever you can think of in combining these.

Marty: Now I think it is coming together for me. So BitGo and Liquid may have different parameters for which they come to these scripts and you’re putting them all in one Miniscript and letting them communicate across eachother?

Andrew: It is not quite that. They would have different Miniscripts but they would all be Miniscripts. The distinction between Script and Miniscript is that given a Bitcoin script you can’t really say anything about it without asking a human to look at it and reason about what it is supposed to do and then convince themselves it actually does what it is supposed to do. But if you have a Miniscript, a Miniscript is a much more abstract thing. It is like a tree of different combinations of signature requirements and hash preimages and stuff. If you want to convince yourself that say you are a countersigner to every branch of a Miniscript or at least every branch that doesn’t have a timelock on it, that is very easy to do with Miniscript. You just go through every branch of a script and you check whether or not your key is on there. You say either my key is there or there’s a timelock. Maybe the timelock has to be a certain length so you know people can’t take your coins too quickly or something like that. If you want to know what the timelocks are, it is very easy you just scan through the Miniscript looking for timelocks. Here’s where things get interesting. If you want to know how large a witness for a Miniscript might be that is an easy question to answer. You can just go through this, we know the rules for encoding things on Bitcoin. Miniscript supports complicated things, if statements and branches and all sorts of stuff. Sometimes you have to add extra data beyond signatures, maybe you have to push a zero to take one branch and a one to take the other or something like that. Because Miniscript is small and self-contained we have libraries out there that know how to take a Miniscript and just tell you how much it will cost to satisfy. It can tell you the maximum cost, the minimum cost, the average cost and so on. It can tell you which public keys you need to give it signatures for. I have a library written in Rust which will request signatures on a list of public keys and you give it all the signatures that you have. It will tell you whether the script can be satisfied with the signatures that you gave it. If you gave it enough it will produce a satisfying witness, it will make the smallest satisfying witness. So if you need 3 of 5 signatures and you give it all 5 it will choose the 3 smallest ones for example.

Marty: So almost like an efficiency alarm?

Andrew: It lets you do things more efficiently. Actually kind of amusingly I’m aware of two examples of people who using Miniscript were able to find more efficient scripts than the ones they had come up with by hand. One of them was us with Liquid. We were able to save 2 bytes in our Liquid spending policy using Miniscript versus the scheme that we came up with. The other is the company called Arwen in the Boston area. This is Sharon Goldberg and Ethan Heilman and a few folks like that. 

Marty: They’re doing custody solutions correct?

Andrew: They’re doing a split custody crypto to crypto exchange using a custom Bitcoin smart contract similar to a Lightning HTLC but it is different in a way that lets them support Bitcoin Cash which doesn’t have SegWit and therefore is vulnerable to malleability attacks. They’ve taken some measures to prevent that. Using Miniscript they were able to find a slightly more efficient script than the one that they had there. But then also because Miniscript is so general, when you’re spending coins you can find a more efficient way of spending coins than you otherwise would. Simply because you have a single library that everybody can use to answer the same questions. Arwen, Blockstream Green, Liquid, BitGo, Casa and everybody, we all care about the same questions about our scripts. We care about how large they are, they care about how much they cost to satisfy, we care about how do we satisfy them if we have the right signatures. How do we satisfy them if we have to use a timelock? As far as I’m aware there is no tooling out there for using timelock emergency things. I think there is in the Lightning software but nobody else has it. In Liquid today if the network goes down and we need to use the emergency alternate spending mechanism to recover coins, we’re going to write software when that day comes. It is fine, it is a weekend project it is not a big deal. But it is silly that we have to do that. With the Miniscript library it can just do it for us. We got for free that we no longer have that tool to write which is great.

Marty: I was talking to Lawrence about ABCore decentralization being the ideal that we strive for. Stuff like this helps us become more decentralized because it tames the growth of the size of the chain?

Andrew: So Miniscript is probably bad for the size of the chainstate because it is going to let people do more interesting things. Although to the extent that Miniscript is bad in that direction Taproot will then recompress things and things will be even smaller than they were. What Miniscript gets us is a much wider variety of possibilities for using Bitcoin and much more robust uses for Bitcoin. Let me give you an example that affects me personally and many people I know personally and also many institutions that I’m aware of. I have a non-zero number of Bitcoins that I hold personally and those Bitcoin are stored on ordinary single signer SegWit addresses associated to a single public key which is derived deterministically from some master seed which is then split up and stored securely in some collection of locations or something. What I would like is that my coins would be stored on some sort of multisig, at least my long term storage coins that I don’t spend very often. I would like those to be stored on some sort of multisignature, some redundant 2-of-3. I can spend them if I go to my cold storage thing or maybe if I’m willing to call my parents or my girlfriend or somebody to countersign them we can move them. I would like there to be a locktimed ultimate spending path that will allow my coins to be recovered in the case that I lose my keys or I die or I disappear or something. Right now because there is no tooling for doing this whatsoever I don’t do this. I have my coins on single key addresses. My parents have a letter explaining how to recover them. This letter involves them phoning multiple Bitcoin Core developers at home and asking them for help because I couldn’t even give a reasonable workflow in this letter. Part of this is because I wrote my own wallet with insane spending requirements. But part of it is that it is difficult to use Bitcoin. I’ve wanted for a long time to write some tools that will let you recover my coins, that will let me do this and still be able to spend my coins and still be able to recover them and stuff but the problem is this doesn’t help with recovery. If I wrote a tool on my personal GitHub account my parents don’t know how to use that. So I’m back to square one telling them “Call this Bitcoin Core developer. He looked at my tool once and he’ll be able to figure it out.” With Miniscript now I’ll be able to do that because there will be general Miniscript signing tools out there and I’ll be able to give a few simple…

Marty: This will be something like if you don’t sign a message every n blocks release to this address or something like that?

Andrew: It would be something like that. I’d set n to be six or twelve months I think. The most you can set in Bitcoin script is twelve months I believe. I forget the exact reason, I think it is the number of blocks. 

Marty: So does it use UNIX time to derive that or is it going on block height and guesstimated year length?

Andrew: This is embarrassing. For the one in script I don’t know. There are two mechanisms by which you can do locktimes like this. One is to create a locktimed transaction spending the coins normally that has something called a locktime on it meaning the transaction is invalid until some time is up. For that one if you give it a number less than some threshold, 5 million or something like that, then it is interpreted as a block height and if you give it a larger number that’s interpreted as a UNIX timestamp. I wonder what the threshold is and if we’re going to hit it soon. I should take a look at that. The other way is to directly support this in Bitcoin script using an OP code called CheckSequenceVerify which is horribly named but it means check how old the coin is. For that I believe you can only set a number of blocks and I further believe that there is a maximum number of blocks you’re allowed to set in the consensus rules that works out to roughly a year. You cannot locktime using this technique which is a bit more robust than having a locktime transaction that you’d better not lose. But it limits you to doing one year.

Marty: So would you be able to set it up from a watch only wallet app that says a hundred blocks before the timelock is up you should probably sign a message and it will push it more into the future? Is that how it works?

Andrew: Yes. Here’s another specific benefit of Miniscript that makes this kind of thing very easy. So we actually have something similar today in Liquid. The way that the Liquid network works is that all of the coins in the system are ultimately custodied by a 11-of-15 threshold signature of the quorum of participants in the system. After two weeks, 2016 blocks, these coins then become available for spending by an emergency policy which are some cold keys that are spread across the world. The idea is that if the network crashes or all of our HSMs catch fire at once or something like that we’ll be able to recover the coins in the system by some alternate human mediated method. The Liquid network functionaries who are supposed to control the coins need to make sure they move these coins every 2016 blocks. Otherwise there would be an alternate spending path which should never be available while the network is alive. The way that our existing code, the deployed code does this is that it has a very specific template that the coins should be controlled by. It knows how to parse that template, it knows how to recognize functionary keys in that template, it knows where to look for a locktime, it pulls out a couple of bytes that represent a time, it parses those as an integer and it says as long as it’s not older than that number I need to move the coins. With Miniscript this is much, much easier. You take this script, you run a function that looks like miniscript.parse this script and now it is a Miniscript. You’re just representing the script as a Miniscript and then you say “Miniscript list all the timelocks that are available.” The first one will always be zero, I guess if you had coins you just couldn’t move… It will be zero, it will give you a second number and now our code that we haven’t deployed yet checks are there two numbers, the bigger one is the expiry. That’s how simple it is. This is way more robust against changes in how we control what the spending policy looks like because we are no longer templating scripts and trying to parse and doing all this ugly stuff. And it is way easier to read. You look at our source code and you can just see what is going on.

Marty: So is Miniscript like a wrapper for these scripts?

Andrew: This is the cool thing. There are two ways to look at Miniscript. I think of it as an alternate language to Bitcoin Script for describing spending policies for Bitcoins. Miniscript has an encoding that is in the form of Bitcoin Script. So you can encode and decode Bitcoin Script to Miniscript and the encoded form when run by the Bitcoin Script interpreter will have exactly the same semantics as the Miniscript as described. You have some policies that are kind of human readable. It is like “this key and this key or this key” kind of thing. The semantics of that are exactly what I described. What semantics means is what it does, what the spending policy actually is. When you encode this as Bitcoin Script it will look much more complicated. It is going to look something like “Push this public key, call the CHECKSIG operator, push the result to the alternate stack, push this pubkey, call the CHECKSIG operator, pull the result from the stack, run the boolean AND OP code, push the result…” The semantics of that are actually the same as this key and this key but you can see now that what I just said is very non-obvious that those do the same thing.

Marty: It seems arduous.

Andrew: Yeah it is arduous. With Miniscript we have a set of pre-defined script templates or script fragments that as far as we’re aware express all of the most efficient constructions for doing ANDs and ORs and thresholds and stuff in Bitcoin script. And that Pieter and I and a few other people who have gotten excited and read through our code have basically vetted that all of these fragments do exactly what we think in the ways that we think. Now we’ve vetted those fragments, it required a fair bit of human work, now we can just use Miniscripts. We can take a Bitcoin script that is already on the network and just decode it as a Miniscript and then we don’t have to worry about the script semantics because now it is in a form that directly represents those semantics.

Marty: And you don’t have to ask permission for that at all?

Andrew: No. And what’s cool is that on the spectrum of things that are permissionless this is to the moon. It is really cool. So first of all it is permissionless in the Bitcoin sense of anybody can use it, anybody can do what they want. It doesn’t require any consensus changes or consensus layer logic. Anybody can use it with the existing Bitcoin system today. And then because it encodes to a subset of Script even if Pieter and I go and change the language as we define it, anybody can run whatever code they want but even if Pieter and I change the language a hundred times and what we call Miniscript is this thing, the chances are that if you are doing something that is not really contrived, our new version will still encode what you were doing and you just keep on parsing your script as Miniscript and don’t worry about what changed at the edges. If we changed to allow RIPEMD instead of SHA, we might add that for example.

Marty: So it is backwards compatible as well?

Andrew: It is very backwards compatible, it is very robust to changes in the underlying script. The reason for that is that we have to be able to encode to Bitcoin Script and decode from Bitcoin Script and that doesn’t change.

Marty: It is fascinating. How the hell did you get this smart? That’s the question I have right now.

Andrew: There’s a funny story about Miniscript. All the intelligent stuff here is Pieter Wuille to be clear, it is not me. All the efficient parsing and all that good stuff. It is funny, as we were designing it sometimes Pieter would put stuff in and I wouldn’t know how to parse it and I’d say “I reject that change because I don’t know how to write the code for it. It is deliberately very simple to write a parser for it because I didn’t want to understand how LALR parsers worked.

Marty: Keep it simple stupid.

Andrew: Yeah exactly. Fortunately we didn’t have to sacrifice efficiency anywhere to get that. We were worried that we would but it turned out everywhere where something was difficult there was an equivalent construction that wasn’t so difficult. The story behind how Miniscript started was Carl Dong who is a Bitcoin developer who works at Chaincode right now….

Marty: TFTC alum too, he has been on this podcast talking about GUIX containers. 

Andrew: Carl is one of the maintainers of the rust-bitcoin project, a library that does all sorts of Bitcoin transaction and block related things for Bitcoin. He wanted to add some support for multisignatures so he wrote some code and he wrote some unit tests, it was all solid stuff but he had templated a specific kind of multisignature and I said “I don’t want that in the library. This is a general library and we’re not going to use your special purpose multisignature thing because that is one specific thing you’re doing is multisignatures. To be clear I was being irrational here, multisignatures are very general. I was like “No that’s too specific.” What if I wanted to do a multisignature and a hash preimage or something? Carl said “What the hell do you want me to do? I’m not going to write a general script analysis engine or something so you don’t have templates in your unit tests.” I said “Ok let me think about this.” I happened to be in Mountainview near Blockstream’s office at the time so I was able to go locate Pieter Wuille. I said “Pieter I need to define a subset of script that will contain everything that I care about but that isn’t just a fixed set of templates.” And he said “That’s funny because we need to do the same thing in Bitcoin Core.” So we both independently had the goal of creating such a thing. So we got to work doing this, we took out two or three whiteboards in the Blockstream office in Mountainview and we spent like 40 hours laboriously going through every possible Bitcoin script construction we could think of and counting OP codes, counting bytes and reasoning about how much it would cost to satisfy them. At the end what we came up with was Miniscript. It was a combination of a lot of hard work and grinding to get the most efficient thing that we possibly do that we were a little obsessive of. And Pieter knowing the computer science stuff about what could be efficiently satisfied and what could be efficiently reasoned about. Pieter was able to write a compiler from an abstract, even more human readable language than Miniscript to Miniscript where it would choose the most optimal of all the different Miniscript constructions.

Marty: So optimizing the optimizer?

Andrew: Almost. The Miniscript optimizer. What the Miniscript library that I wrote does is optimizes spending coins but it doesn’t find the smallest Miniscript for you. You still have to figure out… you’ve got a few different ways to do ORs, you’ve got a few different ways to do ANDs, you’ve got to choose the right one for your use case that will be the smallest. Pieter wrote a compiler that would find the right one. You’d just say “I want this key and this key or this key” and it would just grind through every possibility basically and do so in quite an efficient way. Actually I wrote a compiler as well in Rust to compete with him. So he and I independently wrote compilers for the same language and then because Pieter had written a general tool for creating sentences in any language, he was able to produce the first 10 million Miniscripts, just programmatically generating them with a tool that he already had lying around that he was using for path generation or something. So he generated 10 million Miniscripts or 10 million of these abstract, what we called policy language. He and I both compiled all 10 million to Miniscript and then compared every single one to check that we got the same results.

Marty: And they lined up?

Andrew: They lined up. That’s how we did a lot of our software testing.

Marty: Is that enough of a sample?

Andrew: We didn’t think so, no. After doing the first ten million then we started generating random ones that were enormous that had like a hundred bits of entropy. We found that when they got too complicated our compilers wouldn’t finish in a reasonable amount of time. They would take hours to run. But we did take a random sampling of quite varied, deliberately random and enormous policies and check that they would still compile to something sane. I wrote some tooling because I was using this, I was writing a production ready Rust library for use in Liquid. I did a whole bunch of tooling for actually producing valid transactions and stuff. I spent a while running random Miniscripts making sure that I could sign for them and that the resulting signatures had a transaction weight that was below what I had estimated. That everything was satisfiable that I thought was satisfiable and not satisfiable when I didn’t think it was. Just generally sanity checking against the actual final produced Bitcoin transactions. So we actually have quite high assurance at least for the more commonly used part of Bitcoin Script just using these random samples.

Marty: Just learnt a lot in the last 52 minutes here, blowing my mind with this. How do you keep all of this in your head? So you have Miniscript, Taproot, all this stuff that you can describe intently. You’re working on Musig as well too right?

# Musig

Andrew: Yeah I am working on Musig.

Marty: That taps into Taproot and Graftroot to help smart contracting capaibilities correct?

Andrew: Yes. So Musig is the protocol that lets you jointly produce a Schnorr signature. So if you have a single signature that needs to produced by multiple people, those people run the Musig protocol offchain and what comes out is a single signature that you would use as Taproot.

Marty: So do you like working on these different aspects? Does it help you stay motivated and do you like jumping from concept to concept? 

Andrew: Yeah it is very cool to have this high level view of the system. I used to wonder about Greg Maxwell who knows everything about Bitcoin, how could he possibly do this?

Marty: Is he an alien?

Andrew: I can’t answer that question. Now that I am the Research Director at Blockstream since Greg left I have a dirty little secret here which is that other people are doing all of these things. So the active Musig development, that is mostly Jonas Nick and Tim Ruffing and Pieter Wuille. All the Taproot stuff that is Pieter and Jonas again and AJ Towns and Johnson Lau. The Miniscript stuff actually was me and Pieter, that is one thing that I really had a part in doing. All of these people and many others send me messages all the time saying “Hey. Here is some thing I’m doing, what do you think about it?” So I don’t have to look to find out what is going on. People come to me with information that they make an effort to make digestible by me, that they try to make understandable. I can pretend like I know all these things about all these million things but the truth is I have people processing this information and doing all the heavy lifting. I kind of just have an executive summary of a lot of it.