{ "episodeId": "SLP507", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "andrew_poelstra": { "name": "Andrew Poelstra", "role": "guest", "tag": "ANDREW" } }, "segments": [ { "speaker": "stephan", "time": "00:06", "start": 5.7, "text": "Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics, brought to you by Swann dot com. Today we're talking about Bitcoin cryptography and scripting with Andrew Poelstra, director of research at Blockstream. So this is the second part of my interview with Andrew, and we get into some of the details about what the team is focused on and what it looks like for Bitcoin more broadly. Broadly over the years, whether that is from a cryptography perspective and also from a scripting perspective. So onto the discussion with Andrew. Yeah, let's talk a little bit about some of the other stuff you're working on. I know you're obviously, at Blockstream Research. There's a lot of discussion and things going on about how Bitcoin advances, and that's on multiple fronts, right? That could be on the scalability side, that could be on the privacy side. So, do you wanna just give us a bit of an overview, what are you sort of, working on, what's the team looking at, what, what, what are you finding interesting?" }, { "speaker": "andrew_poelstra", "time": "01:01", "start": 61.28, "text": "Yeah. the blockchain research over the last year or so is kind of almost split into two, two major categories of research. So, one is cryptography, which is signatures, multi-signature Zero knowledge proofs, all that, the cool, like, the hardcore crypto stuff. And the other is scripting, which is, miniscript, which we, we talk about a lot on Bitcoin, and also simplicity, which we talk about increasingly a lot, but it's still not really, really deployed anywhere. So to give a brief overview, I'll maybe start with what's happening on, on the crypto front. so one, one thing is we've been working on Bulletproofs plus plus. so for a bit of context, we developed in twenty fifteen at Blockstream. The scheme called confidential transactions, which is a way of structuring transactions in a blockchain so you can't see the input or the output amounts, so you can't tell what's change and, and what's not, and you can't tell, you know, how much money is moving in any given transaction, but you can verify that all the transactions balance, right? So you can see the fee, and you can see that your inputs minus outputs is equal to that fee, basically, and that's the only thing you learn, so it's a zero knowledge in the, the particular values. We extended All just confidential transactions. We added asset support, which actually showed up a year later. It wasn't clear how to do, how to, to make this compatible with having different asset classes that don't mix inside of the zero knowledge, scheme. And we deployed this on Liquid, on, on Blockstream's sidechain, Liquid, confidential transactions, with or without assets support, have also appeared in Monero. I think they were the first to adopt it outside of, of Blockstream, on the various mempooled chains, the particular GRIN. I think Litecoin had it now. so this, this made-- this confidential transactions tech has kind of made, made some inroads in various places. Not so much on Bitcoin, because for one thing, it makes the transactions much bigger and slower to verify And for another thing, it means the soundness of the system now depends on cryptography not being broken. So right now in Bitcoin, if the crypto gets broken, well, maybe people can fork the chain and like, you know, the, the blockchain fall apart, maybe people can like steal coins and like reverse private keys or whatever. But what nobody can do is inflate it, right? So if we look at the state of the system in Bitcoin at any given time, we know how many coins are out there And if there's some catastrophic break, and so they say, \"Well, the break happened at this point. Here's where the coins were before that, \" and that's somehow figure out how to, how to go from there." }, { "speaker": "stephan", "time": "03:30", "start": 210.1, "text": "Whereas in something- Yeah. And I guess to point out here, that's not a theoretical risk, right? Zcash did have a hidden inflation bug, right? Exactly." }, { "speaker": "andrew_poelstra", "time": "03:36", "start": 216.47, "text": "Yeah. and Monero almost did. Monero had this kind of neat, like, 8x inflation bug, although it appears the, the Zcash one was really insidious" }, { "speaker": "andrew_poelstra", "time": "03:51", "start": 231.3, "text": "Would have involved just creating money from Siner, creating coins from Siner. so the supply of Zcash, arguably nobody knows, right? With Monero, they had an inflation bug in the crypto, but fortunately it wasn't hidden. Had anybody exploited this on Monero, then it would have been visible. You could go, like, go back and look at the, the blockchain history. and actually in Bitcoin, which may, may surprise you to know, is still around, which was a Monero pre-predecessor that was run by some, some scammers somewhere. the bug was actually exploited on Bitcoin, so there, there have been actual inflation bugs. So yeah, so Bitcoin is really like, thanks, like, I, I, I even as one of the developers of confidential transactions, like, I would really not recommend putting anything like this onto Bitcoin until we have a lot more until we, we, we tighten up the crypto to at least make it so that it depends on the security of hash functions, like hashes not being collided or whatever, versus the current situation where we depend on like elliptic curve security and stuff like that, where there's a lot of algebra and a lot of structure that, nobody's fully explored So part of confidential, confidential transactions is this piece called a range proof, which just assures you that every output is less than sixty-four bits long. And the reason we have to do that is because all the numbers that are happening inside of the zero-knowledge scheme are two hundred fifty-six bit numbers, and if you add a couple numbers that are both really close to two to the two fifty-six Then they'll overflow and go back to zero. So you can use this overflow to create like negative amounts, right? So I could take my one Bitcoin and then send it to myself and give me a, a, fifty Bitcoin output And a negative forty nine Bitcoin output, and it will all add up, right? And then I send the negative forty nine to, like, I don't know, to, to the president or somebody I don't like. And, then I've, I've created money out of thin air, right? I started from one, and now I have fifty. So to prevent that from happening, we just need to keep our numbers very, very small relative to this two to the two fifty-six overflow threshold. So we keep them at two to the sixty-four, so you would then need two to the one hundred and ninety-two outputs in order to get an overflow, and you can't, you can't fit that many outputs into this, into this universe. So we have a new scheme for range proof. So our original range proof from twenty fifteen was at the time the most efficient range proof, without any trusted setup or anything funny, that existed Which is funny because it was really inefficient. so the range proofs, the 64-bit range proof takes like four kilobytes or something of extra data on every transaction. So an output in Bitcoin is like 50 bytes by itself, right? It's a key or a hash of a key and then an eight-byte value, so that's 40 plus a little bit of output, so, so well under 50 bytes. We add an extra 4,000 to each of these, it's just, it's 10x the size of an entire transaction So we have this new scheme called Bulletproofs, which replaces those, and now instead of being four kilobytes, it's about six fifty, seven hundred, and we have a new scheme called Bulletproofs++, and this-- and there was another one called Bulletproofs+ that, that happened in between. And this is another reason not to bring this into Bitcoin, by the way, is that every other year we get this massive increase in efficiency. So with Bulletproof++, now our individual range proofs are less than five hundred bytes, and we can combine them across transactions, even multi-asset transactions. So you have like one transaction that has, you know, like ten inputs, ten outputs, has like five different assets, all sorts of stuff going on, and then you have this single proof attached to it, which is something like five or six hundred bytes in size, and that assures you that every one of the individual assets was, It is, balances that nothing was created or destroyed. And the verification time, is, is significantly faster than the old Bulletproofs, which in turn were significantly faster than our old RangeProofs. So that's one thing we've done. So we, we hired Liam Egan, who is a cryptographer who developed this Bulletproof Plus Plus scheme, and with his help, we've been working on implementation of those, implementation of Bulletproof Plus Plus compatibility with other zero-knowledge proof schemes. So this not only does RangeProofs, it is arbitrary zk proofs, but like It, it does a lot of cool stuff. compatibility with these other ZKP schemes, working on getting the paper into shape. So we wanna have like a really rock solid proof that will pass peer review and stuff, and not require, you know, like three block streamers to spend eighty hours like studying it in great detail, because no, no amount of peer review is, is going to, to compare to that. So we're working on simplifying the scheme, on finding ways that we can streamline the paper and, and make it laid out more clearly and stuff. So there's a So that's, that's the ZKP piece separately, and I realize I spent like ten minutes on like the part that I personally find the least exciting. So I'll, I'll try to be quicker with the other stuff we're doing. also on, on crypto though, we're working on signature stuff. So we have two schemes, MuSig two and Frost. and MuSig two is a multi-signature scheme, an interactive multi-signature scheme. So you can split your, your, keys into like ten different pieces, very similar to, to what you do with Shamir's Secret Sharing, and then you can use the pieces interactively if you can get all ten of the keyholders to be online at the same time. They do an interactive protocol and produce a single signature for the original key. And the cool thing here, is that none of the data they exchange with each other is secret. So you could have, so if any of your signers is malicious, they're not able to learn the other signer's secret key data or, or produce false signatures or anything. All they can do is just screw up the protocol and like fail to sign. So that's, that's pretty cool. So this is, and then the result is just a single signature. So this is great, I mean, it's all the, the efficiency and like low fee, privacy benefits of Shamir secret sharing, but it's actually an interactive thing where you don't need to bring all the key material together. But the cost is that it's interactive and the protocol's a little bit complicated, and we've been working on, on implementing that and getting an API that is, is secure, even when, even when surprising things are happening. 'cause you've got, whenever you have multiple participants that are all working in sync, you gotta wonder like, what happens if like any one of them is giving bad data? What if somebody's giving inconsistent data to some participants but not others? What happens if somebody just doesn't reply? What if they reply really late? there's all these Or what if you start the protocol and then you like restart one of the devices halfway through the protocol and get it to rejoin a second time? Or what if it's in a VM and you just fork the VM and have the same device with the same state trying to join twice? Like, the interactivity is horrible. It's just like so much harder than, like, it's, it's kind of funny we can do these massive, crazy zero-knowledge proof schemes, and as complicated and huge as they are, they're actually easier to develop than are these interactive schemes. Even ones that just produce a single signature can do nothing else. Somehow the interactivity just, it explodes them. Frost is like music, but for thresholds. And here the interactivity issues like actually like get exponentially worse. It's, it's really quite a, a thing. But the idea there is that you can split your key into like ten pieces, and now rather than needing all ten, you could have any three, or any five, or any seven, you know, whatever threshold you want. And they, threshold many of them, will similarly be able to do an interactive protocol and basically- Fill in the gaps of the missing participants and then produce a signature with the same key. So that really does get you the same power as, Shamir secret sharing, but, but it's even more that there's now a complicated setup process and then the protocol is even more complicated. So a lot of what our crypto team has been working, has been, has been doing, has been working, certainly with each other, but also with some external people, Jesse Polzner, Lloyd Fournier, several others who, who I'm, I'm blanking on now, to try to spec this out, get like a dip quality draft where like, here's the exact protocol, and here's all the bytes that go on the wire, and here's who says what to who and so on. Get an implementation, get, you know, a significant Be like a really exciting, a really exciting change in the Bitcoin space if now, whenever you look at keys on, on the blockchain, you can't tell if that's a single key for one wallet or if it's a multi-signature key or if it's some sort of threshold signature key, or even in principle you can do like arbitrary, you have like two of three, else two of three, like a Trees and stuff and still build these interactive protocols. We call that nested music, is, is what we, is what we want to support and that we've been working on supporting. So there's been a whole ton of work there, getting a spec, getting an implementation, getting review on all of this stuff, and then also on the academic front, there's actually continual improvements on the strength of our proofs and, and the efficiency of the scheme and stuff like that. So we just had a paper accepted to Crypto twenty twenty-three that I think we presented or one of our external, collaborators presented yesterday at, at Crypto, which gives a better proof of, a much more solid academic proof of the security of Frost even in the presence of participants who are misbehaving and like not present and dropping out and stuff like that. I think that's it for crypto." }, { "speaker": "stephan", "time": "12:48", "start": 767.56, "text": "Right. Yeah. Okay. Yeah. And I mean, I just didn't have said, I haven't released that yet, but that's the one with, Brandon Black, who was talking about the experience with BitGo and, implementing music too. So we spoke a little bit on that. Oh, that's right, that's right. and so, yeah, interesting to see that. And then also the guys, you know, the Frost Snap guys, Nick Faro, Lloyd Fournier. Yep. and then there's" }, { "speaker": "stephan", "time": "13:17", "start": 796.74, "text": "Yeah, right. And, yeah, and I guess some of this stuff might even be, some of the, some of these complicated a-aspects may be used in Lightning as well. Okay, so that's on the, you know, cryptography side. And then on the scripting side, do you wanna just touch on what's happening there, like Miniscript and, some of the other stuff?" }, { "speaker": "andrew_poelstra", "time": "13:37", "start": 817.11, "text": "Yeah, yeah. So we have kind of two, two main projects here. One is Miniscript and the other is Simplicity. And so Miniscript" }, { "speaker": "andrew_poelstra", "time": "13:45", "start": 825.32, "text": "is Script so that you can reason about what your script is doing as a set of spending conditions rather than as like a bunch of opcodes. So the problem is this is that on the blockchain, we have this script interpreter. So every time you spend coins, we've actually this like script system, it's not just like, \"Here's the key, here's the signature,\" there's this whole complicated script system. And the way the script system works is that you have what's called a stack machine. You have a stack, you have all these blobs of data, one on top of the other, and you Reading each opcode and the opcodes can like put things on the stack or pop them off or rearrange them or reinterpret these opaque blobs as like booleans, like should I do this or should I do that. They can reinterpret them as public keys, as signatures, as hashes, as hash preimages, as numbers, you know, but they're really they're just blobs and then they like choose what they're supposed to be After being, you know, mixed up and rearranged and so forth, then at the last minute we decide what the blob is supposed to be and then do a signature check on it or do an equality check on it or add two numbers or, or whatever. But the way that users think of Bitcoin scripts is as being spending policies, right? You think, \"Well, I've got like a two of three multisig, but then there's a time lock, and after the time lock is up, then there's this other two of three backup keys kind of thing.\" And the mapping between the user model of- The spending conditions and the actual Bitcoin model of this abstract blob factory, right? There's, there's a gap there. And bridging that gap historically has been the job of wallet authors, who need to write these complicated Bitcoin scripts and then convince themselves and other people that these scripts actually match the policy that they're supposed to, to effect. And they need to figure out how to estimate fees and figure out like, if there are multiple signatures going on, what order do they appear, and do you have to stick millions in between them, like? What's the largest size that this all could be and, and so on. And, what if I have a countersigner and he's not present, how does that affect what's going on? it was all this like very complicated ad hoc work that you had to do, in this context where everything in the end was going into the, the blob factory, right? And you had to make sure that there was no path through the blob factory that would let somebody steal your coin without the record work with the keys, and also that every path that involves the keys actually will let you move the coins, right? You don't want them to be frozen, you don't want them to be stolen, as, as always. So Miniscript lets you model, takes a subset of script that can handle signature checks, it can handle hash pre-image checks, like what Lightning, htlcs use to kind of propagate data between, between different channels, and it can do time locks. And it can combine those, and it can say like, you know, you take an and of these, or an or of these, or like two of three of these kind of things. You can kind of build these trees of, of different spending conditions. And you can directly serialize the tree into Bitcoin script and deserialize it and like rebuild the tree. So now the script, which really like morally represents some sort of like blob factory instructions, now you can think of it as an encoding of this tree of different spending conditions, and the mapping between those is done by these small like five to ten opcode fragments of script that Peter Wuella and Sankei Candle And myself who, who developed this, and many other people have like, you know, really squinted at all the like awful wallet work that wallet developers historically had to do for everything, we just did for these small little fragments and convinced ourselves that they fit together. And now with Miniscript, you can support basically arbitrary policies. As a wallet developer, you can let your users have arbitrary policies, and as long as you can fit it into the Miniscript frame, framework, then you can produce a script that does that and be assured that it's the correct script. And then You just pop the script up into the tree and do the analysis on the tree. So you wanna know like, what is the, how much, does, worst case, how much does this cost to, to, spend? Like, what's the largest size of your witness? Well, you go through the tree, right? If you have an AND at the bottom, you say, \"Well, I have to take the size of this plus the size of this.\" Then you hit an OR, \"Well, I have to take the size of this or the size of this, And then you just go down, and then now you have this very easy to compute bound on the size of what you're doing. If you wanna know what signatures are required, you can easily get a list of what signatures are required. If you wanna know, is it possible to spend these coins without a particular signature? You can just analyze the tree and answer that very efficiently. If you say, maybe you need like some set of signatures, and you've got a whole bunch of signatures, but you don't need all of them, how can you figure out the most efficient choice of which signatures to use and which We actually get in many cases more efficient outcomes for wallets in terms of transaction size using mini-scripts than we did from the hand rolled kind of code that we were working before, because we were able to just like aim so much mental firepower at this small set of fragments that are easier to reason about, and compose in this nice way. So, yeah, we've been working on this for a number of years, just in the last year, or to a number of wallets, pardon." }, { "speaker": "stephan", "time": "19:03", "start": 1143.01, "text": "There's been a lot of development there, right? And I know the Liana We're working on it, Anchor Watch, Rob Hamilton and them. I know the Ledger, Salvatore, Ledger guys are working on it. Yep. And more hardware wallets are adding support for this, so it's an interesting-- there's been a lot of progress in the last year or so on mini script. Yeah," }, { "speaker": "andrew_poelstra", "time": "19:20", "start": 1159.74, "text": "yeah. And I'm not really sure what happened, all of a sudden like people were like really excited about it, 'cause we've been working on this for a few years. and as a bit, I mean, it is actually fairly complicated, it's So this whole new script framework and then this policy framework, and like, as a wallet developer, like, how do you present these policies, right? If you, if you have a wallet where the coins can be spent, or if the wallet signs, or if a different wallet signs, neither one of them should like present to the user that they solely own it. Like, how do you communicate that as part of the product? Difficult product questions to, to, answer that people are, are starting to answer. And then on the, the, kind of low level development of We've been doing is extending miniscript to work with Taproot. So Taproot gives us this whole new way of doing ORs, where you have this whole tree of different scripts and any one of them, might be used. So you kind of reveal the particular script that you're going to use. But you could in principle have a Taproot output that had like a billion scripts in it, and then at spending time you decide which one you actually want to use, you know, uses whatever particular signature tree is available or, or whatever, and then you reveal that one script out of four billion kind of trade-offs that you make and, and the, way that the weight of your program relates to the signature set that you have and, and stuff like that. And it affects PSBT, so how do you, what data do you need to encode in a PSBT if you have multiple wallets cooperating to build something? How do you indicate which branch you want to take? Do you need to reveal all the branches? On chain, you never reveal all the branches, you only reveal one, so we need a coding format for that. And so, so Taproot's actually put a lot of, a lot of extra work on us for, for Miniscript, which is in some ways a little bit ironic because a lot of the design we did in Taproot The script system was to make Miniscript easier to implement, to, to get rid of like multidimensional limits and to, to kind of simplify the way that we do this analysis. but just the whole Taproot model is, is a big, big difference for Miniscript. We've spent a lot of time working on extending that." }, { "speaker": "stephan", "time": "21:32", "start": 1291.79, "text": "Back to the show in a moment. Are you interested in Bitcoin development? Are you interested to learn how to be a developer, or are you already a developer and you need to actually learn some Bitcoin specific skills? Base fifty eight is a Bitcoin protocol school by Lisa Nagert, and this is the place to get guidance in your Bitcoin developer education. Base fifty eight has classes and materials ranging all the way through from beginner developers all the way up to expert level classes, and there are online classes as well as in person intensive classes where you can learn in a safe guided pathway for Bitcoin and Lightning x. Experts, the Taproot Intensive in-person class is coming up soon, and it will cover using Taproot, TapScript, Schnorr, Frost, and MuSig too. This in-person Taproot Intensive class is coming up just prior to TabCon in Atlanta from the fourth to the sixth of September, and this class is on again in Austin, Texas, thirteenth to fifteenth of November. Go to base fifty-eight dot info to find out more. Mempool dot space is a comprehensive Bitcoin explorer covering the entire multi-layer ecosystem of Bitcoin. It's not just a plain old block explorer. Now, You know, you can go there to target the fee for your transaction, whether that's low, medium, or high priority. But you can also search transactions, you can look at the mining tab, you can see the Lightning Network explorer, and don't forget, mempool dot space is open source software that you can host yourself. So if you don't wanna trust a third party, you don't have to. And if you're with an enterprise, mempool dot space actually also offers custom mempool instances with increased API limits and additional access to the team, so you can find out more about all of this At mempool dot space. Okay, and, with the scripting, my understanding from, you know, earlier years of Bitcoin is that there were, I guess, part of the limit or the restriction is that you didn't want, what's it, I think, it's a sig hash limit, isn't it? So it's the idea that you don't want like a particular transaction that can, like, crash someone else's Bitcoin node or that it can, you know, be too onerous. So how do you sort of think about that and combined with Miniscript deals with, you know, the Bitcoin script that exists today or a subset of that, and, you know, how do you deal with the, that sig hash limit aspect?" }, { "speaker": "andrew_poelstra", "time": "23:40", "start": 1419.6, "text": "Yeah, yeah. So there are a couple different limits, and we were able to kind of simplify the whole, the whole kind of, landscape of this. So one was, so, so one issue that, that SegWit addressed was that we had this quadratic hashing issue. Now, this was kind of an old one, and I'm not sure if this is what you're referring to, but the idea that if you structured your transaction properly, you could have a one megabyte transaction, so it fills the whole block, but forces the validator to hash like ten gigabytes of data And take like twenty minutes to validate this block, and then by then, whoever mined this is laughing and has already produced three blocks and now it's taken over the chain, kind of thing. in SegWit, we were able to just like get rid of that quadratic hashing. So basically, if you have a one megabyte transaction, then you have to hash one meg-megabyte of data to validate all the signatures on it. Like we really, we, maybe it's like one and a half or something, but we were able to get rid of that explosion in the amount" }, { "speaker": "andrew_poelstra", "time": "24:35", "start": 1475.25, "text": "of," }, { "speaker": "andrew_poelstra", "time": "24:38", "start": 1478.27, "text": "Because we had what was called the sigops limit, and here we had a limit within a script where you have a limit of how many opcodes you're allowed to use, two hundred and one. Separately, I think within a block, you had a limit of like a thousand sigops that you were allowed to use, and so a sigop is specifically an opcode that does signature checks. so check sig and check multisig are the two options. And the thinking behind this, right, is that the sig, the, the signature opcodes are significantly more expensive than the other opcodes, so you want to have a much lower limit. Like across the whole block, you want to kind of cap that, I think, was what Satoshi was thinking with this limit. But the problem is, as a miner, is now you have these two different things you're trying to get the most fees per byte, so you're trying to, you know, cram the most, transaction activity into your block, but then you have a separate limit, separate from your weight limit, right? So you can have a most, four, four mega weight in your block independently." }, { "speaker": "stephan", "time": "25:35", "start": 1534.7, "text": "Okay. And, with the scripting, my understanding from, you know, earlier years of Bitcoin is that there were, I guess, part of the limit or the restriction is that you didn't I want, what's it? I think, it's a sig hash limit, isn't it? So it's the idea that you don't want like a particular transaction that can like crash someone else's Bitcoin node or that it can, you know, be too onerous. So how do you sort of think about that and combined with Miniscript, is it just that Miniscript only deals with, you know, the Bitcoin script that exists today or a subset of that? And, you know, how do you deal with the, that sig hash limit aspect?" }, { "speaker": "andrew_poelstra", "time": "26:11", "start": 1571.21, "text": "Yeah, yeah The whole kind of, landscape of this. So one was, so, so one issue that, that SegWit issue, addressed was we had this quadratic hashing issue. Now, this is kind of an old one, and I'm not sure if this is what you're referring to, but the idea that if you structured your transaction properly, you could have a one megabyte transaction, so it fills the whole block, but forces the validator to hash like ten gigabytes of data and take like twenty minutes to validate this block, and then by then, whoever mined this is Taking over the chain kind of thing. in SegWit, we were able to just like get rid of that quadratic hashing. So basically, if you have a one megabyte transaction, then you have to hash one meg-megabyte of data to validate all the signatures on it. We really, we-- maybe it's like one and a half or something, but we were able to get rid of that explosion in the amount of, of possible, possible- Multiple hashing that you'd have to do. Another limit, is we had what was called the sig ops limit, and here we had a limit within a script where you have a limit of how many opcodes you're allowed to use, two hundred one, separately I think within a block, you had a limit of like a thousand sigops that you were allowed to use, and so a sigop is specifically an opcode that does signature checks. so it checks sig and checks multisig are the two options. And the thinking behind this, right, is that the sig- the, the signature opcodes are significantly more expensive than the other opcodes, so you want to have a much lower limit, like across the whole block, you want to kind of cap that, and I think was what Satoshi was thinking with this limit. But the problem is, as a miner, is now you have these two different things you're trying to get the most fees per byte, so you're trying to, you know, cram the most, transaction activity into your block, but then you have a separate limit, separate from your weight limit, right? So you can have at most, four, four mega weight in your block. Independently, you can have at most a thousand sigops. And then as a transaction developer, you have to think about this as well. You have to, you have to say, \"Well, my" }, { "speaker": "andrew_poelstra", "time": "28:17", "start": 1697.26, "text": "I can only have two hundred and one opcodes, I can only have twenty sigops or whatever the standard is limit was. I can only like my script can only be a certain length, my stack elements can be a certain length, like there was like ten different limits that you had to simultaneously stay beneath. and it was basically impossible, it was NP-complete to, to solve this in general. The other result we had to do heuristics and do kind of suboptimal things. So in Taproot, we got rid of a whole bunch of that stuff. So we left Like super high and nobody would realistically ever hit. So I think like you aren't allowed to have more than ten thousand stack elements. If you have a script that has ten thousand signature checks in a row, then you're going to be in trouble, kind of thing. but in order to get that ten thousand at, I guess, about a hundred bytes, I'm gonna confuse my zero, but you would need like a megabyte of nothing but, Nothing but signature data. So it's not a realistic case for the opcode limit, which was a real limit, that, that really was causing us grief, the two hundred and one opcode limit. So we got rid of that. There is no opcode limit, because every opcode you use uses a byte of space, and you already have to pay for every byte of space you use in a transaction. So what's the point of having a limit, right? Like it, it actually doesn't achieve anything, because people are already limited by how much of the block space they're willing to pay for. And then for the separate sigop limit, we got rid of that, and we said every sigop costs you fifty bytes. So if you use a sigop, then somewhere else in the transaction you have to just stuff fifty bytes. And so this sounds like kind of concerning and wasteful, right? That we're, we're-- 'cause we, we really only want one cost, which is how many bytes you use. So every time we say like this costs fifty bytes, the way we affect that is by saying you have to stuff fifty bytes in there. Well, conveniently, a signature check already involves" }, { "speaker": "andrew_poelstra", "time": "30:06", "start": 1806.47, "text": "And so the signature is already large enough, like just by paying for the signature, you have paid for the sigop, so we're able to effectively get rid of that limit as well. and using scripts, you can find ways to run into it, right? Where you take the same signature and then you like duplicate it a hundred times in script, so every duplication only costs you one byte instead of sixty-four, and then you check them all in. But real, realistic uses of Bitcoin script, every check, every, sigop will be accompanied by a signature, and the signature you have" }, { "speaker": "andrew_poelstra", "time": "30:36", "start": 1836.13, "text": "The cost for a normal opcode, as you are for a signature, no need for anything special, so we were able to get rid of that. And so as a result, in Taproot, when you're creating scripts, you basically just have to think about how many bytes will each part of the script cost you, and you have to pay for that many bytes, and you're not going to run into a situation where like you go above some limit and suddenly your transaction is invalid, which used to happen. You can just say like, \"Okay," }, { "speaker": "stephan", "time": "31:01", "start": 1860.52, "text": "I gotcha. So" }, { "speaker": "andrew_poelstra", "time": "31:01", "start": 1861.02, "text": "this is an optimization problem instead of" }, { "speaker": "stephan", "time": "31:06", "start": 1866.35, "text": "Got it. Okay, yeah, I think I was referring to the SigOps limit, 'cause I think I'd seen some writing from you and I, you was, you were mentioning this limit and I was curious if that sort of played into Miniscript. Okay, and so when it comes to simplicity, this is, this seems like it's a, you know, sort of like a far off thing that everyone seems to talk about, or not, not everyone seems to talk about, but people mention it being this far off thing, but I, I guess I, I haven't been able What is, what is the idea here? What would it mean for us?" }, { "speaker": "andrew_poelstra", "time": "31:39", "start": 1898.93, "text": "For sure, yeah. So simplicity is something we've been working on for a long time, right? And so it certainly gets this reputation as like something that's like some weird research project that, you know, Russell O'Connor has been quietly working on for six years, and no one knows when or if it'll see the light of day, kind of thing. but it will, in, for some, some sense of light of day, pretty soon, and I'll, I'll talk about that. But the And you kind of reason independently about parts of your tree and then reason about how they're, they're clipped together. And you build an entire language out of that. And then rather than having the leaves of your tree be these kind of complicated, hairy things like signature checks involve like millions of elliptic curve, not millions, thousands of elliptic curve operations and, and field operations and stuff, and hash checks that involve like running through this whole SHA-2 thing and, and time locks that involve reference to the entire blockchain and, and limits, how about their leaves are just like fundamental computer science? It's like the minimum kind of fragments of computation that you would need to, in principle, build up a computation. And in the case of simplicity, when we do that, the two fragments that we use, we have one called unit and one called idempotent. The identity. And the unit one does nothing, it just like outputs a, a null value basically, and the identity one takes an arbitrary value and outputs an arbitrary value. And then amazingly, by combining those in various ways, and it's a little bit more involved than and and or and threshold now, we can compose these in various ways, and in seven ways in particular that will allow you to construct a program that can express any arbitrary computation. and actually, the, the resulting language, there are nine common irises, iden and unit and these seven And together, they're so small that they fit on a t-shirt, which I happen to have right here. believe it or not, this notation is useful. The reason that I had it there is that I use this shirt as a reference, because I'm too lazy to open a PDF or get it on the screen. What's cool about this is that because each of those, despite being in this like opaque, scary mathematical language, are computationally and conceptually extremely simple things. So you can express those directly in Coq or Agda or Idris or F# or whatever kind of, formal proving, Computer assisted proof scheme that you might want to use, so you can create an actual formal model of exactly what a simplicity program is inside of a theorem prover, and then you can get machine checkable proofs of whatever property that you might want. So in Miniscript, I, I maybe kind of hinted at that, right? So if you want to know, like, is it possible to spend these coins without my signature? Am I really a co-signer? Then you can do that. There's a mechanical process by which you can do that, but the mechanical process is a little bit of an ad On the structure, miniscript, and assumes that the actual semantics on chain are what you expect. And because it's all a little bit ad hoc and thrown together, if you're trying to do something really complicated and say, \"Well, I suppose I need these ten conditions to be true of my script. And then together these conditions imply, you know, something. and it's hard to give an example with Bitcoin scripts concretely, because, like, you need more expressivity, you need the ability to do mathematics and, and stuff. But you can imagine, like, you have some sort of script that is trying to restrict the fee range for a particular output and say, like, \"Well, if this person signs, then the fee is allowed to s-exceed ten satoshis.\" But if they don't sign, then the fee has to stay below ten. So now you can kind of delegate to, a signer you maybe don't trust so much, and then you only need the high trust key in the case that the fee, fee market has, has gone crazy. Or you can have like a vault setup where you can only move so many coins at once, and then the rest of them have to go back again conditioned on the different keys that you want. And you can imagine trying to describe all the different conditions you need to hold. And then a mini-script or a, a hypothetical mini-script extension, you could probably come up with an ad-hoc argument for all these things. But now suppose you tweak something a little bit, well, which ones of your ad-hoc arguments are valid and which ones are no longer valid and need to be redone? And what about the way that you're connecting these from the start? Like this. you, you'll quickly find that over the, the life cycle of, program, just like tweaking it and then trying to like correspondingly tweak your ad hoc kind of informal arguments, you're going to eventually slip up and then you'll accidentally have a program where it's possible to move the coins when you don't expect or impossible to move them when you do expect. In simplicity, you can describe this all, the exact behavior of your program formally inside of this, this abstract model called the bit machine, and then you can produce A machine checkable proof of every one of these weird claims that you might need to be true. And then when you tweak it, you know exactly which parts of your machine checkable proof are valid and which aren't, because you can use the machine to check them, right? And so if you break some part of your proof, but maybe the rest of it is still okay, if you break this one part, so now you know, well, I need to redo that proof, and you redo it, and then does the new proof still hold, it still compose your larger, larger thing, let's you As well. And so now you have this very high assurance, assuming that you've modeled your problem correctly and you're actually checking the right statements, which is, you know, a big if of this whole field of, of program specification and analysis. But assuming that you've figured out how to model what your program is, you can have machine-checkable assurance That all of these properties are true, and that's kind of essential to go beyond the, the simple Bitcoin, you know, spending condition model to something more elaborate where you could have keys that are like controlling capabilities, or you could have parts of programs that are like checking activity on other blockchains, or checking zero knowledge proofs of things, or, or checking, you know, arbitrary signatures or oracle signatures on the outcome of, you know, like horse races or, you know, whether a certain president has died or, you know, whatever you want. So the- The idea behind Simplicity is that we have the mechanics to build a formal model, and our thinking is that probably nobody's going to directly use Simplicity, it's so low level and so like, it's so difficult to build this stuff. But what Simplicity gives you is it gives you a rock solid, kind of bedrock of, of formal semantics where you can then produce a library of proofs about, kind of your base components, you can compose them, you can make proofs about your composition, assuming that your theorems about the, the- pieces of the bedrock hold, and you can say pretty strong things. And what's especially interesting about this is we can use it so even let me shift gear a tiny bit to talk about will simplicity be in Bitcoin ever? And yes, one day, at least ten years from now, I hope. Right? Like it's, it's as far away from Bitcoin But even before we get simplicity, into Bitcoin or anywhere near into Bitcoin, what we can do is we can use simplicity to model extensions to Bitcoin. So you could take something like OpCTV or, OpVault, which James Obrien has been pushing, or, SeeCash, AnyPrevo or, or whatever it's called these days, or like all these different extensions to Bitcoin, and right now these are kind of defined by the C++ code that extends the script interpreter. But you can imagine a world in which you had a specification in simplicity, and then if you wanted, if somebody was worried, like, \"Oh, I think this would enable some like horrible thing to happen in this edge case,\" they could either prove that it doesn't happen or generate an example where it does happen, and now you have that, and anybody can verify that Right, so it's really, we're not arguing about semantics or arguing about hypotheticals, or like disagreeing or saying like, \"Well, maybe the script interpreter does that, I don't know. Like, I guess we have to go read the C++ code and write a bunch of tests and hope that we, we cover every, every, angle here.\" You can have a formal specification of stuff so in the medium term, that's sort of what I imagine Simplicity would be used for, is literally adding specification language for proposals that would go kind of by themselves outside of Simplicity into Bitcoin In the very long term, I'd like to see it in Bitcoin, 'cause then that's even better, right? 'Cause then you're not only like, \"I wanna do the CTV thing, here's the specification, it's complicated,\" you can say, \"I wanna do the CTV thing, here's literally how to do it on Bitcoin today. What I want is first-class support, so it's cheap, but at least I can do it, and maybe it costs me, you know, a whole ton of opcodes, but, you know, you can still do it and feel" }, { "speaker": "andrew_poelstra", "time": "39:56", "start": 2396.5, "text": "The actual fork, if you want to fork, is just a matter of taking an existing program and replacing that with optimized code, which is cheaper. So that's the long term vision. And then the short term vision is that we're planning to launch simplicity, on a liquid test network at some point in the next few months. it's a little bit uncertain because I'm, I'm pushing on this a fair bit, and I am going to be a father at some point, probably by the time people are listening to this. So very soon." }, { "speaker": "stephan", "time": "40:27", "start": 2427.46, "text": "Oh," }, { "speaker": "andrew_poelstra", "time": "40:29", "start": 2428.76, "text": "I'm going to take off work for, for a few months, and then it's hard, it's hard for me to make predictions about, about stuff where I'm not there. but in the short term, we're building up to a release on- on a, on a, a liquid test network, we would like this release to include example programs and some developer tool, like a toy wallet that people can play with, and we really want to have like a coherent, like, Package that people can use, but we're not kind of just throwing the white paper or the t-shirt at people and saying like, \"figure it out.\" We really want this to be tangible, bearing in mind that it is a very low level language and it is very complicated to use, and, and our eventual goal isn't that people would use it directly, it's that specifiers will be using it, with a whole bunch of machine tooling to help them out and so forth. But we want people to be able to play with it, and we want to deploy it on a real blockchain, And we are gearing up for, for sort of a test net release where we can start doing demos with this and start thinking about how we can build real stuff. But that's been, that's been pretty exciting and, and in my day to day work, that's probably the thing I spend the most time One is, is pushing forward on" }, { "speaker": "stephan", "time": "41:29", "start": 2489.18, "text": "that simplicity stuff. Yeah. Back to the show in a moment. The lead sponsor of this show is swan dot com. Swan dot com is the place for safe and easy Bitcoin buys. You can set up a recurring purchase plan, you can also do a one time buy or a smash buy, and Swann offers free custody in your own legally owned trust account with free automated withdrawals to self custody. Now, if you are a high net worth investor, you might be interested in Swann Private. Swann Private is a trusted partner on your Bitcoin journey. You get a dedicated Bitcoin expert, you have exclusive events, support for retirement, trust and corporate accounts, as well as Bitcoin and investment research. There's all kinds of support that the Swan team can offer you, whether that's education or help with your self-custody. Go to swan dot com and sign up for more. When it comes to securing your coins, you need reliable Bitcoin hardware, and coinkite dot com makes the best. They've got the Coldcard Mark IV, which is an extremely reliable and ultra-secure device that you can use without even Even phoning home. You can plug it into the wall and not even plug it into a computer. That's the kind of security that you can get using the Coldcard with a micro SD card, and they've got a new device coming out soon which is called the Q1. So that's also available for pre-order. They have a range of other devices, such as the TapSigner and the SatsCard. The SatsCard is like a physical, smaller way of sending Bitcoin around to people. It's kind of like the new version of the OpenDime for those of you who You can get over at coinkite dot com, get a discount on your cold cards using the code Laverre over at coinkite dot com. And now back to the show. Okay, interesting. Yeah, so, yeah, because it does raise all, all these questions around, well, yeah, as you said, well, I mean, you've answered in terms of what does it do, what is it for. I'm curious as well if you have anything to add around some of the discussion about covenants, right? So there's, there's discussion about that You know, there are, there are, I mean, there's different camps out there, right? There are people who are like, \"Oh, CTV didn't do enough,\" right? That's some people who are in that camp. And then, maybe a few years ago, there were a lot of people who were anti-CTV, and now I think it seems like more people are maybe- You know, mildly positive on CTV because maybe they see ideas of how it could be used in practice, and then I guess the questions people are asking are things like, \"Oh, our recursive covenant is bad for Bitcoin, is that gonna be, you know, a bad thing?\" Or \"Is it actually, something else that they're objecting to, whether it's like something they heard about in Ethereum having a global state machine or some other aspect that they're, they're critiquing?\" How are you seeing some of this, and when it comes to Bitcoin?" }, { "speaker": "andrew_poelstra", "time": "44:11", "start": 2651.06, "text": "See, Voice, like, I mean, I think you summarized all these different, different ideas. I would say I'm, I'm in the camp that thinks that CTV doesn't go far enough. I would rather have CTV than have nothing, so I guess that's like mild support, but certainly I, I think that we should have a, I would rather we have a general covenant. Kind of like a fully general, like do recursive covenants, do non-recursive covenants, do literally everything. And a long time ago, I was kind of in the camp that was quite worried about recursive covenants, because there's these kind of, doomish kind of ideas where you can imagine using recursive covenants to like attach some sort of like watermark or like some sort of like Federal Reserve signature to coins or something, and then like you can imagine there's regulatory pressure to have people move their coins into this special covenant where like somehow the coin is, is tainted or whatever Then once it's in the covenant, it can't come out. And then wallets would start to support this, and then gradually all the coins would move in, and they can't move out, and then all of a sudden every single Bitcoin, not all of a sudden, but you know, gradually this whole virus takes over the whole Bitcoin. I'm very unconvinced now about this scenario. So for one thing, there are some big technical barriers. Even with covenant support, it would be expensive, it would increase the fee burden on every single transaction, so wallets wouldn't want to support it because it's going to make everything more complicated. That are more expensive, it would make everything more complicated. It's a whole bunch of extra code to write, it's a whole bunch of extra things that the wallet developers have to do and get right. it probably opens them up into some sort of legal liability because it's unclear whether, like, a, a debt in Bitcoin can be settled by tainted Bitcoin and so on. And so now, like, people don't wanna touch that. And there's no shelling point around this. Right? Like maybe like somehow there's like a world government that says we want this covenant, but like, no, in real life it's going to be like ten different governments making ten different incompatible demands on people, and most people will like strongly dislike at least nine of those, probably all ten, right? And so there'll just be this whole cluster of, of incompatible things that are all bad for wallet developers and bad for users and we'll be unable to get any traction. And then the other reason I'm not worried about this is that you kind of can do it today with multi-sig So you can imagine, say that the Federal Reserve were to lean on Coinbase and say, \"We want to be a counter-signer for every single coin. So you aren't allowed to send coins to users directly. You have to take their address and then like convert it to...\" Like a multisig with the Fed, okay? And then the Fed in turn will only ever sign transactions that send it back to, to such a multisig. And so now without any direct blockchain support, just by leaning on one large company, and then having the Fed enforce its own rules, they've managed to do this kind of watermark thing. Right? And this has the same kind of, disastrous consequences as something covenant based, but when you illustrate it in terms of multisignatures, I think it's much more intuitive, logistically, why this wouldn't work, right? Like it, it's, it's-- you can sort of see like all the million and one difficulties the Fed would have in defining this policy and enforcing it, on every single transaction they sign and figuring out how to be a multisigner and convincing Coinbase to go along with it and dealing with the legal consequences in other jurisdictions and dealing with the PR Disaster. And like, well, they could have done it for the last eight years and they haven't, and nobody's made any movement towards doing such a thing," }, { "speaker": "stephan", "time": "47:27", "start": 2846.98, "text": "right? Right? Yeah. And by itself. I think the point I've seen people make is that this would be resisted at a social layer, not as, it's not really a technical discussion per se. and the other argument, and, and I think I agree with this point, which is that you, the user, are opting in. So you, you, you, the user, can say, \"Uh, I" }, { "speaker": "andrew_poelstra", "time": "47:50", "start": 2869.52, "text": "Exactly. You know," }, { "speaker": "stephan", "time": "47:51", "start": 2870.88, "text": "like, so it's kind of like opt in anyway. So if you want to opt into a, a covenant context, and I generate some kind of covenant address, and the exchange or the counterparty pays me into that, well, that's another whole thing, 'cause I opted into that. It's not like they can ex- externally impose it on me when I didn't ask for that." }, { "speaker": "andrew_poelstra", "time": "48:09", "start": 2888.93, "text": "Yeah." }, { "speaker": "stephan", "time": "48:09", "start": 2889.49, "text": "So I'm not too worried about that. But I guess, do you see like a technical reason why, you know, recursive covenants or things like this would Bad for the network in some way or is it not really?" }, { "speaker": "andrew_poelstra", "time": "48:22", "start": 2902.34, "text": "So a technical reason? I don't think so. Like in terms of efficiency of the network or efficiency of the script interpreter or like vulnerabilities in, in anything, or like wallet mode, the surprising behavior, I really don't see any technical reason. not to do this. In fact, technically speaking, we've come very close in the past, to having--" }, { "speaker": "stephan", "time": "48:44", "start": 2924.5, "text": "Right. And you've done some blog posts on OP_CAT, right? Right. Yeah." }, { "speaker": "andrew_poelstra", "time": "48:47", "start": 2927.12, "text": "Like, for example, if we had OP_CAT or anything that, that resembled OP_CAT, we'd actually already have a simple form of covenant by abusing, the Taproot signatures to act as a, to, to get you a hash of your transaction. and even before this, you could use ECDSA, actually, if we had SigHash and E-P" }, { "speaker": "andrew_poelstra", "time": "49:09", "start": 2949.08, "text": "To get a very limited sort of covenant, and again, like it's like a really twisted kind of, kind of logic you have to do and be very inefficient. My point is just like, it's very difficult to avoid covenants, it turns out. we've been technically very close, and fortunately, even all these accidental covenant proposals, if they had turned out to work, if like a couple minor things have been different, they wouldn't have been harmful either, right? So it's not like we, like, \"Oh, we really dodged a bullet there,\" it's just like, \"Oh, it's kind of a weird, a weird property of the script interpreter that we didn't expect.\" So technically speaking, I, I don't think there's much. I think the reason, the reason for opposition are, are in part the social one about like contagion and a newer one that you kind of hinted at about maybe this enables colored coins or multiple assets or like somehow economically decouples, Bitcoin transaction activity from paying miners because like you have these, these like zero valued, zero Bitcoin valued outputs that like somehow represent colored coins and so on. And there again, I have less of like a confident like- That's impossible kind of thing, but there again, it's kind of possible today to do stuff like this, right? And I get that there's a lot of social resistance when people try to do stuff like this, but you don't really necessarily need covenants to do something like colored coins to have multiple assets on Bitcoin." }, { "speaker": "stephan", "time": "50:26", "start": 3026.27, "text": "that's true. I mean, RGB exists today. Yeah, RGB exists today. If you want," }, { "speaker": "andrew_poelstra", "time": "50:30", "start": 3029.59, "text": "you know, fungible tokens, if you want NFTs, Ordinals, right? and that's, that's a bad example. People really don and I apologize 'cause it's kind of my fault that all the script, all the script limit relaxation I was talking about for Taproot, that's why we can do it." }, { "speaker": "stephan", "time": "50:44", "start": 3044.38, "text": "Right, but I think people did make the point that this stuff was even possible before, but just in other ways." }, { "speaker": "andrew_poelstra", "time": "50:49", "start": 3049.3, "text": "Yeah, right. If you're willing to split up your image into like multiple thirty-two byte chunks, you can hide it in signatures, you can hide it in public keys. Counterparty used to do this in like twenty fourteen. they would use like one of two multi-uh, check multisig opcode or one of the keys was not a real key, it was just data that they were sneaking in, kind of thing. So, yeah, I certainly like, I don't regret relaxing these script limits because it makes one particular form of data stuffing possible." }, { "speaker": "stephan", "time": "51:14", "start": 3073.96, "text": "Like each decision made sense at the time, and I guess the other one people are saying is, \"Oh, no, the SegWit discount or the, you know, the four million wei-weight units,\" but even then, you would still say" }, { "speaker": "andrew_poelstra", "time": "51:28", "start": 3088.29, "text": "Yeah, I mean, that's exactly right. You can point to every individual part of the system and say, \"Well, if this part we tweaked somehow to like shove a wrench in this thing I don't like,\" well, okay, you could, but I mean, you shouldn't just grab at random parts of the system and try to, to use them to, to gum stuff up because there's a reason that these, that things work the way that they do, and we would- Undermine a whole bunch of legitimate use cases and probably not undermine illegitimate ones, because there's a lot of ways to, to stuff data in the chain, if you really want to." }, { "speaker": "stephan", "time": "51:56", "start": 3115.62, "text": "Yeah. Okay. So I guess if we, if you, like, I guess in your view, as you're saying, you would prefer something with, let's say, quote unquote, more power than CTV, what are you talking about there? Are you talking about like the TX hash plus check sig from stack thing or other proposals, OPTX, I think Rusty had one. What kinds of things would" }, { "speaker": "andrew_poelstra", "time": "52:17", "start": 3137.3, "text": "My favorite proposal, which isn't even a proposal because I'm too lazy to make it, would be one where we add a bunch of introspection opcodes. So the idea is that you would have an opcode that just like loads the, the, input value of the current input onto the stack or loads like the output of a specific-- the value of a particular output, you just load that onto the stack, and you have an opcode for each part of the transaction, you load it onto the stack, and then you can, you know, compare it to whatever targets you want, to say like, you know, this, you, you can only have this many outputs, and like the total value can only be this much, and, and stuff like that Like that. The, the way that like OptiX and, and TXHash and these kind of things work is that they load the entire transaction data, kind of like a whole transaction, onto the stack, in the form of a hash, and then they ask you to reconstruct the hash In terms of, kind of a combination of, free-for-all data, which isn't constrained at all, and data provided by your program, which then is constrained, and you try to get exactly the same hash And I think Jeremy Rubin characterized the difference between these two approaches as having negative covenants and positive covenants, and through a subtle argument that I don't remember right now, one of these approaches is useful if you think that you're going to be restricting a small part of a transaction, but assuming the rest is going to be a free-for-all. And the other one is useful if you think that you're mostly going to be constraining your transaction to be a, like, a particular template and then only allowing certain pieces to be, be a free-for-all. And I think that Oh, I haven't thought about this in a while, so I'm gonna have to be careful. But, but my conclusion the last time I was thinking carefully about this is that I'd rather have the positives coming at us, I'd rather have the ones where you, you, you point at a particular part of the transaction, you load that on the stack, and then add constraints to this. but like fundamentally they both have the same expressivity, it's like really about which one is more efficient under what circumstances, and maybe there's an argument for having both actually in, in this Situation." }, { "speaker": "stephan", "time": "54:18", "start": 3258.42, "text": "I see. But yeah, that's" }, { "speaker": "andrew_poelstra", "time": "54:19", "start": 3259.2, "text": "what I'm thinking. These, these new introspection opcodes." }, { "speaker": "stephan", "time": "54:22", "start": 3262.3, "text": "Yeah. Okay. And so as I understand, there's already, so from that recent episode with Brandon, actually, he mentioned, we were talking a little bit at the introspection, as I understand, there's a little bit of, there are some of these introspection opcodes on Liquid today, but not in Bitcoin. Is that correct? Yes," }, { "speaker": "andrew_poelstra", "time": "54:35", "start": 3275.48, "text": "that, that's correct. Yeah. So we, kind of as part of our work in Liquid on extending min To support, so Liquid a long time ago, as since its inception, has had this checksum from stack and cat based covenant system, and this is one of the oldest ideas for covenants, and the idea is that we take these like almost accidental covenants that come from the ECDSA signatures, and we just promote them to being first class. The idea is you have a signature on your transaction, and you validate the signature twice, once you validate it against the transaction, and the second time you validate it against an arbitrary blob of data And if they both pass, the arbitrary blob has to be the transaction, and then you can deconstruct the blob and then start like putting constraints on it and doing covenants that way. And what we found on Liquid was that when we tried to use these checksum stack based covenants in Miniscript, we found that it was actually very difficult to make this fit into the Miniscript model Because Miniscript tries very much to be local, right? It tries to, so like you have this tree of different, different things, like you have a signature check here and a half check here and so on. And imagine we wanted to add covenants, we'd say, \"Well, and here, like this output can only be this particular value, and the fee rate can only be this much, and like so on, and you add and or and build these together.\" Well, with CheckCeed from Stack and with all of these negative covenant proposals, what this means is every time you want to constrain one particular part of the transaction, you kinda have to load the whole transaction up and then try to restrain, constrain this particular part and then throw away the rest kind of thing. And in the end, what we did with Miniscript was we wrapped the Miniscript in this kind of script structure that we called the machine. I don't know where we got this name, but where at the very beginning of the script, we would load the whole transaction, we would create this arbitrary blob that represented the transaction, we would use op-cat to break it into a bunch of pieces, we'd put all the pieces at the bottom of the stack, and then later when we wanted to refer to them, we would use the depth and size, these obscure opcodes for, for manipulating the And we do our regular script, and then we drop everything from the bottom of the stack, the, the stack has to be empty in the end. And so what we were doing was we were taking this negative covenant construction, and then we were artificially inverting it so it became a positive covenant, if I'm using those two words correctly. We, we were inverting it so it became a positive covenant construction. And kind of the lesson that we learned from that is that we'd be better off if we just directly had positive covenants. So rather than doing this whole thing where you use checksums to put all the data here, then having these opcodes where you like find the right index at the bottom and pull, pull our, our data out, then wouldn't it be better if we just had an opcode that would just grab the data right from the transaction and put it there where we need it, and then we could fit that into the So we did actually add a whole set of opcodes for looking at all the different parts of the transaction, into liquid, and we were able to extend Miniscript. We have this fork we call Elements Miniscript that Actually uses these opcodes and you can do covenants with this today if you wanna go like find the source repo and, and build and tr- like build weird things on Liquid. it is like, it's sort of specked out in a readme document that's kind of fluid, like it's all like a little bit experimental, but in the context of Liquid where we have multiple assets, we've been able to create things like, Like fully collateralized options where you have, we're able to put up some amount of like, LBTC of, of Bitcoin moved onto liquid, you put that up and say like these coins can only be moved at this date if you send me this amount of dollars in Tether for it For example, so you can build options that way. you can make the negative side of that option be tradable, so it's not you're sending fifty thousand to me, it's you're sending fifty thousand to somebody who holds this like inverse option token, and just with these very simple extensions with these, With these introspection opcodes, we were able to construct that stuff in the mini script model, where we still had a nice tree that we could reason about and stuff, which is, is pretty cool. but we haven't done, we haven't done vaults, we haven't done OP, or we haven't done seckhash, on no input. there are a few things that we're pretty sure we could do if we like put our minds to it, using these, these introspection opcodes, but we haven't worked out the details yet." }, { "speaker": "stephan", "time": "58:48", "start": 3528.05, "text": "In some way, if you had introspection, you could replicate or do some of the functions of like APO or Vault. And okay, so that's what you were sort of getting at at that idea that you, you know, if you had something with more power than CTV, you could do these kinds of functions. Right." }, { "speaker": "andrew_poelstra", "time": "59:06", "start": 3546.12, "text": "Yeah, exactly. You can, you can kind of simulate these things. and certainly if you went all the way and you had something like Simplicity, which can do any computation Then you can emulate anything, like even em- emulate it by writing a specification. This is a cool idea. And that's just kind of philosophically the direction that I would like to push things in." }, { "speaker": "stephan", "time": "59:23", "start": 3562.94, "text": "Yeah, interesting. Okay. And so I guess I take it then that you are, I guess, loosely pro APO as well, but you might-- but taking what you're saying, is that you would write, you might prefer it being done maybe in a different way than just APO, the proposal as it is today, or how are you seeing that?" }, { "speaker": "andrew_poelstra", "time": "59:40", "start": 3579.77, "text": "I don't I kinda like APO the way that it is. So if you were to try to simulate APO using a general covenant construction, or even using CTV, I don't remember if you can do that or not, the result would be pretty inefficient. I think if we want APO, we should have APO, and I, I personally think we should have APO. the arguments against APO were like, kind of wallet safety, like APO is very dangerous if you were like had like a normal consumer wallet and was willing to sign APO transactions, all of the bad surprising things would happen. But I don't think normal wallets would do that. Like, I think like lightning wallets would use that in the context of the vaults and like contained" }, { "speaker": "stephan", "time": "01:00:16", "start": 3616.26, "text": "lightning, you know, lightning symmetry sort of context, yeah." }, { "speaker": "andrew_poelstra", "time": "01:00:20", "start": 3620.62, "text": "So, but I don't know, I mean, people tell me I'm not being cynical enough, but I think that I am. Like, I don't, I don't think people would do this, I really don't. Right? This seems, seems pretty radical." }, { "speaker": "stephan", "time": "01:00:30", "start": 3630.0, "text": "Yeah, interesting. Okay, yeah, well, look, we've been going, for a little while, so I might, I might end up splitting this, this up into multiple episodes anyway. But, thanks for joining me today, and," }, { "speaker": "stephan", "time": "01:00:43", "start": 3643.99, "text": "do you have any, I guess," }, { "speaker": "andrew_poelstra", "time": "01:00:49", "start": 3649.11, "text": "Well, I have one more thing I'd like to say about Codex 32, and maybe I'll close on that, which is that, or, or about two of two secret sharing in general, which is that you can use a two of two secret share as a form of encryption. And what I mean by that, well, you can almost imagine what I mean. If you have some sort of secret data, you do a two of two share, you split it in half, and you can think of one half as a seed and one half as the encryption key if you want, although One of these tubes across the country or across a border or something, and you're worried about your security in transit, then what you can split it in, let's assume your endpoints are secure, so it's starting off in a secure location and ending up in a secure location, but on the way, you know, you gotta worry about the TSA and about, you know, passing" }, { "speaker": "stephan", "time": "01:01:36", "start": 3696.0, "text": "a border or something, or" }, { "speaker": "andrew_poelstra", "time": "01:01:37", "start": 3697.41, "text": "train hijackers or whatever. you split it into two pieces, you carry one from A to B, then you go back and carry the second one from A to B. And if you get compromised on either trip, because only one share is compromised, that has no information, so then you just destroy the other share and you restart with a fresh try. Every try, every time you split, you get a fresh, like, independent start. So you just keep on trying this until finally you manage to, to, Trips in a row, and now you have assurance that even if, like, you get stopped by TSA and searched, and they open up your tube and like write down all the values in the tube, right? Which I've never heard of happening. It certainly is within their rights to do so. even if that happens, you, you're still safe, so you can transfer your data this way. And the fact that you can do it by hand using these paper computers and you don't have to worry that like your weird encryption scheme, is somehow broken in some way, which has a high probability-- this is such an obscure thing to do, right, that it has a pretty, a higher probability Of there being problems with any particular scheme that you find or make, but you do it by hand and you have pretty high assurance about that. And you can do it with Slip 39 as well, if you wanna use computers. Slip 39 is very well supported by Trezor. I would suggest to the people how their seed words and they're trying to move them, to split it into a two of two secret share and carry it. And then zooming out, I guess I will give you a high level thing about Bitcoin, which is that right now, I've been spending a lot of time on simplicity, but really I think the most important problem pressing Bitcoin is the user experience around self custody. And a big part of why I'm working on this project with these paper computers and stuff is that I want to make I guess I want to make it accessible, I want to make it tangible, I want to make it possible for people to manipulate their seed data in ways where they know exactly what's happening and where they have high assurance that their data's not being leaked in some way. So as they're doing these, as they're verifying their checksums, you know, they have a single piece of paper, it's got the secret data on it, you put it in a blender with a cup of water and you run it for a minute and now that data's gone, it's not stored anywhere else on any like piece Just as a grape pulp in your blender, and now you can dump that in the garden or flush it down your toilet or something, right? It's gone, you know? So I've been very-- and this touches on a bunch of things we've talked about. So, so the Codex 32 is probably for a pretty advanced kind of crazy person, even though we really tried to make it step by step. Mechanical. Like if you didn't, if you weren't super comfortable with it, I don't know that you'd be comfortable just blindly following the instructions. We talked about Miniscript. Miniscript lets you have arbitrary policies, and let you have, like, back- Backup keys and stuff, and then be able to define a policy where you don't need to use some particular ad hoc kind of wallet, you can just come up with a miniscript policy and any wallet will support it. And, and Liana, conveniently will even like hold your hand doing this. That's what they do, is, is a state planning based on these kind of policies and stuff. So, I'm really excited to see how that evolves, both like directly with seed custody kind of things, like, and, and I think this also like, is a great technical innovation, these that's really what I think is, is the most pressing thing on Bitcoin right now. Like, I, I think the script stuff is cool and, and I love to work on it and build it up, and, and the cryptography as well, although I haven't really had time over the last year or two to, to be, super deep into that. but really I think what's important is, is this like making the, the custody story understandable and making it tangible and making it user friendly and, and So that it will survive, people." }, { "speaker": "stephan", "time": "01:05:11", "start": 3911.95, "text": "Yeah. Well, that's a great spot to finish up. Yeah. So Andrew, I guess just lastly, where can people, find, find your work and find what you're working on?" }, { "speaker": "andrew_poelstra", "time": "01:05:20", "start": 3920.27, "text": "Yeah. so I'm not, I'm not on X or Twitter or any, any social media really. you can find me on IRC, although if you're on IRC, you probably are already talking to me. There aren't, aren't a lot of us left. you can find me on GitHub. My name is and that's-- those are probably the two, two best ways to see what it is that I'm up to. If you're interested specifically in the book, Codex 32, you can find that on the Blockstream Store, store.blockstream.com or we have a website, secretcodex32 dot com, which has some, some more explanation and, and download, downloadable, downloadable links and so forth, or there's a GitHub repo for it Which I think is GitHub slash Blockstream Research slash Codex thirty-two, where you can poke around at" }, { "speaker": "stephan", "time": "01:06:08", "start": 3968.49, "text": "that. Right. Okay. Fantastic. Well, I'll put all the links, in the show notes there. And, thanks for joining me, Andrew." }, { "speaker": "andrew_poelstra", "time": "01:06:13", "start": 3973.64, "text": "Yeah, thank you. It was a lot of fun." }, { "speaker": "stephan", "time": "01:06:16", "start": 3976.25, "text": "I hope you enjoyed the show. Make sure to find the show notes over at stephanlivera.com. Thanks for listening, and I'll see you in the citadels." } ] }