BTC, ETH, WLD, ZEC Privacy

Transcript

So, hi everyone. This's the last session today. Thank you for staying. Um My name is Ing Tong and I work at Ideal Group and I work on a private payment application. Um and today's talk is about private applications on blockchains. So, I didn't coordinate with Justin and I made a whole slide deck. Uh but, I think what we can do is make use of the expertise in this room and just open up the discussion uh and we can use this slide deck for to structure it.

So, um recently there's been lots of interest in privacy on blockchains due to um institutional adoption, stablecoin adoption, and even policies like identity verification, proof of personhood. Um Yeah and so, uh for this workshop, what we're going to explore is first of all, what private applications are we building? What private applications are interesting?

Um and then secondly, how these are affected by the post-quantum transition um in terms of privacy. So, if you post ciphertext on chain, um is harvest now decrypt later going to affect your anonymity set, for example? Like security, so if you're using pre-quantum ZK proofs of validity, uh can people forge proofs now? Um and if you are moving to a post-quantum system, um post-quantum proof, the proof size is probably way larger than what you have right now. Like 5x larger or

more. Uh how is this affecting your performance? Um so are you going to store all these proofs on chain? Um do you need to introduce third-party services to make this efficient and so on? So this is kind of the structure of today's talk and I Can I have a show of hands? How many of us are building private applications? Okay. Okay. My first question is how are you guys doing?

Um >> [laughter] >> so [snorts] I think it's very much the case that um the notions of privacy that are interesting um come from the application and comes from the threat models and the privacy invariance [snorts] that your users have. So yeah, my first question is what privacy invariance um define your application?

Um and then secondly um your application also um implies some kind of deployment context. So are you assuming people are proving on mobile? Um uh what's the memory requirements? Um computation? And so once we have these down, then we can examine how much of our our security and privacy invariance as well as the performance uh relied on certain pre-quantum um qualities and so how the post-quantum transition

now affects us. So with this, I'm going to open it up actually. Um does anyone want to volunteer um what you're building as an example, dear Emma? >> Building a private and anonymous um cash system. Um and privacy invariants um basically each transaction should only leak um an unknown amount of metadata. So, for example, the number of actions. Ideally, we want to hide even that, but but we know that we can't yet. Um the uh so, the performance requirements have to be able to prove in ZK on mobile. Um

uh has to be able to um So, for scalability, we want recursive proofs. Um we need hardware wallets to be able to um uh kind of control spend authority um without leaking it to the software wallet. Um and what was the other um So, uh oh, how How is the How is Phantom? Yeah. So, the obstacles there are that we use short addresses, and so we don't want um the address size to balloon to to a point where they become impractical, which either means kind of moving to something other than addresses, out-of-band payments, um or kind of finding some other way to

to deal with the bottlenecks of um kind of scanning the whole chain for uh ciphertexts. And we also want to fix um both harvest now decrypt later attacks and kind of um we need things to be private in the very long term. Um because it it could be that um uh people's financial transactions 10 or 20 years ago um are still relevant for their privacy. Um so, yeah, we want all of that.

>> Mhm. Yeah, actually of course have Zcash. I prepared a slide for Zcash already. I You didn't mention proof sizes, I think. Does Okay cool. >> Well, recursion helps a little bit with proof sizes. [snorts] Um but yeah, they're still relevant. And also the So, if there are intermediate proofs that users are sending to aggregators and so on, then those are relevant as well as the on-chain proof size.

>> Okay. So, >> I Yeah, I think I think maybe if I was to try and and make a a bit of a difference because I feel like at the end of the day we're like all the chains that are interested in privacy are like all going for the same thing like PQ recursive aggregation. Um yeah, on Ethereum it's going to be like receiver or like who is behind hidden but not the amount. So, you have like a bit of differences.

I think one key difference for example between Zcash and Ethereum is like um you can have like many apps on Ethereum that do you know, stablecoin, DeFi, or whatever. Um but I think it's way behind Zcash in terms of where it's at now because we have like these sort of like trusted third parties and I don't know. It is it's just not very very mature ecosystem. I think UX matters a lot as well in terms of, you know, having like wallets that are like really made for it.

But but yeah, I do I do feel like the sort of like invariants people are going for are the same. And for me, I I know. For me like right now for if you take Ethereum and you take Zcash, they both have like very different properties, but I do feel like, you know, when I hear Zcash is trying to, sort of, like, maybe considering proof of stake, um, then there is maybe programmability that is also, sort of, like, interesting. And those for those things, like, Zcash is a bit behind. But um >> Yeah, that's a prioritization prioritization issue and complexity issue rather than we don't want programmability.

>> Exactly. Um, but then on the other side of the spectrum, you have Ethereum that has, like, programmability and proof of stake, but as that that is a bit behind in terms of, like, privacy and and maturity, which is kind of fun because, like, they both sit at different ends, but I do feel like they might converge towards, like, similar designs eventually. >> And just so, you said I was at your talk just now about privacy on Ethereum L1. Um, I think maybe my biggest takeaway, I have to read all the EIPs, but my biggest takeaway was account abstraction.

Um, that basically decentralizes the role of relayers. So, >> It get It gets rid of them. >> Gets rid of relayers. So, now they're bundlers. >> No, no, no, they are no They are not there anymore. Um, you can submit your transaction directly in the public mempool and you don't need any third party between you and the public mempool. >> So, who pays gas for you? >> The pool. You set the pool, like, the privacy pool as a sender, and you set you also set you as the payer. And so, because of account abstraction, you can actually, sort of, like, make use of this. Um, so, there is no, yeah, there's not going to be any any third

>> privacy pool, they define they deploy a paymaster contract that >> Yeah, they are their own paymaster. So, yeah exactly. >> I see. Um I also didn't understand what you said just now about how Did you say you conceal the sender and recipient, but not the amounts? >> Yeah, it's very much uh Tornado Cash like um like you cannot link the addresses, like the sort of like the one that shielded the amount from the where it's with withdrawn, but the amount >> Uh okay.

>> except if you want like a TC thing where you have like fixed amounts, but ideally, I think we won't we don't we don't want that. Even though it's better for anonymity, but it it's just like UX is is quite bad. Um so, but the amount is still visible. >> Uh this is a very interesting difference in design's perspective because we we see hiding the amount as kind of essential to privacy. Um So, so the trade-off is it's very much more difficult for us to prove um balance.

Um um we've had recently a balance um potential balance violation bug um that I had to sort of stay up all night fixing in Zcashd. Um So, our response to that is formal verification. Uh >> Yeah, I'm curious. So, the the reason why the fee pay amounts are public it's So, it's it's Is it technical challenge or more like um like kind of more like a regulatory legal >> Oh, no. It's it's it's it's a technical challenge. Like it's uh it's actually not trivial to hide the amount.

>> Yeah, it's very non-trivial. Um yeah. Um like we we're dealing with the same thing at Aztec cuz we we also like we we launched with account abstraction, and private fee payments was something which was very important to us because it it does it yeah it is like a it's a extraordinary. Like if you look into that like it's a horrific amount of information leakage. You know where honestly kind of like you kind of get practically the anonymized. Um because because this Yeah. Um uh You know particularly in Yeah. Cuz like gas prices are so so precise.

Um And the only like like one of the solutions that we we like we are working on is again because of account abstraction you can do a lot particularly So if you're running an application and you don't mind paying gas for your users then obviously then you can you can not only um Uh well then then um you can you can basically pay their fees via proxy. Um but but the ultimate requirement really is that the actual um sequences the block producers uh they get paid their fees privately. Um >> Yeah.

>> Which um Yeah. There're also uh interesting challenges with actually providing the information required for a user to to perform that payment. Um but Yeah. Yeah. >> Yeah. >> So so the the the there are ways of doing it. I man, I wish my I wish my CTO was here cuz he knows more than me about this. Um but things involving partial partial notes where basically you um you privately um where you you basically what happens is you you pay um So what happens is at the start of the transaction

you you you create a note which basically says um which which hides your identity. Um and it defines a maximum value. And the idea is that that maximum value is is kind of canonical with everybody. Everybody pays the maximum value. And then what happens is at the end of the transaction um cuz again we have I think you call it frames or statuses that like you like transactions are like have these discrete atomic units. So, at the end of the transaction the the miner they they receive that payment. Um, and then they issue a refund um, back to the user privately um, with the um, which is uh, you know, the original deposit minus the amount of gas that's spent. And that way you do get proper fee privacy um, in a in an account abstraction model because um,

uh, but yeah, that's a lot of complexity. >> Yeah, I think that makes sense, but then it assumes yeah, this sort of like I think that that sort of like private uh, channel between like the the builder or the validator or like the proposal or whatever. >> No, it doesn't it doesn't require private channel because it's it's this like this is concept of partial like partial UTXOs where the idea is like in in the first frame you you create a UTXO that's like half halfway finished. >> Yeah, with the max amount. >> Yeah, the max amount. And then you but then the miner at the end of when they're actually when they're actually building the block and creating the transaction building the proofs, they then complete them. They take the UTXO and they add their their like, you know, like just um, they just add their identity into the

hash to claim it. >> Mhm. >> Um, so so so the use the use the transaction doesn't need to know who the miner is. The miner knows who the transaction sender is or at least they know they know something about them because they they um, the the the the transaction sender also creates a partial refund note. >> Yeah. >> And then the and then the miner and then the and then the miner basically adds the um, refund value onto that and then creates that as a UTXO. >> Okay, >> Yeah. But it can't be null, right? Because you need to But you need to know um, that the user's good for the money that they have it.

>> Yeah. >> Yeah. Yeah. That's it. Yeah. Yeah. But like you need to prove it You need to prove the start at the start. Yeah, you can pay that much. >> Doesn't need like how how high is that value cuz I feel like if you if you set it too high, then you you know, you have you need to front a lot. And if you set it too low, then you are limited in the sort of like amount of payment or like >> Yeah.

Yeah. But the the approval is needs to be public, doesn't it? Yeah, then you need to broadcast. But then the Yeah, but without the relay, then yeah, it does need without without that broadcast the the approval unless needs to be public. So, that is one Yeah yeah.

Right. >> So, I I think I missed some context. Like, are we discussing onboarding into Aztec? >> No, I think the the Yeah, we are trying to to assess if there are like any or like what are the designs that will help an Ethereum-like privacy application hide the value as well.

Um instead of just >> Specifically hiding fees, right? So, on Aztec or anywhere else, right? I've got to pay some kind of some gas, some money to a to a to a block producer, right? And um how do you hide that? Um with a um without having to have like rounds of communication between the transaction center and the block producer. >> So, the fees are hidden even in the Ethereum model because when you have like your statement um you pay some fee to the pool, but the the pool is both the sender and the payer. So, the pool will pay for you, but uh no one will know about the the actual fees you paid.

>> You said that identities were hidden, but amounts weren't. >> The the values, like the fees are hidden, but the values, like how much you transacted, are not. >> Oh, you were talking about the actual like token transfers. >> Like, yeah, like if you transferred 1.2 ETH, like that value will be public. But the the But I'm talking about the value transferred, not the fees. Does that make sense? Yeah, the the fee amount is paid by the pool because it's set as the payer. So, as a user, you send your transaction, your frame transaction, and you set this both the sender and the

payer for that transaction as the privacy pool. So, that pool will both be sort of like identified as the sender and pay the fees to fund your transaction. Um so, the value of your transaction will be public, but the fees will be hidden, if that makes sense. And all you need to do is So, it's it's it's a it's yeah, it's very similar to sort of like setting a high a value, um and then not then not knowing exactly how much of your fees fees you're paying.

>> So, how do you get obviously like you sign your transaction private. >> Yeah. >> You don't know at that time how much fee you have to pay. >> Yeah. >> You commit to a max value. >> Exactly. Yeah. >> Um transaction later lands. >> Yes. >> You now find out that oh, actually I only needed one ETH. As fee. >> Yeah. Yeah. Yeah. >> How does the like how do you time travel back for the fee payer app to refund the user? >> Well, the the the pool will have this sort of like dynamic encoded into it. it. It's written in the smart contract of the privacy pool basically. And you have this sort of sort of like logic of like

hey, does the the sort of like transaction I'm recei- I'm receiving uh paying enough? If yes, I'm going to fund the fees for it. And you know, the sort of like value I had at the beginning uh if it was higher than what I actually ended up paying, I'm just going to refund. So, you you have the whole logic sort of like embedded in the smart contract. >> But then you only find out the exact value to be refunded after the transaction lands. >> Yes. >> Is that a second transaction? >> No, it's you found it find out after the transaction lands, but the once the transaction is included in the block and sort of like actually has landed, the logic is to refund the user.

But you >> Okay. Yeah. >> Yeah. Yeah. >> But if the logic is to do it privately, how how is that executed? >> The what is it? >> you're that basically like when like when I'm when when I'm like when a block producer is inserting that transaction to block right like they are executing that refund logic. >> Wait, what? Sorry. >> So like you only know how much to refund right once the transaction has been mined and you understand the gas costs.

Right? So so there is there is some some code being executed that will that will process that refund right? And and the user is not creating any kind of like client side proof or anything like executing that code. That code is getting executed at like by the by the block producer block builder. >> No, no, the the the transaction comes with a proof. Like >> Yeah, but it can't come with a proof of the of the refund. >> No, not of the refund. >> This is what I'm talking about the refund. >> Yeah, yeah. >> Yeah, and like so so how is that refund both um calculated and and and given back to the original transaction sender?

>> Uh Yeah, I'm not sure I get it. The Yeah, the the I mean the the It it looks like the transaction comes from the pool, right? So it can be public. It's more like the that that's why everything is hidden hidden but the owner like who's behind behind the transaction like because what the privacy pool does is like handle all the logic of like hey, I received

enough. I'm paying fee fees and everything and then like all of these can be public because it looks like it will look like a a transaction that is like originating from that sender and from that payer that is the actual pool, if that makes sense. >> A little bit, but I'm I'm just a bit Maybe maybe there's something I'm not understanding because earlier you like you were saying that the the fee payment values are private, but if it's the privacy pool paying, then that would imply that they're public because the privacy pool is is like it's a deterministic smart contract.

>> Yeah, so it's private as in Okay, okay, that there is the confusion. In the end, it's public, but it but it's private how much that person will have paid for fees. Because it's the pool that's emitting the the the transaction is associated with the pool. So it's it's impossible for like an external observer to say this [clears throat] transaction was actually made by this address, right? And the the the You know what I mean? Like >> Yes, you say So an observer says, "Ah, there's a transaction here. I don't know who sent it." Like the privacy pool is like I can still but I can see Yeah, how much fees that pool paid for that transaction.

>> Yes. Yes. Yeah. So it's it's private in the in the way that you can't link the transaction originator from the thing that lands on chain and no one actually knows what it is, but the fees and the and the the and the amounts end up being public. >> Yeah. >> Yeah. >> Can you explain what the difference why it sounds like there's more than one of them or is there just one that should be >> Um I mean, today on Ethereum there are like there are many and they have different designs.

One of the older design is Tornado Cash. Um and I with fixed amounts and it's a mixer really. And then you have like people that have iterated on that design with you know, um private DeFi, um stable coins, arbitrary values, um they have also innovated with like the compliance mechanisms they have put in place to access those apps. Um, but so, yeah, I would say like the three main ones are probably Tornado Cash, Railgun, privacy pools today.

Um, and each of them comes with their trade-offs. Um, and amongst the trade-off are also like the, you know, do they have a token? The fees, um, the governance associated with it, and all of this sort of like is actually quite different across the these protocol like these privacy pools. So, yeah, you have a bunch of them, which is like also pro in a sense. Um, I think it's like kind of nice to have diversity and and maybe competition between the pools.

But of course, it can also for example, it splits the anonymity set, right? Like it's you don't have like this one canonical um, uh, app. So, you know, there are like ideas like can we do some some kind of like no teleportation to get benefit from the anonymity set of like an app to another or whatever, but it's it's not easy and it's obviously uh, less ideal than in terms of anonymity set to have than having this sort of like one app. Or one and find pool. >> So, it used to be like in the days of Tornado Cash, the issue was that when I try to withdraw from the pool, I need to somehow pay the gas for that

withdraw transaction, and that step of funding this gas is de-anonymizing, and that's why people used relayers. Whereas now, with this um, account abstraction, uh, I can directly request uh, say Tornado Cash to pay me >> Yes. >> pay the fee for me as well as um, um send me my withdrawal minus the fee. >> Exactly. That's exactly it. And the caveat is like when we say now it's it's really >> soon.

>> Uh within 1 year. So, it's it's like planned in the future, but it's not live on mainnet. >> Dear Emma, >> I do feel we're slightly rabbit holing on fees, but I just want to mention um how Zcash handles it, which is that the fee that you pay is um a public function of the transaction shape. So, um the things that are leaked anyway like the number of actions. Um and that's sufficient um Well, we we had a sustained denial of service attack that um lasted um 18 months, but shouldn't have done because we um the engineers suggested how to fix it within um you

know, 2 months, but um but that's a separate governance issue that I always get on my hobby horse about. But let's not do that again. Um but as long as you have a sensible um kind of global fee policy, then you can make sure that transactions aren't leaking any more than um they uh would do anyway. Um and still have public fee amounts. So, that's the other way of of handling it. Mhm. Um I I do feel we should get on to kind of the the issue of what is needed from the underlying cryptography um to have post-quantum privacy in the in all of the application areas that we

want. >> Yeah. >> Yeah. >> Then it's just like recursive proof aggregation that it need come down to this one thing. >> Okay Okay, but there's lots to say about that. >> Okay. Yeah. Yeah. >> Yes. >> Right. Yeah, yeah, yeah. >> Okay, so here's the question.

>> You mean like it's too big like the size is uh >> Well, maybe not. >> Yeah. Yeah. Yeah. Um yeah, so so I don't know whether everyone here was in the earlier session where we were talking about um Mike um which is a a very recent um it well it it recently all of the cryptographic engineering details have been sorted out. Um there's a there's a proper spec for it um which is a non-interactive um isogeny-based key exchange and like um

and um it's really interesting because it has quite short ciphertexts and public keys. Um it's post-quantum as far as anyone knows because it um uh it it doesn't So, the way it works is it's a module action um and the um the scalars are in uh a monoid, but you have um the bases are a different kind of thing and the public keys are a different kind of thing. Um so, it has some of the um properties that you get from Diffie-Hellman um but it's it's uh avoiding the problem that would allow you to run Shor's

algorithm or a a period-finding um algorithm to break the private keys. Okay. Um but the problem is um yeah, the the ciphertext and the public keys are nice and short, but decryption is um quite expensive. Um so, I was working out it was 30 times more expensive than um um ECAS. Um on the Pasta curves. So, um for a similar security level. Um So, the question is, can we do better?

Um I think maybe there are other um Nikes in the same style um maybe using different algebraic um number theory um that we could explore using our kind of nice new AI tools um that understand a lot more mathematics than um most of us do individually. Um and we could try and find something that gets that 30 times down to something practical like a five times would be fine.

>> So, to contextualize um why we need this key exchange is so that we can basically encrypt a note plain text uh in band to the intended recipients. And the cash does this right now. So, meaning that if you are the intended recipient, you have to go through every single ciphertext, try to decrypt it, see if it might be yours. And if decryption suddenly becomes really expensive, then uh you probably find it really hard to trial decrypt and catch up to the chain uh if you're on just like a mobile

phone, let's say. >> Yeah, exactly. >> Um I >> Yeah, I think even the the use case, I don't know what you guys think, but like I think like 95% could be done out of band probably. Like it's we are optimizing for these sort of like use cases where you want to do donations or deal with merchants or but it's like how how often is that? So I I I do feel like it's an important topic but like it feels like you know, maybe if it's not optimized to the to the max, it's not like the biggest issue in the world if you are able um not to have to you have to use it for um out of band sort of like

communication. >> So that was the that was the viewpoint that we started with um kind of when um Tachyon was um starting to be developed that we would just use out of band payments and then um it was you would still allow um cipher texts on the blockchain. >> Yeah. >> Um but two things. So um So So going in one direction, you may not want cipher texts on the blockchain at all if you want long-term security because um kind of even the post-quantum the conjectured post-quantum algorithms may get broken.

Um so that's a long-term risk. >> Mhm. >> Um kind of especially with AI um kind of knowing a lot of math and um potentially being able to break schemes that we currently think are secure. Um the other thing is so going in the other direction um you want some way of if you kind of So if you lose your wallets and you only retain the um the seed phrase. >> Mhm. >> Um How do you catch up? Um so kind of the the traditional traditional answer in Zcash is that um and you just rescan the chain.

>> Mhm. >> Um Now for scalability, you don't want all nodes to have to remember the whole chain, but it was still possible for archival nodes to remember whole chain and then you would query one of those if only in the case where you'd lost your key, lost your wallet, you bricked your phone or something. Um and that was a sort of fairly nice trade-off, but it it doesn't solve the problem this long-term security of the encryption schemes. So, there's no there's no answer that solves all of the issues simultaneously. I think we'll have to find some compromise that is good enough.

>> Zack. >> There's another There's another rather large problem when it comes to programmable systems that that that I think we ran into that we needed to solve, which is basically if you were in a programmable system then you you're going far beyond simple payments and you're creating like DeFi protocols where let's say I I'm I'm in I'm doing some kind of some some protocol where I need to pay you something and and once I pay you something else happens, like maybe some escrow or some unlock whatever. >> Right. >> Then I need to probably pay you on chain. Um that a smart contract can check. And so, um you know, and and I I I I shouldn't be able to grief you, right?

I like so so I need to So, if I'm giving you an encrypted note, you don't know how to decrypt that note unless I give you the secret to it. And on chain I need to prove you I've given you that secret. >> Right. >> And so that that's really hard to do without Yeah, the topic key. >> That's a good point. >> encryption and it's it's just really important. >> Yeah. >> Um >> So, yeah, maybe a auto research competition on Mike and and we optimize it. But then >> Yeah, but but then one of the other problems there is you kind of need to run the You don't need to prove that you've derived the secret correctly on chain, which then means that the actual execution of the scheme, the fact that Mike is 30 times slower Uh that becomes >> That's why we need the auto research

competition. >> [laughter] >> But also, there's one last thing I mean I don't know how how Mike seems quite new. >> It is new and it is I such an ease. >> Probably like somewhat vulnerable to AI for analysis. >> Maybe. I don't know. Um I I remembered the the approach that I liked to um kind of um thread the needle on these issues, which is to um you hold most of your funds in a long-term storage protocol that is only dependent on symmetric cryptography.

Um so um if you break your phone um and you have to recover from and your hardware wallet, which I did recently, but like he said it just stopped charging. Um I have my seed phrase, so it's fine. Um but that demonstrates um kind of very viscerally for me um that it's necessary to be able to recover from seed. Um but if almost all of your funds were stored in this long-term storage protocol, um then you're not now dependent on um kind of long-term security of these structured encryption schemes. Um

yeah, you just need ciphers, which uh symmetric ciphers, which we know how to do. Um and so I think that gives you the best of both worlds and you can still use public key cryptography for your payment protocol. >> Yeah. >> Um but that can either be out of band or um kind of it can be done in such a way that um you're not at risk of losing funds if the public key cryptography is broken. >> For what it's worth For what it's worth yeah, like we we we kind of we converged on something very similar, which is basically um like the smart contract gets to define how it

does note delivery effectively. So, you can either, you know, define it as yes, it's constrained and on chain, but then to do that securely, it does mean that we did define in protocol precisely what that means, which we will likely need to change with an upgrade to be post quantum. Or or you just, you know, you don't constrain it, but it is on chain with symmetric encryption or you're just or it's unconstrained. And so, nothing goes on chain and it's just the the user's responsibility to figure it out. >> Yeah.

I mean, it makes sense, but it it's tough on the like the the user choice of like Yeah, I don't know. >> on the developer figuring it out, not like I really think the user Yeah, the user will have >> Right. Yeah. >> Um Zach, I was curious how the transition to PQ proofs, like larger proofs, would affect Aztec. Um >> [laughter] >> Well, we're very actively following the the looking at the Ethereum ES progress on the post quantum roadmap because I think that the like the tech they're developing is

um you know, like the the more on like the reason why we built Aztec out as a layer two from scratch was because to do general programmable privacy was the only way back in the day. But, you know, like we'd be very open to just using like moving more on layer one and using more of what Ethereum produces because it's a really it's So, the challenge like as as Star mentioned, right? One of the challenges with with being post quantum as a decentralized framework of privacy protocol, it's you need um So, you need fast recursion client side because other otherwise your memory ex- memory consumption becomes too high.

And could traditionally you need small um small proofs um like a small output proof because if you if you're throwing around 300 kilobyte proofs across your your peer-to-peer mempool, you don't have the bandwidth for that and you can't sustain many transactions. And so either you choose the small, which you can get with elliptic curve crypto, but if you don't have elliptic curve crypto, you're kind of in trouble. And so the the only other solution is the in the mempool, the nodes themselves are aggregating recursively the proofs. And until very recently um like that wasn't particularly practical, but a lot's changed this year.

Um so it's yeah. >> The The other thing we haven't talked about is the CRQC timeline. I'm I'm I'm interested in what other um uh privacy blockchain and app developers um how soon do we think that we have to design these protocols and deploy them? Um Because I'm thinking that we need to have them deployed by 2020 uh start of 2029. >> Mhm. >> Um and so if I'd said that uh 6 months ago, um kind of before um ZK proof 14 and Eurocrypt and whatever, then um

I would have faced a a lot of skepticism, but now I can say it and people don't bat an eyelid because they they understand that um all of the quantum computer companies are uh are getting their work accelerated by AI and um uh I think as Justin mentioned, they um are finding new um quantum error correction codes and um they're solving a lot of the engineering problems uh on a weekly basis. So um everything is going much faster now.

And that means we need to get a move on and kind of design protocols um that without rushing um and without deploying something that um kind of will be broken and will need to to change again. Um deploy things that um solve the problem relatively quickly. So, I I'm glad that we have deployed quantum recoverability already on Zcash. >> Mhm.

>> Um but there's a lot of work to do. I I'm I'm kind of worried that Tachyon the current design is not um post-quantum. So, we kind of need to There was a um a workshop about post-quantum Tachyon earlier, um which was really really really helpful. >> Ophir had uh >> Yes, so my question is actually for Zcash. Uh when you say uh quantum recoverability is deployed what do you mean by that?

Um and the second question is um as Justin was mentioning this morning, uh we have like this bimodal distribution and we need the overtone window to be extended to the AI threat, although that other distribution is has kind of a a lower top. But have we uh like are you guys working on anything anticipating something like a hash break uh from AI new AI cryptanalysis being done and would that require another kind of recoverability protocol?

>> Um so, we're probably not going to use Poseidon anymore. Um uh yeah, cuz algebraic hash function functions um are kind of obsolete now. Um I I'm on board with that argument. Um we should just use um I I don't even know whether Blake 3 is um conservative enough because um seven rounds I I think so there's a um I think it's an academic attack on four rounds maybe three or four. Um so the question is is seven enough?

Um uh Blake 2SIV believe has 10 rounds. Um so why don't we just use Blake 2S for example um or Blake 2B? Um it's a >> And in the new experiment >> Yeah. >> I'm curious how people assess AI risk because I mean like the thinking about it it's kind of like leads to sort of nihilism like you just can't know anything and you like >> [laughter] >> Like why why is 10 rounds better or like I mean it makes sense that it's better but like how do you pick?

>> here as well there. >> I think that the thing that makes people scared is that cryptography cryptanalysis are the only things missing from Open AI's recent discovery and that the NSA has spent like around 30 billion I think in uh token maxing recently so yeah. >> In terms of timelines we have the same timelines on Ethereum. It's like 2029 is like And and they're accelerating. It is like you know it was said like 2029 I mean maybe like six months ago and now even the call days are like trying to

say hey we actually bring a lot more people up there to need for to make sure we actually get there earlier than them, so yeah. >> Since we're in the business of wildly speculating about about cryptanalysis, um you know, of course P P can be unequal to NP, right? And functions can really be one way and so on and so forth. So, I I think that it seems equally likely if not more that the AI wave would lead to new lower bounds and security results than than insecurity results.

>> Yeah, I I agree with that and I think that um >> Sorry. >> Uh yeah, it the challenge is that it is all vibes, right? And and you and there is there's never there's there's usually the incentives aligned so that like you want to be conservative um and risk off because there's no real reward for being a risk on. You look like an absolute fool if you're wrong. Um but no one really, you know, no one's going to blame somebody for being conservative. Can I just finish with the one thing which is um Yeah, I think that that there is a big difference between AI making fun like massive leaps in open math problems where the whole point is like we expect that to be a solution but we've not found it. And and breaking hardness assumptions that

have faced decades of cryptanalysis. Um so, you know, I would I'd be quite comfortable wagering that, you know, like despite all the tokens spent by the NSA, code models have not broken um like elliptic curve discrete logarithm. Um I do think that it's likely that, you know, the state of the art attacks will be improved and that that seek like bits of security will get reduced. I'm a little less certain about like I mean, you know, whe- whether AI is going to is going to threaten a hardness assumption. I do think it really depends on how much human cryptanalysis is being done, how old these primitives are. So, things like pairing inversions, I'm a bit more worried about quite a lot of bits of security being knocked off those.

Um but things like, you know, elliptic curve discrete log, I mean, there's just there's zero evidence, right? And it's And you can you can lose your mind by by like by interpreting the absence of evidence as evidence itself, right? Like the fact that OpenSSL hasn't published anything, well, maybe it's just they couldn't find anything. And And it was a bit embarrassing, you know? I think there's plenty of cryptanalysis results you could publish that that that that wouldn't have the NSA coming down on you like a ton of bricks. Um you know, because because they would be relatively minor like the effects would be minor, but the fact that they would was achieved would be substantial.

Um uh and the fact that none of those have happened as well means that I think that uh you know, you know, you you don't know what you don't know, but and it's all speculation, but but I think that these hardness assumptions are probably a little harder than people than than a lot of the doomers are saying. >> Well, I think like like a lot of that like what what do we know what has been what's the word dumped in this AI uh right, that is not sensitive, right? This the big what made also what people took as an argument like, "Oh, maybe they broke discrete log." is this improved algorithm for integer multiplication.

Now, my understanding is that algorithm has an overhead of 10 to the 650. So, that could be an indication of like, "Okay, maybe this this sort of LLM um thing it it finds very complex algorithms, uh but not necessarily ones that are practical." >> Mhm. >> So, I I I don't think I'm grasping the distinction you made between cryptographic hardness assumptions and math problems, right? So, both are conjectures that could go either way, right? It's not as if every conjecture is resolved in the direction that people expect, right? So, are you claiming that was your claim that discrete log is more

likely to be, you know, hard than than not hard because of the fact that we haven't But that's the nature of a conjecture is that we simply don't know one way or the other, right? I mean, in other words, the fact that it hasn't been broken yet just means it's still a conjecture. >> Yeah, you're you're right that there is some fundamental level this this it's it's unknowable. Just But there are you know, subjective factors at play here. The hardest problems were constructed explicitly to be unsolvable. Whereas open math problems people want to solve a lot of people like and a lot of these problems are ones that you know, people think can be solved.

Whether that's true or not, who knows, but >> We think there's an answer, but it could be a false answer, right? >> Yeah, but but that but these problems were not designed to be like by design computationally hard. And and I think there is a you know, that is a distinction there. And also there's been a lot of um, you know, uh, incentive over the past multiple decades, you know, for for people to do cryptoanalysis to break these hardest problems because of how much economic value is at stake, which is not the case for the open math problems. So, again, it is subjective, you know, uh, but I I I I I would wager that

breaking D log is much much much harder than going beyond that long end for integer multiplication just because of the scale because of the um, how these problems were crafted in the first place and the incentives over the last few decades to solve them. >> So, the the the the main difference I see is dollar value of breaking it. That that is the only difference I really see between this and like the Hodge conjecture or something, right? I mean, >> Well, I mean, >> Well, I guess you raised Okay, you >> There's a reason why the people didn't have any use of Hodge conjecture like as a hardness assumption cryptography, I guess. Um you know

>> Well, if we could, that'd be great because it's likely to be, you know >> This is where I mean this is like to be to be fair, you know, I'm not a pure mathematician. So I you know >> It would be great if there were a cryptosystem that was who that the only way to attack which was to solve the Hodge conjecture. I think that would probably be more secure than discrete log. >> Fair [laughter] enough. >> I wonder if we start to get cryptosystems where we have sort of an upper bound on how large the keys would be because if you get larger than this, suddenly the end log end algorithm actually becomes relevant and like your security proof no longer holds. So it would be in a range like you need at least this to get your soundness and you

need a at most this for the soundness proof to remain valid. >> The way I think about it as a protocol designer is um if you can just um double the number of rounds or even 1.5 times the number of rounds on your hash function and kind of shut down the speculation um because that that there's a theoretical possibility that that AI is good enough to break um Blake 3, right?

But not Blake 2s or Blake 2b. Not SHA-256. Um so yeah, and not definitely not SHA-3. Um so why not use the um the things that just we just have to pay a small constant overhead and kind of we know that that's feasible because um proof systems are getting better every day um and the the circuit size problem for the cost of proofs is no longer as much of an obstacle to theoretical designs it used to be. So, let's just use the the more conservative hash functions and

have done. >> I think in practice it's funny because it's also exactly the way it's gone without predicting it was going to go like we started with Poseidon like all in, you know like and then um I think like the then Linvian for example was sort of like all all all on like three for a bit and now it's on Blake 2S and it feels like we're slowly moving to like safer hash functions uh just because um just because we can uh in terms of performance uh and so as long as you have like the expected performance you have in mind for like throughput and and stuff like this that are that is

obviously quite important then you might as well go for like the safe safe option and I think um we're moving there, which is nice. >> Yeah, especially for um kind of the long-term storage idea is I think how all um kind of protocols that hold value should be going um because your it's fine for your payment protocol to to be dependent on this fancy crypto um but your long-term store of wealth should not be dependent on fancy crypto and doesn't need to be.

>> Yeah. >> I think there is a tension when it comes to asymmetric crypto on do you harden against AI or do you harden against quantum attacks? Because the um you know, like the post-quantum symmetric asymmetric crypto it's well, it's a lot newer and it relies on different hardness assumptions that might be a bit weaker cuz they've just had less cryptoanalysis. Um I don't know for for for me that's that I feel like that's a tension. So, if we've like if one was to like Mike came out two days ago, right? Like if someone was is implemented that what's the risk that AI is going to is going to wreck that versus uh quantum computer coming down the line and um smashing your your your elliptic curve Diffie-Hellman.

Um I'm curious what other people think about that cuz I've no no idea. >> Yeah, I'd like to So, one thing that I wasn't aware of till last year is the isogeny stuff, the assumption is really not that different from Diffie-Hellman. It's just about group action versus group operation. So, right Diffie-Hellman, discrete log, it's like you're assuming it's hard, you have two group elements G and H, it's hard to find the scalar that goes between G and H. The isogeny stuff, they're just going from group operations to what's called group actions.

So, now you have a set instead of a group. The set is like the set of some set of elliptic curves. And there's an action going from one element the set to the other. So, and now you have two set elements A and B. They're both usually elliptic curves, and you're like, "Oh, it's hard to find the the And now you have a group acting on the set. And you're saying it's hard to find the element of the group that goes from A to B. So, the problem is not really So, I you know, you someone could speculate that oh, it it will turn out that this group action problem, discrete log in this group action setting, is not really that much harder than the

discrete log in the regular group setting. >> I I mean, to to >> It's fun on that. Um And the scalar that you're trying to find in a a group scheme is also a walk in an isogeny graph. It's just a trivial case, right? When the the isogenies are between the same curve. Right? Um so, degree one. Um So, yes, the the um the isogeny-based schemes are just a strict generalization. Um but I I also think that um um I I do have a little bit more confidence in the isogeny-based schemes that um are not dependent on the inversion problem.

It if if it's dependent on um inversion, then Kuperberg's algorithm algorithm applies, and you can imagine there being improvements to Kuperberg's algorithm, um and so you Yeah. I I I'm kind of arguing against myself here because the the diversified dress scheme that I um presented at the earlier workshop um had depended on um inversion, and so it would be insecure by the argument that I'm making now. Um Uh so, maybe we just shouldn't use that, and uh we should just have out-of-band payments the way we were originally planning to do for Tachyon, um and just do that. Uh there's a there's always a a good argument for doing the simplest

thing, I think. >> I'm really curious >> Don't say. >> Oh. Um I'm really curious about about the harvest-now-decrypt-later cuz I think so far um this we've been discussing upgrading the proof system, and uh that's only relevant for soundness cuz you want a proof that cannot be forged by a CRQC. Whereas the harvest-now-decrypt-later, as we all know, uh it can be done to historic cipher texts. And what I am super curious about for Zcash is So, so here's what can happen. Like,

I Let's say I know your public key already, and now with my CRQC, I get your private key. And now using this, I go through the whole chain, and I decrypt all the plaintexts that you've ever received. So, that's the attack. So, what is what are the effects of this? Like, is this going to shrink the anonymity pool? Uh how how do these attacks on like historical data affect current users of Zcash? I How are you reasoning about this?

>> I mean, there's not much we can do about it. >> Yeah. >> Um so, um I I do encourage people to keep their addresses private. Um yeah, don't publish your addresses. Don't put your addresses in um memos. Um use a different address for each counterparty. Um cuz that will help a lot because it it will break the the chains that um uh quantum adversary can um detect when they are able to decrypt the whole blockchain, right? Cuz they can only decrypt links that um they know addresses for.

>> Mhm. >> Um uh we we should actually prove formally that that's the case. That that's a conjecture, but um I think I'm fairly confident in it. Um because the um so, the the reason for that, by the way, is that the KDF uses the um address as an input. So, if you don't know the address, >> Mhm. >> then even though you can break the um the public key crypto, you still can't compute the shared secret. >> Mhm. >> So, so it just de- generates to a uh to a PRF on the address. Um so, that that's actually a really nice property.

And I I have for a while been encouraging people to keep their addresses private. Um yeah, but there's nothing we can do about the remaining leakage. >> Do wallets uh can wallets sort of like automatically um use different addresses every time you >> Yes. So So, this So, this is what diversified addresses help with. Um so, I I think currently in Zcash, if you ask for a new shielded address, it will give you a new diversified address. Um >> Nice.

>> Uh yeah. And it's not linkable. Well, okay, except that um so, the linking between addresses is pre-quantum. So, um kind of any addresses that the adversary does know um if they are diversified addresses, um then they can be linked. So, it's it's harvest now, link later. Um Yeah. Um >> Well, and decrypt, I guess.

>> Uh and decrypt. Yes, exactly. >> Cuz they they can see that they have the same decryption key. >> Yeah. Yeah, exactly. >> It's unavoidable. >> Yeah. But and so, yeah, let's say they um the adversary knows a bunch of addresses, they decrypt everything they can, link everything they can. And let's say like it's still not enough to produce anything interesting, they can still cause more harm like simply by publishing all this because yeah, that decreases the anonymity set

for everyone else. >> Yeah, and then anyone can combine it with information that they know in a um intersection type. >> Right. Pierre. >> Uh what's the plan for uh diversified addresses, by the way? I heard that you have you are pretty optimistic with uh lattice-based schemes, but I'm wondering uh how compatible that would be with say hash based knock or something like that. Like how Like what's your Yeah, are you just going to ditch diversified addresses in the future?

Yeah. >> I mean so diversified addresses are only needed if you're doing scanning of the chain. Yeah, so So assuming we're doing the long-term storage protocol, that would be um symmetric cryptography only. So you'll be able to recover your funds from the chain um that are stored in the long-term pool um only with symmetric key scanning. um Which means that um it doesn't matter so much that you're using a single um kind of symmetric key to do that

scanning. um And therefore you don't need diversified addresses. So Yeah, it just Yeah, let's just do the simplest thing. >> Yes, please. >> Okay, you've convinced me, um I think. But I mean if if we find if we find a way to make Mike 20 times faster than I don't maybe I'd I'll change my mind again. >> Well, there's another reason why I personally would love it if we would stop supporting diversified addresses, which is I don't think they provide good UX. I think they're more confusing than helpful to users at least so far and it's been like 8 years, so whatever.

>> Does doesn't it work in a constructive way or like why >> Because And I think Der ammo might agree with me. It's not generally a good idea to give the user a privacy or security improvement that they can't understand. Like like like I do I tell do I tell the user if you give out your addresses to people they won't be able to tell that it's the same addresses as each other or do I

tell them make a separate wallet or separate account? In fact, that's what we used to tell them was make a a business account if you want to advertise. >> [snorts] >> And then you make a separate personal account for your your your wallet. That is like something a user can understand what to do, but I don't think I can explain diversified addresses to users so they wouldn't understand how to use them. >> I I remember having this argument with you when we were designing sapling. I think I think Strat was on my side in that argument and I still think that diversified addresses were the right solution because we would be in a lot of trouble if we didn't have them with scanning cost. Um

but if you can eliminate scanning cost then you don't need them. So, you just said um and therefore the usability issue becomes mute although I do think that um uh they will find usability. >> I agree on the UX point. Like when I heard you say like oh we have to tell users like Yeah, use a different diversified address per counterparty and like don't give out your address publicly. I feel like as users [snorts] should do as little key management as possible, basically.

>> But yeah. I mean the the wallet will handle it. I think like you will ask users also to necessarily do it. It's like um every time you do the connection automatically it's like >> Um I've even seen recently Zcash um wallets have started rotating addresses, both T addresses and Z addresses and new addresses, and I've even seen users being confused and complaining about that. They were actually relying on being able to recognize the same address, and now it's different.

That was the only way they had to figure out if that was the right address, it's a problem for them. >> I I mean, I've had the problem that Keystone and the hardware wallet will only show on the screen a single address. Um so you [snorts] can't check that any other diversified address you're using is the same one that the Keystone um shows. So So that's an assurance problem that you have. If you don't trust the software, then um yeah. You But that's that's because Keystone is not designed with diversified addresses in mind, and it it should be able to just recognize is this my address?

That should be a function that is is right there on the um the the default screen, but it isn't. I Maybe I'll do a pull request and and fix it. >> wallet UX problem. >> Yes, exactly. Yeah. The This is one pull request to wait to fix. >> Yeah. >> So I would propose that as an input to the cryptography design decisions, we have a table of user experience uh situations, like the one you described with the Keystone, and the one I had this experience with more than one user recently um with software wallets

and the scanning issue that Der Emma mentioned which if there's someone who has like a million addresses that they've distributed which literally can happen if that person's a C X but Anyway, we have a We write all that down. And then we can use that to determine like um I I would like to say we we we shouldn't pay cost to implement things which cause confusion in users.

Indeed I might like to uh of uh avoid implementing the thing that causes confusion in users even if it were free. I I mean >> Same same questions in Ethereum like we are thinking of wallet standards or like new wallet UX that is you know using new addresses every time and I just because it's just like a healthier sort of like prac- like practice uh and I Yeah, I feel like if the user is able to sort of like figure out that it will sort of like use different addresses and all it cares

about is like the balance and just like I I I feel like it it should be fine to abstract it away. Like I do I just feel like it's a you you do gain a lot by having this sort of like new address to every time in terms of of of privacy. So I don't and it doesn't feel like a sort of like I understand the sort of like attachment to your address and you're trying to check something. It's not the same. That I get but um hopefully in the future users can move away from this attachment to addresses as well. Like they they don't you know, I feel like maybe yeah, old crypto users would feel this way, like I'm checking addresses like I know what my address is address looks like, but then is that like the

right level of abstraction? I'm not sure. >> I I I think we should get rid of addresses because um I I think so the the cases that we really need to support are you have a private channel um with your counterparty um and you want to receive or send a a payment. That doesn't require you to understand addresses at all. The functionality does not need addresses. Um so um I and if you're kind of in person, you just want to be able to scan something and go and that doesn't require addresses either.

So um yeah, I I think we actually can do everything without abundant payments and the the the donation use case um is a special case that we might want to support, but um it it that might be vulnerable to long-term cryptographic attacks that other use cases aren't and that'll have to be fine because it's it's kind of inherent to that functionality. >> Yeah, I don't Mhm. >> So I don't want to take a stance on the diversified address question on Zcash. I just want to say that uh um the the reason why we would have uh

we would get users to have uh many different addresses on Ethereum though is very different from Zcash, right? Because Ethereum isn't a shielded pool. So I think we would try to find a very different privacy invariant in the case of Ethereum. Like it would it poses other kind of UX questions like balance consolidation in the case of Ethereum. So yeah, I I don't think the comparison would hold too much between the two protocols. And so Zac wants to talk. I just want to throw that in the wild. Maybe we can talk about that later, but it's the question of the spend oath scheme that I would be interested to to talk about with the Zcash people.

Uh in the in the post quantum context, of course, yeah. >> Oh, I've got Oh, sorry. Yeah, I think it's um What was I going to say? Uh one of the challenges with this question of not just like, you know, do you have diverse addresses do you addresses at all this is is is effectively like this this is part of this is about like there is a level of complexity to to like to to safely transacting on chain whilst maximizing your privacy whilst whilst preventing um you know, um uh and and and like, you know, ensuring that you

it depends on the the the needs of like things like Ethereum or Zcash or wha- whatever, but um um but but diverse addresses is basically a case of pushing this complexity onto the application developer uh to some degree. Um uh and you know, I think we it's it's pretty clear that like blockchain already has a pretty bad UX. Um and [snorts] and that um app developers like as with critical designers, right? The most important thing is to try and reduce complexity for app developers.

And and also there's a also like a mishmash of almost like incentives because like the more value somebody has at stake on a in in in on on chain, the more they're going to care about these kinds of things. Um whereas, you know, if I've if I've got $1000 um in an account I'm just YOLOing and I'm buying NFTs or doing something stupid, I don't give a damn. Um and so I think >> As long as it's not linked to anything else. >> Yes. Um uh and and so, really like what what the right level of, you know, obfuscation or security is around around addresses, around identities. I don't think there is a one-size-fits-all solution, you know. Um for example, you know, if you have a if you have a lot of crypto, right, it's yeah, you you should put it in cold storage, you should put

it in an address that's never been spent before, and you don't share your public key. And if you have lots of money, it's it's take you're willing to do that, you're willing to care. Whereas um you know, uh you know, for example, but if I've just put got like 100 dollars in crypto and I've downloaded an app, I don't want that app to show me like, "What's your treasury management policy?" or things like that, you know. And um Yes, I so I feel like um it's probably better to better to leave this to um like application-specific domains um where instead of just having diversified addresses, you just have different addresses. Um uh if people really need that separation.

>> I I've had big arguments about whether um the onboarding flow should kind of enforce or strongly encourage people to um uh securely record their um seed phrase. And I said put it should, and um I've had that push back against because um it complicates the onboarding flow too much. Um so I I Yeah, you do need to basically make a distinction between hot wallets and and long-term storage wallets. Uh onboarding means introducing a new person to Zcash or whatever the um the system is.

>> Just like the whole seed phrase set up. Yeah. >> I did it's just that the um issue of um kind of seed phrase security came up. >> I think it's like a UX question overall of what where you are pushing complexity and what trade-offs you're making and yeah, maybe there is no one size fits all but you're going to have to push that complexity somewhere. I think like as protocol designers, we're like trying to keep the complexity away from the protocol, but

like then sometimes it gets onto the dev x or all the users and yeah, I mean those are just like hard questions. I don't think there is the good solution for it. >> Because I was I'm not sure if I understood what what you said before well, minutes before. Uh so the initial idea to come up with diversified addresses not so much that that you're you're you know that you uh let's say that the people you you you receive funds from can link you.

Uh but it was more scanning the entire blockchain history in case in case of that you you bricked your hardware wallet and and try to that that was really the the uh how to say the spark that led to the design decision. >> Right, so so you can solve the um the privacy issue with people being able to um link the addresses that you um gave them um by just giving them completely independent addresses, right?

But then you have a um a scanning cost, which is per address. Um unless you have diversified addresses, in which case in a certain sense, it's the the best of both worlds because you have the um, the cost of scanning for a single address, and you're still able to give people um unlinkable addresses. Um, and the problem is just that, um, quantum computers break that. Um, uh, well, maybe they don't because, um, it's possible to I think it's possible to do diversified addresses in, um, with ML-KEM. Um, you just need to re-analyze the error bounds, um, but we can do that.

Um, but the if we don't need it, then we shouldn't have the practical complexity. So, if we're if we're strongly encouraging out-of-band, um, payments, then we don't need the practical complexity. >> Okay, we're we're at time, and I want to thank everyone for bringing your knowledge, and also experience and questions. I I feel like this post-quantum transition, at the very least, is helping us to, like, re-examine many aspects of our protocols, and maybe, like, give us the chance to

improve them. Like, stuff like out-of-band payments or diversified addresses. Like, so, it could actually be a forcing function to simplify our protocols, as well. Um, but yeah, I also heard just lots of uncertainty about how to assess which primitives are secure in the face of AI, as well. So, yeah, overall, I feel like, uh, lots more questions than answers. Um, but it's it's really great to have converged on some questions, um, and I hope we can keep working on them together. So, thank you all.