Post-Quantum Transaction Signature Breakout #12

Transcript

Alessandro Baiocchi: Who?

Matteo Vicari: I…

Antonio Sanso: Hi, everyone.

Gianluca Felli: Hi.

Matteo Vicari: Hi, Antonio.

Antonio Sanso: As usually just a few minutes before I have a few slides, let me check that… Machinery works. And then we'll wait a couple of minutes. Sure… You see my PDF, right?

Matteo Vicari: Yep.

Alessandro Baiocchi: Yes.

Antonio Sanso: Alright. So we are… it's 3 o'clock. As usual, we start around 2 minutes after 3. For the people joining now, we'll wait a couple more minutes.

Hi, Benedict. We're waiting a couple more minutes, too, for a new joiner. Hi, Fara. You still didn't see my PDF, right?

Gianluca Felli: Yep.

Antonio Sanso: Okay. I think we can start, and someone joins. It's, just… Skipping a few slides, and… okay. So, welcome, everyone, to Breakout Room Number 12. Team is Post Quantum Transaction Signatures. Today's Day, 22 of July. This is a quick recap of the previous calls. So, we covered a bit of ground so far. So, let's see what we can do next. Of course, the starting point for us is the straw map. we are still, like… our target, the main target is JSTAR, where there is post-quantum SPHINCS. So we still have 3 releases to go before to… to ship something, but yeah. For sure, we should not risk to go to some analysis paralysis situation, so we weren't really to start and…

And… do something more real. So, so far we excluded a lot of stuff. And, we kind of came to the agreement, probably. Hash-based signatures is our target, so… and SPHINCS it looks appropriate. Of course, this doesn't exclude the The fact that we can still use ephemeral keys with FORS as well, in parallel. Let's see the agenda for today. We have only one presentation scheduled, then if someone has some topic they want to bring, there's some times. Today we have RivaLabs that, as far as understood, they are presenting some… SPHINCS variants. So, I don't know who's gonna present, give the stage to Matteo, I guess.

Matteo Vicari: Starting, starting Alessandro, and,

Alessandro Baiocchi: And start.

Matteo Vicari: You can check, yeah.

Antonio Sanso: Okay.

Alessandro Baiocchi: I'll share my screen.

Antonio Sanso: Yes, thank you.

Alessandro Baiocchi: Cute. Okay, so Shaq… And this one. You should see the slides. Right?

Matteo Vicari: Yes?

Alessandro Baiocchi: Okay, good. Okay, yeah. So, a quick introduction that we… on what we are working on… one of the things we're working on right now is, we… we've seen that there has been a lot of work around selecting the right parameters for SPHINCS, and… And of course, the, like, the features of the SPHINCS signal can vary a lot by changing… simply changing the parameters, as we have seen with, like, the really nice work with SPHINCS Minus. And what we… what we are going to show is, like, what… what's our… Like, angle on how are we working on this? And, like, this is just a very brief recap, because I don't know if everyone here is how much everyone is familiar with SPHINCS, I assume we are all very much familiar, but yeah, basically the parametix we are working with are these zcs, these three parameters.

And they… they each represent something in the signal. For example, N is the number of bytes that each hash value has in output. And mainly, like, it decides the security level of the zk network, and H is the EIP of the is the total hypertree length that contains the WOTS signing leaves, and D is how many hypertree layers are set in the signature, and K and A, instead, are about the fourth part of the sphinx. They set it… they set, respectively, how many trees the FORS have, and how deep each tree is, and… and then W is just the WOTS param… interlinks parameter for the WOTS, for the WOTS signatures, and it's just how many hash steps are in each… in each… in each WOTS chain.

Well, once… now let's work done with this, This is, like, the… our main thing, because… There are a lot of possible paramedic sets, of course. And… Each set, set of parameters has its own strengths and weaknesses, because you can use, you can set parameters that, result in large signatures with low, like, verification costs, or, like, low signing work, and vice versa, and… you should, like, choose, which parameters to use, depending on what you… what do you want. So, of course, if you want low verification cost, and you don't care about signal of time, the best parameter set for you will be 1. And if instead you want a signature that is almost instant to sign, and you don't care about how much gas you're spending, then the program itself will be different.

And… one of the… One of the metrics that we… that, of course, a lot of our works, cut on is the use budget, because as of the standardization for SPHINCS Plus in the NIST, there is a 2 to the 64 release budget for, for SPHINCS. But that's, like, extremely large for any real use case, so we, we… depending on the use case, you can tune it to be, like, in the range of 2 to 16 for, like. for example, called storage applications, you don't want that many signal drugs to be… you don't need that many signal drugs, or 2 to the 32 should be more than enough for any real application. And so, we… what we've done is, like, we…

Basically, we looked at a bit… a lot of configurations of parameters, and we've seen that basically, we… this is… these are just some we selected. Of course, we are not limited to… to this exact parameter sets, but we just selected those. And… it's basically one for each main application that we could come up. So, if you want to optimize thickness of time, you should go with, like, with fast. variant, if you want to, with, to optimize the gas cost of the verification, there is this gas ZVA variant. And, of course, it's compared with also the FORS Plus C and, SPHINCS Plus, standard, like, signet hooks. And the standard, I think, is, yeah, it's the sphinx minus, parameter set.

This zinc, I think, yeah. Okay, so… to better understand what we… like, why each parameter set is suited to… to, different, use cases, like, this is a visualization of how SPHINCS Plus works. And each hype tree, is, one layer of the total, like, hype tree that contains the WOTS. Each WOTS signature signs over one, the signs over the root of the layer. Beneath it, And… And then, at the end, we have the fourth layer, where each tree gets one leaf chosen to sign a part of the message. And, yeah, that's the… the whole, SPHINCS structure. What we highlight here is that… is the, like, the whole construction is the blue nodes, like, these are all nodes that need to be, like, computed to… to sign… to sign the… yeah, a message.

And the orange path, instead, is basically what the verification needs. So, you… when you want to verify a message signed with SPHINCS, you need to climb up, With the… starting from the FORS leaves, and you are given the siblings of each node you are at, and you basically hash up And verify that each signature is valid, by going all the way up to the root. So you don't actually need all the nodes that are printed here, but you only need, basically, to climb… you need only the orange part, like the siblings to the orange part. And that matters because, for example, if you want to, Like, here we see an example of a parameter set.

Like, this is… it's always a SPHINCS signature, but by selecting, like, extremely lower parameters, for example, we have, instead of 7 layers of EIP trees, with a total of 63, depth. We just have a total depth of 15 for the WOTS, with a split in 3 trees. And then the first two are, extremely light. We get a signature that is… Of course, it's faster to… this is the optimization for the signing part, so this is… this requires the least Hash operations to build a signature. And… This is, for example, the, like, the main part that we cut on here is, if you see, this signal has, with these parameters, has a Qmax of 2 to the 16, so this can be safely used for about, like, I think it's about 64,000 times.

And, of course, that's not, it may be good for your use case, or it may be unacceptable, depending on what's your, what's your use case for this signature. Another example is this set that's meant to be, like, the optimized set for gas saving, and you can see it's very different from this other one, because here, there are, like, a lot of leaves, both in the forest and in the WOTS part. For example, the fork tree are… very, very deep. They have to do the 20 leaves, which is, of course, very inefficient for signing, because you have to compute a lot of hashes. But if you don't care about signing work for some reason, and you only want the verifier to be light, because you spend less in verification gas, and the signature also is smaller.

Here you just have, you can see here numbers, you have about, like. Half the verification cost of the fast Signer. And half the signal sites, indicatively. So, This, of course, this parameter set is not good for any use case either, because you have a lot of signing work, so if you have to do this on a constraint device, this probably won't work, or it will take an extremely long time. But it has some other use cases. And this is basically our take, and the fact that you have different parameter sets that allow you to do different things. Doesn't mean that you have to, like, to put, to, like, decide what's the use case that everyone needs to use, and decide the best parameter set, but…

Since we are, like, on the EVM, we can do account abstraction, and we think this is, like, a solution that's possible. And basically, by using smart accounts, you can have multiple signers authorized per one user. So, what you can do is, one user can, basically add, for example, a gas saver signer and a fast signer. They are both authorized for this account, and there need to be, of course, two verifiable contracts that… or at least a verifiable contract that's able to verify both the fast version and the gas server version, like, different parameters. And… at this point, the user can… For, depending on the use case that… on the situation that he's in, you can either sign with the fast signer, or the light signer for the… or the gas-saving signer.

And, like, this basically puts the least constraint possible on the parameter choice, because it basically leaves it open to the user to what it needs. And we actually built something like this, so I'll leave it to Matteo to show the… the… to showcase.

Matteo Vicari: a request for,

Antonio Sanso: statement? I accepted it.

Matteo Vicari: Okay. Okay? You can see my skin? Okay, this is our implementation on our showcase wallet. We do the same wallet using the first, and we just implement with SPHINCS. For example, what we can do now, we select the SPHINCS signing here in the menu. And then we can just, do a quick send, okay? This is Sepolia testnet. I just, take one address… Okay, this is a transaction. And then, when we, prepare the transaction, we can choose up, the setup of things. For example, in this case, we have first set up our, prepare inside our smart contract wallet. One is the standard. This, took on, my device, around 1-2 seconds for the signing time.

And then, is, cool data and gas. Then we can choose, choose, for example, a gas saver parameter, and this takes a lot of time for, do the stuff, but, for choosing is really simple. We just click here, and we choose, like, a video game, or just have, the, the quick signer of, the fast, that is, really quick, but is more expensive in terms of cool data and the gas. Or we just use SPHINCS plus, parameter, but, for example, now we go with the gas saver. We make the transaction. We wait. This is take the time for signing, and send the transaction to account abstraction, user op. We don't have a setup for gas sponsoring really optimize, so it takes a lot of time.

But the time is splitting from the approvation inside the blockchain, and also the signing part. So we are just waiting. And then when the transaction is complete, we can see inside the… ethers can always work. We're just waiting. So, we can, in this showcase, we have, for example, fork signing, different, and we use, in the same wallet, without changing nothing. It's really, simple to use, and the people can choose, like, the people chose for the gas they want to spend. For example, if I have to do a trade, I have a really tight time for the trade, like, for example, for the slippage or all this stuff, I can do the fast sign method, or if just I want to send ZoomMate to my friends, I can have

more relaxed time, and I can take a lot of time to sign.

Antonio Sanso: Matteo, I have a question. Now you have, like, these five different, forks. 4, sorry. Well, 4 plus 1, that is the fourth. Let's say you have this.

Matteo Vicari: Oh, yeah, yeah, yeah, before, and then the fourth, yeah.

Antonio Sanso: So, I mean, is the FORS… since, like, you have these four configurations. Is the FORS still making sense, or will be overlap with…

Matteo Vicari: The FORS, the FORS are more, cheaper and more faster, in terms of sign, in terms of gas, so are, always better, for this kind of application, but we need to rotate, in any case, the… the next signer. This demo, we add this part. In normal use case on our wallet, the DI is using always FORS, and then there is some problem, use things. with this demo, we just want to highlight the possibility to use SPHINCS for a different use cases. Right, right. But I'm…

Antonio Sanso: In terms of, like, so the FORS… like, if you take this four-parameter configuration of today, if you instead use FORS, it's always winning in any axis compared to the SPHINCS, or… Yeah.

Matteo Vicari: Yeah, Ford's always winning. There is…

Antonio Sanso: All the access, all the access. Yeah.

Matteo Vicari: all the axis… just one axis is not winning the budget. The budget of designing the FORS is, Around 3, 4. So it's, really different, but if we rotate the signing with the FORS every transaction, we keep up the budget growing. There is the only, the only limitation the FORS have now. In fact, Ali, if you can reshare the… this is the demo, I don't know if you want to see another signing with another thing, we can do. It's simple. Something nice to see, for example, in this case, for example, the signing with the… is this, and it's different. For example, if we use, the faster signing, the signature is more bigger, because, for example, we… with the faster signing, we try to optimize just for, go fast, with the signing time, and not the…

designated size or verification. This is relevant, for example, because it can be a use case, for example, faster L2, they don't care about the Senior size, because the L2-level data costs less, and just the Senior speed is important. So, it's different also, depends on the chains, depends on the L2, all different. If Felli you can share the screen, we have…

Alessandro Baiocchi: I think I'm still sharing.

Matteo Vicari: Yeah, so I just, huh? Sorry? Okay? Okay, no? Okay, yeah, go up, in the… there is all the parameter, there also… there is the FORS. For example, you can see the last one on this slide is the FORS. It's faster, cheaper, there are more compact signers, all the parameter, but the only problem is the reuse, so this is why it's important to highlight the difference. We have this.

Antonio Sanso: Okay, indeed, like, I missed that, actually, that's why I was saying 5. Actually, in your slide, you were already having the 5 configuration because of the FORS.

Matteo Vicari: Yeah, yeah.

Antonio Sanso: Excellent.

Matteo Vicari: And then, just the final slide, just for some talking about our idea and all this stuff, by Galo.

Alessandro Baiocchi: Okay, yeah, basically, how Matteo was saying, the reason for this is there are a lot of possible use cases for, like, different things parameter sets, and these are just a few that we identified, like, for example, cold storage has very different needs from normal day-to-day usage. For example, you… these are very, sparks transactions, so you don't care that much about, gas costs, and use budget too, because if you, like, if I say you can do maximum 32,000 transactions for cold storage, that's more than enough. So you don't need, like, heavy things for that. And… but you maybe want to optimize for signal to work, because If you… construct may be often done on constrained environments, so if you have to do a lot of hhashes on an actual wallet or MPC setup, you… you can actually facilitate the work if you choose a more lightweight signature.

Or, for example, you can completely change needs if you… if you use If you go to, for example, a hot wallet of an exchange, you have to do a lot of transactions, you cannot bundle them, you have to, like, maybe you don't care that they are extremely fast, but you don't want to pay a lot of gas, so you optimize for the total gas cost of the transaction. And another possible use case, if you, like. it's your wallet, you decide you… you don't… you don't trust NIST level 1, you want NIST level 3, you can actually, like, if you… if there is a verifiable constrain, you can put a signer that uses a parameter set that gives you strings NIST at NIST level 3, and… and use it. So…

Matteo Vicari: Another.

Alessandro Baiocchi: He's like… Yep, yeah, that's.

Matteo Vicari: Another stuff to highlight is also if you want to use an MPC with SPHINCS. have a really high budget is a lot of hashes, a lot of hashes in, MPCs is really hard to do, take a lot of time, but if you tweak the parameter around these needs, you can also do an MPC with SPHINCS, really fast, sub-second. So, there is a lot of, a lot of combination that people can choose and, highlight and use. So, for us, our take is not one set of… one sphinx parameter that is good for all, but depends on the use case you want to use inside the chain. And, that's it. This is our idea, and thanks for, the attention. If you have questions, we can answer it, other way.

Antonio Sanso: I have one, actually. And… is, so, if we take in consideration the fact that the… for Ethereum, we will have aggregation. Probably the thing that works better with aggregation will be the fast verification, so having less hashing for verification, right? Because having less hash for verification means that the ZK proofs Will be… will be cheaper.

Matteo Vicari: Yeah.

Antonio Sanso: So we're…

Matteo Vicari: this is something, we can just have the gas saver, but for example, if you… the gas saver is also take less gas for verified, this kind of signature. The problem is, for example, this is take a lot of time for signing, so, maybe it's hard to… to use, because, for example, it's okay if I won't just send it to another person, or just send money, but if I want to trade or stuff that requires timing. it's hard to have, this, big, signature. For example, this, the gas saver parameter is, 100, 100 million of hashes that I have to do. And depends also, this capability depends also in the wallet you have to do. Because, for example, now we have, this number, 10, 50 seconds, inside our extension that have, a very.

optimize Rust, signing method for make parallel lhashes. But, for example, if you have to do this inside a ledger, it's really hard to do all these dhashes. So, there is a lot of combination, and I think with the aggregation, it's more easy. to think, if, for example, I, I choose you, you can choose, for example, the… the set of parameter you want to use. It's like, like choosing, the… the… de… the fee you want to pay. So the idea is, if you have verification, you have aggregation, for example, if the prover have to do more hashes, you can pay more. But if you pay more, maybe the signer is faster. So, depends, also, these can adjust around, also, the aggregation.

And another important stuff to highlight, all the stuff we have working now, is, working with SHAKE, SHAKE, sorry, but, you can swap and use another ash function. The number, remain the, the, the same, so, all the stuff is the same, just, change the, underlying, function that, we're using for the hashes. For example, the sphinx, plus parameter, go up. it's, what we implement is not, really SPHINCS Plus, because we, for example, use SHAKE, and I use SHA2, or, or the Rush function, because in, ethereum, for now, we have this, precompile. With aggregation, it's, different, so… VDIs have the flexibility to the user, and, for the work.

Antonio Sanso: Anyway, I have one comment and two questions. So the companies, like, in my opinion, when… if this will really fly, in my opinion, the default should be the one that is aggregated friendly. But then we can discuss this in the future. But my question is, like. I… you… you showed that you can change all these four different… Type of, situation. But is the public key the same?

Matteo Vicari: We, this is another important, stuff to highlight. We use account abstraction. So, we don't care about public key or all the stuff, for example, all, like, Shrimps does. Because we just, put inside our smart contract wallet another sign. It's another entry in our, mapping for the signing. So, we don't need to have the, the same, public key, because we have the same address. So, for… make the same address and have more signing, we just add more stuff inside our code.

Antonio Sanso: So, am I correct?

Matteo Vicari: AC.

Antonio Sanso: Am I correct to say that you actually don't know the private key of your address?

Matteo Vicari: Yeah. This is the idea. Okay. We never know, because we create our address, using crate2, it depends on the parameter. The parameter for us, a lot. We do, for example, a post, I think, 3 weeks ago, that also highlight, for example, to make this kind of architecture work in a different chain. I'm keeping the same address.

Antonio Sanso: So you really, you really don't know the private key of your address?

Matteo Vicari: Yeah, we don't know, because it's a smart contract.

Antonio Sanso: Yes.

Matteo Vicari: In other implementation, for example, what's happened inside the Bitcoin, you need. But also there, you can also have more stinks there. Because, for example, you can just make a big root using different route of these different things, and, like, you add more and say, okay, if there is one of these, I can use these or these. It's… it's like a multisig in Bitcoin.

Antonio Sanso: But, I mean, a stupid question here. If you start from a seat, you can always… I mean, if you have your seat, you can always, like, recover and… yeah, okay. Yeah.

Matteo Vicari: We… the seed, the entropy we used to generate this wallet, and also all the ephemeral FORS, the fourth, is a B44-like. We just have, tweaked the, for example, the zero. that use, for example, in Bitcoin, we use just for the SPHINCS. So, the 01 is SPHINCS, with this parameter, the 02 is SPHINCS with this parameter. the important stuff, they have to start with a different entropy. We can just derivate from the same, same, I can say private key, but it's not a private key, because then there is possibility to have collision. So, it's important to have different before, different things, but it is simple, and you can just, use for starting your wallet.

Antonio Sanso: And the last question, and then I open the stage if someone has another question, is… I'm not sure I've seen in your access the keygen time. Is that part of it, or… All the results.

Matteo Vicari: We… we don't put the… the keygen, We have to do, but it's similar, for, designing part. So, it's, something, similar. I don't know, if…

Antonio Sanso: You do a key gen every single time, you're telling.

Matteo Vicari: No, it's not, SPHINCS, we're signing a transaction with SPHINCS. Depends on the message you are, want to sign. For choose, the… the FORS underneath, okay? So, when you just do the signing part, you have to recompute all the stuff. I don't know, Alessandro is better, to… Oh, yeah.

Alessandro Baiocchi: I was just… yeah, sorry. I think the point is… Back for the FORS? FORS? The… since we rotate each, like, each transaction, we rotate the signer, we need to… do a full key gen of a new fork, for each transaction. For these things, we, like, we do not rotate the signer, of course, because it's not a few times. So, the key gen, like. It's, yeah, I'd say it's the… the signing time is actually, like, it's… It's the work required… what we here call, sorry, what we call here signing, like, if you see in the lower left corner, like, signing log. These are the hhashes required to, like, to build the full tree. So it's basically what we would call Kijan, I say, I'd say.

And… and then, like, if you, like… if you already knew the whole tree, you actually wouldn't need to recompute it to sign, but we put it in signing time, because it's, we're assuming you don't store the tree, you need to compute it to sign. That's…

Matteo Vicari: because storing the tree is really hard and expensive, there is a lot of data, so it's better to just recompute the part of tree you use for signing this message. Because it's important, we don't put inside our slide, but in SPHINCS. The fourth, you have opened the last part of the tree, it depends on the message, so it's like a random value on the message, so it depends on the message, so you can… if you… you have in memory all the tree. It's faster, but it's better for now, for what we know, to compute it every single part, every time you want to sign.

Antonio Sanso: I still… I still don't understand how the keygen will work. I mean, that's the thing, when you're actually… when you actually change between the four… the four combinations. I mean, what do you do? You, like, you generate… I mean, on the fly…

Matteo Vicari: Yeah, we, we put… you imagine, when we create the wallet, we put, the root of the SPHINCS. Inside our smart contract, and this is something that is verified. So when we sign, we just change the signing part. It's all… this part is off-chain, so you can do really, really fast. And then you compute the signing, and you prepare the signing, and you… Put inside the chain.

Antonio Sanso: Isn't the keygen four times different? You have 4 key jets, no? I mean, you have four combinations.

Alessandro Baiocchi: And maybe, yeah, maybe I… maybe I see the confusing part here, like, the fact that, like, in the demo Matteo had, like, the four, modes on the same wallet, like, they are actually, like, yeah, they are four distinct signups, they… they do not share anything with each other. Like, for example, you, you may have let's say you have an Augsburg wallet, you may have an Augsburg wallet with only one of those signers on it. And you have only that mode on that wallet, and on your laptop, you have, like, the extension, which has Other signals on it. And each signal has its own, like, parameter set associated, so you… they are called distinct signers, yes.

Antonio Sanso: When do you do the key gen? Like, when you install the wallet, or on the fly, when do you do it? The first time you use it?

Matteo Vicari: The idea is, the keygen is something… you… you have, the stable… the stable part of, the process is, the entropy you use. So you start from the.

Alessandro Baiocchi: Yeah, sorry, it's, that's on the fly, because, yeah, in some cases, you may be able to store the whole, like, the whole data, but in some cases, it's a lot of data, so it's, yeah, you only store the secrets under the…

Antonio Sanso: So, what you actually do when you sign, you do keygen plus sign.

Alessandro Baiocchi: Yeah, in this case, yes, right?

Matteo Vicari: Yeah, the keygen's design, I can see. Because you have to think, when you film, you have signed with the FORS, you just open the leaf. So the signing part is really fast. The keygen is the stuff you have to recompute for all the parts.

Antonio Sanso: But I will imagine that the four public keys are in the smart contract.

Matteo Vicari: Yeah, they are in the smart contract.

Antonio Sanso: Okay, so probably when you deploy the smart contract.

Matteo Vicari: You have to complete it one time, yeah.

Alessandro Baiocchi: Yeah, of course, yeah, when you deploy, you need to do it once for each signer, yeah.

Antonio Sanso: Four times, four times. So the kijin, the real keygen, actually, it happens when you… The first time, you put the seed on your wallet. Yes. Because you have to create… okay. I mean, I think you should add that this as well, somehow, because I mean, not in the… I mean, at the end, you will level 4, so you have, like, 4K gen to do, basically. For the wallet you showed, you have four keygen. So, maybe installing the wallet might take a bit of time, but usually you install… you have the fork combination only on the desktop, and the problem is fast.

Matteo Vicari: Yeah, yeah, the more important part of this presentation is the flexibility. We don't want to say, okay, this is the best set of the parameter for us, because when we start working on MPC or other stuff, we see, okay, but… If we change the parameter, we can arrive at this implementation. If we want to just use a SPHINCS plus parameter. it's impossible. So, it's like, have the flexibility, and, we think about this when we see the NISTA, the NISTA… they also have four, for example, their two different set of parameters, fast signing and, cheaper, stuff, so…

Antonio Sanso: Okay.

Matteo Vicari: we're starting to have this idea.

Antonio Sanso: Thanks a lot for the demo. I was actually wondering if anyone in the crowd has some questions The chat is open, the mic, we can open. Comments, question? Okay. Looks like not. Alessandro, were you saying something?

Alessandro Baiocchi: Yeah, yeah, sorry, just… this was just one quick note about what you were saying about, like, the setup might take some time, yeah, of course, it's, that's possible, but, another thing to keep in mind is that you're not FORSd to, like, add, like, for example, in the whatnot I was showing, there were four modes. But you're not FORSd to set them up at the same time. Like, this is just our demo implementation, but the fact that you're using a smart contract basically allows you to, like, if at some time you want to add a new signer. you can do it. Like, you can just… you can write a function on your smart contract that says add signer with its own dedicated parameter set, and then you can do it after the initial setup, anytime you want. Basically, you can add the new signer, or remove an old signer, or basically handle how you sign your transactions.

Antonio Sanso: Makes sense. No, I'm not too much worried. It was not part… since the keygen was not part of the slides, I was just wondering.

Alessandro Baiocchi: Yeah, yeah, you're fine.

Antonio Sanso: I really like your demo. If you don't have anything to add, then there are no questions. I have one more announcement to do, or same announcement. And it's basically, like, as I said, I want to avoid any analysis paralysis. I think it's not for now, time for now to start writing something. So, I'm gonna… The plan is to fork the ERC repository of Ethereum. And start a New Year's seed. That start to cover what we've seen so far. I will post the link on the Telegram channel. If anyone… I'll start this new ERC. If anyone wants to contribute, just ping me, and I cannot… to the… to the list, or we can go doing PRs and so on. The plan is, again, to start

with, some version of, SPHINCS, and, and cover all these details that are about, like, an abstraction, this, create tool, this potentially adding the key rotation thing, as an ERC, because as we are not doing EIP, we are not doing, any precompiles, all this should be covered by ERC, so we should really specify the details on how to sign and, you know, all these kind of things. And again, I will plan to start working on it Monday, and Monday will put, A link on the channel. Right. So… If no one has any more questions or comments, we can wrap it up and see you in two weeks.

Matteo Vicari: Yep.

Antonio Sanso: Cool, thanks a lot again for the demo, Alessandro and Matteo. Thank you, have a nice day. Bye-bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.