WBD110 Audio Transcription 

Andrew Poelstra on Schnorr, Taproot & Graft Root Coming to Bitcoin

Interview date: Friday 24th May 2019

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

In this episode, I talk with Andrew Poelstra, Director of Research at Blockstream about some of the exciting new tech coming to Bitcoin. We discuss Schnorr Signatures, Taproot, Graft Root and Confidential Transactions.

Interview Transcription

Peter McCormack: Hello again Andrew, good to see you again.

Andrew Poelstra: Hey Peter, it's great to be back.

Peter McCormack: Yeah, so soon! That last show we did was really popular, everyone loved it.

Andrew Poelstra: Yeah, you sent me some footer links. I was very happy to see that.

Peter McCormack: Yeah, I don't know what happened. Perhaps because I had no idea what we were going to talk about it. It was one of the first interviews, I came without any questions and we just rolled with it and we seemed to get a really great show out of it! So today I've cheated slightly, I've got five words to prep for this interview and five things I'm going to ask you to take me through, which will hopefully help other people who want to understand these things. Now we covered the first one in the last interview. But Pieter Wuille…

Andrew Poelstra: I say Pieter Wuille, which he doesn't correct me on. But he may have just given up!

Peter McCormack: I see. I wasn't sure what it was... If I meet him, I'll ask him! So he obviously put out proposal for a couple of new BIPs, is that correct?

Andrew Poelstra: Yep.

Peter McCormack: Okay and there's a few things within there that we should unpack, but we covered Schnorr before, but let's do it again because I think it's going to go with everything else. So start by explaining what Schnorr is and why it's helpful and good for the Bitcoin.

Andrew Poelstra: Sure, so Bitcoin today has a scripting language that it uses for controlling the spending of coins, for defining the spending policies. Typical Bitcoin spending policy is just somebody has the public key, they need to provide a transaction with a digital signature associated to that public key. You can also do multisignatures and whatnot.

As a primitive in Bitcoin for checking these signature, there's something called ECDSA, which is just a cryptographic object that was defined by Nist, I believe in 1990, as a short, depending on how you encode it, its like 73 bites elliptic curve based digital signature.

The reason that that this was defined, as opposed to suggesting people use the Schnorr signatures scheme, which had been created a couple of years before, by it's supposed inventor Claus Schnorr. I shouldn't say supposed, his name is on the patent!

Peter McCormack: And it's named after him!

Andrew Poelstra: So a Schnorr signature academically is the simplest instance of something called a Fiat-Shamir transform and this is just a way to take some interactive protocol, in this case, a Schnorr identification protocol and that really is what Schnorr invented, which is a way for somebody to prove who they are. A Fiat-Shamir transform turns that into something non interactive.

So now you can just write down something proving that you are the holder of some secret key and in doing so you have the ability to insert some auxiliary data, some arbitrary message. This turns this from just a proof that you are somebody, that you hold a key, into a signature on some data, "I hold this key and I attest that this message is something that I want to sign."

So this is a very simple, elegant, easy to describe, easy to implement protocol with a lot of nice features. But Schnorr put a patent on this, which expired in 2008 and so it was basically unusable. Anybody who wanted to use these short elliptic curve based digital signatures were either forced to pony up money to Schnorr or go somewhere else and use RSA or something like that.

Peter McCormack: Hold on. If it was 2008 why didn't Craig Wright put it into Bitcoin?

Andrew Poelstra: That's a very good question. It would appear the inventor of Bitcoin had no idea that it existed, which is strange because Craig Wright has insisted that he does know about it. So perhaps somebody is lying here? I don't want to say that Craig Wright is a fraud and there's multiple instances of this and that he didn't invent Bitcoin, but the fact of the matter is that Craig Wright is a fraud who didn't invent Bitcoin, and there's multiple instances of this.

Peter McCormack: I mean these are your own opinions and they do not represent What Bitcoin Did. What Bitcoin Did would never ever call Craig Wright a fraud!

Andrew Poelstra: Absolutely not. I'm not aware of What Bitcoin Did ever calling Craig Wright a fraud.

Peter McCormack: Never, ever has the podcast What Bitcoin did ever say Craig Wright is definitely a fraud.

Andrew Poelstra: Nope. Certainly not saying that Craig Wright is definitely a fraud.

Peter McCormack: So we're agreeing that we have a different opinion on Craig Wright being a fraud?

Andrew Poelstra: We agree.

Peter McCormack: Okay, sorry!

Andrew Poelstra: All right. So Schnorr patented this digital signature scheme. In response, Nist defined, I think it was David Kravitz at Nist. I hope I got the right name there.

Peter McCormack: I see that guy's name on Twitter quite a bit?

Andrew Poelstra: Yeah, he's on Twitter now. He's a cool guy.

Peter McCormack: He gets into some debates with people?

Andrew Poelstra: Yeah, he's one of those old school, cryptographer cypherpunk people who is really engaged today and I guess excited that because of this cryptocurrency thing, there are lots of people interested in cryptography, like relative laymen who are interested in cryptography. I think that's a really cool thing.

Peter McCormack: Very cool.

Andrew Poelstra: There were people doing this stuff in the 90s, when it was a really much more of a niche thing and it was very difficult to get any penetration into the public. But Nist defined an alternate short digital secondary scheme and it was not nearly as simple. It was not as easy to describe. It was not as easy to argue security for as Schnorr, because Schnorr signatures, by being the simplest, most obvious thing, by definition you couldn't get something else that was as simple and obvious.

You think that would be grounds for there not to be a patent on it, but I'm not the patent office and they apparently disagree! So ECDSA came into being. By the time 2008 rolled around and the patent had expired, there were no implementations of Schnorr signatures anywhere. A few years later in 2011, Dan Bernstein created Ed25519 signatures and these are Schnorr signatures actually. 

As far as I'm aware, this is the first widely used standard for Schnorr signatures. This was 2011, so several years after Bitcoin at launched and it appears that Bitcoin used ECDSA, essentially because that's what was exposed by the open SSL library. In the early days Bitcoin depended entirely on open SSL for all of its cryptography. So that finally brings us to, what are Schnorr signatures and how do they benefit Bitcoin?

With that history, maybe the answer is self evident, which is that Schnorr signatures provide an alternate to ECDSA, with very similar size and performance characteristics but which have a much simpler structure that make certain kinds of out of bound protocols, a fair bit easier to implement. The big one in particular, is that you can create what are called Schnorr multi signatures in a fairly straightforward way.

So with ECDSA, if you want to create a compact multisignature, meaning a signature produced by many people, that is nonetheless a single signature with a single key associated to it, you have to do some fairly heavy general multiparty computation. There are a few papers describing how to do this and in the last couple of years, there've been a few new papers doing as much more efficiently, but it's nonetheless much more complicated than it would be for Schnorr.

As far as I'm aware, there's no production ready implementations of this. Meaning that if you want to do multi signatures, if you want Bitcoins controlled by many signers, you have to have them all create a separate ECDSA signature and post that to the Blockchain. So with Schnorr there is a fairly standard folklore way of doing this, which is actually insecure.

There's a slightly modified version of the full core version called MuSig, which myself, Pieter Wuille, Greg Maxwell and Yannick Seurin developed almost two years ago where multiple signers can come together, they combine their public keys into a single joint public key that represents all of them. Then when they want to sign, to move the coins, they do an interactive protocol and the result is a single signature that moves coins over.

So Schnorr signatures, there's a way to create multi signatures and that's even threshold signatures, you can have two of any three participants and the three create a joint public key and any pair of them can produce a signature. You can do this in a way that the resulting signature has the same size and all the same properties as just a single signer signature. You get better scalability and better privacy because you're no longer revealing the original participants or even the number of original participants.

Peter McCormack: Okay. So when this is implemented, does ECDSA get stripped out or does that stay and you have both?

Andrew Poelstra: So we have both.

Peter McCormack: Is that for backwards compatibility?

Andrew Poelstra: Yep and there's actually, I guess in principle it would be possible to remove ECDSA with a soft fork to Bitcoin, but there's no particular reason to do that. The way that new upgrades to Bitcoin go, there are maybe two categories of upgrades that this might be. One is there are a variety of op codes in Bitcoin script that are defined to do nothing at all and it's possible to give these meaning. For example, to add a new op code that just verifies Schnorr signatures.

But with Taproot, which I think we're going to get a bit deeper in, we changed a fair bit more than just adding a new signature type. We cleaned up the multisignature process and importantly we changed the structure of what a output looks like and what a witness for that output looks like. We did this using a new versioning system introduced by SegWit. So let me quickly describe how Bitcoin's transactions are structured.

You have a Bitcoin transaction, as a pile of inputs and a pile of outputs. The inputs are all references to old outputs with one exception, which are the coinbase transactions which create new coins. We can forget about those. So there are a set of what are called UTXOs, unspent transaction outputs and to create a new transaction, you take a bunch of those that you own, you provide a witness attesting to the fact that you actually do own those and a witness in particular, you're both attesting that you own the coins and you are signing the transaction, to prove that you are the owner and you authorize that transaction. 

Then that transaction destroys those UTXOs and creates new ones of equal or lesser value. That's how transfers happen. The UTXOs are each labelled by what's called a Bitcoin script, which describes the spending policy. So if I want to send money to you, I take coins that can only be spent by me. I destroy those coins, that can only be spent by you, that's a transfer. So what SegWit did, was introduce a new way of encoding these outputs.

What we used to call the scriptPubKey and I'm going to go with what we used to call the scriptPubKey, is now called a witness program. What this is, is the hash in SegWit v0 outputs. This is either the hash of some complicated policy and you need to reveal the actual policy to spend it or it's a hash of some public key. If you want to spend those, you just reveal the public key and then you also reveal a signature associated to that public key.

These v0 witness programs are defined to have the semantics that I just described. The SegWit actually has 16 versions. You can also have a v1 witness program, v2, v3 and the rules that Bitcoin enforces on these today are simply some links limits, I forget exactly. It is some links that they aren't allowed to exceed. That's it. So we can soft fork in meaning to a later SegWit version, which is v1 right now, it has no meaning. We can say if somebody has a v1 witness program and then that program is some sequence of bytes.

Now that is going to be a Taproot output and that's how Taproot is implemented. So now we have these two different versions of Bitcoin outputs, well plus all of the old legacy ones that are pre-SegWit as these v1s that continue to use ECDSA, that continues to use a script that we know and love, that continue to work with all of our existing signing hardware and transaction creation software and all that good stuff. Then we have the separate v1 outputs and those have the new semantic associate to them and they both exist side by side.

Peter McCormack: So I guess if you were to strip out ECDSA, that's going to undo a bunch of work that's already been done on various wallets or various companies have implemented, but Schnorr gives them new tools to create new multi-sigs?

Andrew Poelstra: Correct, yeah.

Peter McCormack: Does it affect someone like myself who isn't technical, who isn't building anything in my everyday use of Bitcoin or is this just something in the background that just makes Bitcoin better?

Andrew Poelstra: In your SegWit addresses, the BC1 addresses, I believe one character of those will change. That's it. That is what you will notice when you switched to a wallet that supports these new things. As a user, especially a user who simply owns their own coins and are sending their own coins around without complicated policies, it's unlikely that you would notice anything beyond that.

Peter McCormack: Will wallets have to upgrade to support this?

Andrew Poelstra: In order to actually use these new features, wallets will have the upgrade.

Peter McCormack: Okay, so similar at the moment, I've got a couple of wallets, say my Ledger doesn't support Bech32 addresses at the moment. So I get a little warning. So the same will happen with this and there'll be an encouragement for wallets to upgrade to support?

Andrew Poelstra: So I'm not sure that there would be encouragement like that. So unlike the upgrade from traditional addresses to bech32, bech32 sort of include supports for all of these future versions of witness programs, meaning that ideally wallet software that should own and control these things, the v1 outputs, will need to be upgraded. But everything else that works with them, will not

So unlike the transition from the older style addresses to bech32, there's much less of a coherent... There's much less of a reason for people to upgrade, if they don't want these new features. Although as an ordinary wallet user, it will be more efficient to spend Taproot outputs, than it will be to spend v0 outputs.

But the other thing or another reason to upgrade to bech32, from the old style addresses, is that bech32 has error correction built into it. You can tweak up to five different characters in your address and this is guaranteed to be an invalid address.

Peter McCormack: Why is that?

Andrew Poelstra: So the reason is that Pieter Wuille, I believe using a Blockstream compute cluster, spent quite a while searching through this class of what are called linear codes. These methods of taking some data and extending it in a way that you are adding redundancy, but you're adding very structured redundancy, such that if you add say five characters of redundancy, then if five characters anywhere in the thing, it's not just the five that you added.

It's not even really meaningful to say which five that you added. But if up to five characters are incorrect, then there would be no original data, that would have extended to that. We're sort of taking the space of valid public keys say, for which half of all the sequences of the bits, are valid public keys and we're extending it to a longer string, so maybe we add five characters and every character in bech32 with five bits, so we're adding 25 bits or 2 to the 25 times as many things

So that's 32 million times as many addresses! But we're doing so in a way that only one in 32 million of those are actually valid addresses.

Peter McCormack: Okay, so there won't be any chance that two addresses are very similar, but one character different then?

Andrew Poelstra: That's exactly right.

Peter McCormack: So I'll tell you where that's kind of interesting as a user. Historically I copy and paste addresses. Not once in the history of doing this, have I ever made a mistake. But there's been a couple of times where I haven't had the copy and paste facility and I've typed the address out as I'm reading it, I'm typing it out and then I'm double checking, I'm triple checking. So that would reduce my fear of making a mistake when typing the address out manually.

Andrew Poelstra: Yep and I should emphasize though, how for the current address scheme, it does actually have a check. But it's kind of a probabilistic check. So if you make any number of mistakes in typing an address, there's roughly a one in 4 billion chance that that one mistake will result in a valid address. That sounds like an enormous number of course.

But when you are a merchant or somebody generating hundreds or thousands or tens of thousands of addresses and there are tens of thousands of such people, you quickly get to scales where these kinds of collisions seem possible. So as bech32, for the first five mistakes, there's zero chance that anything will go wrong. Then after that you get this 1 in 4 billion, I don't know the exact probability off the top of my head, but then you fall back to this probabilistic kind of thing after five mistakes.

So if you actually want to demonstrate the fact that in Bitcoin you could have two valid addresses that are one character away from each other, you can do this. I did this once, it took me about 20 seconds on my laptop to generate such a pair, to make a point on r/BTC, to somebody about it being possible. But it's actually very unlikely that an individual user making a few addresses a week kind of thing, would run into that. So existing addresses are safe in practice and I'm kind of wincing as I say that!

Peter McCormack: Is it problematic or bulky for Bitcoin to have so many different types of addresses?

Andrew Poelstra: So Bitcoin itself, on the Blockchain layer, verifiers don't see these different kind of addresses. The verifiers do see the different kind of, what are called scriptPubKeys or witness programs. They see that there are the old school legacy addresses, that have been in the system since the beginning. They see the newer style p2sh addresses, which are the ones that start with 3 and when they see those they need to say, "oh this is actually the hash of some script." 

Then they need to check that, what would have been a satisfying script sig or witness for that script, is actually another program, then another attached and they also know the rules for the v1 outputs. Then there'll be new rules for the v1 Taproot outputs. So for verifiers they have to support each one of these things. Although they're fairly well isolated, so when you add support for one, you don't have to go mess with the code for the other.

They can basically write that code once, it works, it just sits there forever. As a wallet user, you may, when sending to different types of addresses, you may need to know how to translate that address to a script pub key. So if you see a 1 whatever address, there's a rule for doing that. If you see a 3 whatever address, there's a rule for that.

The cool thing about bech32, is when you see a bech32 address, there's a rule for that, but it's the same for v0, the same for v1, the same for v2, the same for every SegWit version. So as somebody who's just sending coins around, once you support sending to bech32, then you support every future SegWit version whatsoever.

Peter McCormack: Right. If you were to rebuild Bitcoin core today from scratch, would you still have a requirement for different address types or could it be built with a single address type now?

Andrew Poelstra: If we could go back in time and start Bitcoin, from scratch, I think you would basically just only have bech32. We may still start with SegWit v0 and then layer on v1 and so on like Taproot vs non-Taproot. But these are still the same kind of address. That's the important thing.

Peter McCormack: Will there become a time in the future where these old addresses will become irrelevant or redundant or are they required because they're some part of like... Because the addresses existed that the protocol needs to be aware of them?

Andrew Poelstra: So I have a fun story about this. So I hang out on IRC. My name is AndyToshi. You can find me on £Bitcoin, on freenode and a few other channels. About 6 or 12 months ago, somebody came onto IRC, they said, "I'm trying to spend from an old Electrum wallet, but it's not letting me spend my coins." I said, "okay, can you tell me what's happening?"

It seemed like Electrum was creating invalid transactions spending these coins and I said, "how did you get this wallet? What's going on here?" And he said, "oh, well I had a wallet from 5 or 6 years ago and I tried to upgrade it to Electrum, to the latest version of Electrum and it didn't really work. So I hacked some things around and somehow I got it to start up and produce signatures for this."

So I messaged him privately, I said, "can you please show me one of the UTXOs? One of the outputs that you're spending?" I messaged him privately because you should never reveal your UTXOs in public. That's a loss of privacy and you'll at the very least be revealing a lower bound on how many Bitcoins you are holding. But importantly you're revealing which Bitcoins are yours. It's like you're just like feeding information to the chain analysis machine.

Peter McCormack: Evil chain analysis!

Andrew Poelstra: It's horrible! He showed me this output and this was a very old school output. It was actually a pay-to-pubkey output. So this was before we had addresses, like even the 1 addresses that we have today. 1 addresses is actually a completely different semantics. This is, I don't know the history of how this happened, it was a very Satoshi thing to do, to like associate the EC pubkeys to addresses, rather than scriptPubKeys to addresses.

So it used to be a long time ago, there was a type of scriptPubKeys called pay-to-pubkey and you would just reveal a public key and to spend the coins, you would reveal a signature. This was supplanted by what we now use, in 1 addresses, called pay-to-pupkey hash, where what hits the Blockchain is a hash of a public key and only when you're spending, do you reveal the public key. 

This is shunting data from the UTXO set, which is a set of all active coins, to kind of witness data, which is data that's necessary to validate transactions. So this changed the validation properties a little bit in favour of people maintaining those change state, by making some data that was originally a semi-permanent part of the state now something kind of ephemeral.

I'm kind of waving my hands! So SegWit finally did the correcting, which is to actually segregate the witnesses, to move them to a separate part of the block Merkle tree, so that they could actually be validated independently. But this was the first step towards that and because these are all 1 addresses, these old school things and the things that we now know as the 1 addresses, what Electrum was doing was trying to produce a pay-to-pubkey hash signature for a pay-to-pubkey output, which of course is just invalid.

So the result is a script that just didn't validate, an invalid transaction. I looked at this and I'm like, "what on earth? Where did you get this?" So I looked into my copy of the Blockchain and I looked out the UTXO that he was describing and it was in fact the genesis... I'm sorry the coinbase... Wouldn't that be cool for the genesis transaction right! And this was Craig Steven Wright! No, it was a coinbase transaction for some block, around height, I'm going to say between 50 and 80,000. I know the exact height, but I don't want to identify this person.

Peter McCormack: But early!

Andrew Poelstra: Very early! This is from, I want to say 2010 and he just had this old Electrum wallet, just laying around and he tried to upgrade it and he kind of hacked it up. So in the end I said, "can you show me the transaction spending lesson?" So he showed me the transaction and I think I was actually able to munge the transaction myself and vim using raw transactions, because that's how I use Bitcoin.

That's how real hackers use Bitcoin, is opening up vim and editing hex! So he was able to move his coins and I said, "congratulations. Don't tell anybody you have these outputs" and I'm sure he had quite a few of those, because if you had one block back then, you were probably mining coins from blocks back then, it was pretty easy to do on a CPU.

This whole story is you asked like "one day will be able to retire these and will these just go away?" The answer is no, because of stuff like this. There are people out there that have pretty old outputs. I have first hand experience with outputs as old as 50 to 80,000, but I'm sure there are even older ones out there. The effect of removing these would be to confiscate those coins.

Peter McCormack: Yep.

Andrew Poelstra: And as I mentioned, it would be almost a false saving. The code to validate these is very ossified and stable, by definition it will never change, because any future changes will just happen in new versions, new SegWit output versions, new independent blocks of code.

Peter McCormack: So when is Schnorr coming?

Andrew Poelstra: So a couple of days ago, Pieter Wuille published a draft for a BIP, for a pair of thing called Taproot and Tapscript. These together comprise a definition of SegWit v1 outputs that we are proposing and this is the culmination of work over the last year and a bit, depending how you measure it, the last five years there are different ways you can think about where we started here. Taproot started with a conversation that Greg Maxwell, Pieter Wuille and I had in a diner in California in January of 2008, so a little bit over a year from when we really started working on it.

Peter McCormack: 2018?

Andrew Poelstra: Sorry! Wow. I've been revealing Satoshi all over the podcast.

Peter McCormack: This was the original Satoshi meeting!

Andrew Poelstra: Wow. This must be what it feels like to be Craig Wright!

Peter McCormack: So 2018 then?

Andrew Poelstra: 2018, yes.

Peter McCormack: Did you go boating that day?

Andrew Poelstra: There were no boats involved. I don't want to say how far away from the ocean we work because, privacy. So this v1 SegWit output proposal I guess, called Taproot, is the upgrade to Bitcoin that I expect will be the one to bring Schnorr signatures to Bitcoin because alongside Schnorr signatures, it brings a whole host of other cool benefits that I'll talk about in a moment.

So we published a draft for a BIP, a couple of days ago and the draft right now is going through a bunch of revisions. A lot of people replied to us on the Bitcoin Development mailing list. A lot of people replied to us in private and on IRC and stuff, so we're getting a lot of feedback from stakeholders and the draft is changing and evolving in response to that. So it's impossible to put dates on these kind of consensus actions.

But I'm going to make up a bunch of numbers for you, because people like made up dates. I'm going to say that there's going to be a couple months probably, of this kind of iteration and changes to the draft and revisions and so forth. Then we'll finally settle down into a fairly concrete proposal and that's what will eventually be assigned a BIP number.

Being assigned a BIP number is basically a way of saying this is a coherent finished proposal. It does not say this is going to be deployed. It does not say anybody likes it. It does not mean anybody's going to use it. It just says, as an author, it's complete and coherent and it's probably not going to change too much. So once we have a BIP number, then there will be a bunch of work done on integration and actually writing... I guess alongside having a BIP number, there will be a bunch of integration type code and then there'll be a whole ton of QA cycles, where they do that, probably 6 or 12 months of just regular software QA.

In parallel to that, there needs to be a community discussion about do we want to accept this BIP? Do we want this BIP to be part of the Bitcoin protocol? If so, how do we deploy that? What is the deployment mechanism that will be used? Should we try to use the BIP8, where you have basically technologically giving miners a veto, not politically.

Although we have in the past, miners believed that they did in fact have a veto and then there was a tremendous amount of controversy and political shenanigans related to that. Will we try to use that, will be use BIP9, will we use some sort of a user activated soft fork, which is actually to be clear, all soft forks are ultimately user activated, of course.

But by having miner signalling, you reduce the chances that you're going to have a chain of invalid blocks appearing, that miners are producing and perhaps some old validators who haven't upgraded, will see that as valid. That can cause quite a bit of chaos and confusion. I don't know how that's going to shake out, but that needs to be shaken out and it wouldn't surprise me if we have 6 or 12 months of argument just on that.

Then maybe if everything goes well and this lands on "we really want this and we want to deploy it" and the community is all Gung Ho and let's actually deploy it, then we will actually do the deployment and that requires an actual upgrade mechanism that requires some sort of date in the future or some block height in the future, at which point this will become active and that itself will probably be 6 or 12 months after everyone agreed that it should be deployed.

Peter McCormack: Can you see any reason why people would be against this? It seems like when Pieter Wuille put out about this, it was very popular.

Andrew Poelstra: Yup. So there isn't really... This is the kind of thing where because it's a new SegWit version, everybody who supports sending to these things, everybody who supports sending Bitcoin to SegWit outputs, already will support sending to these things. There's no wallet upgrade required if you don't want to actually use these things. I guess really something that you can just ignore if you don't care about it.

The additional complexity is much less than that for SegWit. So SegWit itself is actually very simple. It was moving some data from one part of the block Merkle tree to another part. The difficulty with SegWit was that because of added extra difficulties to transactions, there were changes to the peer to peer layer that needed to be made, to communicate with old nodes and to negotiate with old nodes and say like, "will you understand if I give you this extra data" and they're like "yay" or "nay" except the old ones couldn't say no, because they didn't know it was coming of course.

So there was complexity of deployment around that and we don't have any of that with this. This is really just touching the consensus layer. But the consensus layer within the existing consensus rule, there's no new data. There is no one new extra anything. Related to that, there are not any changes to parameters of the system such as block size, which happened with SegWit.

SegWit increased the Bitcoin block size and that, for those of you who were at Magical Crypto Conference a couple of days ago and saw Luke Dashjr's talk arguing that we should have reduced the block size many years ago, that itself is a point of contention. So all of the stated reasons for the noise around SegWit basically don't apply here and it would surprise me very much if that kind of FUD were being spread around.

Having said that, there is one point, there may be a general point of opposition that you might see as people thinking we should do this slightly differently and this sort of bike shedding and revisions and stuff. It's plausible that maybe we just never find a solution that everybody thinks is best. That would surprise me, because this is the kind of thing where they're fairly minor technical compromises to made and when people get tired of arguing, they stop arguing about that stuff because ultimately it doesn't really matter.

There's one specific point of contention that I'm aware of, that there's been some noise about on the Bitcoin mailing list and elsewhere, which is with Taproot outputs, every output rather than being a public key behind a hash, is now just an elliptic curve public key, meaning if your coins are parked in a SegWit output or a SegWit v1 output, a Taproot output, and quantum computers appear out of nowhere, then your coins could be stolen.

If you instead had a SegWit v0 output or a legacy address, that public key, the EC public key that's vulnerable to quantum computers would instead be behind a hash and the coins couldn't be stolen until such time as you tried to spend them. This is how the argument goes. This is wrong, for a couple of reasons, that are fairly non obvious and this is why we're having this discussion.

One reason is that actually the public keys associated to about two thirds of the Bitcoins that are out there are known. There are all these old pay-to-pubkey outputs, that have explicit pubkeys. There are a tremendous amount of re-use addresses, meaning addresses that somebody sent to and then those coins were spent in the process of spending they reveal the underlying EC key.

Then there are a ton outputs that were spent on the Bcash chain, in order for people to sell their Bcash for Bitcoin and in doing so, they revealed their public key to the Bcash chain, even if they didn't reveal it to Bitcoin and that also is a way to reveal your public key. I actually think a lot of people did that.

Even people who don't re-use addresses, kind of de-factor re-used an address because when they receive to that address, that turned into a joint receive of a Bitcoin and a Bcash, as long as you received before the split happened. Then there's a whole other category of ways to reveal your public key that are not easy to measure. For example, when you communicate with a hardware wallet, a hardware wallet is doing a BIP32 derivation and it will produce a public key that it sends to your host.

So if you are communicating with a hardware wallet over some connection or whatever, it is probable that anybody who compromises your host or who is able to talk to your hardware wallet, even if they are unable to produce signatures, it's very likely they'll be able to ask your hardware wallet for public keys.

Ask it like, "please derive these public keys." Right now, public keys are not treated as secret data for pretty much any purpose in the Bitcoin ecosystem. So outside of producing transactions, there are all sorts of ways to obtain public keys from signing devices, that are not yet translated into addresses. So if you're worried about a quantum attacker, you better hope that nobody ever plugs your dongle into a computer or something like that.

So as a result of all these things, basically all the public keys are exposed now. So maybe you are a crazy person like me who wrote their own wallet software generating nonstandard hardened BIP32 paths, connected to some hardware dongle that's using their own special wallet that has encrypted, entry is a fixed size, for every single address they generated.

Peter McCormack: Yeah I did that. I did it this morning! That's why I was a little bit late.

Andrew Poelstra: It's a good exercise, right? You want to spend 15 minutes a day writing your own wallet and then 15 minutes meditating and then you're ready.

Peter McCormack: I didn't meditate. I put the meditating off just to build this and I'll show you afterwards.

Andrew Poelstra: Okay yeah, I'm excited to see that! If your head wasn't clear then I'm uncertain that it will be secure! Even if you do all these things though, if everybody else's Bitcoins were lost, then good for you. You have retained some of these tokens that are now completely worthless and unusable.

Peter McCormack: It's the end of Bitcoin.

Andrew Poelstra: Yeah, exactly. So the hash that exists in front of a public key, as I mentioned earlier, this is there to sort of shift some of the data retention costs from public keys, which are normative non-witness data into witness data. It sort of shrinks the amount of data that validators are required to store, in order to validate future Bitcoin transactions.

But it was never intended as a quantum protection and it doesn't function as a quantum protection. There's sort of this idea out there that it does, but it simply doesn't. Even if it did by the way, it's very unclear how you would ever spend your coins again, because you have to reveal the public key to spend your coins. 

People talk about, "oh, we'll invent a quantum resistant, zero knowledge proofs scheme and you reveal your public key and sign inside of a zero knowledge proof." We know how to do that. The resulting proofs are over 100 kilobytes. So if you want to attach hundreds of kilobytes to every single one of your transactions and try to fit that in the Blockchain, I mean I guess there will be room because Bitcoin's dead! I mean, this isn't realistic. This is not really a thing.

Peter McCormack: Is quantum computing a genuine fear of some Bitcoins? Because I asked Luke about this and he said he thinks we're a long way off, if it's ever actually going to be possible to create quantum computers.

Andrew Poelstra: I think they will. I don't think it's never. A lot of people in the space do you think it's never. I do think it's a long way away. Somebody asked me about this a couple of days ago on a Monero podcast and I said, "I would be shocked if it's less than 15 years. I would be quite surprised if it was less than like 25." It's important that we start thinking about post quantum systems, because if there's no preparation whatsoever done, then it doesn't matter how far in the future it is, we're still going to get blindsided.

So it's important now that we start working on standardization and exploring ideas and exploring what Bitcoin is going to look like, in a post quantum world. But right now they are no candidates for post quantum signature schemes that are good enough that it would be reasonable to deploy them in Bitcoin, given how astronomically unlikely it is, that they'll be needed in the near future. Unlike some applications of cryptography in particular, unlike encryption, Bitcoin signatures are kind of ephemeral. If we're really like, "oh, quantum computers will be around in five years."

One day maybe we'll think that, then we need a new signature scheme and you need to move your coins to that new signature scheme and then problem solved. You can stop worrying about it. Compare that to say if you're receiving a GPG encrypted email, now NSA has a copy of that email because they've tapped all of the communication lines and they're storing every encrypted email. 

There's nothing you can do. If they come up with a quantum computer, even if it's 30 years later, they will decrypt your email now. So if you're worried about encryption, then maybe you should be transitioning to quantum secure schemes immediately, as fast as you can. The reason being that you are vulnerable not only to quantum computers tomorrow, but quantum computers ever. But Bitcoin is not like that. You're only vulnerable to quantum computers tomorrow and as long as it's not this tomorrow, there's no need to be trying to transition.

Peter McCormack: And there's higher priorities right now.

Andrew Poelstra: There are higher priorities right now and we've seen continued exciting developments in the post quantum... The surface of post quantum cryptography is changing much too quickly anyway.

Peter McCormack: Okay. So you mentioned Taproot, another thing I've seen mentioned recently is Graft Root? What is Graft Root?

Andrew Poelstra: So Graft Root is kind of a cute thing! So associated to Taproot, is something called Tapscript. Let me take that back. Let's stay on Taproot. The Taproot includes a feature called MAST, Merkelized Abstract Syntax Trees, where all the different ways that you might spend a coin go into a giant thing called the Merkle tree.

To actually spend the coins, if you don't want to just sign with your Taproot output, you reveal one of these branches and you reveal a proof that spending policy was actually committed to, by your Taproot key and then you reveal whatever witness you need to actually satisfy that policy. They idea is that you don't need to reveal any of the different policies that you didn't use, unlike today, where today in Bitcoin script, if you want to do such a thing, you need to write this giant IF tree in Bitcoin script and everybody downloads a whole IF tree, they see all the different policies, even though you only had to use one.

So this is cool, except... So MAST is cool compared to the current status quo, all these IF trees. But it requires you know all of your signing policies, all of your spending policies upfront at the time that you create the output. If you are doing something weird, like you have billions of these and then you need to create a billion entry Merkle tree, which is computationally kind of difficult to do. So what Graft Root instead proposes and Graft Root is not part of the Taproot proposal, let me emphasize.

But let me explain what it is and why we decided not to put it into the proposal. What Graft Root lets you do is delegation. It says, rather than having a public key that secretly commits to a giant tree of all possible spending policies, we let people sign a new spending policy with the existing public key and then that spending policy will be activated. So now you're allowed to spend coins with that policy.

This means that to actually use a policy, you simply reveal the new policy and the signature on that policy. It doesn't matter if they're are a billion showing of these things, you just reveal one signature and one policy. So you kind of get this MAST tree where you don't have to generate the whole tree at once and the cost of revealing which branch you want to do is constant. You can also choose new policies after the fact, which is kind of cool!

You have an existing output and the idea is you graft on some additional spending policy. There are two reasons that we decided not to propose this... Let me say three reasons, although the first two are kind of the same, that we decided not to bring into the Taproot proposal. One is that there is a lot of room to iterate on the design. In particular, how do you handle re-used public keys? 

What if I have some coins that are controlled by some public key. I signed some alternate Graft Root script and then I have that alternate Graft Root script floating around and then somebody later since coins the same public key. Should that original Graft Root scripts be applicable to the new one or should it somehow be tied to individual UTXOs or whatever. There are a whole bunch of trade offs.

There are a whole bunch of different ways of using it that are enabled or disabled, depending on what you choose there and we don't have any clear use cases that would guide us on what choices to make there. This brings us to my second reason, which is that it seems like however we propose this, it's kind of a "foot gunny" thing. It's possible to use in a way that has unexpected consequences.

Then the third reason, and this is really the most important reason is that a Graft Root spend or a Graft Root signature on alternate policy, is basically equivalent to just signing a one input, one output transaction, well to give you the same effect. If you want to sign an alternate spending policy, just sign a transaction, moving to coins to that policy. Ultimately Graft Root is just a more efficient way of doing that, that's blessed by the Blockchain.

Without having any clear use case or user guidance on how to make decisions about that, it seems like basically we're optimizing for something that we don't really know what it is. So for that reason we just didn't put Graft Root in and we've got almost no complaints to that effect. We've been asked many times like "why isn’t Graft Root there?" But nobody said like "I needed to use Graft Root for this and now it's disabled."

Peter McCormack: Who gets to name these things?

Andrew Poelstra: So with Taproot, I believe this is Pieter. So somehow it's always Pieter Wuille who comes up with names, which is weird because we all make fun of him for coming up with terrible names, but then none of us will step in and take one for the team! I believe what happened with Taproot was Pieter sat down at the table at this diner and he had stepped up for a moment, while Greg and I hashed out some final details.

We were like, "how do we name this" and Greg said, "isn't there the name of a root that goes into the ground and you can't see it, but it anchors the plant to the ground or something." And Pieter said, "yeah, that's a Taproot." We were like, "We don't think so." So we looked it up and sure enough Wikipedia vindicated him.

So then it was Taproot. Graft Root I think was Greg Maxwell. I think there was a pun on Taproot, related to grafting and then we went back and forth, he was worried that people was saying about graft and doesn't graft mean city politics, collusion and corruption kind of things. I said "no, that's grift" and then we deterred those both. Both were bad. We shouldn't have grift. We shouldn't have Grift Root!

Peter McCormack: Have you named anything?

Andrew Poelstra: Has anyone used my name? I don't think so. I'm trying to think what my names were. I feel like I have some really good ones. I will take credit for Grift Root.

Peter McCormack: So somebody, who knew I was going to be interviewing you, asked me to ask you about Dandelion. Now I know a bit about Dandelion as somebody covered it, it might have been Lopp? But it's for improving privacy? Can you explain how it works and then if and when it's coming to Bitcoin?

Andrew Poelstra: So to your second one, I believe it's already in Bitcoin. So Dandelion is a change to the peer to peer layer in particular. Actually not even a change to the peer to peer messaging, although I think it does need some... It's a change to how transactions are propagated amongst the existing peer to peer network. So the problem in Bitcoin today or Bitcoin in the recent past, is that when you create a transaction, your node broadcasts this transaction to a bunch of people and they all broadcast the transaction to a bunch of other people and you get kind of this shockwave effect across the network.

That is easy for somebody with a fairly global view of the network to centralize the origin of that shock wave and say, "this is a person who created the transaction because this is where all the propagation of this transaction is coming from." So as a result, transactions that are kind of unnecessarily linked to the time you created them, your IP address and which node you connected to and all this bad stuff.

There were a couple of papers demonstrating specific attacks related to this and related to the kind of timing analysis that was done. Some of the existing mitigations against this, such as Bitcoin core nodes putting random delays and stuff and the propagation. So what Dandelion does is when you create a transaction, you create a sort of path, a series of nodes that you connect to you. 

Actually I think you only create the first part and then the next node chooses one person to send to, send one person to send to, send one person to send to and so forth. So the idea is that you were propagating your transaction along some specific path and somebody who wants to figure out that you are originating the transaction, would need to be on that path, which you'd need to very global and you would need to pretty much have dominated the network, to have a high probability of doing this.

Then after some random timer, everybody along the path switches. So this is called the stem phase. The idea is this little path, like the stem of a Dandelion. Then we switch at some random time. Everybody along the path all at once switches to what's called the bloom phase, where now they do the original transaction, kind of blooming propagation logic that the flood network kind of thing.

Peter McCormack: Hence the name Dandelion because it creates the stalk and then...

Andrew Poelstra: So now somebody who's trying to figure out where these transactions came from, they will get a similar looking shockwave, but now it will be centralized along the line of many nodes, which by itself will make it much harder to figure out where it comes from. But also it's very hard to even do what I said.

I'm giving a very visual metaphor of a shockwave here, where you can imagine a shockwave being very clear where it came from because it's a nice circle that's going outwards. In real life, the Bitcoin network is not a circle. It's a connection of fairly densely interconnected graph of nodes that are introducing random delays and propagating things at different times and so forth.

So it's actually quite difficult to just like roll back in time and say like, "where did this transaction come from?" If you're seeing it from multiple places at once. This was why some of the papers that spurred the invention of Dandelion and the use of Dandelion, were publishable papers and their original research was that it's not as intuitively obvious that this was possible, as it was.

So Dandelion works to undermine this kind of transaction propagation graph analysis, just to distinguish from the transaction graph on the Blockchain.

Peter McCormack: Okay. What is the status of confidential transactions and how are they being implemented? Because I know this is being asked for a lot, people are quite keen on this.

Andrew Poelstra: So confidential transactions was developed by Greg Maxwell in 2015 I believe, as a more efficient version of some proposal Adam Back had posted to the Bitcointalk forums, back in 2013, I think I want to say. You can Google for this, it's called homomorphic value commitment or something.

It's not confidential transactions back then. This was deployed on the elements Alpha Blockchain, which has now been iterated, as now the Blockstream Liquid network. Along the way, this was adopted by a variety of different projects including privacy focused Blockchains like Monero. It's the basis of the Mimblewimble Blockchain design...

Peter McCormack: Which is you worked on?

Andrew Poelstra: Yeah, I worked on the design and one of the earlier papers, turning the Voldemort paper into something more fleshed out, that came from me. There are now a couple of projects out there implementing Mimblewimble. The way that this works is that you have all of the amounts in your transactions are replaced, rather than being explicit amounts, are replaced by these objects called homomorphic commitments, which hide the amount, but still that people verify that the input side of a transaction, equals the open side.

People are very keen on "when is this coming to Bitcoin!" There are two broad reasons that it's not coming to Bitcoin anytime soon. One is the efficiency. So confidential transactions require replacing all these outputs, with these things called Pederson commitments, these homomorphic commitments and associated to each Pederson commitment, is this object called a range proof, which proves that it's not a negative amount, because if you can create negative amounts, you can cancel them out and create cash out of thin air.

So these range proofs are pretty big. In the original Greg Maxwell design, they were, I want to say 128 bytes per bit or something. So we have these 32 bit range proofs showing a number between zero and 4 billion Satoshi, meaning between zero and about 400 something Bitcoin I believe. These are two and half kilobytes and if you wanted to cover the entire range, you would need to do, I think a 52-bit range proof, which would've been about 50% larger, close to four kilobytes per output, to be clear.

So if you're spending a coin, even if you're just sending to one person, there's an address belonging to that person, there's also a change address going to yourself. So you need these four kilobyte outputs hanging off of each of those and both of these would acquire several milliseconds for a typical verifier to handle, which is just obscene compared to the current situation, where there's almost no validation happening on the outputs and every input has an ECDSA signature, typically just one and those take like 60 microseconds.

They are several hundred times as much validation time. So that situation has been greatly improved with something called Bulletproofs, that were developed by Dan Boneh...

Peter McCormack: They're on Monero?

Andrew Poelstra: Monero does have Bulletproof. Liquid will have Bulletproofs, when we get around to deploying them. It's kind of funny, like so many things in Monero, Bulletproof originated from Blockstream research in part. It was actually, I shouldn't say it was primarily an effort of Dan Boneh and Benedikt Bünz and Jonathan Bootle at Stanford and University College London, with help from myself, Pieter Wuille and Greg Maxwell.

So we at Blockstream research did the initial implementation of Bulletproof, all of the benchmarks and stuff that was us. We developed the way to do what's called the batch verification of Bulletproofs, which allows you to verify one Bulletproof in a couple of milliseconds, so maybe two or three times as fast as the old ones, which is okay.

But then multiple Bulletproofs, with a marginal cost of only a couple hundred microseconds. So on the order of magnitude of these signatures as long as you're doing more than one at once. But the core idea was the folks at Stanford and UCL. So Monero is using those in places that are they are interested in, but the numbers are still not great. There's still not where they need to be for Bitcoin, I would say. Some people disagree. Luke [Inaudible] would agree with me quite strongly.

I still take several hundred bytes, which is much better than multiple kilobytes, we've got a factor of three or four, improvement in size and the verification speed is much faster, but it's still not comparable to signatures. So that's the first reason that confidential transactions, even with Bulletproofs is not coming to Bitcoin anytime soon and that none of us who have been working on Bulletproofs have taken the time to write a proposal.

Peter McCormack: It just needs a bigger breakthrough then?

Andrew Poelstra: Yeah and we've seen a series of breakthroughs. So maybe there will be some series of breakthroughs that bring us there for efficiency reasons.

Peter McCormack: It's coming to Litecoin, I hear.

Andrew Poelstra: It's plausible. I've been requested to help work on this by Charlie Lee and others at various points, which I have not... I'm not sure where they're going to find the manpower to do that.

Peter McCormack: How do you feel about working on other chains? Do you feel like it's good because it will get out it out in the wilds, to be used on another chain?

Andrew Poelstra: So let's not forget that I'm still talking about the reasons not to bring it to Bitcoin. But let me answer that first.

Peter McCormack: Sorry!

Andrew Poelstra: It depends a lot... I don't work on any other chains under my name. You can see if you look at the Github repo, even for things that people believe that I'm working on and that people speculate that I'm working on or that the press incorrectly reports that I'm working on, you won't find my name on any commits for those things, except possibly commits to Bitcoin that happened before these projects forked off.

Having said that, I often give advice and chat with people working on other things, such as the folks behind Grin or the folks behind Monero and we have a lot of friends at the Zcash foundation who we work with and we share ideas and actually we get ideas from each other. This is not just like me hoping. This is actually a collaborative process, especially with folks like Sean Bowie and Daira Hopwood at the Zcash Foundation, helping with zero knowledge proof design. 

So as researchers, we are very collaborative. In terms of actively developing these alternate chains, I don't do this for two reasons. One is just in practice, I don't have the time to work on these things. I have the time to give like drive by contributions, but then I don't have the time to convince myself that they're secure, they're robust, they're to the level of quality that is necessary for my work on Bitcoin and my work on Blockstream products.

That could potentially be very embarrassing for me, if I were to do things and then they were broken. The second reason is that I am very uncomfortable with the moral hazard and the incentives surrounding alternate cryptocurrencies and these alternate Blockchains having their own associated token. Unfortunately, we're in a world where if I work on any of these projects visibly, that could be seen as an endorsement, not of the technology but of the token.

That is something I very much do not want to do and I do not do. I do not endorse any tokens except for Bitcoin, but it's very difficult to work on things and even sometimes it's difficult to collaborate without people inferring some sort of endorsement

Peter McCormack: Well at least you are not on Twitter, where you would be destroyed for it!

Andrew Poelstra: Yeah, I still am. People send me links of people saying things about me and then I call my friends who are on Twitter and say, "well you reply for me!"

Peter McCormack: "Tell that motherfucker to shut up!" All right listen, there's one other thing I want to ask you about while we're here and then I'm going to let you get back onto your work. Did you see the Microsoft announcement yesterday?

Andrew Poelstra: I did and I met one of the folks at your party here in New York.

Peter McCormack: Daniel?

Andrew Poelstra: Yeah Daniel!

Peter McCormack: Yeah, so I interviewed Daniel yesterday. How do you feel about the Bitcoin Blockchain being used for things which are non financial transactions?

Andrew Poelstra: So Daniel actually asked me the same question.

Peter McCormack: I asked Daniel the same question!

Andrew Poelstra: The way that Microsoft is using the Bitcoin Blockchain, is as an anchor or as a timestamp for a tremendous pile of these identity, I don't want to say tokens, but these identifiers of some sort. The way they are doing so, is that they take tens of thousands of these things and they collapse them into a Merkle tree and then they publish a single transaction, with a commitment, with a 32-byte commitment to that Merkle tree.

This is a similar thing that was done by open timestamps for example, which is a project run by Peter Todd, which is tremendously useful by the way. If you're not timestamping everything, every time someone sends you an email, every time someone sends you a tweet, just timestamp it.

Peter McCormack: Well actually I found out from Peter the other day though, that people think if they just @opentimestamps Twitter account, that actually creates a timestamp and it doesn't!

Andrew Poelstra: Oh my goodness, don't do that. Download the open timestamp software and run it and it will actually put a commitment in the Bitcoin Blockchain for you. So to answer your question about people using the chain for non financial things like this, my view is that open timestamps and Microsoft projects and a few other similar things are being very non abusive.

I don't like using the chain for non financial things in principle, but these projects are using on the order of kilobytes a day of data, unlike some other projects that I will not name, but which are strongly associated with Roger Ver, which tried to do similar timestamping things where every single document they want to timestamp, they create a separate transaction on the Bitcoin Blockchain. So they're just like loading it with thousands of 32 byte hashes.

That is incredibly abusive. It's using a tremendous amount of space for things that are not financial, that's driving up fee prices, that's driving up rates for people who are using Bitcoin for financial things. It means that people like myself who are running nodes, because we care about the robustness and continuation on the network are required to validate these things, which we aren't interested in validating.

Worst of all, it's completely unnecessary even for what they're doing, because you can accumulate these things, you can easily get tens of thousands or million x efficiency improvements just by aggregating into these hashes and pretty much every application of Blockchain publication kind of stuff. Well most things don't need publications, most things need anchoring and you can do that with this technique of embedding a hash.

So the resulting space usage is very, very small. It could be reduced to zero actually using a technique called "sign a contract" that I believe Greg Maxwell developed. But the difference between the amount of space they are using now and zero, is already pretty small. So while I would like them to reduce it to zero, I don't feel very strongly about it and I commend them for demonstrating that it's possible to do this 10,000x aggregation and I wish that everybody else throwing shit on the Bitcoin Blockchain would do the same thing!

Peter McCormack: Brilliant. That's a great way to end things! Just remind people, how they can stay in touch with you Especially if you're not on Twitter!

Andrew Poelstra: So I found a new trick. I'm here at consensus in New York and I'm constantly being accosted by people who aren't even in the industry, just trying to vaguely network and I tell them, you can find me on LinkedIn and this is true. If you Google me on LinkedIn, you'll find me. I don't know my LinkedIn password.

I haven't known it for years! But they do and they go away. I don't have to deal with them! But perhaps your listeners I have a little bit more respect for. So I'll tell them! There are two main ways. One is email I guess, but the main way is I am AndyToshi on IRC. I'm on a few other related channels. You can also find me walking around the streets of Austin, Texas…

Peter McCormack: Where you accept beer?

Andrew Poelstra: Yes, where I accept beer!

Peter McCormack: Which you accepted on Sunday night!

Andrew Poelstra: That is correct! Someone was asking me about you the other day and I blanked on your name and I said, "Paul McCartney!" I thought you might like that!

Peter McCormack: That show has become the first one I send people to now. When people are like, "oh, which show should I listen to?" I say, "listen to the Andrew Poelstra one because it's a really good combination of fun and tech." The tech goes way over me, but is explained in a way that I can maybe get to grips with it, but it's just a really fun episode and it was so warmly received. I actually had an idea while we're here, do you know what we should do sometime?

Maybe I'll come to Austin and do that. I think we should do a whiteboard session and get a video camera and you explain to me how Bitcoin works. How do UTXOs work? How a node works? How the miners work? Like a real white board session. I think that people would love that.

Andrew Poelstra: Yeah, we can absolutely do that! I've got room in my apartment, I've got a whiteboard on my wall.

Peter McCormack: So I'll get the camera and we'll make this happen! All right, well listen, thanks for coming on

Andrew Poelstra: Thank you. Good to see you as well!