AM: That's not good. Hi everyone. Thanks for coming to the future of privacy coins panel. I want to spend a minute talking ablout backgrounds and interest in this area.

BG: I have a PhD in something. I got into monero a couple of years ago. I needed to pay rent, so I did some work in math in exchange for money.

AP: I work on confidential transactions and scriptless scripts and I do not have a PhD.

AM: What do you think about taproot and schnorr signatures?

AP: Sure. There was a new proposal posted to the bitcoin-dev mailing list for taproot and tapscript, which is something that myself and Greg Maxwell and ajtowns and jl2012 have been working on for a little over a year now. This helps you hide bitcoin scripts inside of public keys. The motivation is the realization that a few of us had a few years ago that in common applications of bitcoin script like claim-refund constructions, typically you have a number of parties that are interested in making sure coins move depending on some condition or some contract. If everyone agrees that those conditions are met, they can sign and move the coins. We have this blockchain scripting language called bitcoin script designed to enforce these conditions. But realistically, if everyone agrees, then they can just sign off on it. So taproot lets you replace your bitcoin script with a public key that perhaps multiple people contributed to and need to sign for. The idea is that in the non-cooperative case, you can say there's an alternate scale and reveal the preimage to a hash or something. You can reveal a script with those conditions and then you can prove that your original public key committed to that script so you're not just making up a script after the fact. In the cooperative case, you never reveal the script. In the uncooperative script, the script is still there on the blockchain and can be revealed when you need it. The consequences for privacy is that as long as people are doing complex things like atomic swaps or lightning or whatever, the resulting transactions will be indistinguishable from single-signature individual transactions.

AM: Peter Todd spoke earlier about zcash and trusted setup. What are your thoughts on that and on zcash in general?

BG: My thoughts on zcash are complicated. I do firmly believe that the folks who are working on zcash are trying to make the world a better place and they do want to remove trusted third parties from finance. I don't believe in the idea of becoming a trusted third party in order to do that. I personally have a real hard time trusting trusted setups. In monero, we want to avoid trusted setups to avoid what petertodd was talking about-- in the end, you're still trusting on petertodd that he really drove across Canada instead of just using photoshop or whatever. Are all the participants trustworthy? I'm not so sure. The way zcash has handled recent issues, like the deleted transcript, I have complex feelings about this. The math behind zcash is really cool, though.

AP: I am also against trusted setups in general. Zcash foundation is distinct from the Zcash corporation. There's a few specific points on petertodd's talk that I want to talk about. I agree with all the specifics about this being a real, hard difficult thing. But it's hard to fix the things he brought up. It would have been nice if he could have done the trusted setup in the woods without any internet connection. To do this, you would have to drive back and forth between cell service areas and non-service areas. The best you can do is some computation. That's unfortunate. The second thing he talked about was the discussion about deterministic software builds. At an ecosystem level, we're slowly getting better at that. It's not yet at the point where it needs to be. I hope that people realize that deterministic builds are a really serious issue and we desperately need that for cryptocurrency and cryptography software.

AM: What are your thoughts on zero-knowledge proofs and their use cases?

BG: Zero-knowledge proofs are the word 'synergy' from 1972 transported decades into the future. Everyone talks about wrapping things up as a zero-knowledge proof. It's an interesting thing. Black holes leak information about the contents on them, but the idea that cryptography is different from black holes, is all under certain theoretical assumptions like you're in a closed system and there's no metadata being leaked or anything along those lines. Assuming the availability of metadata, you can link things together. Monero blockchain has metadata about the zcash blockchain, and vice versa. I can use information from zcash blockchain to try to link monero data. Any time you have two anonymized data sets and you bring them together, they are not necessarily anonymous anymore. The idea of having zero-knowledge statements without revealing any of the contents, I think this is a very theoretical topic in computer science.

AP: I disagree with all of that. Zero-knowledge proofs are kind of a buzzword, yes. They have been around since the 80s and 90s. A zero-knowledge proof is a mathematical object that somehow demonstrates some statement is true without revealing anything else that the statement is true. There's ring signatures in Monero which are actually zero knowledge proofs that some key image you attach to a transaction correspond to some specific.... so the zero-knowledge property hides which key was involved, but there's the risk of using the same key twice. When people talk about zero-knowledge proofs today, they are usually referring to very general zero-knowledge proofs, not about some specific statement that is chosen to achieve some goal with a minimum of efficiency, but instead we have some arbitrary program that you might describe arbitrarily, and you might execute the program and if it's accepted or it returns true or whatever your accept condition is -- perhaps it's bitcoin script or something-- and it's a zero-knowledge proof that it was accepted, without giving any information about what the program is in some cases. Zero-knowledge proofs, for them to be practical, wasn't a thing until a 2015 paper "SNARKs for C" which was a computational proof for a subset of the C programming language that will let you generate zero-knowledge proofs which were slow to generate, slow to verify and had a trusted setup. We got from intractable to inefficient in 2013 or 2015. Since then, we have seen leaps and bounds in terms of representing programs to make them more efficient in zero-knowledge schemes and also methods of making zero-knowledge schemes more efficient. There's also exciting development in replacing trusted setup with something that doesn't have trusted setup. This is stuff like STARKs by Eli Ben-Sasson. I'm excited to see all of that moving forward.

AM: Why is the ability to obscure data important?

AP: When you talk about obscuring data in a blockchain context, we're talking about not publishing that data permanently to the entire world. So let me rephrase the question. Why is it important to not publish all of your data to the entire world? The answer might be intuitive but let me explicitly state that. If you are a business in financial technology, you cannot reveal your orderbooks or your internal accounting. If you are an ordinary person, you cannot reveal what you're buying. You don't want to reveal to your landlord what your income is. You don't want to reveal to your church that you're buying birth control or voting democrat. In some cases, there are serious consequences. In some cases, you don't want to reveal to your government that you are doing certain things. When we develop privacy technologies for cryptocurrencies, we're not just trying to hide data and obscure and prevent anyone from seeing what ew're doing. What we're trying to do is preventing everyone from seeing what we're doing, and this is necessary for running a society. ((applause))

BG: I absolutely agree. I think something that people forget is the history of cryptography is steeming in.... back in world war 1 and 2, being able to pass messages secretly were how those wars were fought. They were fought with bullets too, but the history of cryptography is a history of an arms race. For all the reasons Andrew mentioned, if we aren't constantly battling against forces like Facebook that want to unmask us forever for all data, they want to exploit your psychology, you're actually engaged in a form of information warfare. People tend to forget that cryptography is not really a game. People's lives are on the lane. When you have people in Venezuela experiencing 10,000% inflation daily, they need to buy food and pay rent. If they go to buy bitcoin transparently, they are putting themselves in danger and there are lives on the line. I absolutely agree with what Andrew just said.

AM: What are some of the downsides of hiding data?

BG: I guess I'll start. Facebook can't .... we all know about the tradeoff between security and convenience. There are password vaults on our phones, but at least you don't have to memorize 75 passwords and chain code regularly. But then some people don't have security vaults for their passwords, and they just append digits to the same passwords they have been using since 1992. When you talk about the downsides of security, there's the downside of convenience. There's a dirty part of me that wants facebook to advertise to me, because they know I like bonsai trees and I want those advertisements. But if I do that, I sacrifice all of my ability to act as a private individual. So there's a tradeoff.

AP: Something that is not a downside, and often regulators don't see this--- this is the idea that if we had information privacy, and if people were able to transact privately, then they would be unable to meet reporting or auditing requirements that they are required to have. But this isn't true. What about proving that a contract does what you say? We want to be able to control the explosion of data and not broadcast it to the entire world, like credit card transactions to your credit card company and advertisers and so forth. We want to ensure the information goes only to the people that neeed it. The second side of this is that a lot of the knowledge into general purpose zero-knowledge proofs involves describing programs in a way that can be understood in a zero-knowledge proof system, in a way that makes it possible to verify and do formal analysis of computer programs. If you have a smart contract that somehow uses computer code to encode data from financial derivatives, you could run that code through an analysis system to actually prove to you that it will not have certain adverse effects. In general, that is extremely difficult to do for an arbitrary program. But there are certain ways to construct programs that make formal verification easier. We're improving privacy, but also improving assurance that information is flowing in ways that they should be in order to run a free society.

BG: There's also our right to know what people know about us. Unless I file a freedom of information request, I am not necessarily going to know what the NSA has on me. Maybe they have nothing. I hope they have nothing. But we should also be able to know what other people know about us, and we should be able to provide consent over our data being handed out to other people.

AP: When you send a FOIA request to the NSA, they do a lot of manual work shifting thorugh their trillions of documents to find something relevant to you that doesn't have national security concerns. The reason you have to file a FOIA instead of this happening automatically, is that they are unable to do this for every possible request you make. We can hope tha twith the advent of zero-knowledge compute tech and verifyability then it should not be a problem, and we should push legislation that the NSA should not be storing all this data and they shouldn't know what this story.

AM: Can you explain monero's PoW algorithm and how it is different from bitcoin's sha256d algorithm?

BG: The ring signatures don't have much to do with PoW in Monero. The history behind Monero is starting with Cryptonote. There's AES encryuption, it XORs the result, encrypts it again, it does Merkle-Damgard. The idea was to take out as much of the L3 cache as possible. It's a slow part of the memory system. This way, ASICs wouldn't be able to do the mining on Kryptonite unless they had huge memory capacity. This was in pursuit of ASIC resistance, and perhaps as we all know, about a year ago we changed our PoW algorithm and we saw a 80% drop in our hashrate. There were monero ASICs. I believe that we hav eanother change since then and we saw another 80% drop. There was only about a six month delay. So ASICs manufacturer were able to completely make up for their losses within 6 months. Depending on who you speak with, they can roll out ASICs in 30 days. Kryptonite is an interesting weird animal.

AP: Do you want to talk about the original cryptonote implementation?

BG: The original cryptonote implementation had like all of its comments stripped out, on purpose.

AP: Deep in monero's history, monero was a fork of a cryptocurrency called bytecoin which developed ring signatures but didn't have confidential transactions back then. It didn't have twice as efficient ring signatures. But this was a first demonstration of the ring signature technology for privacy. It was very interesting that it was a genuine technical innovation. It was released with a whitepaper with a forged timestamp on it, claiming it was 2 years younger than it was. It had an obscure mining algorithm on it. It claimed to use sha3 but it used an alternate pre-standardization version of sha3 that nobody knew about, and it's frustrating to work with monero. The mining algorithm was supposedly ASIC resistant. There were lots of loops in the reference code, it had goto statements, there were no comments, there were like 3 comments in the entire codebase- they were in Russian and not helpful. After it was revealed and it became more popular, it was discovered that they stripped out a whole lot of those loops and it was possible to mine Monero like 100x faster. So it's not really any hard evidence of what was going on here. The original people behind it were pseudonymous and nobody knows who they were. It appears they deliberately devised the scheme so that they could mine bytecoin much faster than the general public could. Monero took the bytecoin code and said we're going to drop all your weird secret scams or whatever, and we're going to clean of our hands of that.

BG: Bytecoin had like 2 years of fake blockchain. They said people have been using this on the darknet market forever already, so therefore it's worth something. Scarcity had nothing to do with the market value of this coin. It was being run by a manipulated market. Bytecoin's history is the stuff of movies. I can't wait for the first movies to be released, like speculative fictional movies about who built bytecoin. This is going to be more interesting than the speculative movies about Satoshi Nakamoto.

AP: There was at least one cryptographer in there. This happened- bytecoin continued running for quite a while, and that's still a thing I believe. It's very strange. It's a very strange world we live in where anonymous people can develop new technology and deploy it and continuously use it for their scams without any indication of who they are.

AP: Lightning today... on lightning, you have this primitive with a payment channel where you have two parties moving money between each other, they use a claim refund construction to make sure you can get your coins back. They sign some transactions, some of the coins go to the first party and some go to the second party. When they make a payment, they sign a replacement transaction. They keep doing this, over and over and over. The lightning network is a way to link these payment channels and make them talk to each other. They use HTLCs to do multi-hop lightning network things. .... we can do cooperative closes, or we can do uncooperative closes then you have to reveal all of these hashes to the blockchain and then it's very visible that we're using the lightning network and that these payment channels are all part of the same path in that specific payment. There are some improvements made possible by taproot, which is a privacy improvement, that would make this a much better situation. The first is that taproot itself allows a cooperative close case to happen without revealing the underlying script and HTLC contract. So you no longer reveal the hash or preimage, so now the public can't see that all of these--- the blockchain validators can't see that this is a lightning network related transaction. That's pretty cool. One problem is that there might be the same actor multiple hops in the same route. This might interfere with someone trying to obfuscate their payment flow. This effectively shortens the routing path for privacy reasons from 5 to 3 in this specific example. Now it's a philosophical question, is this really an attack? Well, it's certainly not the intent. There's another technology related to taproot that eliminates this problem. This is something called adaptor signatures. I'm not going to go too deply into the math of this, but the idea is that each of these payment channels are between two people, and in order to spend the coins ew have to use multisig. In taproot, we have to use a joined signature on our one key. It is possible for me to encrypt a secret to my contribution to the multisignature, in a way such that when I later actually do contribute to the multisignature, my counterparty will be able to decrypt the secret. As soon as I take his contribution out of my own, my counterparty knows that I will be revealing the secret key by observing the blockchain and learn the secret. We can replace the HTLC with these so-called adaptor signatures where actual signatures on the blockchain are now doing the job that the HTLC was doing. So now we can do payment channels in this way, where we reveal a secret and pass it along between the signing parties. The algebra for secret construction differs from hash construction, and we can do reblinding of a secret. When I receive a secret from the last person in the line, we all get-- everyone gets a --- I blind it, pass it to the counterparty, she learns a secret, she reblinds it, passes it to me, and now the second secret I received because Alex reblinded it, no longer looks like a secret-- I can no longer tell that it's the same secret. Then the payment goes through. Because I can't see that these were on the same payment channel, I can no longer tell that it's the same route. My ability to map out lightning network payment flows is now severely undermined. Once we have taproot and we solve all the engineering challenges related to deploying all of the technology I just described, the privacy of the lightning network will really come to fruition.

AM: How do you think exchanges would respond if bitcoin soft-forked in confidential transactions? Does this run the risk of silent inflation?

AP: Confidential transactions use pedersen commitments which hide the amount, but still allow people to add commitments together and check that they sum. These are range proofs too. As long as the amounts are equal on the inputs and outputs, then the transaction balances. This was originally created by Greg Maxwell for a project we had been working on for a few years called Blockstream Liquid. It's not an altcoin, it's just a fork of Bitcoin Core and the primary token you can use on Liquid is a proxy of bitcoin, it's pegged 1-to-1 with bitcoin by a cryptographic peg. When coins are in the Liquid network, they are custodied by a consortium of many different exchanges. I believe the majority of the federation members are exchanges, and they all have joint custody of the coins in the network. You need 11 of 15 to sign off on any transaction moving bitcoin back to the bitcoin blockchain. Inside the network, there is confidential transactions and confidential assets. Our fear in 2014 was that- we were very excited about confidential transactions- we thought this would really improve the privacy story for bitcoin and make bitcoin private, but we were very worried that exchanges would hate this and say making bitcoin more private makes it more criminal or something. But what we actually found, when we started pitching it to people, was that real participants in the financial ecosystem got very excited about this. They said wow this is really amazing, and now we can solve a problem of people frontrunning transactions when they see money being transferred between exchanges. This undermines liquidity because it reveals our positions and balances and impacts trading. So my experience as a technology provider for exchanges, is that they are really excited about privacy.

BG: I think exchanges are aware of this, I am not sure if regulators are aware of this... but in the vast majority of the cases where you talk about cryptocurrency transactions, someone buys some coins from an exchange, and the vendor then goes cashes it out for dollars after they purchase something. So you have end-to-end KYC, especially if it's the same exchange, the exchange has all of the information necessary even if you're using zcash or monero to deanonymize you. So KYC exchanges are looking at their intenral information with perfect information. They have a hard time with looking outside their system. Convincing a regulator that an exchange using KYC already has all the information needed to comply with KYC laws has been challenging. In the regulatory space, they want to be able to see past 1 hop in a private sequence of cryptocurrency transactions. But if I withdrew money to Wells Fargo and sent it somewhere else with a wire transfer, they might know which bank it went to, but what happened after that they have no reasonable idea. It's unreasonable to ask Wells Fargo to file a suspicious activity report for that. On the other hand with cryptocurrency, they seem to want to be able to see beyond one more hop. This is an unreasonable demand and doesn't even apply in the current banking system. I think users and exchanges are excited about privacy, and regulators just don't know what they are doing. I don't want to say regulators don't know what they're doing, but they don't.

AM: We have time for one more question. What is mimblewimble and what are some of the projects?

AP: What is mimblewimble? Hmm.

BG: I describe mimblewimble to people, as a former math teacher, it's a sequence of telescoping sums. You add one, subtract one, add one and subtract one and you keep doing that and then all the interior additions and usbtractions cnacel out. That's how I imagine mimblewimble. It's a sequence of schnorr signatures, and you add up all the ones on the interior and they all just disappear.

AP: That's a good way to put it. I can add a little bit more extra detail to that. Mimblewimble is confidential transactions in its purest form. You take a confidential transaction chain in liquid or monero and you have a bunch of other things-- then you remove all the scripting, all the ring signatures, and now, you say, rather than having these blinded commitments to your amounts, just represent a hidden amount, take that blinding data and say it's pretending to be a secret key in a complicated definition of "pretends" that works in practice but is difficult to describe. I can own two coins in mimblewimble without owning either one individually. It would be interesting to see that tried in court actually. But because confidential transactions are homomorphic commitments, you can add and subtract and you can add our two transactions together. In mimblewimble, you can do to that to the entire blockchain.

BG: Does that include verification from scratch? Like if I start mining tomorrow, and it's time to sync up, can I just add up all the blockchain transactions and be good?

AP: Almost. You need to learn all the coins that have been unspent. You also need something called the kernels, associated with every transaction. This is a single public key and a signature used to ensure verifiers that the transactions were not created to cancel out other transactions. You do need to download and check the signatures on every single one of those.

AM: Alright, we're out of time. Thank you for joining us.