-
Notifications
You must be signed in to change notification settings - Fork 37
blog post about frost threshold signatures #207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's our thoughts on blog posts written in first person?
Perhaps it'd make sense to title the blog something like:
Drop your phone into the ocean: Experimenting with a threshold signature scheme in iroh
To me this would help set up expectations.
That said, perhaps this blog post title should be more about the frosty
experiment itself? Given it goes into detail on what it does/how it runs.
Co-authored-by: Philipp Krüger <philipp.krueger1@gmail.com>
Co-authored-by: Philipp Krüger <philipp.krueger1@gmail.com>
Co-authored-by: Philipp Krüger <philipp.krueger1@gmail.com>
Co-authored-by: Philipp Krüger <philipp.krueger1@gmail.com>
# Conflicts: # src/app/blog/frost-threshold-signatures/page.mdx
|
||
I was vaguely aware that something like threshold signatures exist. This is - very roughly speaking - a scheme where you split the private key into multiple parts called *shares*, and need a certain number of these shares to sign a message. Since the shares never have to be in one place, this provides safety in case a single share gets compromised or lost. | ||
|
||
What I did not know however is that there exist threshold signature schemes such as FROST that work with Ed25519 such that generated signatures are *fully compatible* with normal Ed25519 signatures. So you can sign a message with a threshold signature scheme and then validate the signature as usual using the ed public key. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'd say that backwards compatibility is not really the "new" thing here. It's still true that it is surprising!
The reason for that is mostly that with FROST we have an MPC protocol to generate a signature, without having to reconstruct the secret anywhere.
The fact that that signature is ed25519-backwards-compatible was surprising to me.
But reconstructing secrets to sign stuff in essentially a backwards-compatible way was done since shamir secret sharing was invented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't claim that this is new, just that I did not know it... Probably hard to believe, but I also did not know about shamir secret sharing. However, given the fact that it requires you to collect shares in one place I don't find it that useful for this use case.
WDYT, just add a sentence namedropping shamir secret sharing and call it a day?
Compared to Shamir Secret Sharing, the FROST scheme does not require shares to be in one place to sign.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great.
There's two paragraphs where I have some nits on correctness, and otherwise only some typos that I found.
I'm leaving it up to you to resolve these things ✌️
Todo: