PQ Tachyon

Transcript

Yeah uh thanks for coming to uh Piquet Tachyon workshop. Uh I'm here moderating. I'm Ulrich for those who don't know me. Uh so, recently switched to shielded labs which is just last week. So, I hope I'm good enough here for moderation because uh I first entry point was that digging into get on to speed with with the design of Orchard uh and Ironwood. And uh yeah, first time since long uh maybe just a very little background about myself. When I jumped to industry without having any knowledge except classical 90s

zero knowledge proofs based on uh in of the Schnorr type, you know, ECDSA type of proofs. Uh actually big inspiration for learning for me was uh the Zcash uh spec. So, all all the rank one CS back then. All all all my knowledge about how to write efficient circuits and all these tricks by uh was by Shawn and by Daira. Uh so, it was really it feels to me now like uh returning or let's say going uh joining shielded labs is a bit like for me going back to the roots where I came where where I start my study in CK.

Okay, having said this, so I'm familiar with Orchard uh and uh and Ironwood. Uh so, when it comes to Tachyon, I have I have just a rough overview of of the upgrades or different diff the diffs uh to uh to uh Orchard. Uh so, uh I'm not sure how this work is going to stop uh uh start start off. I think the best would be to start off with just a list of of the main diffs before we come to the question of privacy in particular uh with PQ uh with quantum computers uh being present.

or feasible. So, as far as I know, maybe maybe the best thing is I start and you help me uh learning here. Uh >> I just want to say I I'm not a sponsor of the Tachyon team. >> That I'm aware of it. Is anybody here from the Tachyon team in the >> I did I did see him earlier, but I don't know where he is. I'll I'll go on with my question. >> Okay, thanks. So, who's familiar here with uh with the with Orkhut Ivan Iron boot design

shielded with the shield boot design? Hands Hands high for those who are familiar because for those who are not, maybe it's good it's good that I start. For me, it's a kind of uh kind of uh uh recap of what I've learned in the last 2 weeks. Uh so, I'm not looking much now on the transparent side of of Zcash of the Zcash blockchain, which seems to be very uh very similar, if not the same, correct me please if if I'm wrong, to uh what be the the capabilities of Bitcoin scripting language.

Uh so, uh for the shielded pool itself, uh currently uh everything every transaction or every action in some sense that is done uh is is is committed in a in in a blinded manner, in a CK manner, and of course to uh, to uh, to to assure that everything goes according to the rules, to the spec of the system, uh, you need zero-knowledge proofs. And in this case, uh, the zero-knowledge

proofs that Zcash are using since day one are elliptic curve based. And in particular, the modern uh, ones they use uh, they don't use anymore growth, they don't use KCG commitments. They use uh, transparent commitment schemes over quite arbitrary elliptic curves. And as far as I know, uh, the whole the whole math machinery is is built, but I'm not going too much into details of a cycle of ordinary elliptic curve Palace and Vesta's. Uh, and the initial thought when I digging into Orchard that the whole proof here uses already recursion, which it doesn't. It prepares for it. It prepares for it. So, simplicity Orchard pool

is built over an elliptic curve, over a single one. Let's just think of that. Scalar field of a single elliptic curve. And uh, from the mechanics, uh so every action, every transaction is done, is committed, is added into a Merkle tree that keeps state of of the committed actions. And uh, and in order to prove a spend according to the rules, we need nullifiers, right?

So, that means we need something that we that that we match to the content of of of the of so of of the committed UTXO. it's a note. in an unlinkable manner. So, that means the the proof proves that that the nullifier you just claim is in fact correctly derived from the thing that is behind the encrypted or committed note. And and given that the proof system is sound, there's no way to cheat here about.

So, I'm I'm not aware aware of it, but maybe there are. >> So, I mean nullifiers um go back to a paper by uh Sundar and Tashma 1999 anonymous watch [snorts] for our trying cash and I mean Monero uses them as well. They just call them key images.

Um As far as I know, you can try and do an account-based model. We we thought about this a lot and it's really difficult. Um because the the problem is that um it's hard. So, Mina uses a an account-based model and that's why they don't have privacy because it's hard to hide the updates cuz you're crediting someone else's account as well as debiting your own.

Um and that it's hard to do that without revealing information on chain. Was it That's the problem that nullifiers solve. I I mean I I would hesitate to say that it's unnecessary um kind of design element, I don't know how to do it any other way um with the same privacy properties. Yeah. Um yeah, and so actually I think um it might be interesting to go back to Sprout. Um so when I um sort of think about possible post-quantum designs for D cash, I go back to Sprout because its

circuit is post-quantum. Right? It's not a post-quantum proof system, and it's it's not other parameter choices um uh are pre-quantum, but um the what the circuit is proving um is just using hashes for authentication. So um how it works is a an address is um a public key that you use for the note encryption um and also an APK value, which is just um uh a hash image. Um and to prove that you um own the note, you just prove that in ZK that you know the pre-image. Um

so that works just it just works in a uh post-quantum proof system. Um and that has a lot of advantages. Um it it's also something that you can think about um even doing a proof on a hardware wallet because if you only have to do a proof of one hash um plus the linking commitment to another circuit that you're doing on the untrusted device um then that could be you could find a post-quantum proof system that makes it feasible to just prove that one hash.

Um and it can be a very conservative hash function um so that you have long-term security um and you're not having to worry about the long-term security of a um uh structured um post-quantum scheme lattices or codes or whatever. Um, so I I think that is the right approach, and you can hold most of your money in a um a pool that only depends on that. Um and you can do some more sophisticated um payment schemes that depends on more complicated cryptography um and get low latency for that,

but still not be risking most of your funds with the complicated stuff. So, I think that's absolutely the way to go. >> When When you say the the sprout circuit is PQ secure, what do you mean by that? >> I I mean that if you look at the statement, then it's only depending on PRFs and um there's a commitment and um a Merkle path check, so if the Merkle >> Okay. Okay. So, you are not talking about the proof system here.

>> No. Not the proof system. The statement does not depend on any um quantum vulnerable cryptography at all necessarily. >> Mhm. Mhm. >> And And we actually use SHA-256 for sprout so >> What What kind of signature was uh was used? >> Didn't use signatures. >> It didn't use any signatures? >> No, because we didn't support hardware wallets. >> Ah, okay. Okay. Okay. It just means prove the pre-image of a hash. >> Yeah, that That was one of the innovations for Sapling, the linking the linking to a randomized signature, um which introduced a point of quantum vulnerability, um which it kind of was necessary to support um hardware wallets at the time.

But, now that we have um kind of we potentially, with a bit more engineering, have proof systems that can run on a hardware wallet that are post-quantum for small circuits, then you can use that approach and then you don't need signatures at all. >> Uh I'm a bit skeptical. Well, right. I mean, may- maybe with with with uh Keystone, you could could run a very very small proof system.

>> Pe- People should just use more powerful hardware wallets. >> Yeah, that would be nice. That would be nice, but at some point uh I think >> really should. >> Yeah. That would be super cool. Uh in the end, seems like I mean, we're still one of the most mostly widest used devices is Ledger and the Ledgers are quite conservative here. So, happy That's why I was asking in the in the session before having just a hash-based signature like Sphinx Plus. >> Yeah. Yeah. >> Or similar to Sphinx Sphinx just with a different parameter setting.

Signing a transaction uh below 1 minute is already a huge suc- success uh and seems like they can do it with uh uh just with a few seconds. I'm I'm really curious what the trick will be here. Maybe pre-computation and that's it. >> Well, um you need a key re-randomizable signature because uh if if you're putting that signature in the transaction, >> Well, I guess if you you don't need necessarily >> have recursive proofs, then it's easy. >> Uh exactly. And this is this is or if you have proofs at some level, just depends on uh what what what statement you're going to prove. Doesn't have to be recursively, that just prove that I just don't use the signature, the authorization given by the hardware

device as a extra piece of data that prove it. >> No, but you have to link the the key that you're signing under with the transaction somehow. >> Mhm. But if you have recursive proofs, then um it's fine because you're already already using recursive >> sort of a recursive proof, I I agree. So, it proves already the existence of a valid signature, but uh but it's you don't have to have the whole uh succinct blockchain idea of of having just proving the entire history history.

>> No, you can you can do this just at a transaction level if you want. >> Um >> Thanks. Uh so, when you talk about hardware wallets and privacy, what is your model here? Is it that privacy should hold even against the malicious software, or is it okay if sort of let's say I the a malicious software cannot steal my funds, but it privacy is sort of out the window against the malicious software. Because then that's that makes things simpler, right? If you say privacy shouldn't hold against my software, against everyone else, yes, but >> Yeah, so the current model for Orchard is The current model for Orchard is um yes,

you you trust the um the software wallet with privacy. >> Okay, but >> Because people want to be able to um view their funds without going to that without getting out the hardware wallet. >> Yeah, but then do you really need Why do you need a re-randomizable public key signature scheme then? >> Okay, so so in Orchard, for example, or Sapling, um you're putting the um the key that that signature is under, so RK, um in the transaction. Um so if that's the same key for every >> decision.

>> Yeah. >> In short. >> If it's the If it's the same key for every um use of that address, or or funds sent from that address, then it's linkable. >> But couldn't the the public key under which you sign be part of the witness in some sense? >> Exactly. That's that's what you can do, but they just didn't do it. It's a more efficient circuit and you know elliptic curve signatures are super super small. >> Yes, exactly. >> So what they do is >> if you put it in inside the circuit and you say the software is trusted in terms of privacy, then you could just use things or whatever, right?

>> Exactly. >> So don't you lose re-randomizability, right? >> That That is re-randomizability. Um Oh I see. So >> You don't need re-randomizable. It's You need re-randomizable in the current or hard ironwood construction. It's just the way how design decisions were done for the sake of efficiency, I think. >> Well, okay. So suppose that you're doing it um the So So you sign with a random Sphinx key, okay?

Um >> And you prove the signature. >> You You prove the validity of the signature. So So it's not like you forward a randomized signature to to the outside of the world. >> Yeah. Yeah. >> And the proof links the two. >> But that's really expensive. Uh so so in Orchard, the circuit is just proving the randomization key. >> most likely for efficiency reasons uh >> Right. But let's say we make the assumption that we can efficiently prove knowledge of a valid uh Sphinx signature where the where the public key is part of the witness.

>> Mhm. >> But that then you've defined away the problem and it's easy. >> Well, okay. So from the Ethereum perspective, that's exactly what we focus on a lot like proving efficiently knowledge of of these signatures, right? So maybe >> I think I hope that's also my hope uh that >> It was impossible to make that practical because um So it was difficult to um the performance gains from circuit size that we did in Sapling and in Orchard. Um and if we'd had to prove verification of a signature as well, um I mean, that that we would have gone up um to one power of two in the circuit

size. Um and yeah, the the performance effect would have been very significant and it it would have been hard to justify deploying that in order to support the hardware wallet signing cuz we didn't have an implementation of hardware wallet signing. Mhm. This This is quite speculative and never really implemented for Sapling. Mhm. Um cuz it was difficult enough that it had to wait till Orchard until we implemented it. Um so, yes, it did need to be the simplest scheme where you just prove the randomization. But, if you have recursive proofs, and especially if you're using recursive proofs at the transaction layer anyway, then yes, you don't need to do the more

complicated thing. >> Okay, so and and anyways, even working on recursively, I would guess, it's just a guess, that if you use uh a binary proof system and and you use Sphinx with one of the binary hashes as standardized say uh or maybe another one if that is a problem for hardware wallet wallets uh performance, uh if you use that, I would guess you should do be able to run uh on a smartphone a proof an action proof that that does not use the re-randomization trick.

>> Y- You can do that. Um I I still think that the So, the um actually proving um a hash pre-image and an empty commitment in um a a proof system on the hardware wallet with the right um trace of proof system, it is a competing approach to the >> Yeah, if you wouldn't have such constrained devices like Ledger S. >> Even even on a Ledger. >> I'm skeptical with with >> It's fine.

>> You think? >> Yeah. >> You would get that even with the memory constraints? >> Yeah, some of the newer lattice basing schemes. >> Okay. >> With the camera. >> Okay. >> Maybe. I I don't know. It It probably needs an element to kind of optimize it for this use case, but um that's a few prompts away these days. >> It's interesting. So so lattice based proof system on a on a Ledger Nano, say. >> No, not a Ledger Nano. Get Get rid of your Ledger Nanos. Ledger S. Excel whatever it is.

>> Okay. >> Excel. Okay. It's okay if we don't support all hardware wallets. >> Mhm. >> It's fine. >> Mhm. Mhm. What's your What's your stance on on on on on lattice uh security here? So >> We We shouldn't rely on it for long-term security, but it's fine to rely on it for for proof systems. >> But if those proof systems uh create a spending proof, you know, the authorization essentially.

>> Um no, because what you're proving So if you use my approach, then you're not relying on the signature scheme long-term at all. What you're relying on is the pre-image security of that hash function. >> But you could fake a proof. >> Yes, in the short term. And then you stop You stop accepting those proofs. You just go to another another proof system. You have a hard fork. >> Okay. Okay, so as an as an intermediate solution yeah. >> Um can I ask a question? Sure. What What are the um constraints of hardware wallets? I don't know.

>> Very different. >> Yes. They're They're very different from each other. Um so if you if you have a keystore I used to I worked for 15 years doing um embedded industrial um kind of software. Um, and we were working with 32 kilobytes um Motorola code ColdFire um chips and um it Yeah, there's a a big difference between um that kind of embedded programming which is more similar to what you're doing on a on a Ledger Nano.

Um, and keystore which is kind of like writing software for a desktop system in the '90s. It's it's fine. >> So that would be accepted. You think uh that community not supporting uh Ledger? >> I mean people It's just a question for myself. I I mean if you can do a lean Sphinx um signature on a Ledger then yeah, let's do that.

I was saying that that's not the only possible design choice. >> And also it's good to mention the devices are going to evolve and like the Ledger Nanos are 15 years old now. Nano S uh 10 years old something like this. And then there will be next generation. So like bending your protocol for a device that is 10 years old. >> Yeah, that's Yeah, fully agree. Just dived in and I was surprised actually to be honest. I was really surprised that something like Sphinx even though it's quite compute intense in its uh standardized version uh that this is such a troublesome for

Trezor for >> Yeah, and and it works with the printing on the Nano S. So >> I mean it's partly just that NIST is very conservative and um kind of wants things to work for 2 to the 64 signatures, which no one actually needs in any practical protocol. Um it's a bit of a hobbyhorse there. >> So when I designed the Sphinx minus version for the EVM, I also checked the biggest nonce on Ethereum and since the merge you should take the 99.9 percentile so almost no one on the network.

Um it's like 500 signatures per year, so more than one signature a day. So with this lifetime, like even the most intensive users could last decades and if you don't rotate your key in a decade, you have another problem. >> Yeah. >> So yeah. >> Yeah. >> Oh, yeah. Okay. >> So >> I don't know how Yeah question.

>> Um so this comment about evolution of hardware wallets, I've been thinking about um putting a small more deterministic boundary making model on one of these wallets. Is is that something that's going to create way too much privacy risk because the model will like like holds onto the traces of its decisions. Um is it even possible? Um I've been experimenting with putting like tiny models onto Raspberry Pis and doing non um cryptography related things.

But uh is is that something that the room is anticipating that hardware hardware wallets might have like compute or like small LLM or models within >> sure if if you're I don't know addressing what's currently the design case anyways where so you have a software wallet communicates with with the hardware wallet if you have one and the software wallet sees everything except the secret key that with that helps you for proving you your you you're you're allowed to spend.

But everything else it sees already. So for in terms of privacy the software wallet reads everything. So if you don't trust the software that's another good thing and that was I think what the previous discussion pointed at at some steps like uh the most conservative if you don't if you don't want even to give privacy means that the whole hardware wallet the whole security device does everything. It it scans it communicates just Well it needs to scan the blockchain in some sense.

>> Yeah. >> To find which nodes are are for you. >> But I think there are has something more interesting to say. >> So if you want to kind of split your privacy so that um your less trusted device that you take shopping with you can only see your hot wallet funds and you have another device that you keep more secure that can see of your long term um stash then I think that's a better model than trying to make one device do everything.

Um because otherwise your device is going to get stolen or you're going to going to get kind of kidnapped along with your device um and forced to open it then you want only a subset of your funds to be at risk. So, yeah, device separation is the best solution to that problem. And then, that solves the privacy issue as well, to a certain extent. >> That's a good point for the super paranoid.

>> I mean, not just super paranoid. >> Yeah, yeah, well, yeah, I'm also given, I don't know if everybody was on Twitter yesterday or this morning about about the hardware tampering of a certain Ledger devices from a certain reseller. Uh that's also I have a Ledger Nano S, but I purchased it like 3 years ago or so. Hopefully, it's good. I never opened it. Uh but that also started to make me think, okay, maybe a fully air-gapped thing, first of all, maybe something that is not target of like having an old computer, you build out everything from the wireless

cards to to Bluetooth and everything, air-gap it by yourself. Uh is is maybe a more currently more secure or less a target or more less likely that this is going to be targeted than than one of the hardware wallets. Yeah. >> We should talk about other things than hardware wallets >> Yeah. Can you? >> I was just going to say >> we should talk about other things than hardware wallets. I've been using and recommending air-gapped things that you can buy at a store anonymously, um which is how we did the Zcash setup ceremony, for the same reason. Um so, let's talk about other things than hardware wallets.

>> Okay. >> [snorts] >> Okay, so last other [laughter] >> It just came to it somehow, now. >> There is the So, in the past, it was quite complicated to do the DIY thing. Now, it's it's way easier because you can debug yourself. So, it's a great time to to do DIY stuff and there is a hardware wallet PQ1 that is shipping and that offers you to buy the parts. So, I guess more and more hardware wallets are also going to propose to just buy the parts by yourself and then flash the firmware. And it's going to be much more accessible than it was in the past.

So last hardware wallet. Cool. >> I have a question maybe related. >> [clears throat] >> How come multi-party wallets are not that common? I mean, even if you go for a hardware wallet, why not split it into like two wallets? I mean, it's rarely used as far as I understand. >> There are several reasons for that. So, the standardization of FROST took a lot longer than we thought it would. Um kind of we we could have um kind of designed a adapted music, for example, um and just accepted the fact that it has it needs three rounds for security

um and deployed it sooner. Um but we instead chose to go with FROST and um try and get that through the RFC process. The RFC process is very long and torturous. Um and it it led to a lot of delays. But >> But But generally, why >> I Yes, yes, I know, but that was the design um kind of decision that was made that took as to what to focus on. Um And that's what uh caused a lot of the delays and cuz I I think the demand for multi-sig is certainly there.

Um we didn't have implementations. We didn't have the standards. >> Thanks. Okay. Let's talk. Let's not talk about hardware wallets. >> [laughter] >> For me it was the natural entry point because thinking of Orchard, you know, thinking of of future future PQ secure upgrades. >> It's an important topic and >> It's It's the constraints.

They have a lot of impact of the protocol in the protocol designs. So, Mhm. But >> I don't think it's fair to say that someone has to buy a new hardware wallet to upgrade to the latest >> Mhm. Mhm. >> I mean, you can't you can't reuse your old one. I don't think that's fair. You're a killer. >> But but you can use you can use hardware wallets from a few years old. You just can't use them from 10 years old. >> Right. >> Thanks.

Okay. Uh Let's circle back to Tachyon. Diff to Orchard Ironwood. So, first of all, recursive proving that means the possibilities of proving the entire chain from day the entire pool from day one until now by a single by by single uh snark. The second is some design decisions that come with it, which are are greatly are much different. For example, there is one unified accumulator rather it's not anymore a Merkle tree.

It's a polynomial-based polynomial commitment-based accumulator that stores both. You could do the same with Merkle trees, but it's just not it just wasn't done for historical reasons, I suppose. So, you just store both commitments of notes to the encrypted notes, so to speak, in some sense. Plus nullifiers in the same structures. I think they're they're called tachygrams right? Yes? >> Okay, sorry. Um for the recursive proving, who's doing the proving and for the encrypted notes and uh nullifiers, who's holding those? And like, where you know, what part of the stack is

I'm trying to solve that. >> question. Uh I think there are there there are certain notes dedicated to proving. >> Okay. >> Uh so, that means not the client, first, if that was the question. So, so recursive proving and even aggregating proofs, uh uh like like many transactions, like just for one block. I don't know what's the throughput currently, how many transactions are are then to be considered. You would have prob- probably full node or something like it or some some some some proving services on top that that prove uh the current block and then iterate recursively uh to bind it to the history.

>> Okay. So, then the the the >> The problem with that is obviously the the trade-off with the the trust assumptions you have because if you have very few nodes that are doing the aggregation or the recursive proving in the end, you you are bottlenecked in terms of uh you know, censorship resistance and um like by default >> There is not in terms of censorship resistance, hard to say. For the pool itself, there's nothing to see. So, I'm I'm not I'm not if you're just looking at the data.

>> No, but the if those aggregating like recursive proving nodes go offline >> Yeah, yeah, that's a problem, then. >> Just have enough of them. >> Yeah, and enough of them independently run. The existing Zcash infrastructure in practice relies on light quality nodes or light client server nodes. Um So, we that's not a new kind of dependency that already exists. And in fact, you're trusting um a a light client protocol um node more than you would be trusting an aggregator much more cuz it kind of affects your privacy as well.

You you still do get some privacy properties, but there's um the light client protocol um it kind of has a an honest what honest but curious security model, which I I've always been skeptical of. I I think we just need to rip it out and replace it. Um because it it's probably the biggest vulnerability that you have to your privacy in practice when using Zcash. Um if the the light um what server is um malicious, then they can infer a lot. Um Um But Yeah, so so we need to fix that anyway.

The The thing is who runs the aggregators doesn't really affect the protocol very much. That's a higher level issue. >> Yeah. >> Um that's what we just need to figure out. >> scheme >> Yeah. Well, you just pay them. >> Yeah. >> Uh I I do not know, uh Tal. >> I I also don't know. >> Oh, some somebody from Techuim. Finally. >> [laughter] >> I I I So, as far as I understand, and um note that the protocol has been evolving a lot lately. So, um I'm not caught up on what it currently looks like. Um But

I >> We So, we we have team members who have done cost estimates. Um I'm more on like the proving system side. Um the design of like what we call the oblivious sinking service has changed a lot in the past even couple weeks. So, before um the the oblivious sinking service actually like derived the user nullifier. So, we would have like a constrained PRF scheme from a a 2010 Bonet paper where the the wallet the wallet would give the OSS some key.

Um it would model a constrained PRF and in a Merkle-like structure um the OSS would uh would derive the nullifier by walking some bit path of the key. Instead of the the OSS now deriving the nullifier, the wallet derives the the nullifier. And it generates these like dummy PRF values. Um they're just hash outputs. It gives it to the OSS. Uh the OSS So, the naive way the naive way um the OSS would like check that the the p nullifier is not in uh the current epoch is you would build a polynomial.

And this polynomial would be quite massive. It would be um assuming the epochs of let's say 2 weeks, uh you'd have hundreds of millions of of tachygrams. Uh there's no distinction between a nullifier and a commitment. Uh both of them are just tachygrams. And you would have to prove that your nullifier is some root of this like massive half billion root polynomial. That's quite inefficient and it and and it would blow up verifier time to like 20 minutes or 30 minutes. So, what we do now is the the wallet de- derives the nullifier. It sends these like PRF Poseidon outputs to the OSS.

Uh the OSS builds um uh it effectively builds a Merkle-like structure, so it's incorrect to say that Tachyon does not have Merkle trees. We have polynomial accumulators, which is the hash chain, but within every epoch you have like a quadratic residue based Merkle tree. >> Mhm. >> To prove that the nullifier efficiently the OSS uses this uh quadratic residue Merkle tree to prove efficiently um that that the nullifier is not in in the epoch, so you effectively construct a Merkle structure, you decompose it into QR buckets, um the oblivious sinking service uh generates a PCD proof that the nullifier that the wallet sent

is not in one of these buckets by in the circuit um proving uh some Merkle path, and it sends that PCD proof back to the wallet, and the wallet recursively uh combines that PCD proof with it its own PCD proof among proving other things like uh the commitments derived from um from its own note, and uh you can then also derive the nullifier for the current epoch, um and show unlinkability between nullifiers. So, it it the design changes quite fast.

Like 2 weeks ago the OSS was deriving the nullifier, now the wallet derives the nullifier, but we have this like quadratic residue based uh design, which is much more efficient. >> Mhm. >> So, I think it took verifier uh it it took proving in circuit that the verifier uh proving in circuit that the nullifier is not uh has not been spent from half an hour to like seconds. So, it's a lot more efficient. >> That's cool. Um so, my understanding is that that part of the protocol it's just a black box uh non-membership set, right?

And that you're using a quadratic residue base scheme and I've always been skeptical of using that because it's pre-quantum. But um >> What is that true? >> Oh, okay. I may be wrong there. >> I don't know if that's true cuz um the hardness assumption is like just squaring right? And >> Squaring in a ring. >> In a ring. >> Squaring Squaring in a ring is pre-quantum.

>> Right. Right. >> So so the the hard problem is inversion. >> Yeah. >> Yeah, that's pre-quantum. >> Right. >> But but you that's for short-term security, right? You can just switch to another scheme and it doesn't matter because your nullifiers are evolving. So um >> Okay. Can you explain what the quadratic residue thing you're using is? >> Yeah, so I did not implement it myself. Uh um I I don't know actually much about how that part works. I'm more of building the proving system, but I know we have some like QR-based Merkle tree

as of like last week. >> What is it used for? Like I don't I'm maybe I'm just missing >> Non-membership proving. >> Like is it like an RSA accumulator? >> Yeah. >> reduce it into buckets.

>> Yeah, you you you have like you effectively have buckets of tachygrams, and you build vector commitments. You commit to each bucket, and you build layers of vector commitments until you have um some root. And and that is that is the Merkle. >> Do Do you mean that uh the whole non-ship non-zero evaluation proof, or non-membership proof, is somehow recursively composed in some sense according to a tree logically?

>> Exactly. >> Ah. >> And you prove this in the circuit. And it's from what I saw, quite efficient. Um but the internal mechanics I don't quite understand. >> So So, we know how to do post-quantum non-membership proofs. Um There's There's There's just the Um so, there are optimizations of this, but the obvious um kind of interval scheme where you um you use a conventional Merkle tree, but you prove that um the nullifier is in one of the intervals that are not um uh not the nullifiers that have already been used.

That scheme works. It's just We're We're talking about optimizations on top of that. Um and my understanding is that um the PCD scheme uh based scheme is on top of that, and just uses um that non-membership scheme within an epoch as a black box. Um so, there's plenty of scope to not do the QR thing, and to do something else instead. >> Yeah. Uh so, why do you still use a a tree? Um So, it's an open question. Uh you keep using a Merkle tree, but why do you keep using a tree and not another

way of committing to the data? It's an open question. It's the You The answer can be because it's how we do. No, I mean It's an open question. Have you thought about another way? >> Well, I'm not from Tachyon, but um >> No, yeah. >> To to me, um the reason I would consider um Merkle trees is just that I know Merkle trees better. Um but you can you can use any um any non-membership accumulator.

Just just pick one that's that has your efficiency and security properties. >> Thanks. Uh yeah, zooming out a bit more again, like I think I'm just also trying to understand like you said you have already have like sort of nodes with just assumptions that you want to get rid of, but like if I understand correctly, Tachyon introduces two more, right? So, you have the aggregator uh and you have the OSS service. The OSS service is in the hot critical path for transactions, so and I'm wondering like I mean one answer is like you know, you you just need to have enough of them and you just need to

pay them, but like I do feel like it needs to be sort of like sorted out because otherwise you you introduce a lot of trust, yeah. >> We we already have this problem. Um I I don't want to add another two things on top of like wallet servers. I want to replace light wallet servers and think about the incentive structure for running these things, but they should have weaker trust strictly weaker trust um assumptions than what we have right now.

>> Good. Okay. >> Um and preferably um the fact that they have weaker trust assumptions makes it easier to run more of them. >> Yeah, exactly. And and the incentive structure like, you know, if it's >> Exactly. >> cheap enough to run, then you don't even need to worry about it that much. >> Also, we have we have an anonymous cryptocurrency, so it's it's easier to pay um uh for infrastructure with privacy. Um >> Yeah. And just like another question that's related is like is it is the assumption for both those services like the aggregators and the OSS uh one out of and like you just need one or like will that sort of like break

down if you just have one OSS and one aggregator? >> So, my understanding is that for privacy, you're not trusting them at all. It's not a one of them >> Yeah. For for >> For availability, >> just like No, if they go offline, you know, no one can actually transact. >> Um Yeah, so so you just need to find one that does what you want. Or um if they all break down, then I guess you can um submit your transactions directly to the chain because uh um an aggregate of one transaction is valid.

Um >> Yeah, I so the throughput of the chain will go down by a ton if like everyone needs to now sort of like go directly to the chain without aggregator, I guess. >> Yeah, but but that means there's an incentive to run aggregators because the network is not working, then people will pay you to get it working again. So, >> All right. >> Yeah, that's your solution to that problem. >> Yes. I I got two questions. The first is uh easier. What What What does OSS stand for? >> Uh Oblivious Sinking Service. >> Oh, okay. Yeah, makes sense. The second right, so my high-level understanding of the motivation is right right now the nodes, their state includes all nullifiers from all time.

>> Correct. >> And right, we want to reduce that. So, do these OSS nodes, like what they need to store is is smaller? Like, how does that What What How big is I I cuz I I feel like they have to store some version of any nullifier ever used? No, or is that not true? >> No, because um uh so you're using effectively the succinct blockchain idea to prove that your nullifier is not in any It was not spent in any previous epoch.

Um and you can do that with recursive proofs without anyone having to store um uh long-term information that is proportional to the the duration of the blockchain. >> Yeah, but why does it stop? >> You You have to have evolving nullifiers for that to work. Because otherwise you I think >> You You really You really have to store uh two windows of nullifiers. Uh cuz you have to assume that some transaction lands in the mempool and then the nullifier goes out of date and updates.

So, you store uh really two two nullifiers per epoch. Um and and that is sufficient. >> When you say evolving nullifier, what do you mean by that? >> Uh just that the um the nullifier You effectively take take the blockchain, you split it up into epochs and um nullifiers have the ability to um update every epoch over time. So, they're not associated with any commitment. Um they're associated uh with an epoch.

>> And then >> I um And and the commitment. >> [clears throat] >> If a client is offline for an extremely long period of time, like somebody must have the previous epochs to produce the non-inclusion proof. Is is that That's accurate? I I'm not sure if that's what you were asking, Ariel, but like some kind of archival node or something. >> Yeah, so we we don't have like archival nodes now. That is an optional uh That is an optional like workflow, but now the the user who who goes offline for a long time would have to self-update.

And would have to do that linear work to catch up. It would Exactly. Yeah. >> There has to exist an archival node that unless you want the risk of someone not being able to spend their funds, there has to be some archival node >> Yeah. In [clears throat] in current Tachyon's construction, assuming a non-succinct blockchain.

When you get to a Mina style blockchain, uh you you >> [clears throat] >> you don't care about history bloat, you care about like state bloat. So the the incentive is to get rid of all of the past history and not have an archival node, right? >> But but is is that like is there is a scheme for that that with literally no archival node and a privacy-preserving cryptocurrency, I I can spend my I can sure I I'm sure I can spend my node even if I'm updating from scratch?

>> Yeah, so Mina has this, but they're non-privacy preserving. >> Right, so that's what I'm asking. Like I can can see without privacy, but like with privacy that this do we know such a scheme where nobody has to store the nobody has to store the nullifiers from the beginning of time? >> this is not something Tachyon has thought thought of yet. This is an an open question. Um I I don't know of any scheme. >> Sorry, can I ask a sort of a meta question um about the the goal? I mean, the the the session is PQ Tachyon, right? So, when you say PQ

I mean, if you look at the properties that you want, it's uh you know, the the blockchain or the the the currency that you're developing here should be secure in a sense that no one can steal money, no one can create money. That's say one property, and that that's something other chains have as well. And then you have the other property that is uh privacy and anonymity. It could be that one of them is PQ and the other is not. Is there is there some you know, do you prioritize one of them to be PQ earlier? I mean, that sort of whole QR thing raised that.

>> Okay. Um so, in my mind there are two stages and so so there are there are three things that you can achieve, but to me it doesn't make much sense to distinguish between two of them. So, so the first thing you can achieve is that it will be possible at some time um in the future um to post-quantumly recover your notes. That's quantum recoverability. Okay? So, we need to deploy that um kind of we needed to deploy that right now, and we did in any 6.3. So, that's on mainnet.

Um for Ironwood notes. So, if if you have um ultra disrupt ling or um even still disrupt notes or even transparent notes then transparent UTXOs then you need to send them to Ironwood to get that property and you should. Um. But we've got that now. Um, and so the other two things are um Uh, so that there's H and L resistance as now to decrypt later for the node encryption and then there's full PQ which is kind of PQ soundness and also privacy.

And to me because we're talking about long-term keys um, the kind of the I I think the argument that you can get away with just doing H and L now is if you interpret that as meaning you need you only have to deal with encryption now then you're wrong. The the actual distinction is between short-term keys and long-term keys. Right? And then a cryptocurrency your addresses are long-term.

Um, so you need to solve both of there's no point in only solving one of these problems. You need to solve the encryption and the kind of integrity at the same time basically yeah. Um, now that doesn't mean you have to necessarily upgrade everything at the same time. That can be if you know how to do something now and you don't know how to do this other thing now then just do the thing that you um, do things incrementally so that you're not having this big bang upgrade where you um that has a lot more risk.

But it's not that um there's any fundamental reason why you should do one thing first. >> I mean the >> Apart from QR. >> Very naively, I would say that, you know, if if you have a currency and soundness is broken or, you know, someone can create money, then you can forget about that currency, right? You can just throw it away. >> Yes, exactly. >> Whereas if privacy is broken, then it's still a it's still a currency and I I see your point that maybe at that point you will never be able to fix privacy because of you know, looking back into the history and so on, but yeah, I think naively the the soundness of it should be a little

bit more important. >> So So this debate has kind of been obsoleted by the advancements of the CQ C timeline. We just need to do everything now and we can because of the AI and we should because it could be that we get a CQ C CQ C demonstration in 2029 and we need to be prepared for that possibility. >> Yeah, okay. Makes sense. >> Which means we have to design everything right now. >> Yeah, I think I agree, but there is a caveat. For example, on Ethereum, there is a bit of a path dependence of like you have, you know, protocols now that are like not secure and you might as well sort of like, you know, ship an

upgrade to get your like protected against like sort of like H&D attacks and then, you know, like when you get the cryptography ready and sort of like migrate after, like it it does feel like that's the only reason why you would sort of like care for one. >> And that's why we put quantum recoverability in any 6.3 because we we had an upgrade, we knew how to do it. So, yeah, we included it and and we had the specs ready. >> Yeah. >> So, yeah, why not include it? And the same will be true of kind of if we have a So, encryption is harder in Zcash because you need um you need key privacy

and if you're still doing scanning, then you need something like diversified addresses. Um uh so that that's basically um key rerandomization, but you have the same private keys. Your scanning cost is only um uh dependent on the number of incoming viewing keys that you have, not the number of addresses. Um so that's a really useful property of the um the current um discrete log-based um but basically Diffie-Hellman scheme. Um and it is possible to do that. So, um I was discussing this with um Strad recently. Um there's a new um post-quantum um non-interactive key agreement called Mike.

Um it if you search for Mike you print, then you'll find it. Um and it's based on monoid actions. Uh so basically, think of it your scalar space is a monoid, which it is anyway in Diffie-Hellman. Um it's just the monoid is just multiplication in the scalar field. Um so Mike still has that property. Uh it turns out that's almost all you need for diversified addresses. There there's some complexity because um it turns out to be less efficient um because you um uh basically, your base and your scalars and your public keys are in three

different spaces instead of two. Um and it gets more complicated if you have to be able to do diversified addresses at at the same time. But it's only a small constant factor. It's uh I think it's only three times uh between two and three times more expensive to do diversified addresses in Mike. But Mike itself um the base scheme is already um at least 20 times, probably 30 or 40 times um less efficient than, um, just, um, Diffie-Hellman AECHAS.

So um yeah, it's it's not clear that that's deployable. It might be deployable with more optimizations, but we don't know yet. >> Okay. >> How about let- lattices here? >> Um, yeah so um diverse photo addresses might be possible with lattices, but you you can't just use ML-KEM. Um, you basically have to to rejig it to support this and then reanalyze it as though it was a new lattice space encryption scheme. Um, which kind of no one has had time to do yet. But it it's probably possible.

The the problem is the error terms. You you have to redo the error analysis. >> And how does Tachyon deal with the size of the ML-KEM encrypted notes? Uh, >> It doesn't. That's a completely orthogonal um issue. >> But Yeah, yeah, yeah, no, I know, but like if I remember correctly, there is a still a plan to use encrypted notes with Tachyon with ML-KEM. And you have >> The So, the these are orthogonal design questions, really. And Tachyon addresses the um the nullifier scaling issue, addresses, um, kind of the the blockchain size issue, um,

couple of other things, but, um, by itself, it it's kind of independent of how you solve note encryption. >> Is is that accurate? >> Yeah. >> So, the the the high-level way like Tachyon works is you have So, in Orchard, um, the notion of like a payment protocol and the shielded protocol, they're very tightly coupled. So, um, you have key addresses with with uh, uh, you have addresses with very complex key capabilities baked into the address.

Uh, which we which necessitates a tight coupling between the payment and shielded protocol. Tachyon completely decouples the shielded and payment protocol. So, the payment protocol um, the shielded protocol is only for uh, SNARKs and encryption. Um, the payment protocol is a separate design space for um, uh, for addresses uh, and just any kind of payment protocol you'd want to build. Um, initially, if you read like Shawn's old blog posts, uh, we had we wanted to do a kind of like out of payment out of payment uh, uh, >> Out of band?

>> Out of band uh, payment distri- uh, distribution. Uh, now we've gone back to in-band secret distribution, so keeping the uh, the ciphertexts on chain. >> Are you using ML KEM for that? >> Uh, so we will use ML KEM for the memos and the ciphertexts. So, the ciphertexts do balloon. >> Right. >> Cuz you have to embed the the payment keys inside the KEMs that get sent to the receiver. Um, yeah, that that is a tradeoff to to in-band secret distribution. If you want to recover from seed, that is a cost you have you you pay.

>> But, if I remember correctly, you also have a I don't know. I read it, so I'm not sure. I That's why I wanted to ask, but like if I remember correctly, you have a sort of like hybrid design where you can you can still do your out of band sort of like um, private communication or use ML KEM for like, you know, public addresses where you need like donations or ML KEMs or everything. >> It depends on the wallet. You you can build any kind of payment protocol you want. The the shielded the core shielded protocol of Tachyon is quite simple. It's just just uh, yeah, it it doesn't have anything to do with the actual address itself, right?

You prove you own uh notes and commitments, but nothing else. >> So, this is an advantage of Mike. Um it's uh both its public keys and its cipher texts are short. Um so, short as in um I think about uh 192 bytes or something like that. Um I think [clears throat] that's right. So, the the scheme that the port uh supports stealth addresses, they might be a bit longer, but um I'm not sure about that. Um Oh, I should I should say that that scheme the most practical variant of it um has a Um so, the Grover's algorithm

um because if you can do inversion, then um uh you can link addresses, but that might be okay because you can still get, you know, 100 bits of security for for linking addresses, and So, do you actually care about that because um it it's kind of a a nice to have that you can give out different addresses to different counterparties, and they can't link it, but if if they can link it with uh cost 2 to the 100, then they're not going to do that. Um So, that that might be a practical trade-off. Um And it it's still post-quantum um

because Grover's algorithm probably near-term CRQC's are not going to be able to run it. They'll be be able to run Shore, but not Grover. Um So, yeah. And that gives us time and space to think of something else that is um kind of more efficient or more secure. So, oh, I but but the base security of Mike uh is fully post-quantum. >> Thanks. So, just so I understand, so the Mike scheme so it so the the public keys and secret keys are short. Um is the trade-off that um so I know it's not a signature scheme, it's like a secret sharing scheme, right? But is there

>> It's a Mike um non-interactive key agreement. >> Yeah. Um so what's the like normally for post-quantum schemes like there's there's there's something something which is very large um and what is that thing for Mike? >> Well, it's isogeny-based. So, it's isogeny-based. So, no, there is not anything large. Well, um your descriptions of um elliptic curves are short because they're just the parameters. They're they're just the A um parameter of a I think it's short Weierstrass they use.

Could be Montgomery. >> So, is there any kind of trade-off like what is is it it sounds like it's like a probably just a pretty good drop-in replacement for any kind of key exchange? >> the reason it's not a drop-in replacement is that 30 times less efficient. Uh and we it's already a bottleneck to do scanning. >> Oh. Gotcha. Okay. >> Yeah. >> If if if it's just like a it's just the A parameter of uh so like all curves are >> I I was over simplifying.

>> But we Well, yeah, I'm just trying to understand right in regular Diffie-Hellman it's like it can be like 32 by or 64 bytes if you store Y explicitly and and here you said it's 192 bytes. So, I was just curious. >> you need larger curves. >> Oh, it's just you need just for the security of >> Yeah, you you need the curves to be about twice as large if I remember correctly. You read the paper. >> What about naively just um like you you have a large post-quantum key. You store this in a PIR database and you do a simple PIR query and the thing you store on chain is just a hash or the thing locally that you store is a hash.

But you just PIR query anything that's big in the post-quantum setting. So it's a if it's a post-quantum key or like a large post-quantum ciphertext, you store all of that in like massive PIR databases. >> Yeah, that works. Um someone has to run that PIR server. So we we go back to the infrastructure um issue, but it's it's I think it's more expensive in infrastructure. >> Yeah. >> I I think Zcash has to maximally lean on infrastructure. I mean, we already have um uh what we'll have an OSS and we'll have an aggregator and we'll have tons of PIR databases for many things. Voting, for example, uses PIR. We just need to lean

on infrastructure. I I think there's no way to to scale Tachyon with to scale Zcash without infra. >> I mean yeah. Sure, but it's a trade-off. It's It's like a a choice you make, right? It's not um like you can either like lean on infrastructure and go for max efficiency and max scale or sort of like fall a bit back on the infra and get more trustless systems. Like it's it's not like a one I think I did I I do think it's a trade-off like every chain needs to make, I guess, but like it's I don't think it's like that straight forward that we can just like lean into having this sort of like very trusted uh intermediaries if they if they are. Like

they don't need to be, but >> It's trusted for availability. I I I would be completely opposed to having more or heavier infrastructure that's trusted for privacy. I don't like light wallet the what light wallet protocol at all. >> Yeah. >> I I think we should get rid of it. Um and so I I don't want Tachyon to introduce anything um like that um because if we introduce a new thing like that then it'll be so much harder to get rid of it. Um Yeah, but um having infrastructure that's trusted for availability um it seems fine to me.

>> Yeah, it really depends on the property that I think. Like for example, if you have like a one out of n >> and you just need one to run and it's cheap to run then it's fine. But like, you know, if it's very expensive to run and you need like majority or whatever like then it's very different. >> If you need a bigger bigger organization to run it, um if you need a data center to run it then no, don't do that. >> Um could could someone give a TLDR of what ML Kem is? >> Uh it's a uh standardized post-quantum um encryption scheme.

Uh lattice space. It it's basically So if you know um New Hope, it it's basically a refinement to a standardization of New Hope. >> What uh what all Intel CPUs will use in 2030? Uh assuming assuming Intel transitions to ML Kem by 2030. >> So it's like So it's public encryption, it's just an encryption scheme. >> key exchange >> It it's No, it's so it's a key encapsulation mechanism or an encryption uh scheme based on a key encapsulation mechanism which all of the other um NIST encryption candidates were. Uh Mike is not, so um Mike is something

else. We thought that we needed Kems for um uh post-quantum encryption, turns out we don't. Um well, I I guess like psych was not um uh Kem-based, but that got broken. >> What does Mike stand for? >> I think it's module uh and the module isogeny key exchange. Um so it's based on module actions, um which is why it's called that. Um but yeah, I I ML-KEM is the just no one ever got fired by choosing from using ML-KEM um encryption scheme these days.

>> I [clears throat] have a niche question on the threat model between the OSS and the aggregator. Um so every time a wallet uh has to end off the transaction to the OSS and there is a re-randomization each time? That's is that uh enough to prevent like collision and being able to link the notes if you're the OSS or is there like a mixnet design also? Or like how is the re-randomization >> Uh that was something I was a little bit unclear about. Um it's it's quite complicated and Tal, do you know the answer?

>> Um so we we we don't have like a ZK-SNARK like a like a BCLMS 21 style uh protocol. We have um we have what we have an unblinded SNARK that then you have to blind via re-randomization pass. So you can fold it with like a random instance. Uh well, you can fold it with a proof with a random witness um to to achieve ZK. The open question now, which we haven't finished, is how many times do you have to re-randomize to fully blind the proof.

Um so so the question is one may be enough, one re-randomization pass, but one also may not be enough and you'd have to do potentially two. Okay. So it's either one or two, but we still have not done the the statistical analysis to find out if one pass is sufficiently blinding. Um and if and if it's not, then you have this linkability problem between um dog aggregator and the OSS. Um and and any other party who who who consumes the proof. >> Okay. That would be super cool if you were just >> solve that by doing two randomizations all the time.

For for those particular proofs. >> Yes, but if it's not necessary, then you don't you don't have to do an extra recursion step, right? Um This is an analysis we want to do soon. We just like we're finishing the protocol uh now. And the next step is that kind of analysis, but I don't know the concrete pa- number of passes yet. >> That's will be super valuable for privacy protocol on Ethereum that are using like uh proof of innocence system and like people that are um like I found the system to be very weak because we don't have such mechanism.

>> But but I think that analysis is um quite specific to Regu. >> Yeah. >> Um yeah, it would be completely different for um for a hash-based uh code-based scheme. Um so I I originally took your question to be more about the um kind of the security model and do you need a mixnet? Um what are assumptions you're making about um what network metadata is available to an adversary? Um I I don't know the answer to that. Do you know?

>> Uh Not well. >> So I I think in principle um the information that you're sending back and forth to the OSS um a a passive adversary can't find anything from that. And I think even that active adversary um Yeah. So you would authenticate the OSS that you've chosen to use, right? Yeah, so any any trust assumptions um um kind of uh only apply to the the one that you've chosen to use.

>> Yeah, you you would have like a public idea of the OSS that you're communicating with, but the thing you're passing back and forth are just blinded PCD proofs and tachygrams, which are PRF signing outputs. Um that is the that's the only communication data between them. So it there's no privacy leak. Um >> Yeah, everything's randomized. >> Everything's randomized, but you do know the the OSS that you're communicating with. Um Threat models and uh incentive mechanisms for running the OSS have have been open questions uh that we don't have good answers for. I think Zuko gave a good idea of using the uh

um uh uh You had a interesting idea to use um the TEEs Not TEEs. Uh Ooh. >> Mixnets. >> Uh not Mixnets. Uh to use shielded labs uh approach. Uh some kind of like staking layer to >> Oh, cross-linking for incentivization. Yeah, that's that's totally unsolved problem future work. But I did want to talk about TEEs and Mixnets just that uh we had light wallet D as core part of Zcash infrastructure all along and we were relying on the um shielding of the balances and other

stuff all along to to to provide the user's privacy. Um but now we have to cross turnstiles more often cuz there's more and more pools and more and more turnstiles. Therefore, you can't rely on hiding the balance. Wait, let me have a turn. >> Is this like a Penumbra style balance hiding for staking? Like you >> No, just shielded transactions meant that you didn't reveal your balance all these years. Right? Like the the the the way to protect your privacy is keep your Zcash in a shielded pool.

That's basically all you need. >> Which you should do anyway for for quantum recovery voting. >> Yeah. But with the Orchard to Ironwood migration, now you're revealing your balance, basically, more or less, probably. >> I Not if you >> [clears throat] >> hey. How many So, give me a turn. Where was I? Uh I'll I'll try to I'll try to make it quick. All right. So, anyways, with the Orchard Ironwood migration, it revealed it really drove home this thing that we've been a little remiss all this time. Like, oh, the fact that the user reveals their IP address to a light

wallet D, well, that's not good, but it's not the end of the world. But, if you start revealing your balance or some information related to your balance, now maybe it is the end of the world. Like, Zcash just had one job, which is don't reveal your wealth level and your home address. And this may have caused it to fail at its one job. So, over at Shielded Labs, for the ever since the Ironwood's beginning of Ironwood, we've been thinking a whole lot more about light wallet D's, and now we have TEEs, boo, and um but it turns out TEEs are good, actually. So, many people, including me, for the first time in our lives, during this emergency where users are revealing their home address to these random

servers on the internet, and then we're like oh actually if that random server would run a TEE, then he'd be able to prove to the user that he's not looking at the user's home address. This is actually useful and a real upgrade. So, we're working on that and we're also working on mixnets and Tor and the That's a funny facial expression. I wonder what you're thinking. Uh okay, final So, the point is maybe if things continue in this vein, then by the time we deploy OSSs, you can rely on some kind of protection of the users like IP address from the OSS. The end. That was a really long

story for a simple thing, but there you go. >> Yeah, we we we did talk about the OSSs and having some kind of uh some Nym Tor uh integration. >> So, what is that? So, as it affects this discussion, it's really just a question of shall you require that the OSS can't see your users' IP address? >> Right. >> And I'd say, yes, just require that. >> [laughter] >> Please. >> So, just run it in a TEE. >> You just would or or over mixnet or ideally both, which is what we're currently pushing for light wallet TEEs over at Shielded Labs. But basically, from the cryptographer's level, I'd like the cryptographers to say to the like infrastructure operators, "Dear

infrastructure operators, you are required to prevent the users' home address from being exposed to the server and then you can use our cryptography." >> I agree. Um and that's why you shouldn't use TEEs um because TEEs make that choice essentially a choice of the infrastructure operator. It's hard to enforce. Um also, you're trusting Intel Intel, which means or AMD, which means that you're trusting the US government because the US government can can coerce those two companies. So, um why would you want to trust the US government? That's that's defeating the whole point of using Zcash.

Um >> Well, if you do it in the open >> Also, that's the problem for the infrastructure operator, not for the cryptographer. >> No, it's your problem. Uh and it's our problem as cryptographers. >> The shoulder labs is our problem, yes, but it's not a problem for the cryptography of Tachyon. >> Um I mean it it might interact with the cryptography of Tachyon because Tachyon is deciding what the OSS protocol is. Um I guess you can treat that protocol as independent of the metadata hiding when you're talking to the OSS.

But it's it's beside the point because you want metadata hiding for everything anyway. Um the reason we didn't have it is just that it was hard to integrate Tor or or Nym um or I mix that. Um uh and we we have libraries for that now. Um Zcash Foundation um uh kind of funded a a re-implementation of Tor in um Rust. I I'm The names are escaping me. >> Tority, A R T. >> Arti, yes, exactly. Uh so we can just use that now. Um and it's fine and we should use it for So there's a question when you're using Tor as um what you should put in each circuit, but um yeah, that's solvable.

Um just a policy decision that you need to get right. Um So what I'm saying is you don't need TEEs, don't trust TEEs, don't get false assurance from TEEs. TEEs get broken anyway every 6 months, so uh >> [laughter] >> But but as it applies to this interface, the important thing >> But I think I I I could be misunderstanding something, but I think the important thing is cryptographers need to know that they do not have to worry about the OSS seeing the user's IP address.

That's important and like you need to know that. >> transport layer. That's a different thing. >> But it just feels like what you're trying to solve is like privacy and the sort of like end end-to-end flow, right? So, it it's it seems a bit weird for me to sort of like isolate the components of like uh you don't have to worry about this because in the end like if there is any leak anywhere in the sort of like user flow, you need to address it for the whole Zcash experience, I guess, to be whole.

So, I I yeah. >> Agree. Agree. We We As protocol designers, we have multiple hats on because we're also um kind of uh working for companies that are providing some of this infrastructure. Um so, we we can't just um treat them as um completely orthogonal problems. Um but we need kind of some abstraction boundaries when we're designing the protocol, and I think that's what um kind of Duca is probably referring to just just to make the um analysis problem tractable.

You don't want everything to interact with everything else. >> So, I I agree with >> But but I agree with what you say. I I think I think it was a a failure. I think it's Frankly, it's the biggest failure of Zcash ever. >> Yes. >> Um yeah, it's it's really the only time Zcash has failed at its one job, and it was because of this that we had allowed the this other part um to to go unstrengthened uh until it was an emergency. We didn't have time to strengthen it before the other part gave way. But anyways, we won't do that again. >> There There are four There are four times that um Zcash has failed at its job. That is one of them.

Um the BC2V the BC2V-14 [clears throat] vulnerability um and sprout is another one. >> [laughter] >> Um the orchard circuit vulnerability is the third. Um and the last one is um the GPU to um ASIC mining um transition [laughter] which I which is a failure because um Strud and I got the parameters wrong for Equihash. Um we didn't read the paper properly.

>> Okay. >> What about sandblasting? >> I think on the on the >> 5 >> So on the meta point, I think I I mean at least at the EF we are almost going back to a more integrated approach because of this the first video of like like we we we I mean I'm I'm also working on the protocol protocol side of things, but like when it comes to privacy, it feels like it's almost inevitable that we you will have to integrate things at least some somehow cuz yeah, I I I don't feel like there is any other way to sort of like make sure you plug all the holes.

>> I really agree, but also you triggered me by saying integrated. Like at the same time there's this yeah, like um I really feel like someone us whoever's designing a thing should take responsibility for the end to end privacy. Security and privacy are both something that you can't encapsulate, especially privacy actually. You you know, like it you cannot have an abstraction layer or a component that provides it. Uh it's systemic only.

Um but at the same time compartmentalization and scope limitation is really crucial for getting anything done. >> No, first of all, yeah. >> I agree. >> So there's this great feature we have right now, I think in both the currency cash with the light wallet D's and in Tachyon with the OSS's where the protocol between the OSS and the light wallet client can be independent from the shielded protocol between the OSS's and each other and whatever the other nodes are. Yeah. >> That makes sense.

>> Nice. Uh so uh You always have to stop when it starts getting interesting. That's We are already 4 minutes over. Maybe last word from you and then I would propose to continue offline. >> I was going to open another rabbit hole. >> Okay. >> [laughter] >> Yeah, let's do that. during lunch. >> Um Yeah, go go go. >> I've said this a few times. I think the light wallet D problem is more important than Tackyon for to solve in the immediate term.

But no one agrees. >> I agree. What is the problem with D L R? What is the problem we solve? >> The The problem is that if the light wallet server knows your IP address, then they get a lot of information. I mean you're So, basic So, there's that and there's also the fact that you're trusting the um light wallet server to um give you an accurate view of the blockchain. So, they can really seriously mislead you if that's not the case.

Uh and that being able to mislead their clients is a privacy problem. Um because then they can observe Okay, um a user is complaining about um uh the connection not working in this particular way. Oh, right. Now I know the IP address. Now they know Now I know some information about their transactions. Oh, I can link this with other stuff. Um yeah, it's it's almost a complete break. >> Good points to make a break here.

>> We We have underestimated um error reports as a uh metadata leakage channel. >> Mhm. >> Thank you, Ulrich. >> Thank you. >> Thanks. >> Woo!