Hi,
Is there a timeline for the incorporation of threshold EdDSA signatures in a similar way to ECDSA signatures are currently supported in the IC?
Thanks.
Hi,
Is there a timeline for the incorporation of threshold EdDSA signatures in a similar way to ECDSA signatures are currently supported in the IC?
Thanks.
Hi @eugaia! We don’t have a concrete timeline for threshold EdDSA yet, it’s definitely on the wish list but we’re not actively working on this yet. Out of curiosity, do you have any specific plans of what you’d want to use tEdDSA for?
Hi @Manu. Thanks for your reply.
Yes, I plan to have wallet integrates with lots of other blockchains, including some that don’t use ECDSA but do use EdDSA.
Can you give a list of some EdDSA-only blockchains?
Here’s a list of the top 100 coins / tokens by market cap, compiled in Feb 2021.
http://ethanfast.com/top-crypto.html
There are some differences now because at least one of the chains have added ECDSA to their platforms now, but I don’t believe every chain has (yet).
Cardano added ECDSA and Schnorr signature support in Feb 2023.
Hi Manu, what is the timeline for Schnorr? This is more important for the Bitcoin ecosystem, as many of the Bitcoin tokens are now using Schnorr signatures.
Same as EdDSA, on the wishlist but not yet in progress so no clear timeline yet.
Could you elaborate on that? I didn’t really look into BRC-20 yet, is every token transfer there a new inscription (meaning you need schnorr to do transfers)?
That’s right. Every token transfer is a new inscription.
Double this.
L2 of Bitcoin wars coming, taproot aware and schnorr will help IC win it all.
First Ordinals and BRC, then RGB and others.
I think it is inevitable
You know, if the IC had a feature where each node could do its own private computation, it would probably be even possible for the community to implement new threshold signature schemes by incorporating existing libraries.
It would not even require too many changes to the protocol - just hacking the http outcalls feature. Allow nodes to combine the results of their custom resolvers instead of discarding them if they disagree; also allow them to store their own private variables, such as key-shares etc. This would enable users to write their own threshold signing schemes.
On a separate note, this would also help with making http outcalls more robust.
I know we would really like to have Schnorr signatures ASAP on the IC. Maybe a community call would help. @bob11 @Manu @dieter.sommer @neeboo ?
Thanks for the input, I’ll look into it in a bit more detail and see what we can do.
Could you elaborate on this? How could a modification to the HTTP outcalls allow for threshold schnorr?
To do custom signatures, we need to basically have a system where:
I think it would be better to have a generic framework that lets others build the key-signing if necessary. This would allow the community to prototype and develop the feature faster, as the community could leverage open-source libraries for key-signing such as GitHub - Trust-Machines/frost: Rust implementation of Flexible Round Optimized Schnorr Threshold signatures
I think this is a pretty drastic oversimplification :).
We have to leave it to you clever cryptographers :). We all are very excited about this feature and want to push it forward.
@Manu Has the topic of threshold EdDSA / Schnorr moved forward yet within Dfinity, or are they still just ‘for the future’?
Thanks.