Post-Quantum Transaction Signature Breakout #17

Transcript

Gianluca Felli: Hi, everyone. Hi, everyone.

Antonio Sanso: Hello, everyone. Can you hear me?

Matteo Vena: Hey, Antonio. Yes.

Gianluca Felli: Hello, hon.

Antonio Sanso: Cesar will wait a couple more minutes, To wait for people starting a bit late. I will test my setup in a second. I'll just have a quick… Slides to show as you're off. Let me share my slide. I assume you've seen my slides, right?

Gianluca Felli: Yep.

Antonio Sanso: Cool, cool. One more minute, then we start. Let's see if people are here. Right, let's start. Today is 28th of October. Welcome to the post-quantum Transaction Signature Number 17. quick recap of the previous and today topics, as I've been telling the Telegram channel, is we're gonna try to choose some default parameters for Lean SPHINCS. The agenda is basically pretty…

these two presenters, Emile, that, is gonna show us, sphincs.art, and Matteo Vena, or someone from, Reval Project 11, that they have their version of, some, SPHINCS parameters. Reminder, this is a Telegram channel where we communicate about Stuff related to the post-quantum Transaction signatures. Here is the QR code, or the link, the one you prefer. And before to start, I just want to… to show a quick things that happened between last call and, this call, we launched thanks to, Gianluca and the Nethermind guys. We launched this testnet version 03 on Daisugi. It's pretty primitive, but we start with a, simple version of, EIP8288, so here we just show one transaction where

we have a proof of… a STARK proof of 20 transaction signatures using a version of SPHINCS. Again, more to come, more advanced features, and we're gonna have a faster and more professionalized, testnet after Devcon At the moment, the main issue with the testnet is that we don't have traffic, so we're gonna have some tool from EthPandaOps that will spam transactions, so we will have better benchmarks. And yeah, that's basically it from my side. Really, without further ado, I will give the… stage to Emile. But it's so good.

T. Wambsgans: Thank you. Hello, everyone. I'm going to share my screen. Can you see my screen?

Antonio Sanso: Yep.

T. Wambsgans: Okay, so I'm going to present sphincs.art. So it's a website that you can go to, and that, is useful to understand the trade-offs for choosing the parameters of Lean SPHINCS. It's… Kind of opinionated, because you don't have a lot of toggles, you cannot do everything you want, but the idea was still to explore what are, in my opinion, the… currently the biggest questions to answer. So, I will go one by one on every of the possible choices to explain the implications. The first choice is the lifetime of the signature, meaning the number of hashes, sorry, of signature that you can safely sign, and staying above 127 bits of security in the ROM, typically. And, it's quite conservative, like, the default is to the 30, it's quite… it's a billion, in the sense that, from a typical user of Ethereum, you can't forget about it. It's so big that there is no chance you will sign a billion times on the same account in your life.

Mmm… But still, you can play with it a bit more, or a bit less conservative if you want. And the more conservative you are, the biggest the signature and the slower it is to sell. Like, you have to pay a little bit the price of the lifetime. The second choice is, the shape of the SPHINCS. The uniform is the… vanilla one, in the sense that SLH-DSA, essentially, except that the tree is imbalanced, but you have a list, like, in this case, 3 small XMSS layers, and, KeyGen only needs to, to, to, you only need to KeyGen the top XMSS layer, at KeyGen, so it's, it's kind of fast. But it turns out, with some caveat, you can, it's possible to.

go to only one big XMSS layer. Which is, by the way, what the NIST recently proposed as a new candidate for SLH-DSA. And essentially. By doing so, key generation becomes extremely, extremely slow. But the trick is to use, pruning, which is, pruning has been, like, developed on SPHINCS by, by conduition.

Antonio Sanso: I think that Emile… Okay, we'll wait 30 seconds, let me be pinging. Emile, are you back?

T. Wambsgans: Sorry, sorry, I'm like.

Antonio Sanso: No worries. Yeah, yeah, now you're back, yeah, sure.

T. Wambsgans: So, sorry, my connection dropped. So, pruning has been developed by conduition, there's a blog post, I think it's linked Here, if you click here. And the idea is that, if you are a constrained device, you will not keygen all the WOTS, you will only keygen a small subset of them. Typically, if you are Ledger, you will keygen roughly 4,000 random signatures. so a small part of the trees, and you will fill the rest of the tree with random surrogate nodes. And this way, you can have key generation, which is most… much faster, but The main drawback is that you leak privacy, because typically, if you sign a lot, someone can see that all the signatures reuse the same few-time signature, and so that, in some way.

It… if you sign a lot, it leaks the information of the size of your pruning subtree. So that's the, in my opinion, the biggest drawback. Then there is the hash, so essentially three hashs available, and then there is the type of the few time signature. The vanilla one is the FORS, as in SLH-DSA, like a forest of random subset. But it turns out, you can do fancy stuff, and… If you're fine with doing fancy stuff, you can have a two-layer forest of small WOTS, and it gives you, essentially, more, more performance, but, it's kind of novel. And also, it's, like, 2X less MPC friendly, because In FORS, roughly 50% of the hashes are secrets, 50% are public, so you only need to run 50% of the hashes in MPC, while in this scheme, in this FTS, close to 100% of the hashes are secrets, and so you have to run MPC on all of them.

Anyway, so the website shows you the… the performance of signing, key gen, blah blah blah, for various types of device. It also shows you, some threshold performance, assuming… and also I want to say that, assisted pruning and, threshold is based on an idea of, Revolabs, which is essentially the idea that you can, I think, I assume you already know this, but you can generate in advance, and you can generate some FORS in advance, and you can delegate computation from the Ledger to the host using a STARK. Anyway, I will… I think I will try to focus the rest of my talk on two points. So… I will quickly go on the two novelties, I would say, or stuff that are not… that are probably not clear for everyone.

First, the… the few-time signature, so the forest of WOTS. it was, submitted to the competition sig.golf by Jonas Nick from Blockstream, and the idea is that instead of having some secret preimage in your FORS, you will instead use very small FORS… sorry, very small WOTS. like, 6 chains of height, 5, for each WOTS. And, the encoding will select, some… some, like, one level on every chain of… on every WOTS. With target some encoding. And without grinding, in the sense that you don't have to retry until every target summary expected. Because, there is a non-injective mapping from one byte to the set of possible encodings, on a WOTS, meaning some encodings are repeated.

But, it turns out, if you repeat only the, the less likely encoding, I believe, yes. It's far… it's fine from… sorry, the less forgeable encoding, sorry, it's fine… it gives you very good properties in terms of performance. And so the performance is roughly, more than 30% better than a comparable FORS. But… As I said before, the drawback is that it's novel, so it would require new security analysis in the standard model. And, it's less MPC-friendly, and, it has a higher variance, like, meaning, meaning if you sign a lot, and you study the concrete security that you get after signing a lot. This number is a random variable that has a mean which is above 127 bits, but still it has some variance, and it's a bit worse than FORS.

At this level, anyway. It still gives quite a lot of additional performance, as you can see. Then there is pruning. So, I was initially, like, a pruning bull, to be honest, but, recently, some people told me that privacy was kind of an issue, because typically, if you're a Ledger. If you prune, like, typically would… you would… the subtree, is, like, 2,000… is, 4,000, non-pruned, few-time signature. And, if you… it turns out that, when… if you sign a lot, you can, detect that, it's a Ledger, because you will repeat You will end up reusing the same few-time signature multiple times, so people can distinguish, and it leaks the… it leaks the size of the subtree that you used.

And… you can… my point… the point that I want to communicate is that, I agree that it's an issue, but I believe there are some partial solutions. So, first of all, the naive way of, choosing, as a subtree, a continuous 2 to the B, few-time signature is a bad idea for privacy, because all the selected indexes are close to each other, so it obviously leaks a lot of information. So one would have, to select the… for the set of few time signatures, a much more scattered set. And it turns out, it's possible, to select the… Kept a few-time signature in a totally random way, and still to have efficient surrogate node algorithms. So this part is kind of solved.

The issue is that when you sign a lot, you end up reusing the same few-time signature, which happens with very small probability if you have a full key, meaning you have kenned everything. And it's, for the parameters displayed on the website. It's, like… If you sign roughly, like, 75 times, the adversaria has, like, it's possible to distinguish you with more than 50% advantage. Meaning, if you don't want to be distinguished, if you want to keep privacy, you would have to sign no more than, let's say, 30 times. But there is, again, another partial solution, which is the following. If you are fine by having, some semi-trusted, I will come back to it later, state, meaning you… SPHINCS is a stateless signature, but if you are fine keeping a bit of state, and in practice it means

Keeping track of the few time signature that you already used in the past. And if you do not reuse a few times signature as long as The number of used few-time signatures is not more than half of all your available full-time signature. In this case, you can get more than 2,000 fully private, meaning no legal information at all, signatures on a Ledger. So I repeat, If you have this seminterested state, you can have 2,000 signatures on a Ledger that do not leak any information. The cost is that you will need to grind a little bit more at signing, And that… If an adversary can control this state, it cannot forge But it can, first.

leak the size of the subtree, meaning you lose the privacy guarantee. And it can divide, roughly, the lifetime by 2. Meaning, if you lifetime on sphincs.art, it's typically 100,000 signatures for a Ledger. you would have only 50,000 signatures for a Ledger. But if you are fine with… like, it's kind of a compromise, but it still gives 2,000 signatures on the Ledger, which is, for most users, probably practical. But still, it's not perfect. Like, it's, again, it's a… it's a compromise, yeah. That's it for me, thank you.

Antonio Sanso: Thanks a lot, Emile. That was a really nice presentation. Thanks a lot for the website as well. I've been playing with the website for the last couple of days, to be fair, looking at all the different, toggles. Do we have any questions? Or we want to wait, Matteo for the presentation, and then we do them together, as you guys want? If there's any question, I will… I will take it now, and then we move.

Justin Drake: Can you explain the 2x degradation in lifetime? I didn't quite understand where that comes from.

T. Wambsgans: It's because, if an adversary controls the state. attack is to typically, like, the adversary will say that the state contains Few-time signature that you didn't sign, and it claims that you are… that you signed, but actually the state contains a few-time signature.

Justin Drake: That's true.

T. Wambsgans: sign, meaning you will use more the signature that you already signed. And so, in some way, it kind of divides by two The size of the subtree, because you will end up using the other part, and so you end up having an effective subtree of size divided by 2, and the lifetime is roughly proportional to the size of the kept subtree.

Justin Drake: I see. And is it an attack where… so let's say the attacker can control this, the state? Can't it just, put in the state all signatures except one, and kind of force you to open a.

T. Wambsgans: Yeah, but…

Justin Drake: specific location?

T. Wambsgans: That, the key point was to say you should always have the state to be less than half of all the available few-time signature. And this way, you… the advantage of the adversary is bonded by a factor of 2. And you can… it's a trade-off, but, like, 2 is the natural choice. If you don't want to lose more than 25%, you can have a smaller state, but then you only have, I don't know, 1,000 signatures with privacy.

Justin Drake: I see, very interesting.

Antonio Sanso: Right? Thanks a lot, Emile. So let's try like this. Let's go to the presentation of Matteo, and then we can kind of discuss in the end. Don't allowing.

Matteo Vena: Okay. Hey, everyone, and thank you, Emile, for the presentation. It was actually very interesting. As a quick intro, many of you know it already, since I've been following these calls, or were present at Cambridge, but I'm from formerly Revolabs, then acquired by Project 11. At Project 11, we work a lot on these, set of problems, let's say, and we have done a lot of work trying to figure out what kind of parameters could be relevant for the future, ethereum, these things. But most of our work is focused around, specific use cases, such as hardware wallets and MPC. And obviously, this comes at a time where it seems MPCs are becoming more and more relevant. I don't know for who saw the news today, but it seems Google is entering the…

crypto market with an offering of an MPC, and actually a security platform for digital assets, so it's never been more relevant, I would say, to keep compatibility with this, With threshold signatures in general. So, in terms of… Where we see… so, can you see my screen, first of all?

Justin Drake: Yes.

T. Wambsgans: Yes, sir.

Matteo Vena: Great. So… These are some general guidelines. So, again, we are optimized for constrained hardware solutions, and also for older models of hardware signers. Given the circumstances, it's also very much to be expected that people are gonna try to extend the lifespan of existing devices for a while. We are trying to maintain full compatibility with SPHINCS-G, and for those of you who don't know it, SPHINCS-G is a SPHINCS+ variant that we developed. And there is a paper coming next month at some point, hopefully, that explains the construct, but it basically allows to… allows constrained devices, such as MPCs and hardware wallets, to sign extremely fast with hash-based signatures and SPHINCS-style signatures. When I, when I, when I say extremely fast.

although there is some operational machinery in there, I mean 200 to 500 milliseconds to do a signature, with some security to be attached, but in general, in the realm of a couple of seconds. We are not considering signature size a strict priority anymore, considering aggregation is coming, and it's part of the roadmap, so it's important, but not the number one priority. And in general. when I say signature size, I still refer to stateless schemes, because obviously we could get much smaller signatures, as all of you know, by going stateful, but at this point, we're really, really trying to avoid state in the security sense of the term. And then there's aggregation friendliness that is relevant, but our opinion is that since aggregation is not coming tomorrow, there is still going to be a lot

We are going to see a lot of improvements down the road. So, I don't think we should stretch the signature itself to the point of being impractical to favor aggregation, when aggregation is… and everything at this point really is moving so fast in terms of news and developments. We think friendliness is important, but doesn't have to be the number one factor. The theater budget has to be very large, so even Even if you don't know how many transactions you are gonna do, you shouldn't worry about it unless you are a very specialized type of user, for example, an exchange running a couple of wallets, or a number of wallets for millions of users, or a bridge, or a stablecoin issuer, or something like that. At the moment, we are considering anything greater than 2 to the 20, or equal to 2 to the 20, to be…

Fine, but the parameters we're going to propose here are all bigger than this. And pruning? Emile gave a good explanation. We have been thinking about this and sharing details about these privacy implications and other problems of pruning for a while now. In general, we are not against it. But we believe, as stated before, that it should be optional. If we design a scheme that can benefit from pruning, and people really, really Understand the security of pruning, want to do pruning, think pruning is a good idea, then they should be able to do it, but it doesn't have to be, in our opinion, the backbone of a scheme or a decision factor. We have this, tool that you can find at research.project11.com, when you can model your own version of SPHINCS+ signatures, and then, once you're done, you can copy the link to the share button, and it's gonna carry all the parameters that you

put over there, and soon we are going to support, different features that you have seen in Emile's presentation, so we are going to expand the tool to support other variations of SPHINCS that could be helpful to model Lean SPHINCS. So I'm gonna share… showcase two parameter sets. This is the first one. This is… this was our starting point in the past, and that's what we have used for a lot of our tooling and experiments, including MPC signatures with our MPC design. In general, we started from the idea that we should stay closer, at least, close, to SPHINCS+, or that was our… initial design goal, and we modeled this signature to be balanced. So, as you can see over here.

We have definitely a bigger Winternitz parameter compared to what you see on sphincs.art, to keep the signature small, basically. And we have smaller FORS. Smaller… smaller FORS are very helpful in the context of MPC, they are easier and allow us for a better signature size. And CAIC is the hash function of choice, for a variety of reasons, but in general, one of the strong reasons to favor it over other hash functions so far is that it allows for less MPC rounds, and having less MPC rounds in the MPC context is extremely important when you deal with the Custody of a very high amount of assets, and you might have a very sophisticated type of setup.

This parameter set has a lifetime of 2 to the 24, size is, 5.5, Roughly, and this is the number of permutation. Now, when we say permutation, we are actually using the average, so it's just like you saw on sphincs.art, it's kind of the same. This was the balance that we had achieved before… before recent proposals. And again, I'm… I'm gonna share this link in the chat later on, where you can just see how this looks like in greater details on the tool. Later on, as we kept trying to understand how we can offer maximum compatibility with what everybody else is proposing, we kept working around this concept. This is the key concept for us. Our desired approach is that there is one single standard verification and aggregation process when you send a transaction on Ethereum, and if your hardware is good enough, fast enough, new enough.

or can work with Lean SPHINCS the way it is. for example, in hot wallet, you just sign, and it goes straight to the network. But if instead you have a constrained device, such as an MPC or a Ledger, you keep compatibility with the same verified and aggregation process, so users can enjoy maximum privacy, especially considering that The more you go up in the spectrum of custody setups. The more you probably want privacy to be there, to be involved. And so this is a second parameter set that we are proposing that is kind of… along the lines of what is being proposed on sphincs.art, with some changes. Now, FORS is now supported on sphincs.art, so it's there, it's an option, and that's what we want to go with, because without FORS.

The MPC is strictly worse. Just replacing… this is, again, one of the principles, using WOTS in the MPC instead of FORS is strictly worse, and so we believe FORS should be kept over there. Now, newer, newer, Schemes, such as the one that came out of sig.golf from Jonas Nick at Blockstream are definitely interesting, and obviously security still has to be proven alongside viability of the scheme, but in general, FORS is still a better pick when it comes to MPC. And what you can see here, there is a… there's some differences compared to what you see on sphincs.art, specifically the FORS are smaller, again, to give some advantages on the MPC, but we went down dramatically on the Winternitz parameters, so it looks…

I would say at least similar to what is being proposed now on sphincs.art. And in terms of the number, we get a lifetime of 2 to the 24, the size is pretty much similar and comparable, and permutations are basically comparable with the schemes being proposed. We believe it's important to make an effort in trying to maintain compatibility with systems that could give us MPC support, hardware devices support, and in general, a good coverage across the ecosystem. And… although I think there is going still to be a lot of work to do to find the perfect Lean SPHINCS, we believe this is a good… this is a balanced parameter set, that could sort of meet the verification requirement, size requirement, lifetime requirement, at least in the middle, but still allow for pretty decent

Usage across constrained hardware. And yeah, this is, this is it. This is what we wanted to showcase, and again, both parameter sets work for us, but we are trying to Come along with something that is more compatible with other proposals.

Antonio Sanso: Thanks a lot, Matteo. Any question?

T. Wambsgans: I have a question. Could you please come back to the third slide, please? I don't… because I understood that the one-time signature that you were previously using was WOTS, but not WOTS+C. Like, it was WOTS with checksum, and that was the reason that you had the average case and the worst case. So, if you're using WOTS+C, what is the reason there is a worse case and an average case?

Matteo Vena: When you say previously, you mean the presentation we had in Cambridge? Yeah, it was with WOTS+, if that's what you were referring, you remember correctly. We are… Let's say, evaluating using WOTS+C, just to save some… something on the signature size, but it's not set in stone. Like, this is not a strong requirement. We are okay using WOTS as well.

T. Wambsgans: Okay. Okay.

Matteo Vena: Then, I don't know, because we just updated the tool, so I don't know, Alessandro, if we wanted to add something, and if you can hear us on this, On the way we were showing the parameter before.

Alessandro Baiocchi: Yes, sir, can you hear me? Okay. Yeah, so yeah, sorry, I think that's just, the, the, you're right. The, the, the, the, like, the reason we, we see, we show, worst case averages, because we, in the tool, we still have, the WOTS+, no C. And… but we computed the numbers for the plus C variant, since we, like, we recently, decided that plus C is, like, a small enough change from SPHINCS+ that it's, a good addition to the C2 in SPHINCS.

Matteo Vena: Yep.

T. Wambsgans: Okay, makes sense. Thank you.

Antonio Sanso: Okay, let's do a kind of meta comment to start the conversation. if we see, like, the version 2 of Emile's sphincs.art, and the last slide of Matteo. I think that there is not a huge amount of difference between the two. To me, like, it looks like the These two slides converge towards an approach that is kind of conservative, for now, and I don't know which one of the two, but we can start with for the… For the… for the… Next version on the testnet, but it doesn't look like too much difference to me, between the last slides of Matteo and the version 2 of Emile. Who, What… from my perspective, I would like to choose one today, and so we can include this in the next version of the testnet.

And… but I don't know which of the two, because they're so similar, that it doesn't change too much, to be fair.

T. Wambsgans: I think the main difference is the lifetime, I think.

Antonio Sanso: Exactly, yes, yes, exactly. That's the only difference. Indeed, like, the… the lifetime is, makes the size smaller on the Matteo's version. Justin, I see you raised the hand.

Justin Drake: Yeah, on the lifetime, I'd be curious to hear if Project 11 chatted with the Bitcoiners. as far as I understand, Shrinks currently has a lifetime of 2 to the 40, and in Cambridge, Mikhail Kridinov was suggesting that You know, he would potentially be open to different numbers. but I guess… You know, presumably the Bitcoiners also want MPC friendliness. So, would it make sense to have a three-way discussion, Ethereum, Bitcoin, and MPC providers, to come to consensus on a good lifetime?

Matteo Vena: Yeah, we had a good conversation on this with him during… during Cambridge. It was very interesting. I just don't think there was enough… thinking going into the MPC part. On Bitcoin, actually, my take is that the lifetime, like, 2 to the 24, is perfectly fine, and that having a much bigger lifetime doesn't add much in terms of… in terms of, benefits for the network, especially in an environment where there are even less transactions than on Ethereum. But in general, I think more… giving more relevance to the MPC is going to be a good advantage in the long run, also considering that the same advantages usually benefit us from hardware signers and other constraints. It's not just those constraints that I've mentioned.

Antonio Sanso: Right? Nico? Nico, I think you raised the hand, so I don't know if it was a mistake, or you have some question.

Nico: Yeah, I think I was muted. yeah, I just wanted to say, I think the proposals are quite similar. But, yeah, if we're willing to be okay with a smaller lifetime, which I think is a good idea. We should also consider just, doing some… More efficient version? With the large H and K. So if the trade-off is, like, MPC friendliness versus speed of the network, I think we should… We should, care about, speed of the network first. MPC friendliness is more of a nice-to-have, but it's also… it can be given by some other techniques, so I think if we bring this to our DAS… With the trade-off of basically everything we… sacrifice here is some hardware requirements, decentralization trade-off, and speed of the network. I think we will end up with

proposals that are closer to the last one that Revolabs presented, but with, even more conservative on the… size of the FORS. So, this is just my take. I'm okay with starting with a very conservative option. But if we frame the trade-off as being speed of the network and decentralization capacity, I… I think we're gonna end up with, more optimized versions. EF.

Antonio Sanso: Thanks, Nico. I was actually wondering if there is anyone, having an opinion, apart the people presented, about the lifetime of the signatures? There's only one… Having an opinion? Like, what would be a number they would feel comfortable with? Any… Is there any sort of…

Nico: 2 to the… 2 to the 24 is very fine. It's just, Like, the number of signatures that it gives you, it's… it's huge, and any situation where something would sign that much, it's probably an automated system. An automated system can automate the rotation. So, honestly, I think every… anything above 2 to the 23 is fine.

Antonio Sanso: I mean, will you be… will you be willing, like, to, in the next days, to add a next toggle with the 2 to the 24 to your parameters to see how they look like? I will expect the size to go down.

T. Wambsgans: Yeah, sure. Yeah, definitely. I can add to the 24, yes.

Antonio Sanso: Just to see how it goes.

T. Wambsgans: Yeah, yeah, I will.

Antonio Sanso: What I like as well of your, sphincs.art… I mean, again, I'm telling you, like, this parameters looks… the last slides on Matteo's Lean SPHINCS, the fold looks pretty similar. What I like of your part is as well that the three XMSS, they have a different size. And the fact that you are planning to cache the, the, the, the top, XMSS, I think it's a nice idea, but it's… I mean, we are really bike-shedding here. Justin?

Justin Drake: Yeah, different topics in a lifetime. I was just curious about the… the forest of WOTS, and this is a question for Matteo. If I understand correctly, there's a 2x performance degradation for MPC, and Matteo made the good point that, you know, aggregation performance is going to increase, you know, maybe 10x over the next few months as SNARK technology improves. But presumably, there's going to be a similar effect with MPC, where the technology just keeps on improving. So, I guess the question to Matteo is, do you see the 2X degradation kind of a bottleneck for MPC, and if so. So, if not, like, would you be open to, To… to a forest of WOTS?

Matteo Vena: Well, the main issue is that it's not like a simple, you know, we do not have enough computational power and that's gonna increase type of problem. It's a structural thing with WOTS. You get much less sequential hashes that you can do. And so, even if you deploy more expensive machines, you still get less benefits. And with FORS, it's just much easier, it's better overall on several axes, and we do not see the speedup affecting all axes. So, in general, we still think FORS are, A much better way… a much better option. Obviously, we are open to experiment, like, don't get me wrong, like, there's still time, and maybe this new scheme from Jonas is gonna get security proofs and everything done, and maybe there's a world where we can do benchmarks, but from analysis that we have done already.

by following sig.golf, we just don't see the speedup happening the same way we see the speedup happening at aggregation.

T. Wambsgans: I think, for context, there is already security proof in Lean in the ROM, just what's missing is a standard model security proof, but to have it, we need some ad hoc properties, the same way, FORS has an ad hoc property to make SPHINCS secure in the standard model.

Justin Drake: One thing that we're considering doing is, having sig.golf 2, And… I'm wondering if we can formalize the MPC constraints in Lean 4. for that next iteration of the… of the competition. Because maybe there's a hybrid, between FORS, and… tree of WOTS the kind of… has a… is a strict improvement over FORS. But doesn't have the MPC downsides.

Antonio Sanso: All right. Actually, I would like, if Daniel doesn't mind, has been bringing a kind of, valid, opinion on the chat, and he's saying that at Circle, they're signing… with the hot wallet, something like 2 to the 17… Transaction per day? Daniel, do you mind speaking, or do you prefer chat?

Daniel Cason: Yeah, I guess I'll also speak, yes. We are doing between 30,000 and 70,000. Per day. So let's pick, like, 2 to 18, or 2 to the 17. the day. So, we… yeah, we have three questions, actually. So, the first one regards the state. You mentioned in the chat that there is no stateless solution that works at the moment, so you…

Antonio Sanso: Aventus.

Daniel Cason: state.

Antonio Sanso: the things, like, there's no real… I mean, stateless… real, real stateless doesn't exist. Like, I mean, the SPHINCS is 2 to the 64 that is practically stateless, but it is not. I mean, 264 is a big number, right? But… It is stateless, but not really stateless in terms of, like, a limited… there is a limited 2 to the 64 that is practically stateless, basically, right? Yes.

Daniel Cason: Yeah, the second question is, yeah, it's this number, so how often the rotation, you say that's 2 to 64, so I think we have several years to… before a rotation, so it should not be the problem. But I saw some of the presentations proposing something that is closer, like 2 to 20-something, right? In this case, you have to… Probably rotate, I don't know, a couple of times a year.

Antonio Sanso: Yes, yes. I mean, that's why we have these kind of calls, actually, to understand what is, like, the situation in the field. Will it be a problem for you to rotate?

Matteo Vicari: Can I add something about this? Because also, we…

Antonio Sanso: Okay, one second, one second. One second, just… I will give you the word in one second. Just, like, to understand if for circle would be a problem of rotation. This is important.

Daniel Cason: Yeah, I have to confirm with them, I can check with you in person, but yeah, probably it's not, but we want to avoid to do that often. Let's put it into a way.

Antonio Sanso: Right. I think, like, the… Sirotation must, I mean, will be probably in, in, in, in your… in your life in the future, if we… if we go… I mean, even if we go for 2 to 32, you… I mean, if we keep the links as they are. The key rotation must be near a toolchain, somehow. Yeah, if you… is it fun if you investigate internally and… Maybe it says something back next time.

Daniel Cason: Sure, sure.

Antonio Sanso: Okay.

Matteo Vicari: Can I add something about this topic? Because we think, a lot about the mechanism of key rotation or other idea. We go, with this technique and this post-quantum signature to account abstraction, in case of frame or other case. So, if you, for example, you are circle, you are doing a lot of transactions every day, you can just bundle up and so you respond also the gas of all the system. So… I think the idea, the constraints is the number of the transaction you can do at the day is something, shifting, I think, because using frame Transaction can also allow you to bundle up the transaction in, in bundles, so you don't have to send a lot of the transactions together. You can send a lot of transactions together. So, I think, because also, if you say, okay, we do, 30K,

A lot of transactions every day. You have also say, okay, but how much faster we can sign, also. This is another, another thing, this important discussion. Because if, for example, we have to sign so much fast with SPHINCS, it can be a huge problem. Depends on the hardware, depends on the constraints, also in MPC can be a problem. So, why you don't think the bundle of the transaction can, help to reduce the number of, the transaction you have to sign a day?

Antonio Sanso: Right, I think it's a valid comment. I think it's a valid comment, and again, in my opinion, like, rotation… Will… will be… will be used by… by everyone to… people need to understand that this is going to be part of their life. Nico, is this, is the Euro Hands From before, or you are raising the hands again? Okay, from before. Cool.

Nico: No, I just wanted to say before doing the lifetime exploration, I reached out to 5 different exchanges that were the biggest nonces on Ethereum, like, the biggest active nonces. And all of them unanimously said that this was absolutely not a problem. These are automated scripts, obviously, and it's a Python script. Rotating the key. from all this infra is less than half a second of computational work every day or so. So nobody mentioned that this was a problem, because Basically, after a few million transactions, you should do it anyway, even in a ECDSA configuration. So… yeah, if you look on-chain, you have… you don't have accounts that are billions of… of signatures, and this was even before this was a requirement. So yeah, I do think if we take the…

user research approach. We don't find use cases where, there is a need to have Billions of signatures without rotating the key a single time. We can confirm again with Circle, but I assume that, like everyone else, they just have an automated script that signs. And that this script can rotate keys every… Few hours, if need be, but this would be every day with the parameters we are suggesting. So, to me, this is not really an issue, and we can obviously investigate, but yeah. I'm pretty confident that anything above 2 to the 22 or 2 to the 23 is more than enough.

Antonio Sanso: Daniel, you mentioned about precompile as well. Which precompile are you looking exactly for?

Daniel Cason: Yeah, I mentioned there is that we really would love to have a SPHINCS+ signature, stateless, and you can use a pure DF and a pure and a precompile. I know this is a lot to ask, but this is…

Antonio Sanso: Well, again, like, this has been presented before, but you have to imagine that, basically, for verification, you're not gonna… when you include the transaction in a block, there's not gonna be any more… so, you don't need to verify anymore the single transaction. So, the single signatures, but the signatures actually are going to be aggregated. So, there's not going to be such a thing as, like. verification of SPHINCS. You verify the zero-knowledge proof Of the aggregation of the SPHINCS. So that's why there's no precompile. There's no precompile, but it's not as well as solidity code for verification. It's just like that we rely heavily on aggregation. That's a real question?

Daniel Cason: I see, I see. I see, thank you.

Antonio Sanso: Cool. So, we have, like, 10 more minutes, so let me propose this for the next, for the next days, if you guys agree. Since there is no big difference between ML parameters and Matteo. I would propose, like, for next upgrade of the testnet, to include the one we see here, on sphincs.art, they're pretty much similar to the Matteo one, I don't see much difference, they're basically identical with With the lifetime being different. And, I will… I will start with the high lifetime for now. So, until we figure out the people in the field are doing. So we don't need to worry about the key rotation too much from the beginning. And, is anyone opposite about this proposal?

- alright. So… Anyone?

T. Wambsgans: And high would mean 2 to the… Like, which, lifetime?

Antonio Sanso: I will leave it for between 2 to the 30 and 2 to the 32 for now. I mean, we can always, you know, like… The difference in your parameter, if you're going to the 26 to the 30, it's really, like, 300 bytes. And even if you go to the 32, it's like, yeah, basically we're talking about foreign bats for the moment. So it's easy to go down, but… to go up will be more complicated. Matteo?

Matteo Vena: Yeah, I want… I wanted to clarify that, I don't know if that was maybe unclear from the presentation, but when we said 2 to the 24, it's specifically so we can make everything work, even in the testnet. For instance, if we want to continue trying and do SPHINCS-G signatures with a Ledger and OS that are fast and everything, we cannot push the… 2 to the 32 or anything like that. Preparing a slot in the construction that you know about would be extremely painful and long, and 2 to the 24th to 2 to the 32 at the MPC layer is, monstrous type of difference, like a make-or-break type of difference. So… Yeah, maybe that wasn't clear for the presentation, I don't know.

Antonio Sanso: Alright, a quick question. Do you know that, basically, like, with the… with the FORS that are included in sphincs.art. There is basically, like. H, so it's not, like, tied to the… to actually lifetime… So basically, like, if you see, like, H is 2 to 22, but the minimum lifetime is 2 to 26, because the FORS are pretty big. When you are saying this, like, do you take this into consideration as well?

Matteo Vicari: Yeah. We… we definitely take into the consideration. But the idea is always to try to keep the FORS, not so much big for any reason, because there is a lot of time to sign and precompute this lot are this part. And also, we can go with, a higher H. I think, going with higher H can be a problem for the grinding, so, we can go, a little up, but, no more than 2 to the 24, I think, on the grinding side.

Antonio Sanso: I think H 2 to the 24 is, like, 2 to the 28, because of this four… Because they're the FORS. Emile?

T. Wambsgans: Yeah, I'm not sure to follow, because even if, as you said, if you keep the same few-time signature, if you increase the H, typically on sphincs.art, if you take a lifetime of 2 to the 30, the H is 26. And as far as I understand, in MPC, for grinding, like, you… it's in plain text, so… and grinding to 26 on a laptop CPU is fine, like, it's 1 second or something. And then, yeah, there is the grinding for…

Matteo Vicari: Yeah.

T. Wambsgans: Guess…

Matteo Vicari: Yeah, yeah, the grinding for the Ledger can be the problem.

T. Wambsgans: Yeah, and… yeah, and then it's a trade-off between offline preprocessing, where you need to prepare more than one, or, like, you need to, I don't know, you need to reverse 16 or 32-time signature, so offline preprocessing would take, I don't know. 50 minutes or 30 minutes, but then once you have enough few-time signature prepared, You still get fast signing.

Antonio Sanso: Look, I think… I think that we go… if we go to 2 to the 28, And, it matched your 2 to the 24, basically. And, you know, if you open sphincs.art, there's as well a simulation as well of this SPHINCS-G on the Ledger Nano S. So… It looks like a good compromise to me, like, going for… For 2 to the 28, that is matching H 2 to 24. Matteo?

Matteo Vena: Yeah, I'm just trying to understand what is the benefit of the higher budget, really. Like,

Antonio Sanso: Why would we…

Matteo Vena: We go with a higher budget in general, not just specifically considering Ledger or any.

Antonio Sanso: rusty.

Matteo Vena: scientific.

Antonio Sanso: I mean, for the comment that was done today by Circle, to me, we'll look conservative to go for high budget.

Matteo Vena: But it doesn't… it doesn't make any difference. If you have a problem rotating. 2 to the 24, 2 to the 28, you still have to rotate eventually, you still have to build the system, you still have to prepare. And also, I think it's a very valid point that with frame transactions, you should have an immense benefit in just Operating your transactions better than ever, and so you should save a ton of signature budget just by doing so.

Antonio Sanso: Isabelle?

Matteo Vena: I mean, does it make any difference? If you have to prepare… so, 22-24, you build the system, but 2-28, you don't? It's kind of the same, but then it's worse for everybody else.

Antonio Sanso: Nico?

Nico: Yeah, I just wanted to say, I think it's important to stay on the… like, user DAS point of view. I agree that the lifetime at 2 to the 28… It's… or 2 to the 30, to me, it doesn't make sense. Like, we're not buying any user experience here. So yeah, I would agree to go to the lower lifetime. But also, I would like to keep in mind that we should Take a scheme that, works… Nicely on hardware, even without any technique. So if we go with uniform and 2 to the 30, the signature time is, 40 seconds. On sphincs.art. So, I would be more comfortable going with uniform. To the 26, where the signing time is 24 seconds.

So yeah, again, an argument in favor of reducing the lifetime.

Antonio Sanso: Okay, thanks, Nico. Justin?

Justin Drake: Yeah, I have several reasons for picking a big number in the short term. One is, as you said, Antonio, it's easier to go from a big number to a small number than the other way around. Another thing that Emile said is that, you know, the cognitive friction of explaining To users and to devs is lowered if the number is just… astronomically high. A billion is super easy to communicate and should appease many people. And then the other consideration is that I'm hoping that we can align with the broader, you know, ecosystem, with Bitcoin, with zcash, with, you know, many other blockchains, and, you know, Bitcoin is at 2 to the 40 right now, I could see them going to 2 to the 30. I think 2 to the 24 will… might be a hard sell for, you know, the ultra-conservative Bitcoiners.

Antonio Sanso: All right, cool. So, let's do it like this, since we are at time, I think we kind of agree almost on anything but the lifetime, so we can already get kind of going ahead. And, with this sphincs.art parameter, and figuring out the lifetime as a next step. Are you fine with this? Right, I think, like, a yes,

T. Wambsgans: Yeah.

Antonio Sanso: So we… Daniel will be really helpful, since Nico already did some homework and talked to some exchange, will be actually nice to hear from Circle, how you guys are, thinking to implement the rotation. And, yeah. Right. So, again, that's probably the… we have a plan, so downloading's open is the lifetime, the rest looks good. And I'm gonna… I hope by the next two weeks, we will have something in the testnet. That has the new parameters. And, in the meantime, we will figure out offline the lifetime.

T. Wambsgans: And just to be sure, just one last thing, to be sure to understand with… the main neck for you, like, if you increase H, you keep the same FORS, you increase H, you're not afraid of grinding in MPC, you're afraid of grinding with the Ledger. Is it correct?

Antonio Sanso: I think so. I mean, from what I understood, yes, because the MPC is fast. Matteo confirmed? The problem is the Ledger, but not the MPC, right?

Matteo Vicari: Yeah, the only problem is the Ledger, and also the anti-steering proof on the Ledger. So, in MPC, we don't need the old stuff, so we can just go faster, because we don't have allty stuff. To care about.

Alessandro Baiocchi: Of course, right? Of course, as long as, like, it is a reasonable number, like the ones we are discussing here, like, if it increases, by… To reach 26, 28 MPC should still be fine, although a bit slower, but the legacy sort of issue should be fine.

Antonio Sanso: Justin?

Justin Drake: One consideration is that for the proof of grinding for the hardware wallets, that's going to improve over time with SNARK technology improving. So we… in some sense, we're going to get 10 times more grinding over the next, let's say, 12 months. Which will help the hardware wallets really.

Antonio Sanso: Can you repeat why, Justin? I didn't get this point. Why you will have better grinding?

Justin Drake: So, the… there's two ways to do grinding in a hardware wallet. You can either do it internally, but you're very limited because the hardware wallet's very slow, or option B is to have a host, like a traditional laptop, let's say. that does grinding for you, they need to have a proof of grinding to make sure that you're not keeping in the grinding. So that's a SNARK that you communicate. The SNARK will be able to Do 10 times larger proof of grinding within the next, probably, 12 months.

Antonio Sanso: per point. All right, let's figure out the offline, the lifetime. The rest, I think we are all fine with the sphincs.art, because it's pretty similar to the presentation of Matteo. And we figure out the lifetime offline, and I think we're good to go. With this, I will kind of wrap the call of today. Thanks a lot to everyone, it was really productive, and thanks to the presenters, and see you in two weeks.

T. Wambsgans: Thank you, bye-bye.

Matteo Vena: Thank you, bye.

Alessandro Baiocchi: Thank you, to you.

Shaaibu Suleiman: Not surprised.

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