sig.golf

Transcript

So, this is going to be a workshop where you can interrupt me anytime. I'm just going to give a quick presentation and then we can have fun on the challenges. Uh so, I'm Nico. I'm part of the strategy team at the Ethereum Foundation and I also uh helped to do some sig.golf and Lean Sphinx work. Uh so, as Justin said yesterday at dinner, we had a secret internal challenge uh before sig.golf, which was ots.golf, where uh we tried to do um to optimize the one-time signatures.

Uh and we found some very cool results. Uh the goal for us was to optimize uh Lean ISA cycles. So, Lean ISA is our um custom ISA for Lean Ethereum. And we also tried uh to improve uh RISC-V. And so, doing this we learned a lot around like how the I personally learned a lot on the auto research format and how you can perform uh very well inside the auto research competition.

And there are a few tricks um and a few skills that we can discuss together to understand how to better um participate in these auto research challenges. So, for Oh. Okay. No worries. So, this one is just a visualization of the current uh sig.golf uh hi- hyper tree, but I think this is not going to work, so let's skip it.

Ah. Let's see if I can see. No, it's going to No. No worries. Okay, so the auto research format we have it on Yukon. You have a bunch of challenges and basically you have two main strategies when you play these challenges. Either you stay with the group and this is the very similar to a collaborative PvP game. So you have a team and you you're trying to win but you also collaborate with with others and it's somewhat similar to cycling. I don't know if there is any cycling person in the room but you probably know what

Look let's You probably know that there is a peloton which is the group of riders that are going to be fast and to be efficient because they benefit from the fact that they're with the group. So they have better air penetration and in the Sig the golf challenge or in the auto research challenge it allows you to make small improvements and to go very fast. So your AI agents can just do a lot of workflows and parallelize and basically what you're doing is that you're spotting the next submission and you're just trying to get a small gain on top.

So this is nice. This is an easy way to get points, let's say, but it's not the best way to drive the competition because when you do this you're basically just building on top of the of the previous submission and so you only go in one direction. So earlier today Justin mentioned that we could have uh when the other [clears throat] side of the Pareto frontier and because I decided to do a little bit uh of a jump we went on the other side of the Pareto frontier. So the other strategy is basically to be uh uh the loneliest copy. So,

in cycling, you have these guys that are trying to attack and to take uh enough of a margin to not get uh caught up by the by the peloton. And it in the AutoResearch challenge, it's a bit of the same because you're going to work on a big gap with a different uh proof, a different strategy, a different structure, and you're going to make the bet that your agent, your AI, is going to finish the proof before the rest of the group catches up. And if you're getting um caught up by the peloton, you basically lost everything.

Because you didn't submit anything, and they're now ahead of you, so basically all your tokens are gone. And well, you should submit because you can find uh cool results, but then it's a bit of a uh you you lost your your attack, basically. >> So, so this assumes that you're going towards the same optimization. >> Yes. >> Because otherwise, you will see the peloton progress on a different optimization, which you can integrate into yours. >> Yes, the analogy is >> [laughter] >> only as good as it as it could be. But uh yeah, so exactly, that's that's also like you have different branches. You need to see this as a if you're taking a a different path. It's not exactly like everyone is

playing the same race, and you have the same uh road basically but >> So, the the reason I say this is because typically, if you're going for a bigger jump, you're likely not going for the same path as the peloton, which is micro-optimizing on the existing thing. >> Exactly. But for the analogy of like the race, you need to be Yeah, just for the performance and the score, this is exactly what's what's happening. Uh so, like during C dot golf, I had a few designs uh that were caught up by the competitions, but I had some big jumps uh that allowed me to get this uh big result.

And we had also uh Jonas Nick from Blockstream who did I guess the same who went uh on the loan is Kathy bass. And so this allowed us to have this uh very cool progress in a short time. And so it's it's just very fun to play that game because you can you know you can have different strategy, you can make your bets on uh on different structure, you can uh see if it work and with lean it's like you never know if you're going to manage to prove the thing.

So it's uh it's sometime a bit stressful because you're like oh I'm this close this was very close to get in but then your agent is like not able to prove it in time or or it gives you an impossibility result at some point and you're like ah I lost. So it's very funny and so if you didn't do it yet uh if you didn't participate in an auto research challenge, you definitely should. Um and so in Sig the Golf League we had a lot of participant and we ended up with like two experts somewhat expert. I'm not really an expert but I did work on things a lot and Jonas is definitely a top expert. So it's not exactly a surprise and I think uh

Alex mentioned this uh earlier yesterday. Um in the auto competition set challenge very often you will see people that you were expecting to see uh in the leaderboard make some progress. So then the question is what is the edge? And in this uh in this case uh for me in Sig the Golf the edge was just history. So I guess all of you had a math uh degree or most of you had a math courses and so you had probably this very boring class that is history of mathematics.

It's actually not really mathematics but I just liked it a lot. So, me personally, I love this class and so I was able to just pull a lot of um math history in the in the challenge and to make some weird links. So, for example, you do um go back in time and you're like, "Okay, what if you were uh Andre Weil and you met uh Bernstein and and and you kind of mix uh the the the papers and you're like, "Can you find a link? Can you find something that uh Andre Weil could have found at the time?"

And it finds very interesting stuff. Um very very interesting uh combination of ideas. Um but it's not only this because like everyone had uh a lot of people had a history of mathematics and and the content is also quite available uh online, so you can just have agents to to do this research before starting your your submission and stuff. Uh so, it's a combination of of different things, uh AI skills, uh some some expertise, but also I think a very important thing if you want to like play this uh auto research at the max is to be a tryhard. And so, being a tryhard in the in the gaming world is just being

someone that tries very hard and that just plays a lot. It's not about like being good, it's just about being very intense and just trying trying trying trying. Um so, some people take it as a negative thing in the gaming space. Like, being a tryhard is not always a good thing, but uh I do believe that the world is actually being moved by people trying very hard. So, in auto research is definitely a very good thing to be a tryhard. And it's not super fun. It's not like, "Oh, I'm having fun trying hard." No, no. It's like you wake up in the morning, you look a screen, and you do it again and again, and you sleep very late at night. So, it's it's not

always fun doing it, but the entire experience of the trying hard the challenge is very very cool and very fulfilling in the end. You you learn a lot more when you do this. So, sometime when you try like very hard in this other research challenge, you can find like cool weird ideas, weird optimizations. So, this is the last one, and it's kind of a free bit saving by doing um less hash call to generate the seeds of the of the chains.

So, instead of doing a hash query for each pair, you're going to do uh less queries, and then you're going to use them uh as the polynomial to generate the seed, and so this reduces the number of hashes that you need to do. And because the competition is only counting the hashes, uh it becomes a free gain, but it also yeah, it matches the the reality, and it's it's secure. Um I was not sure it was secure, but Emil who's not there told me it was secure, so I believe Emil and Claude, uh they are my sources of trust, so this way you can you can find very cool

optimizations. Um Jonas found a a very cool trick that was basically reversing the watts and the force. So, in Sphinx, you have the watts that authenticate the force, and you have the forces the force at the bottom. And he had the idea to put the watts chain at the bottom of the force, and it's not very intuitive. We were discussing this uh few minutes earlier. It's not very intuitive when you think about it. You're like, "Ah, it's going to be just bigger." And well, before AI, it would have taken quite a long time to do this.

And yeah, why would you spend months trying this weird construction that is not very intuitive just to end up, you know, finding that it's not good. But with AI, we can now do all this pretty exotic stuff. And with hash, hash is a structure, it's pretty safe. Like because you're just doing hashes and mixing the the different techniques, you're still in a design space that is quite well known and that is quite secure. I think if we were doing the same stuff with lattices, it would be much more challenging to to be in the safe space. Yeah.

>> I thought about that earlier in the history of Sphinx and couldn't get it to be more efficient. I'm glad I'm glad that someone has thought about that again. >> [laughter] >> See? Well, so this is about it for the presentation and what we wanted to do is to idea together both on the next version of sing.gol like sing.gol V2. And also we just launched a specific challenge. We can do both the real sing.gol and we just launched a a small internal one, sphinx.gol, which

takes some hardware requirements. So, we have two new tracks which are dedicated for constraint hardware and regular hardware. And in sing.gol V2, we would also like to have the MPC angle inside the challenge. So, yeah, now we can just try to submit some um answers on on things.golf. Uh it's from a very easy baseline. So, the reason we did this is because if we try things.golf right now, we're not going to find anything in the next hour.

>> [laughter] >> And it's going to be quite quite hard. But, we can also try the real things.golf, but we can also try this things.golf where we will go faster and just move the the frontier. Yeah. >> Uh just an idea An idea for things.golf V2. Um So, I I I don't know exactly what you check in the um V1. But, um what we need is for for Zcash is for it to be um efficient to check a signature in R1CS.

Um so, as well as having a a cycle count as part of the score, you could have um an R1CS constraint as part of the um score optionally because obviously some submissions aren't optimized for that. >> So, one question here is um how do you deal with the the hashes? Are the hashes part of the R1CS? Cuz usually, you know, when you have lots of repeated computation, you want to take that out so that that as an optimization, so you have a batch. >> Um so, you would have to make an assumption about the >> Needs to be >> Okay. Um you would have to make an assumption about the um the cost of a

hash. Um which hopefully should be grounded in the actual cost of Blake3 or um I don't know what But, >> So, this is what we do. >> same as Blake3 is is a fairly good assumption. >> Yeah, so this is what we do with RISC-V. We assume that um one hash is eight cycles. And um and so you're saying we just assume that the hash is the K constraints in RNCS. >> Yeah, that's what I would suggest. I mean obviously it's an approximation and so if someone finds a faster way to do like three then that might throw things off slightly but it's going to be approximately correct and so

that's fine for a competition like this I think. >> Mhm. >> Yeah, so initially we wanted to keep the design space quite large but then we can go more into detail after like we can have probably multi-dimensional ranking type of situation where we have like um different filters so we could have like a rank where you have this Well, this one is a little bit complicated I think because it's going to specialize the challenge a lot.

>> Well, you can have a kind of a preeto surface where um uh you consider the um So if you have um n dimensions then the surface is n minus one. I I forgot um how to do preeto surfaces but um it's certainly possible. >> Mhm. >> Yeah. I I think we want um I think it would be good to keep as many ecosystem as possible. But for the challenge so definitely want to accommodate for both I guess the Zcash and the Bitcoin constraints even even though we all have slightly

uh different objectives different goals. Uh yeah, we can probably find some way to have a multi-dimensional ranking that covers most of the Yeah. >> Yeah, I mean the the leading candidate in my mind um how Zcash will do hardware signatures is just do the same thing as Ethereum. >> Okay. That's good. If we Good taste.

If we can have the same with Bitcoin. >> Um when do you know when to end a challenge? Cuz you you just said like hey, maybe let's not do sig.dot.golf right now cuz it's kind of hard, but I tried it. >> Yeah, you did. >> And I spammed the leaderboard by in just like not knowing anything. >> Yeah, yeah. >> Uh and I feel like it's a good prompt in a way cuz like when when when do we stop basically? Like >> Yeah, you're the leader right now.

>> [laughter] >> I'm doing pretty good, I guess, but like >> you're doing very good, actually. >> But also like yeah, when do you know when to stop the challenge? Like when when when does that actually because as long as like people that don't know much can just like get better results, it's hard to determine a stopping point. >> It's going up forever. >> So I I can speak to that. So if it's a challenge that you if it keeps going on forever, and it would be good to keep exploring, we just plan to have that be perpetual. >> Okay.

>> Um if it's something that maybe needs to reach a specific objective, then that's a time-bounded thing. Um so like snark.dot.fast is not currently up anymore. Um but ECDSA fail, that's just going to go on forever. >> Okay. >> Yeah. >> Yeah. >> It's It's a bit tough because it feels like it's also almost a in function of compute plus new models coming in and like you could like sort of like hope for the best for Ethereum, for example, where you just like want to get the most optimal version, and you don't exactly know what's the lower bound.

Or like what's the whatever what the the the the ultimate thing it's hard. >> We discussed this initially we thought a few months. We are obviously time constrained because we cannot just run it forever. So I guess few more months. I think it's going to be just in scope but >> I mean we we have a deadline right so which is that we need to freeze the designs relatively soon let's say in 12 months.

And one thing we want to do we know is a V2 at some point so I don't maybe V2 in January or something. One thing that was surprising to me is is how so ECDSA dot fail is literally the the OG auto research program and it's been running for for very long time and we still squeeze every day in now like very very significant amounts. So I'm kind of hoping that the same thing happens with with secp256k1 but it will see it's it's too early to tell.

>> Yay. >> Good. There's there's definitely definitely the question of like new models like if you if you cut your challenge right before the release of like a new frontier models that can be a little bit annoying because like the next week you see that someone smashes the competition and you're like yeah just cut a little bit too early but yeah. >> Yes. Yeah. So I don't think we have exactly 12 months if we want to stabilize this in 12 months. I'd say probably three to six months of this but and then we probably need to start looking at just stabilizing this and then building on top of it because it's not just a signature scheme that we need

for shipping this like there's a bunch of other stuff like how does networking work? Um, how do we aggregate this? So, I definitely say we want to freeze this well before 12 months. >> Yeah, Kev, the acceleration is love it. Um, >> [laughter] >> but like one good outcome might be that, you know, we we we pick a snapshot in 6 months and then between T plus 6 months and T plus 12 months it's net improvements. And along the way, you know, everything's formally verified and so we could, you know, just increment things with the knowledge improve things with the knowledge that

nothing will break or degrade in the networking layer for example because the the messages will be smaller, they'll be faster to verify and aggregate. >> Yeah, I think some people view formal verification in that we look at the optimizations that we get from this and then we apply selectively the ones that make sense and the ones that we can understand. And some people think that, you know, once you have a spec, you if you have an optimization is an optimization.

I think it really depends on what strategy we decide to take. If it's the first one, then this is going to take a lot more time. If it's the latter, then we can just look it's formally verified. >> Just pick just yeah, just pull it out. >> So, what's the former that you read the proof and understand the proof? >> Yeah, if you just fully trust the formal verification, you can just say this thing is secure as long as the specs are correct. But if you're sort of being selective about what optimizations you pull in because you want to understand things, there's going to be some lead time.

>> Yeah, agreed. Yeah. Mhm. >> Yeah, personally I would like at least one person to fully understand everything. >> [snorts] >> I honestly I would say for Sphinx base signatures it's kind of easy to it's a bit of math bit of formulas to convince yourself that you should be close to 127 or 28 bits of security. Um at least I mean it's not a proof but like you I think like a block stream has this python script to estimate the security. It's not exactly the the the security you're getting in the room but the formulas make sense. And so yeah you you can be it's not like a very complex snack where

it's you don't understand anything. It I would say it makes sense. >> Right. >> So quantitatively like how many days would it take from a new optimization [snorts] to you being convinced that it's secure? Or how many hours? >> [laughter] >> I think it really depends on the optimization. Well the arithmetic seed chain for example I think quite fast like it didn't take you very long to be confident that it was safe.

>> I I didn't do the math but I think that if someone take the time to to do the math you should end up on like do the average of each opening set that collision blah blah blah and it often it it makes sense. >> So we need some time who has a lot of someone who has a lot of time to do the math. >> Right. >> I mean it just depends [laughter] on your it just depends on your strategy, right? >> Yeah. >> So what which strategy would you advocate for Kev?

>> Uh I mean personally I think the former makes sense until we have high enough confidence that the formal verification pipeline is secure. >> Mhm. >> Um because if something breaks and it's because maybe it just fell through the TCB then you're kind of you're [snorts] kind of cooked, right? >> So, who here is worried about the lean formal kernel? >> Um probably not the kernel, I guess. >> Not the kernel, okay. >> Just also I think I I I would say for this type of signatures, I think the the authors like like cryptographers could do pen and paper proofs in the standard model and Benedict and go to I don't know 123 bits

of proof security in the standard model, I assume. So, yeah. >> Uh uh Any lean proof is equivalent to a pen and paper proof. You could just ask the the AI AI to give you a equivalent proof. >> the standard model, uh not in the home. Like >> Sorry, I didn't hear. >> So, first of all, I think if you say designs like Sphinx, how do you know that the thing that is submitted there is a design like Sphinx? I mean, if it's close to Sphinx, yes, I agree that it's not that hard, but I like just from the experience for example from formalizing

the security of this Sphinx Sphinx G that we have heard about, it's like a small deviation from Sphinx, but it is actually a quite a significant change in the analysis. And uh I would personally say it we should have a few people who understand why this thing is secure, and these few people should not be AIs, and these should not be the the lean kernel, right? It's uh I think we we should have that, so I would plan for a little bit of time uh between picking the the winner of the challenge and actually deciding that this is what we will use uh for us to understand

on different levels of detail uh why it is secure. Like you can understand uh in at a very high level then someone else can understand it maybe a bit better and someone can actually do a proof or modularize the lean proof or whatever. Like I think we should spend time on understanding it and not just fix a spec and be happy with it. >> Um any signature scheme that is just based on the graph of hashes and that there was like I think um I think 90s or maybe even 80s paper um that considered the general case of signature schemes based on graphs of hashes. Um to me that's fine. That's a Sphinx like

Sphinx is in that category. Um and as long as it has a security proof um and it only depends on hash security, then why shouldn't we accept that? >> I think if you care about concrete parameters, this is a different story. I mean yes, that works, but then you need I mean if you look at textbook Winternitz, for example, that's not what what we will be using because we don't want to rely on collision resistance. So it's like I think we should at least understand these details and uh yes, you be can be convinced, let's say at uh level one quite easily that it's sort of asymptotically secure, but if you want to say that this security actually

matches something that is at least close to what the AI has proven in Lean. I think that takes more time than just saying, you know, there's a paper that does it because most of the time the paper that does it does something slightly different. >> Well, the the security goal that you've set um for bits of security um that kind of um implies that you're not relying on collision resistance because you would have a Q squared term if you were. >> I think that is fine. You you can I can probably submit hash functions with double the size and it will probably >> Well, that's fine then because collision resistance is is secure in the the ROM for those hashes.

>> Yeah, but this is also for example the avoidance of collision resistance is not only because of the size limitations, but also was the design choice because the collision resistance from the history is the first property to fail. >> I know. That's that's why Sphinx doesn't rely on collision >> And so this also another argument when we want to look at what properties we actually have when we do the standard model reduction.

>> Okay, but but if that's your requirement then you shouldn't use this kind of collision resistance. >> stuff is mainly to allow outer research and this is what Benedict's also proposes. This is good to boost the research, but at the end we need to double check. Instead of constantly double checking, we have most likely the final result will be satisfiable, but we just double check at the end. >> I mean I still think that if you were relying on collision resistance with a double length hash, you would end up with an advantage which is Q squared divided by the the two to the hash size.

>> The requirement is for every adversary that makes at most Q queries, the advantage is at most Q divided by something. If you have a bound that says Q squared divided by two to the two lambda, then that's still fine because you just do a case distinction. My adversary makes more than two to the 128 queries, then it's anyway not considered. If it makes less than you can upper bound one of the two Qs in Q squared by two to the 128. So, that's essentially the same thing. >> I just want to add one thing like in my opinion we should speed up a bit the version two. I mean if you were before I heard the word January version two, in my opinion I will make the version two a bit before

than January. Just if we really want to go on this 6-month time frame January might be too late. Maybe we can have some lesson learned from version one and iterate faster on this versions. Just saying. >> The main thing I want to avoid is the version three. I am hoping that we can all align as a community Bitcoiners Zcashers and that just in some in some sense we're bottlenecked by humans just coming to consensus. >> We're we're also bottlenecked by hardware wallet manufacturers. If we actually want to get this algorithm into hardware wallets, they have a huge latency.

>> Yeah. Yeah, hardware wallets are improving too. Uh I would not be surprised if we get some new hardware wallet announcement pretty soon. So, yeah, it's it's it's going to improve and in my opinion we should not bend the protocol for like very old devices. We can find solutions for these very old devices to to to to migrate. But like bending a signature scheme that is going to be used for centuries for a device that was made in 2010 doesn't seem like the best path in my opinion.

>> But 2015 maybe. >> Yeah. >> How easy would it be to require 127 bits in the ROM and let's say 110 bits with reductions and just have the AI do this post-processing work that we would be doing? >> Hm. >> I mean the problem is when you go to something with reductions, how does your verification of the auto research challenge look like because you can either I think Mike said that before you can either fix a set of assumptions like properties that >> We fix.

>> That's something you can do. Then you limit the amount of freedom. I think if you had done that before the design of Sphinx, the properties that I used in Sphinx, you would have not listed them. They are They are sort of There's this ITSR property for example is like very specific to how the few time signature works in Sphinx. And if you don't fix the list of acceptable assumptions, then the AI will just make up the assumption that the scheme is secure. So >> Maybe we could do something like hash smash where the the AI like suggests assumptions and the human say okay, this is reasonable is not reasonable.

>> Yeah, that sounds like a lot of human effort. >> Yeah. Yeah. >> I think uh >> We can just fix them. >> Maybe. >> We we can look at final design. I expect we can pretty fast suggest the properties that would be sufficient for the pen and paper proof, the reduction proof. And then AI can do the reduction proof given set of properties.

Or it says okay, this is not enough. We add one more. But yeah, this this can be done. >> Also for manual review, you can review the big jumps. Like clearly you have hundreds of submissions that are going to take 0.01. Um And and you don't necessarily want you know that someone to spend time on on all of these. Uh but when you have a big jump like we had, clearly it's worth spending some time on on the big jump. So that removes a lot of human work. >> I think it might also be a good idea to have a layer of interpretability screening done by an agent. So, like have a sort of a dual scoring mechanism where even if you make an improvement, if it's

completely incomprehensible, it doesn't get promoted, but it's still available to see and if someone wants to improve it. >> I think that would be hard because then you need an an AI to decide what is incomprehensible or not. >> So, this is what we did in Hash Smash. So, in Hash Smash the uh the agents screen submissions that then go on to a human judge. Um so, we could apply a similar mechanism. Um we'd need to figure out what interpretability means, but uh it could be something like maybe you have to submit a legible description of what you did and tie it back to existing techniques, but um that's an open design space, I think.

>> This is just prompt engineering. >> Yeah. >> Okay. If if you think it If you say it's doable, I I think yeah, that would be. >> One historical note is that um it took about 1 year, if I understand correctly, to formally verify um Sphinx Plus in Easy Crypt. And we actually have the guy who led the team in the room. Um Matthias. Um So, I I I I I guess Matthias, I'm curious. This is a question for you. Do you have any thoughts on on anything related to Signal Golf?

>> On anything related >> Related to Signal Golf? >> Um What do you mean? As in like is it a good initiative or >> Okay, good. Going back I guess to the discussion around um adding In In addition to the the ROM proofs, also having a standard model proofs. Uh you know, requiring for example 110 bits. Like does that sound reasonable? And like would you fix the the set of assumptions? >> And also what are you doing in the next 6 months? >> [laughter] [snorts] >> Yeah, no. I um I also I'm actually this is actually one of one question that I also still had was I was wondering what the lean proofs actually look like now because what I've

been doing always is like the reduction proof which also make more sense to me and all the points that Mike and Benedict um made in terms of like giving the sort of the overall thing more structure and give you a clearer idea of what's actually the thing you want from your hash function um I think it's good. So, even if you lose like a couple of bits in security, I would say this is worthwhile to at least have an addition. um Yeah, and then yeah but overall I think the the approach now uh seems good.

I also liked what Mike said. We talked about it like a couple minutes earlier as well. uh in terms of like um you can do the auto research. Let it run and then eventually [snorts] have like um the properties that you that that you need to actually do the reductions um to eventually get those out anyways. Uh yeah, but overall I think it's uh well on the one hand very cool. On the other hand, it's a bit uh well sad that I had to spend so much time and effort.

>> [laughter] >> And uh yeah, no but um yeah no Ah yeah, true. Yeah, so another reference. So, Sphinx plus was actually a bit quicker than the than one year. But XMSS took one year. um But Sphinx plus obviously builds a lot on XMSS, so that's why it was shorter. But now I did like the generalized XMSS that um right for uh like it's signatures um which was like in under a month now as a side project with AI um compared to like the one year.

Yes, these are reduction properties. So, also the properties that are actually for Sphinx are now in VCVIO. Um because they were needed for this actually message proof as well. >> Um uh another point in favor of reduction-based um proofs. Um so, you have to rule out um the case of hard-coded adversaries that that start off with um uh kind of preimages um uh for say a given message um baked into them.

Um the best way of doing that is and there's a paper by um Rogaway called Formalizing Human Ignorance um which um and it explains better than I can um why you should use reduction-based proofs um to rule out that kind of artificial attack. Um it's not just uh kind of adversaries that have collisions etc. uh hard-coded into them. It's also adversaries that have infeasible pre-computations baked into them.

>> But, this is this is mostly for keyless collision resistance, no? I mean, for preimage resistance and all these properties, these are randomized from the beginning like in that paper. >> Yeah, it's it's it's more important for other properties. Uh you probably get away with it if you're not um relying on collision resistance. >> Right. >> Yeah, the the the It's where because the the specific um choices design choices that you're making allow you to get away with a less general thing than you need um for a more complicated protocol. So, kind of my arguments in favor of the the more general thing don't all work here.

>> [clears throat] >> Um Yeah, just to go back to the previous point cuz I think uh it sounded like I was saying we should understand what's happening from a like theoretical perspective just because, you know, due to theory, but for me it's more about engineering. Like if we don't understand where the TCB is in the formal verification pipeline and something goes wrong then it's either the program, meaning the Sphinx program, which I don't understand, or it's somewhere in the pipeline. So for me it's good to But if you use something like Anios, for

example like Right. >> So so seL4 tells you nothing about the TCB. >> Right. But I want to understand like what is it meant to be doing or what does like what is the Sphinx scheme meant to be doing and if the TCB that had the bug is in Anios, like what has changed between what it's meant to be doing and like what Anios has spat out, for example. >> I I have a possibly controversial opinion here, which is don't worry at all about bugs in TCBs because a human will have to check these things anyway. We are not relying entirely on either

a particular formal verification framework or AI or everything is going to be checked by humans and made to be understandable by humans. No bug that depends on a particular um kernel or library or whatever is going to be able to get through. And if it is then there is another problem with the process that is not about TCBs. >> Okay, I agree. Yeah, if everything is getting checked, then yeah, I agree. That's the original point. >> And the the the the TCB should be invariant, right? Like the the TCB in 6 months should be the same as a TCB in in 12 months.

Right? >> Change implementation details, you might have more or less TCB. >> The implementation detail for us is not part of the TCB. The only part of the TCB is the security property, which says you have 127 bits. >> Yeah, they go go go. >> For the thing you deploy as well, it the you know, for for lean Sphinx, the TCB is going to be the security property. Yeah, yeah, if you implement it correctly, then you minimize the TCB and you know, there are there are no change of TCB as you as you

>> Right, so I agree that if we have x86 specs, the arm specs, RISC-V specs that we are extremely confident are is correct, we have lean specs and we prove those equivalent to the x86 implementation, the arm implementation of Sphinx, then this gives me a lot more confidence that it's probably okay, and the TCB as far as I know would be minimal, right? Like >> Yeah, but the the signatures are not getting verified on chain, right? It's only they're only getting verified within a RISC-V ZKVM, so you you don't even need the arm or x86 semantics, you just need the the RISC-V semantics.

>> They got to run on nodes, right? >> Depends what you mean by run, but um Like you you you can't I mean, one strategy is just to have RISC-V emulators on on on arm and x86. So, it's kind of a a one-time thing and then and then, you know, the there's no there's no change in the TCB. If you if you include the emulators as part of the TCB, which you don't have to if you have a good semantics for arm and and and x86, then then there's no change in the TCB.

>> If you have a bug in an implementation, you just fix it. We Yeah, this is how it's always been. >> Right. But, we're talking about the case where we don't understand the implementation or how it's done. What >> We will. >> Yeah. >> Like, if you do understand the proof, it's immediately you understand the implementation. >> Like >> The what you have in sig.go here tells you something about some theoretical security property which is somewhat orthogonal to the implementation details. >> Right. And I was saying that it's good to understand the implementation details.

>> Yes, I agree. Okay. >> I'm just saying that it has nothing to do with >> Okay. Yes. Yes. Yes. Yes. >> implementation is simple. So, >> I would say the current known best designs are fairly straightforward to implement. You make a drawing and you say there's target sum and that's it, like. >> [snorts] >> I don't think anyone is advocating writing AI just completely run a mock and and give you an arbitrarily complicated thing that you then deploy. No the we're going to choose something that's relatively simple.

>> Emil just said trivially simple outside of the microphone. >> Yeah, the the signature the abstract scheme and the shape of the dag is very simple. Yeah. Yeah. >> It's much much easier to explain and to understand things versus anything else, I believe. >> Yeah. After all the submissions, this is what we end up with and it's a variation of things, but it's not super far. And this is >> What is that? I don't understand.

>> [laughter] >> It's It's obvious. >> Ah, yes, yes, yes. It's just a dog. >> [laughter] >> It's It's not super far from uh the initial things, at least in the in the shape. And this is the beauty of like hash structures. It's You can throw any random combination and there are not so many ways out. Like, at least so far we didn't find something completely different from um hash-based structure from the literature. The main, I would say the main innovation was the having the watts at the bottom of forest.

>> The what? >> Uh uh the chains at the bottom of the forest was the main innovation. And when you think about it, it's like just move the chains from the top to the bottom. It's not that crazy, at least on the paper. >> So, the the this one looks much easier than the 256 / 256 kind of thing. So, like I mean So, implementing this kind of thing in the assembly on the it is easy like risk five um x86. For for for for x86, I don't know uh if the same semantics is ready, but I mean, if you are really worried about

that yeah prove the assembly. >> Read the assembly? That's the Yeah, but >> Prove the assembly. >> Okay. >> Prove that the assembly or the machine code Yeah, computes this thing. Uh yeah. I mean, yes, for the choice of the hash function you also prove that the hash that your the choice of a hash function is you calculated >> All new assembly that is written in a cryptographic context, especially for for critical systems, which most most cryptographic systems are, should be proven.

Um yeah, the world has changed. We we should only deploy proven things now. >> And it's it's easier if you don't use any S and rust. Um Agents are easier Agents have easier time writing writing proofs about new small snippets and compose them than to analyze the analyzing um optimized code coming out of optimizing compiler. >> Compilers are dead. >> Compilers are dead. I mean it's they are huge at least. I mean it's reading LLVM or reading outputs from LLVM, that's that's a much more pain than implementing this kind of thing.

>> I'd like to encourage anyone who hasn't spoken yet to >> So this is a meta question about auto research. How do you understand authorship? Um you know, are are those who care about authorship clinging to a dead uh you know, vestige of a bygone age and just shouldn't care? Um and and to the extent they should, um how do you do it? Do you um alphabetize? Do you put every contributor as an author or or just the person who ran the competition?

>> Well, that's a that's a good question. The way the Ugen platform is showing it uh it's giving you a leaderboard with like everyone that submitted. And in some case I don't know actually how it works but maybe someone in the room does. In some case it like merges the contribution and >> Let me >> [clears throat] >> Can I clarify the question? I'm talking about if at the end of the day when you fully understood this, a paper comes out

because you sat down and understood all that was done and distilled it and wrote it down in a human nice way. They They what? Did it and and how did they do it? Did they just put everybody every contributor was an author and it was alpha Oh, the individual contributor writes a paper is what you're saying. >> Yeah.

>> For better the codes there was like one specific submission that kind of had a new idea and everything everyone else built on top of that. Yeah. Right, right, right. And then for ECDC.fail there was a paper with 100 authors. [snorts] Basically all everyone >> see that. So it it seems that there are different, you know, modalities floating around. Um >> The ECDC.fail paper is different to the paper that came out of better codes.

>> In what respect? In in how they did authorship you mean or what other respect? >> adds their own contribution, right? So they build on things that came up in better codes but better codes makes no claim to, you know, kind of generality or presentation and the papers make a claim to generalize your presentation extending the results and digesting them and it's and they reference better codes and you know, there's no controversy. >> So I think one thing too is that this is very much an open question. Like the cuz the the format of this is very different than a traditional academic venue. And so I I think like uh as this expands and becomes something much larger than just a single number

that keeps going down or up. Maybe as more complicated metrics or multi-dimensional metrics come up. Um we'll need to think about that how to do that for different forms of challenges, but I think um one surface that we've been thinking about is like maybe the person who sets up the challenge is sort of like the primary author uh and then as for solvers, there's a interesting question about you know, how do you measure the impact of one person's contribution?

>> Right. This is a good question. Uh I think it's going to be different for every scheme. Uh and yeah, it's all peaceful until there is a real war there and until there is like this question of authorship and and like honor and going forever. Uh personally like I was on top and I don't consider myself uh a player or worth of being on a paper, so I wouldn't make any claim. Uh if a paper were to come out of this. Uh but I guess depending on the challenge, you'll have like huge solvers uh or huge jumps and maybe this is worth having these people to to the

papers. >> So as yeah. >> Let me follow up question. How do you generate this art? It's great. >> Sorry? >> The art. >> The art? It's not generated. It's actually a designer from uh designer foundation. Uh >> What? Wow. Well, props. The art is amazing. Domo is a very talented designer. So, it's the infinite garden vibe. Yep. >> Domo uses an AI. Yeah, yeah. >> Domo uses an AI. Okay. >> Okay, well. >> Then, see.

>> [laughter] >> Uh >> But, can I volunteer an answer? I mean, I I think basically the answer is that we don't know, right? So, Terrence Tao has talked about this in the AI era, like idea generation will simply change. There will be new ways of doing it. There will be new ways of collaborating with different roles. Um Okay. Sure sure. Right right.

Sure sure sure. >> People will kind of see what are the resources which you needed to go into a paper and assign co-authorship. I mean, it will evolve and it will change. I'm not saying there's a kind of definite answer, but it I I don't think it's something to super worry >> is that the answer then? We just just become like lab sciences? >> Well, I mean, this is an experimental challenge, right? So, it it's not I wouldn't be too surprised if it veers in that direction. >> But, but do you think that's normatively a good that would be a good way to do this or or do you not know?

>> I think it's something to worry about. >> Okay. I I mean, I think math does have something special with the alphabetized, you know, convention, which might be in danger. Let's put it that way. >> I think there is one more problem here is that So, some of the submissions are based on the work on the papers that were not done by the people exactly, which is fine. They took the idea, sub- made the code, run it, submitted.

But and then for example, you put them into authorship list, which is maybe also fine, but probably you will not search for every idea that was used from other papers. Normally in a normal paper you would have attributed. For example, Ports plus FP was in the submission here probably. Would you find it and you will cite the Ports plus FP paper that it was based some ideas were based on it? Well, when if I do my research and I take the idea from Ports plus FP and it's significantly influential, I will cite it.

Here it's much harder for me to find it. Huh? Exactly yeah. >> Well, something has changed in that it might be harder to trace the paper trail, right? So, I agree that the responsibility to pursue that has not changed, but >> Okay, well, you tell me it is harder for me now to match my honest desire to cite people's work.

If I sit down and I want >> But you tell you tell me when a when a submitter submits, do they say where their ideas came from. Um It It should Right. Okay. So, they Right. Sure. Sure. Sure. Sure.

>> I have one idea that I get submission there's a check box. I claim scientific authorship and I make sure the source of sources of ideas are in this list. And then I mean they they would be contacted when they people write papers. If you don't >> Check. Check. Another >> No. No. No. It's It's okay. Like I mean I mean if you are not sure where the where the ideas came from, don't really do the check mark. Don't Don't put a cross. I mean don't claim scientific authorship.

>> So >> Volunteers can, you know, want to be doing the paper writing mode or like not just hobby mode and they they can decide. I mean they they they can try to figure out all the sources of the idea somehow or maybe they don't want to. >> The I think there are two issues two issues. The first is that the AI models we're using are trained on the internet. And so they're going to know about ideas that they don't attribute. Um The second is that I think not everyone is just keeping all of their logs of their AI sessions. So, it may be

Sorry? Uh I can in cloud. So I I Okay. I can see I can see the I can see some of the summaries and I refuse I refused to use new models. >> One or two One different solution is to publish this as a collective. This is >> Bourbaki's raised from the dead. Just a second. You could never see the raw chain of thought because that wasn't English.

You can still see the summary, the thought summaries. I can still I can still see I can still see the same things that I could see with Opus 12.7 in Fable 5.1 and Mythos 5.4 5.1. >> So, one thing is I think that the fear that people will just hide plagiarism is very real at the moment. So, there's this thing that's happening where Right. Maybe I could give an example.

So, there are people in the when ECDSA fail was beginning who were scanning archive for any quantum relevant paper and just applying directly. That works. So, there's something about I think the solver submission format which needs to be looked at with some suspicion because it there's a And also, the the hardest part I think of one of these auto research challenges is definitely setting it up in a way that enables these sort of submissions.

So, This is just like a working model I have, but the way I've been thinking about it is that the the solvers are applying the current state of the art at the most in the most parallel way possible. There's also new ideas that emerge from it, but I don't know if it's easy to separate what's prior art versus genuinely new. Um that would be a really interesting thing to solve, but um in the current format, it's all tangled up.

>> Slightly different direction. Um how can we get twice as many people to participate in SigOpt? >> Yeah, I mean those >> incentives. >> Incentives, that's right. >> I feel like it's pretty obvious. Um you'd need to maybe like I I think we were discussing with like the leaderboard of like showing who had the next best submission is fine to hype people up, but like in the end like at the end of the challenge you need to probably reward people based on how much they contributed to the overall reduction. And then you can come up with

like a ton of incentive schemes to reward based on I don't know. For example, I would be fine rewarding um big jumps in the beginning less than big jumps in the end. And so you can sort of like, you know, do time-weighted incentives or whatever, but um yeah, I feel I feel like that would actually help a lot. >> One cool idea in this direction and I think I heard few people have been discussing this. It's like doing a sort of prediction market, but like theorem markets for uh this type of challenge where basically you uh you put um an incentive either to break the statement, for example, uh or uh to reach a certain threshold and then you

can move when you reach um when you reach a limit, you can say, "Okay, we are now stuck at this point." And then you update the market and you say, "Okay, if someone breaks this limit, it can take more." So, there is a lot of uh good and fun ways to to put incentives. And if you do this, like as a sponsor, it's super easy to onboard. You just buy the no shares. And as a solver, it's super easy to claim because you just buy the yes before submitting. So, there are a lot of uh cool I think design space to do the incentive for the submissions.

>> Yeah, but if you add an incentive on top, isn't everything we discussed before just much worse? Like you're giving people a an opportunity to just steal someone else's work for money. And that would happen at an unprecedented scale. Like to the point maybe you have to get into court and into the regulatory of this just for you can to keep existing. I think this is like an existential type of mistake from a legal perspective. Because there if there's money on the table, someone wants to take the money. And if I can anonymously go there and say, "Yeah, I am Jonas Pike, and this is my submission."

And just steal the work and put it there. I take the money, and then what? >> But what do you mean by steal the work here? Because this is like a It depends on how you design the market. If you said uh um Let's say that we reach uh a limit at some point on Cikada Golf. We are stuck for let's say 1 month. We don't know if we want to close the challenge. And I say, "Okay, I really want to move this limit. I don't care uh who's going to like move the limit." I just like put this threshold. So, I I think one problem could be that could incentivize people to hold off their solutions. Uh that does definitely have a problem. But I think this is a design space where you can solve it.

And for what it's worth, I think it's a better usage of prediction market than, you know, gambling on sports. >> Also, like we it's like we are pretending like the sort of like question of authorship is really good now and like now it's going to get worse with AI and auto resource competition, but like auto authorship has always been very very imperfect and very arbitrary. And like it's it it it's not like a sort of like new problem. It's a it's an old problem that doesn't get better with this, but it I'm not even sure it gets worse actually.

>> So, uh one thing I would just mention is You Can't Currently does weekly payouts for the top solvers, and there's definitely a lot of uh motivation a lot more motivation when there's a prize behind it. >> I have one related to heuristics. I think this works. Um so, each second the bounty increases by 1 cent. And then the new top score will get the uh bounty, and then the bounty goes back to zero.

And the thing is like, I mean, if you look at the existing solutions and you do some quick work and submit it, and then you you you get something, but it's not big. But after after, you know, nobody has found any improvements for 1 month or something, then you get a lot of money like Yeah. If you make a breakthrough. >> But but but like you are kind of make it commercial like this. Like I have an improvement instead of coming out and say this is a potential improvement, what does everybody think? >> the solution. But just like actual incentives versus like versus like cloud social incentives, it's it's I don't like I don't know I don't really understand the the huge difference. It's like now people are participating because it's fun and you can get on the

leaderboard, and it's >> No, the difference is there because who gives you the money? Like do I have to KYC you? Do I have to say, "Yeah, this guy, this was your own original thing? Do you have to fill a form? And anytime you give money to someone >> You do it privately on the cash or or ethereum and that's it. >> Yeah, well, then who is the Yukon.org platform owner? Like this just brings so many issues to the table. It's like doing a contest. Like you you would want maybe to do a contest for everything, but then you read all the rules that you need internationally for for that to be able to run and you kind of don't do it anymore.

>> Uh, I think this is definitely a very open design space. For now, it's just Yukon and we're doing it for fun. But this type of problem is something that can be solved by, in my opinion, designing the proper incentive so that you don't uh, prevent solver so that you don't incentivize solver to hold up solutions. Um, yeah, it's just a to me it's a market design problem that can be solved in a way that is somewhat fair. Um, yeah.

Uh, look, there is a 1 million you know, the clay prices. The the you have prices like this, you know, uh, if someone solves it, these days it seems to be open AI and and anthropic solving these. >> I always thought that he passed. >> [snorts] >> I think I'm wrong about the position. >> But yeah, that's that's uh uh >> But who was it that Perelman that didn't take the prize? >> Uh, Perelman didn't take the prize. Yeah yeah yeah yeah so. >> He didn't have to get the prize. >> Right?

>> He didn't do it on the basis that he was a previous big leap on that problem. It's a secret. >> Yeah. >> You know, this is a very interesting rabbit hole, but I would love to go back maybe to the timelines because I believe that at least in Ethereum we have some goals that are somewhat uh defined. I think we want to have this by I-star if I'm correct, Lin thinks. >> Yeah.

>> And for us, uh what is the optimistic date for I-star? >> After the rest day? >> Yeah, we are very optimistic. >> I think March 28th. >> I guess that >> So, Zcash kind of Zcash kind of needs um to nail down the um signature scheme before that or I would like to anyway. >> It's live on >> Oh, all right. Okay, that's fine. Um so so when would you be thinking about nailing down the signature scheme?

>> I think that we should almost have hardware with this working out in the next year for most >> Uh >> Is that what you're expecting to have things >> I mean >> already going into that that should >> Yeah. I I mean I I would like in the next 6 months um because of because of the hardware wallet um manufacturers being slow. >> In in practice, you need to do it as fast as possible just because the the gap between when you settle it and between like when when it actually goes to mainnet is huge usually, so >> It sounds like we're on the same page in this It Yeah, the the Ethereum and Zcash incentives are aligned here.

>> Yeah. >> I'd like to hear from the hardware wallet people. Any thoughts on timelines and things like that? >> Yeah, you you ask a tricky question here. >> [laughter] >> Well, it's uh well, this topic is very concerning for us because it has a huge impact on the on on the on what is actually implementable on our wallets. So, we have more constraints and timeline to be honest. So, just uh that good opportunity to talk about uh one constraint that we have is that actually um most security of our wallets relies on secure elements, and the drivers of secure elements are mostly the banking industry, uh the telco industry, and the governments.

Uh so, basically uh we will have the hardware acceleration for the kind of algorithm that those kind of industry adopt. And let's say there's a current mismatch between uh the choices that most blockchains are doing on post-quantum algorithms and those kind of things. So, we have a very big constraint on on on the other acceleration we'll have. And uh it's uh shaping up that basically we have either we have two kinds of solution. Either uh you match uh one of those uh type of algorithms from the let's say the rest of the industry, and we'll have the acceleration and no problem for us and 2 3 years you will have a new secure elements with with whatever required to to accelerate the things, or you you

uh we we find tricks like what we discussed today on making uh that acceptable on uh on general purpose hardware, which will make it acceptable for secure elements. Uh So, and I'm fairly hopeful from what I've seen today uh that we might manage to do that. That's still a pretty big open question for us. So, hopefully you will work with us to to find the best compromise on the algorithm parameters and the tricks you can implement securely uh to achieve um reasonable performance for for our wallets. That's it. >> Just a quick announcement for those who wants to go to the talk, the extra talk on aggregating Falcon signatures, it's going to be in the other room, and it's starting very very soon. Um but yeah, we can also just uh extend the

the workshop for those who want to stay uh uh longer, but yeah. >> Uh I I be really curious to hear uh some Bitcoin timeline for this because uh >> [laughter] >> Okay, that's good. Because I do feel like uh we can do a lot on our side, but if Bitcoin doesn't move, we'll have a little problem. >> Um yeah, I wanted to um Yeah, I wanted to know more about the blockers for the hardware wallets um and whether um Oh, it's all right. I think he can hear.

I don't know his name. Yeah, uh I wanted to know more about the blockers for hardware wallets and yeah, just the exact blockers. Is it mostly just standardizing on uh particular schemes? Uh you mentioned like the rest of the industry, so I'm uh there's a high likelihood that they might just use like a lattice-based thing. >> So, mostly uh ML-DSA uh and ML-KEM. This one is a most mostly what most of the rest of the industry goes to actually. So, and we already know that we have we will have accelerators of ML-DSA uh in the next generation of secure elements.

Uh the the problem we have is that um for most hash-based cryptography uh hashes in the in the before hash-based hash-based signatures uh were really uh uh few in numbers in the most protocol you were using. So, there's no hardware hardware acceleration for hashes up until now. >> Mm. Right. >> Uh which gives a pretty big limitation on the kind of thing you you you you want. So, typically just to give you some numbers uh as an idea um depending on the type of hash uh we support between 1,000 hash per second to 10 10K 20K hash per second for the best algorithms.

So, apply that to the to the parameters and what gives you the number of hash uh for a single signature and you will get a pretty good guess of uh of the performance on hardware wallet of of a single signatures. Might be also interesting to mention one thing. Key gen is actually well, take care of it also because it's important for more than you think. So it's not an operation you do every single time. In the world of post quantum, it's one thing you might you you might have to do for every single time you ask your public key from from the hardware wallet.

So it might have an impact for instance when you set up your your your whole wallet for the first time when you scan the blockchain for existing for your existing funds, you might have a pretty long lead time depending on the algorithm we choose and the permanence firm assist of key gen. So Those are definitely UX impacts on all those all those algorithms. >> Right. And does it matter if most of the ecosystem um sort of agrees on a particular scheme or did they just need to agree on the shape of the scheme? Um Or does it not even matter at all?

>> When you say ecosystem, you mean the blockchain ecosystem? That's all. >> Yeah. >> So it's No, no, the shape of the scheme fairly important, I would say. So we have huge difference of performances between the parameters selected, hash algorithm selected, the tricks that are acceptable for the parameters you selected that are So Kev, is there Like your question is like can they run multiple different algorithm and support like different shape for different chains or >> Right. You're right. Is there Is there such a thing? >> This is very doable for for you guys to actually you support ML-DSA on Ledger.

So >> We we don't have a choice. It's so so we have to support all the algorithm collection of algorithm for all the blockchains. So yes, we will have to. Yeah, that's all. >> Okay. Uh For Ethereum, it's it's good to that the latest stuff is also available on the execution layer. It's just not enshrined. So, technically, like you could sign signatures that are ML-DSA. And recently, it has been like optimized a lot. So, like Falcon is now 600k and ML-DSA is like 1.4 million gas. If we scale to 200 million gas limit, this is like a few cents. So, it's not terrible but here the question is more like the native

one. But on the on the hardware wallets, you can do whatever arbitrary computation that you want. >> Okay. Yeah, makes sense. >> Can I just add something? In the next generation of secure element, we will have Shake in the hardware. So, things with Shake is actually better for us rather than SHA-2. >> Okay, I see. I don't think we're going to >> Do you have any idea >> why they did a Shake accelerator and not another one?

>> I think that's because it is used for ML-DSA. >> Oh, okay. That makes sense. That makes sense. Yeah. Thank you. >> It frustrates me that when people choose really inefficient hashes, they should choose more efficient ones. >> We should do lobbying at NIST maybe at some point. >> I'll just say my honest >> Look. >> SHA-256 is efficient because everyone has hardware acceleration for it. Same thing with hardware acceleration, right?

>> All right. Um >> Um sorry, I have one more question. So, um for the hardware folks, or maybe for you, Nico, are we optimizing Are the things that we're optimizing for in sig.golf like applicable to the to what you're to to your hardware environment? Is it really just decrease the number of hashes and then that's that's it? Like nothing to do with like maybe memory or >> Yeah. No, actually two things we saw today are applicable and very interesting. So, the tree pruning technique we discussed and the beginning of at the beginning of the day there was a presentation on a Sphinx D

that might also be applicable to to what we do. So, these two we need to explore for sure. Like definitely looks interesting for other wallets. >> Yeah, actually the small dummy competition that we just launched has a track for constrained hardware which is based on the number that you have when you do Blake inside a Ledger device. So, right now on sig.golf the main competition the budget is more of a general budget that is more for a laptop and everything, but we can definitely optimize for for this and then either you can do like pruning on top of the big scheme and then it becomes more

hardware friendly. But yeah, we are taking this into into account for the design of the of the competition. >> So, yeah. This is why we kept the budget and this is why Michael's solution doesn't fit sig.golf. So, in the V2 we will yeah, basically we will iterate on on this to try to accommodate for both world.

>> You said 5 seconds. Do we know like what is the target here? Like are we okay with 5 10 >> is very uh subjective because like depending on the hardware, it will be different. Uh so there is not only Ledger as a hardware wallet. So yeah. In my opinion, when you're signing a hardware transaction, it's okay if the flow is taking a few seconds. You don't want people to be the gents like the point of signing on the hardware wallet is to take a little bit of time to check your transaction. So I do feel like 5 seconds is okay. I think some application are signing in 9 seconds if I remember correctly for Stagnet.

>> So don't uh don't take my opinion as a reference. I'm not a product guy at Ledger. So that's uh but uh 5 seconds is definitely in the ballpark acceptable for for other wallets for sure. That's all. Anything under 10 seconds I believe we can fit 10 seconds starts to be really borderline in terms of user experience. And beyond the first first iteration of uh uh Sphinx if if you take the NIST uh Sphinx parameters, we sign around 6 minutes which is completely unacceptable for for for for users. So just to give you an idea. So that's all. >> Yeah, uh Zcash currently does it wrong.

We um sign for um every input and that's because we weren't really thinking about hardware wallets when we first designed the scheme. But it's easy to not do that. So The the next versions will not. >> Is it possible for you guys to do this trick where as soon as you receive a request to sign a message, you start signing it? And then only when you press the two buttons, do you send the signature to the to the host? >> So yes, but I would challenge a little bit the security of that of that model.

So there might be some some consequences actually. So >> What are the consequences? >> Uh it's uh so but you you start the computation. So if we ever need to to get the computation out of the secure element before the user actually approved, you you you basically start to release some crypto material before they have actually approved. >> So the material stays within the enclave. The only thing that releases material is pressing the two buttons. >> Uh that's that would be the ideal security property for us for sure because as soon as you get some some security material out it's uh >> So there's no security material that goes out. So you >> So you do you could do the full computation in RAM like 10K 50K of

20K of RAM you think you could do the full computation? >> Yeah everything in RAM or inside the enclave and then only once you press the two buttons you release. >> So in that in that model yes that's would doable. >> Okay. >> I think it's also very interesting for key gen. I had a proof of concept app that I run for early design of things minus where basically for key gen you start to do the key gen when the app is is open so in the background. As soon as you the person opens the app you do the key gen.

And so you can save also UX improvements. >> So don't in so next don't you need the message before you know which hash leaf? Um I So which of the possible optimizations allow you to do significant work before knowing the message? >> Well we But So this would be after you receive the message. So you

receive the message and let's say it takes 5 seconds. Well, the by it it takes let's say 10 seconds to just verify that you've sent it to the right address and the right amount. So, then you can just hide all the the 5 seconds of latency. Yeah. Yeah. >> And plus in addition on on on Ledger wallet at least, you send the message and then we actually uh uh convert and display the message so that it's readable to the user. >> Yeah. >> This fair is there's a we already got the message and there's a user review on the message which is >> fairly long step. So, basically the the user has to review. It's a manual human review on the on the message. So, this gives you at least 5 10 seconds easy uh to to to to start pre-processing the

the the data. >> Exactly. >> So, um as far as key material leaving the secure element before the user has confirmed, you're not revealing um the original secret um values. You're revealing values that are dependent on this message and therefore it can only be used to sign this message, right? >> Yeah, but if you actually the the user um actually declines the signature, if you have revealed that material before that that's kind of a problem, you know?

That's it's as as if you had signed, but at the end you actually didn't didn't sign. So, so that's why I would avoid revealing any values be before before the user has actually signed. But if you can compute the full uh the full hash uh and there's a full authorization pass and there are authentication pass or and everything uh ahead of time, uh if it's a signature that fits in the memory of which starts to look like it like that 6K that fits in a in a in the memory, we can start the pre-computations uh and actually uh keep them in RAM and then just disclose them when the when when we get when we get at the end so >> I wonder if there's a a trick where you

can um kind of not disclose something that is necessary um to prove that this message matches the leaves that you're disclosing. That's it that seems hard. I'll I'll have to think about it. >> I mean one thing that you can start disclosing is the the the public part of the of the Sphinx. So if if you're limited on RAM, you can just uh disclose that because it's not it's not secret.

>> Any more question or we can go and enjoy dinner. Okay. Thank you everyone. Uh >> [applause]